**Important** Migration guide Scala Actors -> Lift Actors

[David Pollak]

Folks,

I wrote a quick blog piece about migrating from Scala Actors to Lift Actors at http://blog.lostlake.org/index.php?/archives/96-Migrating-from-Scala-Actors-to-Lift-Actors.html

I hope this addresses questions that folks on the list have about the affirmative steps they need to take to make the migration.

Thanks,

David

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

[TylerWeir]

Stickied for now, until we think it's no longer an issue.

On Oct 22, 2:57 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Folks,
>
> I wrote a quick blog piece about migrating from Scala Actors to Lift Actors

> athttp://blog.lostlake.org/index.php?/archives/96-Migrating-from-Scala-...

>
> I hope this addresses questions that folks on the list have about the
> affirmative steps they need to take to make the migration.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Dano]

Thanks to David for the migration guide. It is very useful.

Victor Klang had raised the issue of rescheduling the actor in the
message handling function (see below). I did not see a reference to
this in the migration guide. Is it still necessary?

Thanks in advance.


Dan

Text from Victor Klang on breaking change thread:

DPP (and I) recommend just doing schedule and then re-schedule after
message
recieved.
schedule(actor,MyMsg(),3 seconds)
in the actor
{
case MyMsg() => {
doMyStuff
schedule(this,MyMsg(),3 seconds)

[Marius]

Just Simple & Beautiful ! ... Nice work Dave and Jonas.

Br's,
Marius

On Oct 22, 9:57 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Folks,
>
> I wrote a quick blog piece about migrating from Scala Actors to Lift Actors

> athttp://blog.lostlake.org/index.php?/archives/96-Migrating-from-Scala-...

>
> I hope this addresses questions that folks on the list have about the
> affirmative steps they need to take to make the migration.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Heiko Seeberger]

One small step for Lift and Akka, one giant leap for Scala!

Thanks, David and Jonas!

Heiko

2009/10/22 Marius <marius...@gmail.com>

--
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

[glenn]

David,

I attempted to follow your blog piece and rewrite the code in
Integrating Flex, BlazeDS, and Scala/Lift, at http://flexonrails.net/?p=103.

Maybe I'm being a bit ambitious to redo this, but when I run just the
Lift portion (without Flex/BazeDS) and make a call to my LiftActor
implementation, nothing happens. Shouldn't the
messageHandler be called automatically (There is nothing to "start",
is there?). It doesn't when I trace through the code. What am I doing
wrong?

Here's my rewrite of Notifier using LiftActor:

class Notifier extends LiftActor{

val msgBroker = MessageBroker.getMessageBroker(null)
val clientID = UUIDUtils.createUUID()
val msg = new AsyncMessage()
var notificationsSent = 0;

val currentTime = new Date().getTime();


protected def messageHandler = {
case Notify =>{
msg.setDestination("notifications")
msg.setClientId(clientID)
msg.setTimestamp(currentTime)
msg.setBody(new Notification(notificationsSent, "Hello from
Scala/Lift", new Date()))
msgBroker.routeMessageToService(msg,null)
notificationsSent = 1

}

LAPinger.schedule(this, Notify, 500L)

}
}

case object Notify

class Notification(var id: Int, var message: String, var timesent:
Date){
def getId = id
def setId(id: Int) = this.id = id
def getMessage = message
def setMessage(m: String) = message = m
def getTimesent = timesent
def setTimesent(t: Date) = timesent = t

}


I also have an XMLApiHelper with:

def dispatch: LiftRules.DispatchPF = {
case Req("webservices" :: c :: Nil, "", GetRequest)=> () =>
start_feed(c:String)

and start_feed simply calls new Notifiier().

Given this code, the URL: http://localhost:8080/webservices/Notify
successfully calls into
start_feed and creates Notifier but the messageHandler isn't called.

Any help is appreciated?

Thanks,

Glenn

On Oct 22, 10:57 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Folks,
>
> I wrote a quick blog piece about migrating from Scala Actors to Lift Actors

> athttp://blog.lostlake.org/index.php?/archives/96-Migrating-from-Scala-...

>
> I hope this addresses questions that folks on the list have about the
> affirmative steps they need to take to make the migration.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[braver]

I have a simple question on migrating a typical PinS-desribed pattern:

def act() =
loop {
react {
case DoSomething => ...
case EXIT => exit()
}
}

-- now, without exit(), how does it terminate?

Cheers,
Alexy

[David Pollak]

Like any other object in the JVM... when the last reference to the Lift Actor is gone, the Lift Actor is garbage collected.  Lift Actors (like JVM objects) don't have a concept of "running".  They will always respond to messages sent to them.  They consume no system resources other than memory except when they are processing a message, then they will consume a thread out of the thread pool.
 

Cheers,
Alexy

--

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

Beginning Scala http://www.apress.com/book/view/1430219890

[Josh Suereth]

You mean you didn't implement your own GC on top of the JVM's GC?   Where's your sense of adventure...

[braver]

So what would be the scenario where you have two actors, one, the
reader, reading stdin, and sending to the other, the writer, which
then processes it line by line and writes stats? They're now started
in the main driver with start(), the reader, upon EOF, sends a special
EXIT message to the writer, then exits itself; the writer exits upon
receiving the EXIT, then the main thread exits too. The writer send a
"gimme" message to the reader every time it's ready to process, and
the reader send a line to writer then. If it has no line, it sends
EXIT.

I can create the Lift actors for reader and writer, and then they will
start themselves to work forever. How would I recreate the above
semantics to shut down on EOF?

Cheers,
Alexy

[David Pollak]

On Tue, Nov 17, 2009 at 11:04 AM, braver <deliv...@gmail.com> wrote:

So what would be the scenario where you have two actors, one, the
reader, reading stdin, and sending to the other, the writer, which
then processes it line by line and writes stats?  They're now started
in the main driver with start(), the reader, upon EOF, sends a special
EXIT message to the writer, then exits itself; the writer exits upon
receiving the EXIT, then the main thread exits too.  The writer send a
"gimme" message to the reader every time it's ready to process, and
the reader send a line to writer then.  If it has no line, it sends
EXIT.

Neither Lift Actors nor Scala Actors are meant for blocking IO.  So, reading in an Actor is just going to be pain.  You're a lot better off using a thread for reading and a separate thread for writing.

A writing thread should never ask for input... the input should always be put in a queue and consumed by the thread doing the writing.

I can create the Lift actors for reader and writer, and then they will
start themselves to work forever.  How would I recreate the above
semantics to shut down on EOF?

There's no such thing as "shut down" for Lift Actors.  They are like any other object in your JVM.  They respond to messages and when there are no more references to them, they get garbage collected.
 

Cheers,
Alexy

--

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

[braver]

On Nov 17, 2:26 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Neither Lift Actors nor Scala Actors are meant for blocking IO.  So, reading
> in an Actor is just going to be pain.  You're a lot better off using a
> thread for reading and a separate thread for writing.

My reading actor is simply slurping a Source, then it feeds the
writer.

> A writing thread should never ask for input... the input should always be
> put in a queue and consumed by the thread doing the writing.

Indeed, that was my original design. However I have millions of
lines, and in the case of a writer which inserts into a database, the
queue might get out of hand.

> > I can create the Lift actors for reader and writer, and then they will
> > start themselves to work forever.  How would I recreate the above
> > semantics to shut down on EOF?
>
> There's no such thing as "shut down" for Lift Actors.  They are like any
> other object in your JVM.  They respond to messages and when there are no
> more references to them, they get garbage collected.

So here's the crux of the question. If I just create them in the main
driver, the reader slurps all lines of the input and waits for gimme
messages, the writer does them all and waits for exit. How can I
declare them so they will be garbage collected?

Cheers,
Alexy

[braver]

On Nov 17, 2:26 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> There's no such thing as "shut down" for Lift Actors.  They are like any
> other object in your JVM.  They respond to messages and when there are no
> more references to them, they get garbage collected.

I'm probably belaboring the point or missing a koan, but that was
exactly my wonderment, as to where and how do I declare the reader and
writer as Lift actors in order for them to go out of scope when I
desire. I'll stick to my app even though it might not be ideal for
actors, to try to understand how and whether it can be done.

E.g.,

def main(...) {

val reader = new ReaderLiftActor(inputFileName,...)
val writer = new WriterLiftActor(...)

}

The reader slurps all lines in the input file and starts feeding the
writer, one my one, via message. Now what? OK, so I have to leave
scope. Would I do something like,

def main(...) {

var exit: Boolean = false

/* some scope prefix, like while (!exit) ? */ {
val reader = new ReaderLiftActor(inputFileName,...) // affects
exit?
val writer = new WriterLiftActor(...)
// some waiting?
} // end of scope

// yay! may go home
}

Is there an idiom in Lift to create the actors in scopes for the job,
then let them slip into the night?
Cheers,
Alexy

[David Pollak]

On Tue, Nov 17, 2009 at 12:34 PM, braver <deliv...@gmail.com> wrote:

On Nov 17, 2:26 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> There's no such thing as "shut down" for Lift Actors.  They are like any
> other object in your JVM.  They respond to messages and when there are no
> more references to them, they get garbage collected.

I'm probably belaboring the point or missing a koan, but that was
exactly my wonderment, as to where and how do I declare the reader and
writer as Lift actors in order for them to go out of scope when I
desire.

Just like any other object in your application.  Do you worry about a String or a Map or a List being garbage collected?  Does it matter?
 

 I'll stick to my app even though it might not be ideal for
actors, to try to understand how and whether it can be done.

E.g.,

def main(...) {

 val reader = new ReaderLiftActor(inputFileName,...)
 val writer = new WriterLiftActor(...)

}

The reader slurps all lines in the input file and starts feeding the
writer, one my one, via message.  Now what?  OK, so I have to leave
scope.  Would I do something like,

def main(...) {

 var exit: Boolean = false

 /* some scope prefix, like while (!exit) ? */ {
   val reader = new ReaderLiftActor(inputFileName,...) // affects
exit?
   val writer = new WriterLiftActor(...)
   // some waiting?
 } // end of scope

 // yay!  may go home
}

Is there an idiom in Lift to create the actors in scopes for the job,
then let them slip into the night?

Yes, the idiom is the same idiom that you use to create any other JVM object and let it slip into the night:

to create:
val obj = new Object

to slip into the night:

exit the scope of val obj and if the reference wasn't passed to and retained by any other object in the system, it will be garbage collected.

But as I've said, you should not use Actors (Scala or Lift) for IO.  If you want to do IO, use threads and use thread.join to wait until the thread has terminated.

Thanks,

David
 

Cheers,
Alexy

--

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