Looking for some suggestions on best way forward.

[Colin Bester]

Simplified, I have database -> RESTful servers -> LiftWeb (using lift-ng to add angular support).

With memcached running at RESTful server level (I may move this to LiftWeb level).                               

I am current using LiftWeb 2.6 but am planning to migrate towards end of year.

The system serves two client types; users and remote devices which can be managed via above site system and usage collection which is posted to RESTful server.

At the LiftWeb side, there are normal users and administrators. Angular, comet etc are being used between LiftWeb and Client to give user experience.

Now, if certain (but pretty limited) actions are performed by certain select administrators I would like to broadcast message to connected user session snippets as well as (maybe) the RESTful server to manage/clear caches. User session snippet would need to be able to 'broadcast' and subscribe to events (note I use word 'broadcast' very loosely here).

I am looking for suggestions on how to implement this messaging system and was thinking of Akka actors or maybe websockets.

So to finish off, while thanks to LiftWeb pushing data to client is easy, what is suggested (tried and true) method for publish/subcribe event message system.

Hope this makes sense.

Thanks

Colin

[Antonio Salazar Cardozo]

Do you need to do this across servers or just on one Lift server?

If just one Lift server, there's some `CometListener` stuff that's equipped to allow for simple

broadcasting needs within comets. If you're trying to go across Lift servers, the choices become

a little more complicated. I've seen both Akka and RabbitMQ used to do those kinds of interactions.

Akka might be easiest to get started with, but I'm not super-sure. The only one I've implemented

directly myself is RabbitMQ, which wasn't too too bad but did require some extra plumbing to

allow Lift to talk to Rabbit and vice versa.

Thanks,

Antonio

[Colin Bester]

I would like to go across servers. Plus I will be wanting to message from Lift system to Spray system so akka or rabbitmq may be best. I have used akka in the past so may mock this up and see how it goes. 

I will also look at RabbitMQ. I've heard of it but never used it.

Appreciate you getting back to me.

Colin

[Colin Bester]

Challenge is going to be to manage and shutdown any liftweb snippet subscriptions.

[Matt Farmer]

I don't know what your timeline on this is, but Kafka might also be a good fit for what you're trying to do. I've been playing with the idea of a Lift Actor that is backed by a Kafka topic recently. Haven't pushed much concrete code yet, but it's been percolating for a bit. If you think that would sound useful, let me know.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

---
You received this message because you are subscribed to the Google Groups "Lift" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joe Barnes]

I was think the same thing: kafka. It's a well thought out solution to events that I would argue is fundamentally a better design than either akka or RabbitMQ. I've found developers can grasp the fundamental concepts rather quickly. It can be pretty challenging on the ops side, tho. Generally that's where the friction is for Kafka.

I'd agree with other statements that akka is probably the easiest way to get there. But even there, you will have some ops challenges because it could make your servers more tightly coupled regarding rolling out code changes (main thing is to NOT use java serialization). Then there's the whole thing where I think akka is terrible, but that's besides the point.

Also keep in mind that using akka will force you to stick to the JVM for every component of your system. Kafka will allow you to integrate other technologies. 

Joe

[Colin Bester]

Thanks to all. I will look into Kafka, sounds interesting. 

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "Lift" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/liftweb/xwTFKLal1ko/unsubscribe.
To unsubscribe from this group and all its topics, send an email to liftweb+u...@googlegroups.com.

[Colin Bester]

Hi Matt, was wonder if you managed to get any further with your idea of Lift Actor backed by Kafka topic. 

If you have any code pushed I'd love to take a look and see what I can come up with.

~Colin

[Diego Medina]

I just read this. At work we have something similar, minus the memcached part. To communicate across servers, we use rabbitmq, this module https://github.com/liftmodules/amqp and a modified version of 

https://github.com/lift/framework/blob/master/web/webkit/src/main/scala/net/liftweb/http/NamedCometActorTrait.scala (and related traits/ classes)

post explaining how they work (what made it to lift has different names but the main idea is the same) https://blog.fmpwizard.com/2011/09/10/lift-comet-actor-per-tab-library/

Our snippet "subscriptions" are along the lines of, we have a chat widget with a list of users who have access to the current page (each page points to a particular document, so one user could be on several documents/tabs), when a user on any of the web servers logs out of our site, we use all the plumbing to update any document that has any users on it, which also had the user who just left the site, so the status of the user is changed to offline. I think this is close to what you are describing.

I haven't used memcached so I don't know how you update it, but I imagine you can send a special request from the lift server where the admin initiated the request and then update the cache.

This setup has been running on production for over 4 years

Hope that helps.

Diego

To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Diego Medina
Lift/Scala Consultant
di...@fmpwizard.com
https://blog.fmpwizard.com/

[Matt Farmer]

Hey Colin,

Sorry, life got the better of me and I haven't had time to do much with it. I'm angling to get something on this front done for the Lift 3.2 release at the end of the year. It probably won't be a part of the Framework proper at this point, but rather an addon module.

I may be able to open source some stuff from work soon that you'll find interesting, but no promises.

I will point out that Kafka's default API is pretty nice altogether.

Sorry I don't have more for you.

[Colin Bester]

Thanks Diego, looking into this now.

[Colin Bester]

No ways I am going to cast stones :-), I fully understand. I am most probably going to use Kafka as it meets most of my needs. Together with LiftActors and CometActors I think I can get what I want. Still going a little in circles due to not finding much documentation but pushing forward.