CometActor lifetime, events, and caching

[Tom MacGahan]

Hello friends,

I am trying to get my head straight on what the Right Way to use comet actors is, and what options are available to me to discern changes in serverside state, how to make cache consistent, and so forth.  To this end, I will ask a few specific questions:

1) Are there any inbuilt messages which a lift app will send to comet actors for any reason other than my explicitly sending them?

2) How, in broad strokes, might you solve the problem of, say, detecting a change on the host's filesystem and pushing that notification to a page through your comet actor?

3) When does a cometactor come into existence?

4) What happens if I send it a message before render has been called?

5) What happens if I do a partial update from an existing comet actor, but my client doesn't actually have the page to which it corresponds open at the time the partial update is pushed? What happens when they subsequently return to that page?

Thanks for all your time and answering my ignorant questions.

Best,

-Tom

[Matt Farmer]

Hi Tom,

The answers that I have are inline.

—
Matt Farmer | Blog | Twitter

On Aug 21, 2015, at 9:47 PM, Tom MacGahan <wending...@gmail.com> wrote:

Hello friends,

I am trying to get my head straight on what the Right Way to use comet actors is, and what options are available to me to discern changes in serverside state, how to make cache consistent, and so forth.  To this end, I will ask a few specific questions:

1) Are there any inbuilt messages which a lift app will send to comet actors for any reason other than my explicitly sending them?

Yes. That’s the reason your message handler you define for the comet is named lowPriority. There’s also mediumPriority and highPriority, the last of which executes before Lift’s internal handling. If you want to see things break in fun ways define a highPriority message handler with a catch-all case. ;)

2) How, in broad strokes, might you solve the problem of, say, detecting a change on the host's filesystem and pushing that notification to a page through your comet actor?

My first stroke solution would be to define a standard LiftActor that sends itself a CheckForChanges message that checks for changes. If changes are found, it would iterate over all the active sessions in Lift and send a notification of the update to the appropriate comet in each session. The retrieval of sessions is required because LiftActors don’t exists within a particular user session and CometActors do.

There’s probably a better solution that leans on the OS to tell us when something changes, but that’s the first blush.

3) When does a cometactor come into existence?

During rendering when the view processor runs across a data-lift=“comet?…” somewhere in your HTML or when you send it a message. (These two things may actually be the same under the hood… I haven’t looked at that implementation in awhile. But you get the gist.)

4) What happens if I send it a message before render has been called?

The message handler handles the message like any other actor would.

5) What happens if I do a partial update from an existing comet actor, but my client doesn't actually have the page to which it corresponds open at the time the partial update is pushed? What happens when they subsequently return to that page?

I think the answer here is nothing in both cases.

There is handling for the case that a connection is intermittent. So if a user’s connection is going in and out but they’re not leaving the page – when the connection comes back they’ll get every message they missed. There is probably a way to do this even if they willingly leave the page, but I’ve never had need of it.

Normally what I do in cases like that is build my render method based on some internal state of the Comet. When that state changes I may push data to the client, but I set  render is up such that when it is invoked again it renders things in the current state.

Thanks for all your time and answering my ignorant questions.

Best,

-Tom

--
--
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.

[Diego Medina]

2) How, in broad strokes, might you solve the problem of, say, detecting a change on the host's filesystem and pushing that notification to a page through your comet actor?

Matt's answers were spot on, I just wanted to give more info on this one.

Instead of having an actor that checks for changes, I would have a separate application that monitors for changes, doesn't have to be written in Scala, and once it detects a change, it can send the information to a rest api that is served by your Lift application. Then Lift takes over and sends a message to your comet actors.

And to know which comet actor should get the message(s), maybe this series of videos would give you an idea:

http://blog.fmpwizard.com/blog/comet-actors-presentation

It was written for Lift 2.5, but works the same way on 2.6, it describes one pattern to keep track of comet actors across sessions.

Regarding *how* to monitor for file changes, you'll find plenty of options searching online, I personally have been using Go for command line app for over a year now so I would use 

https://github.com/go-fsnotify/fsnotify

Here is an older post that describes the idea of using a REST api to receive data as json, and then passes it to comet actors 

http://blog.fmpwizard.com/blog/lift-comet-and-a-rest-api (that blog post inspired the code for the code that is now in Lift for CometDispatchers, etc)

Hope that helps.

Diego

 

Best,

-Tom

--
--
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.

--

Diego Medina
Lift/Scala consultant
di...@fmpwizard.com
http://blog.fmpwizard.com/

[Tom MacGahan]

Thanks folks, this really helps.  I appreciate your taking the time to answer these.