[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
On Tue, Nov 17, 2009 at 11:04 AM, braver delivera...@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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- 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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
On Tue, Nov 17, 2009 at 12:34 PM, braver delivera...@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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
--
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
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
You mean you didn't implement your own GC on top of the JVM's GC? Where's
your sense of adventure...
On Mon, Nov 16, 2009 at 1:35 AM, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Sun, Nov 15, 2009 at 10:29 PM, braver delivera...@gmail.com wrote:
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?
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
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
On Sun, Nov 15, 2009 at 10:29 PM, braver delivera...@gmail.com wrote:
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?
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
Follow me: http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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
Follow me:http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
One small step for Lift and Akka, one giant leap for Scala! Thanks, David and Jonas! Heiko 2009/10/22 Marius marius.dan...@gmail.com 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 Follow me:http://twitter.com/dpp Surf the harmonics -- 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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)
}
}
On Oct 22, 12:14 pm, TylerWeir tyler.w...@gmail.com wrote:
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
Follow me:http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: **Important** Migration guide Scala Actors - Lift Actors
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 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
