Lift Remote Actors

[Jack Widman]

Can I use Lift Actors as remote actors, node to node? Or do I have to
use Akka? Are there other, typically Lifty ways to initiate a process
on another node?

Thanks.

[David Pollak]

Lift Actors do not support remoting.  I'd suggest remoting via message queues, but not ActiveMQ (see http://goodstuff.im/activemq-not-ready-for-prime-time ).

--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Lift, the simply functional web framework http://liftweb.net

Simply Lift http://simply.liftweb.net
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Peter Brant]

I don't know what your use case is, but you might want to consider a
RESTful call into the remote server too. Lift (and lift-json) make
this really, really easy. We started with Akka, but realized it was
just additional complexity that we didn't need and it didn't help with
some things we did need (for example, serialization). 1.0 has an
annoyingly promiscuous POM too. I think this is fixed in 1.1 (along
with a remote actor shutdown bug we ran into). We ended up with
REST+JSON with lift-json for the Scala clients and Jackson for the
Java clients.

Pete

[Timothy Perrett]

You can use Akka and Lift together without too much difficulty, but it depends on your use case IMO. What specifically do you want to achieve with the inter-node communication? 

Cheers, Tim

[Jack Widman]

Sorry not to reply sooner to everybody's reply. My company launched on
Wednedsay and its been hectic.

The use case I am considering is this. I have a system that processes
a piece of text and produces categories out of it. It is a bit memory
intensive and for this and other reasons I want to run this whole
system on another machine. So what I need to do is , from my main
jetty with Lift server, send a small piece of text to a process that
is aways running on that other machine and have the text processed. I
could simply send it by http. In that case, what is a good way to run
the scala code on the other server as a service and make sure it
always running?

Thanks in advance.

[Timothy Perrett]

How intensive is this text processing? Do the text strings fit in memory or is it something you need to read from disk? 

Additionally, is it at all business critical? That is to say, how bad would things be if you didn't get a response? I think this would impact your choice here somewhat in terms of using say, RabbitMQ, Akka Remoting or HTTP etc... if you dont really care too much, then it should be fine to use a HTTP service, for which you could just implement that with Lift again on the second node, but use DispatchPF to make a REST service. 

Cheers, Tim

[Jack Widman]

The text processing is pretty intensive and likely will get more
intensive. I can fit in memory, but I prefer an entire node/set of
nodes dedicated to is so as not to affect the rest of the apps server
functionality. A response is critical though, its probably acceptable
to save the text sent from the main jetty server and then make sure it
is processed say, sometime in the next 10 or 15 minutes with retries
when necessary. (Though immediately would be better). Basically the
output of the process is a set of additional categories which future
and past posts are categorized under.

[Timothy Perrett]

If its critical to get a response, use something like AMQP to be sure the message got delivered. Thats not to say the protobuf remoting used by Akka or HTTP wouldn't suffice, rather, it sounds like you need to be sure that the messages were delivered (even through a crash) and for that I'd perhaps want more insurance than those protocols provide.

So, perhaps consider a backend based on Akka AMQP and simply have a backend of servers that subscribe to a particular channel in the rabbit exchange? I'm not sure on your use case but you could then have different backend servers listening for different types of message so if you need to split workloads etc you could do that too. 

Just spit balling. 

Cheers, Tim

[David Pollak]

Depending on the volume of "jobs" you need to send, using a durable message queue or using a database for queuing up the work is half the equation.  The other half of the equation is having enough workers pulling jobs off the queue and performing the work.

If you have a small number of jobs being queued (< 10 per second), doing it with a relational database is probably the best bet.  RDBMS are tremendously durable and you've likely already got one set up.

If you've got a lot of jobs, the transactional nature of the RDBMS gets in your way and a message queue is a better bet.  But getting durability and transactionality out of a MQ is non-trivial and the cost of getting the configuration right probably outweighs the value for low volumes.

On the "job runner" side of the equation, you have a set on N boxes that "pull" jobs from the queue and run the jobs.  If you're using an RDBMS for a queue, then you can update job status periodically in the row that represents that job.  If you're using an MQ, then you send out heartbeat messages.  In either case, there's another process that looks for "stuck" jobs (ones that have not been updated or heart-beated in 1 minute) and re-queues those jobs.

Hope this gives you some direction.

--
You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.