lift and background processing

[Rogelio]

Hi,

New to the forum and new to Scala/Lift. In a previous Ruby Rails
project, I needed to
generate some PDF files on the fly in response to a user clicking a
link. For that, I
passed the task off the a worker with BackgroundRb so that the mongrel
instance would
not be tied up for a long time. I then used Ajax calls to update the
user's webpage when
the pdf was ready.

I'm considering Scala/Lift for my next project but am unclear how
something like this
would be done. I've read about Actors and concurrency but the
examples I've seen have
been for passing simple message (stock quotes or something) and not
for starting a
long running process like connecting to a MySQL DB and generating a
PDF report.
Should I even be looking at Actors for this? Is Comet that is
integrated into Lift a
possibility?

Basically, how does something (not necessarily PDF generation, but any
long running
process that user could request) like this get done with Lift/Scala?
I'm thinking I would have to
have Scala use the IText pdf library perhaps. I don't need to have
thousands of
background threads generating PDFs, but it should be able to handle
say 50 before
it starts queueing up the PDF requests (ie, I don't want a simple
first in first out as that
could take to long for the user to get results).

Thanks for you advice and patience with newbie questions.

Rogelio

[David Pollak]

I think Tim has an app that does exactly this.  He uses Actors.  Perhaps he'll be able to share code.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Timothy Perrett]

I do indeed have a system like this - unfortunately there is no way I can
share the code (corporate rules and its highly specific for our
environment).

Essentially I have a bunch of Actors that co-operate to get the jobs done -
I have a "master" actor that handles all the queuing etc then it dishes
tasks out to subscribed workers which in turn have runner actors so that the
worker manager (as it were) doest block and can still receive messages.

Essentially I do some server side management to check on my currently in
process jobs and then update the client when something relevant (to them)
changes by using a comet actor.

Hope that helps, and good luck with your application.

Cheers, Tim

[David Pollak]

Howdy,

Here's an example of using an actor to do background processing and redirecting a browser to the result when it's been calculated.

Thanks,

David

On Wed, Apr 22, 2009 at 1:38 PM, Rogelio <rogb...@gmail.com> wrote:

[Timothy Perrett]

Nice example David - very illustrative for newbies :)

Just wondering if having somthing like this in either sites or sites/
example is worthwhile?

Cheers, Tim

On Apr 29, 1:15 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

[David Pollak]

On Tue, Apr 28, 2009 at 5:21 PM, Timothy Perrett <tim...@getintheloop.eu> wrote:

Nice example David - very illustrative for newbies :)

Just wondering if having somthing like this in either sites or sites/
example is worthwhile?

I'm going to roll some of the recent examples into sites/example
 

Cheers, Tim

On Apr 29, 1:15 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Howdy,
>
> Here's an example of using an actor to do background processing and
> redirecting a browser to the result when it's been calculated.
>
> Thanks,
>
> David