Should Scala's native actors library be marked obsolete.

Wowa .. sheath your sword their D'Artagnan.  I don't think they were abandoned as some major work was certainly done on them for 2.8.  As far as full of memory leaks, I use Scala's actors.  In one particular case I have a "clock" Actor which in turn sends periodic events to other actors.  The periodicity is such I have actors reactively responding on events firing in the seconds range.  My servers are up for weeks at a time under load.  I am unaware of any current memory leak issues.
I don't grok "full of runtime exceptions".   So I'll just whiff a red cape on that one as it goes by.
Bad documentation.  Well certainly the documentation is "terse" and think the wold certainly could use a "booklet" with examples patterns and use cases on using Scala Actors.  
Interesting and a positive sign that you view the Collections library as clean.  There is a different group of sword swinging, pick fork and torch carriers that hold regular chant session on how the new Collections library was essentially an act of language suicide.  Really?
Nothing is perfect, but the vast majority of Collection/Actor mud slinging is frustration from a lack of understanding and to the difficulty in grasping the reactive asynch'ness of actors and how to apply those concepts to algorithms which most programmers have spent their careers studying, hacking and solving using imperative code.

On Sat, Jan 15, 2011 at 11:11 AM, Sadek Drobi <sadek.drobi@gmail.com> wrote:

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA.  Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?
I really think we should either fix it, or replace it.
Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

We can be objective about this...http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&status=reopened&component=Standard+Library&summary=%7Eactor&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=component&order=priority
That's not a particularly long list (and a couple of them aren't about actors).
I think one of the big issues with Scala Actors is that they use a ton of abstraction it can be difficult to distinguish among bugs in user code, incorrect configuration, intentional design limitations, and bugs in the library.  This is confounded by the fact that barrier to initial usage of Scala actors is roughly zero (hence it attracts a lot of idle exploration - not a bad thing), concurrent code is fundamentally difficult even with actors (but people often mistake them for magic), Scala actors can be used with zero configuration (so it's not obvious that a "bug" may be due to misconfiguring the scheduler), and the design limitations are mostly undocumented.
In short, I think people can very quickly run through the first few phases of the hype cycle and get stuck in the trough of disillusionment when the magic fades and they start experiencing issues.
I also suspect the library is suffering from a degree of abandonment by serious users, now that Lift has its own lightweight actors and Akka is around for people who are prepared to go to a little more effort to get things setup and introduce some more dependencies.

i heard rumors about such people. what are they thinking? they should be
forced to use only java collections for a week!

Am 15.01.2011 18:06, schrieb Ray Racine:
> Interesting and a positive sign that you view the Collections library
> as clean. There is a different group of sword swinging, pick fork and
> torch carriers that hold regular chant session on how the new
> Collections library was essentially an act of language suicide.

My suggestion: when you find a memory leak or runtime exception that you're sure is a bug, file a ticket or post a specific stack trace here. If the library is in fact so buggy (which I doubt), the maintainers are not aware of this.
Donna

On Sat, Jan 15, 2011 at 5:11 PM, Sadek Drobi <sadek.drobi@gmail.com> wrote:

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA.  Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?

Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

David.


2011/1/15 Sadek Drobi <sadek.drobi@gmail.com>

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA.  Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?
I really think we should either fix it, or replace it.
Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

On Mon, Jan 17, 2011 at 2:16 PM, David Crosson <crosson.david@gmail.com> wrote:

Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

No, that's currently not possible. They have different philosophies in certain areas, please see this comparison between 4 different actor implementations for Scala: http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared
 

David.


2011/1/15 Sadek Drobi <sadek.drobi@gmail.com>

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA.  Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?
I really think we should either fix it, or replace it.
Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}
(at least I think I got that right).   Basically, this actor changes its 'handler' message based on what messages it has recently received.  After receiving a Push message, it looks in its queue for the first pop and replies to that with the data from the push method.  
In any case, you can see why nested messages can be considered dangerous.  If you have some sort of race condition such that the nested messages do not show up as expected, an Actor can fill up its queues quickly.  Akka specifically disallows this usage to prevent that type of bug (and to improve its own performance).  Scala actors enabled it but the onus is on you the developer to ensure a correct program.
** The second thing the standard library does is allow actors to send messages to 'threads'.  That is, if I have the following actor:
val replies = actor {   react {      case x => reply(x)  }}
And I write the following code *not* within an actor:   replies ! "somemsg"    The response goes to an actor.   However since I sent the message not from any particular actor, the message is placed into a thread-local actor for the thread where 'replies ! "somemsg"' was called.  This ThreadLocal can be used to obtain replies and such.  However, ThreadLocals are prone to memory leaks, and the Scala core library defines its own actor garbage collector to try to clean these actors.   Ideally, the number of these thread locals should be small in a program, however for certain programs it may be large and the performance of this new GC becomes a factor you need to tune and tweak.
My normal "scala core actor" application usually has just a single thread that's sending messages into actors, so this is not a big issue, but it is an additional layer of complexity one must worry about.  The alternative here is to require users to assign an actor to handle responses for every call.  The Scala actors library went for 'very expressive' here.  
So basically, there are a few 'rough edges' to the library, where rough means one must be cautious when using these features.   The library itself is very expressive and easy to use, so it's somewhat deceptive to users that these issues could be lingering in the corners.   It's also not something once can pin on the library, besides saying that it's 'too expressive' or 'too unrestricted'.
IMHO, the scala actors library is create for small-medium sized projects.  The remote/distribution story wasn't the best the last time I tried, so I'd used Akka for any large system, but I'd also say that the core library actors serve a purpose.
I hope that perspective helps.  As stated before, the onus is on the user to wield the power correctly.   
On Mon, Jan 17, 2011 at 8:39 AM, √iktor Klang <viktor.klang@gmail.com> wrote:

On Mon, Jan 17, 2011 at 2:16 PM, David Crosson <crosson.david@gmail.com> wrote:

Didn't agree with you at all, I'm quite new to both scala and actors API.

I've just finished a complex distributed algorithm using scala actors, more than 65000 actors in a typical session, and it runs fine with very good performances (I couldn't believe it first). But of course, I had to manage well the messages flows between actors in order to avoid memory leak.

About Akka, looks very insteresting, but don't know if it is possible to just use standard scala actors API, and using external configuration (parameters) change transparently the implementation to use akka instead of scala default one ? Of course, without having to recompile my application.

No, that's currently not possible. They have different philosophies in certain areas, please see this comparison between 4 different actor implementations for Scala: http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared
 

David.


2011/1/15 Sadek Drobi <sadek.drobi@gmail.com>

It surprises me the contrast between how clean the Collections library is, and how buggy the Actors library currently is. Full of memory leaks, runtime exceptions, bad documentation. And each time I mention this someone would suggest that I use AKKA.  Two problems there:If scala native Actors is abandoned, then removing it is better than letting people go in mud when discovering all the memory leaks.If AKKA is the way to go, why not integrate it into the distribution?
I really think we should either fix it, or replace it.
Sadek

--
www.sadekdrobi.com
ʎdoɹʇuǝ

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: viktor.klang@gmail.com
CC: crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}

Makes sense to me.  If you say "Pop" you mean, "give me the next available item".  If none are available you won't hear back around until someone sends it a Push.  (That's presumably what you'd want from an actor-based queue anyway, isn't it?)

I think it's quite ingenious, actually, to play with the message buffer that way.

  --Rex

On Mon, Jan 17, 2011 at 1:16 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: viktor.klang@gmail.com
CC: crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}

If you say so: I'd expect that popping an element off an empty queue gave me nothing: I would expect to have to poll if I was prepared to wait. That's just the Java speaking I suppose.
Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>
Chris

Date: Mon, 17 Jan 2011 13:33:21 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
From: ichoran@gmail.com
To: oxbow_lakes@hotmail.com
CC: scala-user@listes.epfl.ch

Makes sense to me.  If you say "Pop" you mean, "give me the next available item".  If none are available you won't hear back around until someone sends it a Push.  (That's presumably what you'd want from an actor-based queue anyway, isn't it?)

I think it's quite ingenious, actually, to play with the message buffer that way.

  --Rex

On Mon, Jan 17, 2011 at 1:37 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Maybe I meant elegant; it's a code snippet that in hindsight is obvious, but my first instinct to create a non-blocking queue would not have gone that way.  I probably would have thought of some sort of polling solution which would be more effort and probably less efficient.  It also nicely shows off the power of nested react statements (in that you have a queue of futures for free, and also highlights that consuming only part of the mailbox can be useful).

  --Rex

@Chris - The code is not correct, however you are right.  I should have made the message be "Poll" instead of "Pop".  I also agree with you that you're using a queue to reimplement a queue.  However, it does give a different style of operation, in that you can make the call to Pop/Poll be asynchronous and non-blocking of the current thread.   *that* is the innovative part and the key reason to use actors (if your problem can be model as such).
This simple example shows the power of the standard actors library.  That was the point.  My other point was that it's somewhat easy to create a situation where a message queue will fill up and not be processed, especially if things get complex.  This gives the appearance of the Scala actors library being more flawed than it is.   
The biggest concern I have with the actors library is that of configurability for production.  I believe the library has lots of abstraction points where I can do what I need to do to make it perform as optimital as its design allows, however these are not well documented, nor is it intuitive what needs to be configured.   For example, GC configuration is critical in any large-scale JVM deployment.  This means we need to configure the ActorsGC and the GC for optimal performance with each other.  I'd say that actors library is tuned for most situations you'd run at it.   However, as stated before, if I was doing a large-scale system I'd probably use Akka, as its designed is focused on this use case.  Its configuration is well documented, and there is a performance edge because they do not allow nested messages.
Again, the point being that you can express more powerful concepts in Scala's actors library, but you must be careful with that power.

On Mon, Jan 17, 2011 at 2:16 PM, Rex Kerr <ichoran@gmail.com> wrote:

On Mon, Jan 17, 2011 at 1:37 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Anyway, it's only ingenious until you realize that it acts like a queue because, um, the underlying mailbox is a queue. "How to implement a queue given a queue" is not the most complicated programming problem ever solved. </sarcasm>

Maybe I meant elegant; it's a code snippet that in hindsight is obvious, but my first instinct to create a non-blocking queue would not have gone that way.  I probably would have thought of some sort of polling solution which would be more effort and probably less efficient.  It also nicely shows off the power of nested react statements (in that you have a queue of futures for free, and also highlights that consuming only part of the mailbox can be useful).

  --Rex

I'd be interested to see a blog entry about configuring the scala actors library (and tuning for GC etc) as you are right; there is little or no documentation on it.

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 17:23:10 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: ichoran@gmail.com
CC: oxbow_lakes@hotmail.com; scala-user@listes.epfl.ch

The biggest concern I have with the actors library is that of configurability for production.  I believe the library has lots of abstraction points where I can do what I need to do to make it perform as optimital as its design allows, however these are not well documented, nor is it intuitive what needs to be configured.   For example, GC configuration is critical in any large-scale JVM deployment.  This means we need to configure the ActorsGC and the GC for optimal performance with each other.  I'd say that actors library is tuned for most situations you'd run at it.   However, as stated before, if I was doing a large-scale system I'd probably use Akka, as its designed is focused on this use case.  Its configuration is well documented, and there is a performance edge because they do not allow nested messages.

Actually, it can be used for synchronization algorithms in an interesting way:

case class Put(data: Any)
case object Get
actor {
  react {
    case Put(data) => react {
      case Get => reply(data)
    }
    case Get => val replyTo = sender; react {
      case Put(data) => replyTo ! data
    }
  }
}

A Stack can be written recursively:

case class Push(data: Any)
case object Pop
val stack = actor {
  def recurse(data: Any) {
    var popped = false
    loopWhile(!popped) {
      react {
        case Push(data) => recurse(data)
        case Pop => reply(data); popped = true
        case _ => // ignore
      }
    }
  }
  loop {
    react {
      case Push(data) => recurse(data)
    }
  }
}

It does not guarantee ordering when multiple clients are pushing/popping, but it does, otherwise, work.


On Mon, Jan 17, 2011 at 16:16, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: viktor.klang@gmail.com
CC: crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}

--
Daniel C. Sobral

I travel to the future all the time.

When I've used nesting it has been to implement an Actor as a state machine.  New State, different set of messages it will respond to or ignore.  Obviously any FSM beyond a simple sequencing falls apart with this approach.  But then again almost anything I attempted to do with an Actor is by definition a first time for me and an experimental approach and usage.    The standout example in my code has to to do with file polling / fetching / processing etc.

On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, it can be used for synchronization algorithms in an interesting way:

case class Put(data: Any)
case object Get
actor {
  react {
    case Put(data) => react {
      case Get => reply(data)
    }
    case Get => val replyTo = sender; react {
      case Put(data) => replyTo ! data
    }
  }
}

A Stack can be written recursively:

case class Push(data: Any)
case object Pop
val stack = actor {
  def recurse(data: Any) {
    var popped = false
    loopWhile(!popped) {
      react {
        case Push(data) => recurse(data)
        case Pop => reply(data); popped = true
        case _ => // ignore
      }
    }
  }
  loop {
    react {
      case Push(data) => recurse(data)
    }
  }
}

It does not guarantee ordering when multiple clients are pushing/popping, but it does, otherwise, work.


On Mon, Jan 17, 2011 at 16:16, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: viktor.klang@gmail.com
CC: crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}

--
Daniel C. Sobral

I travel to the future all the time.

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Akka has 'become' which hotswaps the message handler. IMHO cleaner way
than nested receives.
Docs here: http://doc.akka.io/actors-scala#Actors%20(Scala)-HotSwap

It can be used for f.e. building an FSM. See this example of Dining
Philosophers:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/...

Akka also has a FSM DSL. Here is the same problem solved using this the DSL:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/...

/Jonas

On 19 January 2011 16:26, Ray Racine wrote:
> When I've used nesting it has been to implement an Actor as a state machine.
>  New State, different set of messages it will respond to or ignore.
>  Obviously any FSM beyond a simple sequencing falls apart with this
> approach.  But then again almost anything I attempted to do with an Actor is
> by definition a first time for me and an experimental approach and usage.
>  The standout example in my code has to to do with file polling / fetching /
> processing etc.
>
> On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral wrote:
>>
>> Actually, it can be used for synchronization algorithms in an interesting
>> way:
>>
>> case class Put(data: Any)
>> case object Get
>> actor {
>>   react {
>>     case Put(data) => react {
>>       case Get => reply(data)
>>     }
>>     case Get => val replyTo = sender; react {
>>       case Put(data) => replyTo ! data
>>     }
>>   }
>> }
>>
>> A Stack can be written recursively:
>>
>> case class Push(data: Any)
>> case object Pop
>> val stack = actor {
>>   def recurse(data: Any) {
>>     var popped = false
>>     loopWhile(!popped) {
>>       react {
>>         case Push(data) => recurse(data)
>>         case Pop => reply(data); popped = true
>>         case _ => // ignore
>>       }
>>     }
>>   }
>>   loop {
>>     react {
>>       case Push(data) => recurse(data)
>>     }
>>   }
>> }
>>
>> It does not guarantee ordering when multiple clients are pushing/popping,
>> but it does, otherwise, work.
>>
>>
>> On Mon, Jan 17, 2011 at 16:16, Chris Marshall
>> wrote:
>>>
>>> That "queue" behaves very oddly if you call pop() before anyone has
>>> enqueued anything (al least in my opinion). Also you are missing a loop.
>>>
>>> ________________________________
>>> From: joshua.suereth@gmail.com
>>> Date: Mon, 17 Jan 2011 09:27:11 -0500
>>> Subject: Re: [scala-user] Should Scala's native actors library be marked
>>> obsolete.
>>> To: viktor.klang@gmail.com
>>> CC: crosson.david@gmail.com; sadek.drobi@gmail.com;
>>> scala-user@listes.epfl.ch
>>>
>>> To me, there are two things the scala core library does that make it both
>>> (1) scary and (2) powerful.
>>> ** The first is that is supports nested receive/react calls.  These can
>>> be used to create really interesting programs, such as Phillip Haller's
>>> example of a queue.
>>> actor {
>>>    react {
>>>      case Push(data) =>
>>>         react {
>>>            case Pop =>  reply(data)
>>>         }
>>>      }
>>>    }
>>> }
>>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>
>
> --
> The object of life is not to be on the side of the majority, but to escape
> finding oneself in the ranks of the insane. - Marcus Aurelius
>

what a nice example

can the states also be parameterized,
like become(readyFor(something))

in that case
I have this feeling that 'become' can be used
to elegantly implement 'spaces' as well
(and Dining Philosophers can be implemented using
a 'space' that is a 'table with chopsticks on it')

as in http://lucdup.blogspot.com/2009/08/scala-spaces-as-scala-actors.html

for example:

if a worker registers with the space for doing some work,
then the space kind of becomes ready for
processing any x for which work.isDefinedAt(x) = true 


just a thought


Luc

On Wed, Jan 19, 2011 at 9:31 PM, Jonas Bonér <lists@jonasboner.com> wrote:

Akka has 'become' which hotswaps the message handler. IMHO cleaner way
than nested receives.
Docs here: http://doc.akka.io/actors-scala#Actors%20(Scala)-HotSwap

It can be used for f.e. building an FSM. See this example of Dining
Philosophers:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnBecome.scala#

Akka also has a FSM DSL. Here is the same problem solved using this the DSL:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnFsm.scala#L1

/Jonas

On 19 January 2011 16:26, Ray Racine <ray.racine@gmail.com> wrote:
> When I've used nesting it has been to implement an Actor as a state machine.
>  New State, different set of messages it will respond to or ignore.
>  Obviously any FSM beyond a simple sequencing falls apart with this
> approach.  But then again almost anything I attempted to do with an Actor is
> by definition a first time for me and an experimental approach and usage.
>  The standout example in my code has to to do with file polling / fetching /
> processing etc.
>
> On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
>>
>> Actually, it can be used for synchronization algorithms in an interesting
>> way:
>>
>> case class Put(data: Any)
>> case object Get
>> actor {
>>   react {
>>     case Put(data) => react {
>>       case Get => reply(data)
>>     }
>>     case Get => val replyTo = sender; react {
>>       case Put(data) => replyTo ! data
>>     }
>>   }
>> }
>>
>> A Stack can be written recursively:
>>
>> case class Push(data: Any)
>> case object Pop
>> val stack = actor {
>>   def recurse(data: Any) {
>>     var popped = false
>>     loopWhile(!popped) {
>>       react {
>>         case Push(data) => recurse(data)
>>         case Pop => reply(data); popped = true
>>         case _ => // ignore
>>       }
>>     }
>>   }
>>   loop {
>>     react {
>>       case Push(data) => recurse(data)
>>     }
>>   }
>> }
>>
>> It does not guarantee ordering when multiple clients are pushing/popping,
>> but it does, otherwise, work.
>>
>>
>> On Mon, Jan 17, 2011 at 16:16, Chris Marshall <oxbow_lakes@hotmail.com>
>> wrote:
>>>
>>> That "queue" behaves very oddly if you call pop() before anyone has
>>> enqueued anything (al least in my opinion). Also you are missing a loop.
>>>
>>> ________________________________
>>> From: joshua.suereth@gmail.com
>>> Date: Mon, 17 Jan 2011 09:27:11 -0500
>>> Subject: Re: [scala-user] Should Scala's native actors library be marked
>>> obsolete.
>>> To: viktor.klang@gmail.com
>>> CC: crosson.david@gmail.com; sadek.drobi@gmail.com;
>>> scala-user@listes.epfl.ch
>>>
>>> To me, there are two things the scala core library does that make it both
>>> (1) scary and (2) powerful.
>>> ** The first is that is supports nested receive/react calls.  These can
>>> be used to create really interesting programs, such as Phillip Haller's
>>> example of a queue.
>>> actor {
>>>    react {
>>>      case Push(data) =>
>>>         react {
>>>            case Pop =>  reply(data)
>>>         }
>>>      }
>>>    }
>>> }
>>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>
>
> --
> The object of life is not to be on the side of the majority, but to escape
> finding oneself in the ranks of the insane. - Marcus Aurelius
>



--
Jonas Bonér

Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
blog: http://jonasboner.com
twtr: @jboner

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

hmmm..

I just spotted

def available: Receive = {
    case Take(hakker) =>
      become(takenBy(hakker))
      hakker ! Taken(self)
  }

so, yes, what I asked for seems possible,
and, I guess, implementing spaces as well


Luc

On Wed, Jan 19, 2011 at 10:05 PM, Luc Duponcheel <luc.duponcheel@gmail.com> wrote:

what a nice example

can the states also be parameterized,
like become(readyFor(something))

in that case
I have this feeling that 'become' can be used
to elegantly implement 'spaces' as well
(and Dining Philosophers can be implemented using
a 'space' that is a 'table with chopsticks on it')

as in http://lucdup.blogspot.com/2009/08/scala-spaces-as-scala-actors.html

for example:

if a worker registers with the space for doing some work,
then the space kind of becomes ready for
processing any x for which work.isDefinedAt(x) = true 


just a thought


Luc

On Wed, Jan 19, 2011 at 9:31 PM, Jonas Bonér <lists@jonasboner.com> wrote:

Akka has 'become' which hotswaps the message handler. IMHO cleaner way
than nested receives.
Docs here: http://doc.akka.io/actors-scala#Actors%20(Scala)-HotSwap

It can be used for f.e. building an FSM. See this example of Dining
Philosophers:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnBecome.scala#

Akka also has a FSM DSL. Here is the same problem solved using this the DSL:
https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/src/main/scala/DiningHakkersOnFsm.scala#L1

/Jonas

On 19 January 2011 16:26, Ray Racine <ray.racine@gmail.com> wrote:
> When I've used nesting it has been to implement an Actor as a state machine.
>  New State, different set of messages it will respond to or ignore.
>  Obviously any FSM beyond a simple sequencing falls apart with this
> approach.  But then again almost anything I attempted to do with an Actor is
> by definition a first time for me and an experimental approach and usage.
>  The standout example in my code has to to do with file polling / fetching /
> processing etc.
>
> On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <dcsobral@gmail.com> wrote:
>>
>> Actually, it can be used for synchronization algorithms in an interesting
>> way:
>>
>> case class Put(data: Any)
>> case object Get
>> actor {
>>   react {
>>     case Put(data) => react {
>>       case Get => reply(data)
>>     }
>>     case Get => val replyTo = sender; react {
>>       case Put(data) => replyTo ! data
>>     }
>>   }
>> }
>>
>> A Stack can be written recursively:
>>
>> case class Push(data: Any)
>> case object Pop
>> val stack = actor {
>>   def recurse(data: Any) {
>>     var popped = false
>>     loopWhile(!popped) {
>>       react {
>>         case Push(data) => recurse(data)
>>         case Pop => reply(data); popped = true
>>         case _ => // ignore
>>       }
>>     }
>>   }
>>   loop {
>>     react {
>>       case Push(data) => recurse(data)
>>     }
>>   }
>> }
>>
>> It does not guarantee ordering when multiple clients are pushing/popping,
>> but it does, otherwise, work.
>>
>>
>> On Mon, Jan 17, 2011 at 16:16, Chris Marshall <oxbow_lakes@hotmail.com>
>> wrote:
>>>
>>> That "queue" behaves very oddly if you call pop() before anyone has
>>> enqueued anything (al least in my opinion). Also you are missing a loop.
>>>
>>> ________________________________
>>> From: joshua.suereth@gmail.com
>>> Date: Mon, 17 Jan 2011 09:27:11 -0500
>>> Subject: Re: [scala-user] Should Scala's native actors library be marked
>>> obsolete.
>>> To: viktor.klang@gmail.com
>>> CC: crosson.david@gmail.com; sadek.drobi@gmail.com;
>>> scala-user@listes.epfl.ch
>>>
>>> To me, there are two things the scala core library does that make it both
>>> (1) scary and (2) powerful.
>>> ** The first is that is supports nested receive/react calls.  These can
>>> be used to create really interesting programs, such as Phillip Haller's
>>> example of a queue.
>>> actor {
>>>    react {
>>>      case Push(data) =>
>>>         react {
>>>            case Pop =>  reply(data)
>>>         }
>>>      }
>>>    }
>>> }
>>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> I travel to the future all the time.
>
>
>
> --
> The object of life is not to be on the side of the majority, but to escape
> finding oneself in the ranks of the insane. - Marcus Aurelius
>



--
Jonas Bonér

Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
blog: http://jonasboner.com
twtr: @jboner

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

--
   __~O
  -\ <,
(*)/ (*)

reality goes far beyond imagination

Just as the fact that scala allows defs within defs and this enhances readibility by alowing refactoring "within scope"; so do nested receives/reacts allow you to better understand the actor's behaviour *because it is all in one small place*. For example:

def act()   = react {      case GotMyPositions =>        react {          case GotMyMarks => _startTrading        }      }    }

is much preferable to:

def act() = react {  case GotMyPositions => become(waitingForMarks) }
def waitingForMarks = react { GotMyMarks => startTrading }

I have a few actors which have 5 or more nested reacts before they can start their "main loop". I think that understanding what's going on without nested reacts would be a major headache. The Akka way, IMHO, is a less clean way (at least for this use-case). Obviously Akka has other advantages but the "become" feature is not one of them. With scala, I know that I can see the complete lifecycle of my actors by looking at one method. Chris
> Date: Wed, 19 Jan 2011 21:31:18 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
> From: lists@jonasboner.com
> To: ray.racine@gmail.com
> CC: dcsobral@gmail.com; oxbow_lakes@hotmail.com; joshua.suereth@gmail.com; viktor.klang@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch
>
> Akka has 'become' which hotswaps the message handler. IMHO cleaner way
> than nested receives.

On 20 January 2011 20:25, Chris Marshall wrote:
> Just as the fact that scala allows defs within defs and this enhances
> readibility by alowing refactoring "within scope"; so do nested
> receives/reacts allow you to better understand the actor's behaviour
> *because it is all in one small place*. For example:
>
> def act()
>   = react {
>       case GotMyPositions =>
>         react {
>           case GotMyMarks => _startTrading
>         }
>       }
>     }
>
> is much preferable to:
>
> def act() = react {  case GotMyPositions => become(waitingForMarks) }
> def waitingForMarks = react { GotMyMarks => startTrading }

It doesn't have to be a new method defining the new PartialFunction,
you can inline it:

case object Swap
class Swapper extends Actor {
def receive = {
case Swap =>
println("Hi")
become {
case Swap =>
println("Ho")
unbecome // resets the latest 'become' (just for fun)
}
}
}

val swap = actorOf[Swapper].start

swap ! Swap // prints Hi
swap ! Swap // prints Ho
swap ! Swap // prints Hi
swap ! Swap // prints Ho
swap ! Swap // prints Hi
swap ! Swap // prints Ho

Is that close enough?

>
> I have a few actors which have 5 or more nested reacts before they can start
> their "main loop". I think that understanding what's going on without nested
> reacts would be a major headache. The Akka way, IMHO, is a less clean way
> (at least for this use-case). Obviously Akka has other advantages but the
> "become" feature is not one of them. With scala, I know that I can see the
> complete lifecycle of my actors by looking at one method.
>
> Chris
>> Date: Wed, 19 Jan 2011 21:31:18 +0100
>> Subject: Re: [scala-user] Should Scala's native actors library be marked
>> obsolete.
>> From: lists@jonasboner.com
>> To: ray.racine@gmail.com
>> CC: dcsobral@gmail.com; oxbow_lakes@hotmail.com; joshua.suereth@gmail.com;
>> viktor.klang@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com;
>> scala-user@listes.epfl.ch
>>
>> Akka has 'become' which hotswaps the message handler. IMHO cleaner way
>> than nested receives.
>

I used nested react in a scala-swing app, to separate the gui definition from the logic of what button takes you to what screen. Buttons just send their info as a message to the actor, which handles it differently depending which react block it's in.

On Wed, Jan 19, 2011 at 10:26 AM, Ray Racine <ray.racine@gmail.com> wrote:

When I've used nesting it has been to implement an Actor as a state machine.  New State, different set of messages it will respond to or ignore.  Obviously any FSM beyond a simple sequencing falls apart with this approach.  But then again almost anything I attempted to do with an Actor is by definition a first time for me and an experimental approach and usage.    The standout example in my code has to to do with file polling / fetching / processing etc.

On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral <dcsobral@gmail.com> wrote:

Actually, it can be used for synchronization algorithms in an interesting way:

case class Put(data: Any)
case object Get
actor {
  react {
    case Put(data) => react {
      case Get => reply(data)
    }
    case Get => val replyTo = sender; react {
      case Put(data) => replyTo ! data
    }
  }
}

A Stack can be written recursively:

case class Push(data: Any)
case object Pop
val stack = actor {
  def recurse(data: Any) {
    var popped = false
    loopWhile(!popped) {
      react {
        case Push(data) => recurse(data)
        case Pop => reply(data); popped = true
        case _ => // ignore
      }
    }
  }
  loop {
    react {
      case Push(data) => recurse(data)
    }
  }
}

It does not guarantee ordering when multiple clients are pushing/popping, but it does, otherwise, work.


On Mon, Jan 17, 2011 at 16:16, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

That "queue" behaves very oddly if you call pop() before anyone has enqueued anything (al least in my opinion). Also you are missing a loop.  

From: joshua.suereth@gmail.com
Date: Mon, 17 Jan 2011 09:27:11 -0500
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
To: viktor.klang@gmail.com
CC: crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch

To me, there are two things the scala core library does that make it both (1) scary and (2) powerful.
** The first is that is supports nested receive/react calls.  These can be used to create really interesting programs, such as Phillip Haller's example of a queue.
actor {   react {      case Push(data) =>
        react {           case Pop =>  reply(data)        }     }   }}

--
Daniel C. Sobral

I travel to the future all the time.

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

On Thu, Jan 20, 2011 at 4:43 PM, Jonas Bonér <lists@jonasboner.com> wrote:

t doesn't have to be a new method defining the new PartialFunction,
you can inline it:

case object Swap
class Swapper extends Actor {
 def receive = {
   case Swap =>
     println("Hi")
     become {
       case Swap =>
         println("Ho")
         unbecome // resets the latest 'become' (just for fun)
     }
 }
}

There are stylistic problems with that.

It is unbecoming to have to remember to type a command at every point where you might exit a code block in order to get correct behavior.

If there were a becomeOnce that did it for you, that would be more becoming.  It would reduce errors (in the same way that all automatic resource management reduces errors).

  --Rex

On 20 January 2011 22:57, Rex Kerr wrote:
> On Thu, Jan 20, 2011 at 4:43 PM, Jonas Bonér wrote:
>>
>> t doesn't have to be a new method defining the new PartialFunction,
>> you can inline it:
>>
>> case object Swap
>> class Swapper extends Actor {
>>  def receive = {
>>    case Swap =>
>>      println("Hi")
>>      become {
>>        case Swap =>
>>          println("Ho")
>>          unbecome // resets the latest 'become' (just for fun)
>>      }
>>  }
>> }
>
> There are stylistic problems with that.
>
> It is unbecoming to have to remember to type a command at every point where
> you might exit a code block in order to get correct behavior.

Correct behavior? That depends on how you define correct behavior.
'become' swaps the handler, it is not intuitive that it should swap
back to the old handler just because the previous handled message goes
out of scope. They have different semantics because they do different
things. 'become' is more generic.

>
> If there were a becomeOnce that did it for you, that would be more
> becoming.  It would reduce errors (in the same way that all automatic
> resource management reduces errors).

That's a good idea, I think I'll add that to Akka's Actor class.

>
>   --Rex
>
>

On Thu, Jan 20, 2011 at 5:12 PM, Jonas Bonér <lists@jonasboner.com> wrote:

On 20 January 2011 22:57, Rex Kerr <ichoran@gmail.com> wrote:
> On Thu, Jan 20, 2011 at 4:43 PM, Jonas Bonér <lists@jonasboner.com> wrote:
>>
>> t doesn't have to be a new method defining the new PartialFunction,
>> you can inline it:
>>
>> case object Swap
>> class Swapper extends Actor {
>>  def receive = {
>>    case Swap =>
>>      println("Hi")
>>      become {
>>        case Swap =>
>>          println("Ho")
>>          unbecome // resets the latest 'become' (just for fun)
>>      }
>>  }
>> }
>
> There are stylistic problems with that.
>
> It is unbecoming to have to remember to type a command at every point where
> you might exit a code block in order to get correct behavior.

Correct behavior? That depends on how you define correct behavior.

Correct behavior in the example code supplied, and in the application under question, is to switch back to the old handler.  I agree that become is more generic in the same way that not closing a file after dumping data to it is more generic.
 

>
> If there were a becomeOnce that did it for you, that would be more
> becoming.  It would reduce errors (in the same way that all automatic
> resource management reduces errors).


That's a good idea, I think I'll add that to Akka's Actor class.

That's all I was suggesting!  Nothing wrong with having the generic method for those who need it.

  --Rex

On 20 January 2011 23:17, Rex Kerr wrote:
> On Thu, Jan 20, 2011 at 5:12 PM, Jonas Bonér wrote:
>>
>> On 20 January 2011 22:57, Rex Kerr wrote:
>> > On Thu, Jan 20, 2011 at 4:43 PM, Jonas Bonér
>> > wrote:
>> >>
>> >> t doesn't have to be a new method defining the new PartialFunction,
>> >> you can inline it:
>> >>
>> >> case object Swap
>> >> class Swapper extends Actor {
>> >>  def receive = {
>> >>    case Swap =>
>> >>      println("Hi")
>> >>      become {
>> >>        case Swap =>
>> >>          println("Ho")
>> >>          unbecome // resets the latest 'become' (just for fun)
>> >>      }
>> >>  }
>> >> }
>> >
>> > There are stylistic problems with that.
>> >
>> > It is unbecoming to have to remember to type a command at every point
>> > where
>> > you might exit a code block in order to get correct behavior.
>>
>> Correct behavior? That depends on how you define correct behavior.
>
> Correct behavior in the example code supplied, and in the application under
> question, is to switch back to the old handler.  I agree that become is more
> generic in the same way that not closing a file after dumping data to it is
> more generic.

LOL, you are funny. :-)

>
>>
>> >
>> > If there were a becomeOnce that did it for you, that would be more
>> > becoming.  It would reduce errors (in the same way that all automatic
>> > resource management reduces errors).
>>
>>
>> That's a good idea, I think I'll add that to Akka's Actor class.
>
> That's all I was suggesting!  Nothing wrong with having the generic method
> for those who need it.

Right. Thanks.

>
>   --Rex
>
>

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?
def receive = {  case GotMyPositions =>     become {      case GotMyMarks =>        become {          case GotMyHealth =>            become {              mainTradingLoop()            }        }    }}

> Date: Thu, 20 Jan 2011 22:43:11 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
>
> It doesn't have to be a new method defining the new PartialFunction,
> you can inline it:
>
> case object Swap
>   class Swapper extends Actor {
>     def receive = {
>       case Swap =>
>         println("Hi")
>         become {
>           case Swap =>
>             println("Ho")
>             unbecome // resets the latest 'become' (just for fun)
>         }
>     }
> }
>

On Fri, Jan 21, 2011 at 9:37 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?

Yes, but what it won't do is to leak memory, i.e. disregard messages that doesn't fit the current behavior.
 

def receive = {   case GotMyPositions =>     become {      case GotMyMarks =>         become {          case GotMyHealth =>            become {               mainTradingLoop()            }        }    } }

> Date: Thu, 20 Jan 2011 22:43:11 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
>
> It doesn't have to be a new method defining the new PartialFunction,
> you can inline it:
>
> case object Swap
>   class Swapper extends Actor {
>     def receive = {
>       case Swap =>
>         println("Hi")
>         become {
>           case Swap =>
>             println("Ho")
>             unbecome // resets the latest 'become' (just for fun)
>         }
>     }
> }
>

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?

Yes, but what it won't do is to leak memory, i.e. disregard messages that doesn't fit the current behavior.

So what happens to those messages that don't fit the current behavior? Are they silently discarded? Or is there some kind of exception? 
To give an example, what happens if I send a Put message to an actor that is currently only handling Get messages, but will enter a state looking for Put messages shortly?
- Tiark

On Fri, Jan 21, 2011 at 12:43 PM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?

Yes, but what it won't do is to leak memory, i.e. disregard messages that doesn't fit the current behavior.

So what happens to those messages that don't fit the current behavior? Are they silently discarded? Or is there some kind of exception? 

the unhandledMessage-callback on the Actor will be called, the default behavior is to throw an exception.
 

To give an example, what happens if I send a Put message to an actor that is currently only handling Get messages, but will enter a state looking for Put messages shortly?

How do you know that? It might never get into a state of looking for Put messages, accumulating more and more Put-messages until the system OOMEs.
 

- Tiark

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On 21 January 2011 12:43, Tiark Rompf wrote:
>> Indeed - this goes a long way towards solving the issue! I take it that it
>> is possible to nest these "become" functions?
>
> Yes, but what it won't do is to leak memory, i.e. disregard messages that
> doesn't fit the current behavior.
>
> So what happens to those messages that don't fit the current behavior? Are
> they silently discarded? Or is there some kind of exception?

1. You can test an Actor for the message:
actorRef.isDefinedAt(msg)

2. You can implement a handler for unhandled message:
class A extends Actor {
override def unhandled(msg: Any) = { ... }
...
}
If not overridden then a 'UnhandledMessageException(msg,self)'
exception is thrown.

> To give an example, what happens if I send a Put message to an actor that is
> currently only handling Get messages, but will enter a state looking for Put
> messages shortly?

We have a ticket for that:
https://www.assembla.com/spaces/akka/tickets/461-explicit-requeue-of-mes...

Will come in 1.1.

> - Tiark

So are you saying that if I send a message to an Akka actor that has not yet *become* ready for it, that the message will not get added to its mail queue. For example, if below I sent GotMyHealth before GotMyMarks, the actor would just sit there forever?
Date: Fri, 21 Jan 2011 11:36:15 +0100
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
From: viktor.klang@gmail.com
To: oxbow_lakes@hotmail.com
CC: lists@jonasboner.com; ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch



On Fri, Jan 21, 2011 at 9:37 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?

Yes, but what it won't do is to leak memory, i.e. disregard messages that doesn't fit the current behavior.
 

def receive = {   case GotMyPositions =>     become {      case GotMyMarks =>         become {          case GotMyHealth =>            become {               mainTradingLoop()            }        }    } }

On Fri, Jan 21, 2011 at 3:58 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

So are you saying that if I send a message to an Akka actor that has not yet *become* ready for it, that the message will not get added to its mail queue.

I'm saying that it will be unmatched and the unhandled message callback for that actor will be invoked.
 

For example, if below I sent GotMyHealth before GotMyMarks, the actor would just sit there forever?

Just like your actor would just sit there forever if you never receive the GotMyHealth, but the bonus would be that it doesn't leak memory trying to hold on to all other messages that arrive.

We have a feature ticket to add the nested behavior, but it will most likely be a feature you'd turn on, not the default behavior.
Since it is in fact quite dangerous.

 

Date: Fri, 21 Jan 2011 11:36:15 +0100
Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
From: viktor.klang@gmail.com
To: oxbow_lakes@hotmail.com
CC: lists@jonasboner.com; ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch



On Fri, Jan 21, 2011 at 9:37 AM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

Indeed - this goes a long way towards solving the issue! I take it that it is possible to nest these "become" functions?

Yes, but what it won't do is to leak memory, i.e. disregard messages that doesn't fit the current behavior.
 

def receive = {   case GotMyPositions =>     become {      case GotMyMarks =>         become {          case GotMyHealth =>            become {               mainTradingLoop()            }        }    } }

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

So a common use-case for me is to execute a subscribe-and-replay on some feed with a monotonically increasing message sequence ID. That is, I start up at some point during the day and want to recover all messages sent since the start of the day and subscribe to new ones, with no loss (i.e. I need to subscribe before querying). On top of this, I must wait for some external indication to begin:

def act() = {    sys.subscribe() //THE CURRENT Actor WILL NOW START TO RECEIVE MsgEvents    var lastEv = none[Int]    def process(e : MsgEvent) = { lastEv = some(e.sequence) ; doStuff }    sys.queryToday foreach process //PROCESS RESULTS FROM QUERY
    react { //WAIT UNTIL UP TO DATE BEFORE PROCESSING EVENTS FROM THE SUBSCRIBE      case SomeExternalGoAhead =>         loop {          react {             case m @ MsgEvent(seq, _) if lastEv.forall(_ < seq) => process(m)             case ExternalInstruction(e)                         => doSomethingElse(e)                     }        }    }}

(I hope you are following this so far). How would I recreate this flow in Akka?
Chris

> Date: Fri, 21 Jan 2011 14:35:28 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
> From: lists@jonasboner.com
> To: tiark.rompf@epfl.ch
> CC: viktor.klang@gmail.com; oxbow_lakes@hotmail.com; ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch
>
> On 21 January 2011 12:43, Tiark Rompf <tiark.rompf@epfl.ch> wrote:
> >> Indeed - this goes a long way towards solving the issue! I take it that it
> >> is possible to nest these "become" functions?
> >
> > Yes, but what it won't do is to leak memory, i.e. disregard messages that
> > doesn't fit the current behavior.
> >
> > So what happens to those messages that don't fit the current behavior? Are
> > they silently discarded? Or is there some kind of exception?
>
> 1. You can test an Actor for the message:
> actorRef.isDefinedAt(msg)
>
> 2. You can implement a handler for unhandled message:
> class A extends Actor {
> override def unhandled(msg: Any) = { ... }
> ...
> }

Like this?

import akka.actor._
import akka.actor.Actor._
import scala.collection.mutable.ListBuffer

class MyActor extends Actor {
  val queue = new ListBuffer[Any]()
 
  override def preStart {
    self ! 'Replay
    subscribe()
  }
 
  def subscribe() {} //Your external stuff
  def allOldMessages() = List("foo", 5, "bar", "pigdog", true) //Your retrieval of prior messages
 
  def receive = {
    case 'Replay =>
      allOldMessages() foreach process
      become  {
        case 'GoAhead =>
          queue foreach process
          queue.clear
          become {
            case msg => process(msg)
          }
        case msg =>
          queue += msg //Here you have full control, you can handle overflow etc
      }
  }
 
  def process(msg: Any): Unit = println("processing: " + msg)
}




On Fri, Jan 21, 2011 at 4:12 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

So a common use-case for me is to execute a subscribe-and-replay on some feed with a monotonically increasing message sequence ID. That is, I start up at some point during the day and want to recover all messages sent since the start of the day and subscribe to new ones, with no loss (i.e. I need to subscribe before querying). On top of this, I must wait for some external indication to begin:

def act() = {    sys.subscribe() //THE CURRENT Actor WILL NOW START TO RECEIVE MsgEvents     var lastEv = none[Int]    def process(e : MsgEvent) = { lastEv = some(e.sequence) ; doStuff }     sys.queryToday foreach process //PROCESS RESULTS FROM QUERY
    react { //WAIT UNTIL UP TO DATE BEFORE PROCESSING EVENTS FROM THE SUBSCRIBE      case SomeExternalGoAhead =>          loop {          react {             case m @ MsgEvent(seq, _) if lastEv.forall(_ < seq) => process(m)              case ExternalInstruction(e)                         => doSomethingElse(e)                     }         }    }}

(I hope you are following this so far). How would I recreate this flow in Akka?
Chris

> Date: Fri, 21 Jan 2011 14:35:28 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
> From: lists@jonasboner.com
> To: tiark.rompf@epfl.ch
> CC: viktor.klang@gmail.com; oxbow_lakes@hotmail.com; ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch
>
> On 21 January 2011 12:43, Tiark Rompf <tiark.rompf@epfl.ch> wrote:
> >> Indeed - this goes a long way towards solving the issue! I take it that it
> >> is possible to nest these "become" functions?
> >
> > Yes, but what it won't do is to leak memory, i.e. disregard messages that
> > doesn't fit the current behavior.
> >
> > So what happens to those messages that don't fit the current behavior? Are
> > they silently discarded? Or is there some kind of exception?
>
> 1. You can test an Actor for the message:
> actorRef.isDefinedAt(msg)
>
> 2. You can implement a handler for unhandled message:
> class A extends Actor {
> override def unhandled(msg: Any) = { ... }
> ...
> }

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On 19 January 2011 22:05, Luc Duponcheel wrote:
> what a nice example
>
> can the states also be parameterized,
> like become(readyFor(something))
>
> in that case
> I have this feeling that 'become' can be used
> to elegantly implement 'spaces' as well
> (and Dining Philosophers can be implemented using
> a 'space' that is a 'table with chopsticks on it')
>
> as in http://lucdup.blogspot.com/2009/08/scala-spaces-as-scala-actors.html
>
> for example:
>
> if a worker registers with the space for doing some work,
> then the space kind of becomes ready for
> processing any x for which work.isDefinedAt(x) = true
>
>
> just a thought

Sounds like a cool idea. Time to explore it?

>
>
> Luc
>
> On Wed, Jan 19, 2011 at 9:31 PM, Jonas Bonér wrote:
>>
>> Akka has 'become' which hotswaps the message handler. IMHO cleaner way
>> than nested receives.
>> Docs here: http://doc.akka.io/actors-scala#Actors%20(Scala)-HotSwap
>>
>> It can be used for f.e. building an FSM. See this example of Dining
>> Philosophers:
>>
>> https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/...
>>
>> Akka also has a FSM DSL. Here is the same problem solved using this the
>> DSL:
>>
>> https://github.com/jboner/akka/blob/master/akka-samples/akka-sample-fsm/...
>>
>> /Jonas
>>
>> On 19 January 2011 16:26, Ray Racine wrote:
>> > When I've used nesting it has been to implement an Actor as a state
>> > machine.
>> >  New State, different set of messages it will respond to or ignore.
>> >  Obviously any FSM beyond a simple sequencing falls apart with this
>> > approach.  But then again almost anything I attempted to do with an
>> > Actor is
>> > by definition a first time for me and an experimental approach and
>> > usage.
>> >  The standout example in my code has to to do with file polling /
>> > fetching /
>> > processing etc.
>> >
>> > On Tue, Jan 18, 2011 at 8:18 AM, Daniel Sobral
>> > wrote:
>> >>
>> >> Actually, it can be used for synchronization algorithms in an
>> >> interesting
>> >> way:
>> >>
>> >> case class Put(data: Any)
>> >> case object Get
>> >> actor {
>> >>   react {
>> >>     case Put(data) => react {
>> >>       case Get => reply(data)
>> >>     }
>> >>     case Get => val replyTo = sender; react {
>> >>       case Put(data) => replyTo ! data
>> >>     }
>> >>   }
>> >> }
>> >>
>> >> A Stack can be written recursively:
>> >>
>> >> case class Push(data: Any)
>> >> case object Pop
>> >> val stack = actor {
>> >>   def recurse(data: Any) {
>> >>     var popped = false
>> >>     loopWhile(!popped) {
>> >>       react {
>> >>         case Push(data) => recurse(data)
>> >>         case Pop => reply(data); popped = true
>> >>         case _ => // ignore
>> >>       }
>> >>     }
>> >>   }
>> >>   loop {
>> >>     react {
>> >>       case Push(data) => recurse(data)
>> >>     }
>> >>   }
>> >> }
>> >>
>> >> It does not guarantee ordering when multiple clients are
>> >> pushing/popping,
>> >> but it does, otherwise, work.
>> >>
>> >>
>> >> On Mon, Jan 17, 2011 at 16:16, Chris Marshall
>> >> wrote:
>> >>>
>> >>> That "queue" behaves very oddly if you call pop() before anyone has
>> >>> enqueued anything (al least in my opinion). Also you are missing a
>> >>> loop.
>> >>>
>> >>> ________________________________
>> >>> From: joshua.suereth@gmail.com
>> >>> Date: Mon, 17 Jan 2011 09:27:11 -0500
>> >>> Subject: Re: [scala-user] Should Scala's native actors library be
>> >>> marked
>> >>> obsolete.
>> >>> To: viktor.klang@gmail.com
>> >>> CC: crosson.david@gmail.com; sadek.drobi@gmail.com;
>> >>> scala-user@listes.epfl.ch
>> >>>
>> >>> To me, there are two things the scala core library does that make it
>> >>> both
>> >>> (1) scary and (2) powerful.
>> >>> ** The first is that is supports nested receive/react calls.  These
>> >>> can
>> >>> be used to create really interesting programs, such as Phillip
>> >>> Haller's
>> >>> example of a queue.
>> >>> actor {
>> >>>    react {
>> >>>      case Push(data) =>
>> >>>         react {
>> >>>            case Pop =>  reply(data)
>> >>>         }
>> >>>      }
>> >>>    }
>> >>> }
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Daniel C. Sobral
>> >>
>> >> I travel to the future all the time.
>> >
>> >
>> >
>> > --
>> > The object of life is not to be on the side of the majority, but to
>> > escape
>> > finding oneself in the ranks of the insane. - Marcus Aurelius
>> >
>>
>>
>>
>> --
>> Jonas Bonér
>>
>> Specialist at Large
>> work: http://scalablesolutions.se
>> code: http://akka.io
>> blog: http://jonasboner.com
>> twtr: @jboner
>
>
>
> --
>    __~O
>   -\ <,
> (*)/ (*)
>
> reality goes far beyond imagination
>
>

No comments?
On Fri, Jan 21, 2011 at 4:57 PM, √iktor Klang <viktor.klang@gmail.com> wrote:

Like this?

import akka.actor._
import akka.actor.Actor._
import scala.collection.mutable.ListBuffer

class MyActor extends Actor {
  val queue = new ListBuffer[Any]()
 
  override def preStart {
    self ! 'Replay
    subscribe()
  }
 
  def subscribe() {} //Your external stuff
  def allOldMessages() = List("foo", 5, "bar", "pigdog", true) //Your retrieval of prior messages
 
  def receive = {
    case 'Replay =>
      allOldMessages() foreach process
      become  {
        case 'GoAhead =>
          queue foreach process
          queue.clear
          become {
            case msg => process(msg)
          }
        case msg =>
          queue += msg //Here you have full control, you can handle overflow etc
      }
  }
 
  def process(msg: Any): Unit = println("processing: " + msg)
}




On Fri, Jan 21, 2011 at 4:12 PM, Chris Marshall <oxbow_lakes@hotmail.com> wrote:

So a common use-case for me is to execute a subscribe-and-replay on some feed with a monotonically increasing message sequence ID. That is, I start up at some point during the day and want to recover all messages sent since the start of the day and subscribe to new ones, with no loss (i.e. I need to subscribe before querying). On top of this, I must wait for some external indication to begin:

def act() = {    sys.subscribe() //THE CURRENT Actor WILL NOW START TO RECEIVE MsgEvents     var lastEv = none[Int]    def process(e : MsgEvent) = { lastEv = some(e.sequence) ; doStuff }     sys.queryToday foreach process //PROCESS RESULTS FROM QUERY
    react { //WAIT UNTIL UP TO DATE BEFORE PROCESSING EVENTS FROM THE SUBSCRIBE      case SomeExternalGoAhead =>          loop {          react {             case m @ MsgEvent(seq, _) if lastEv.forall(_ < seq) => process(m)              case ExternalInstruction(e)                         => doSomethingElse(e)                     }         }    }}

(I hope you are following this so far). How would I recreate this flow in Akka?
Chris

> Date: Fri, 21 Jan 2011 14:35:28 +0100
> Subject: Re: [scala-user] Should Scala's native actors library be marked obsolete.
> From: lists@jonasboner.com
> To: tiark.rompf@epfl.ch
> CC: viktor.klang@gmail.com; oxbow_lakes@hotmail.com; ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com; crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch
>
> On 21 January 2011 12:43, Tiark Rompf <tiark.rompf@epfl.ch> wrote:
> >> Indeed - this goes a long way towards solving the issue! I take it that it
> >> is possible to nest these "become" functions?
> >
> > Yes, but what it won't do is to leak memory, i.e. disregard messages that
> > doesn't fit the current behavior.
> >
> > So what happens to those messages that don't fit the current behavior? Are
> > they silently discarded? Or is there some kind of exception?
>
> 1. You can test an Actor for the message:
> actorRef.isDefinedAt(msg)
>
> 2. You can implement a handler for unhandled message:
> class A extends Actor {
> override def unhandled(msg: Any) = { ... }
> ...
> }

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

On 23 January 2011 13:22, √iktor Klang wrote:
> No comments?

I think it solves the problem in a very neat way.

> On Fri, Jan 21, 2011 at 4:57 PM, √iktor Klang
> wrote:
>>
>> Like this?
>>
>> import akka.actor._
>> import akka.actor.Actor._
>> import scala.collection.mutable.ListBuffer
>>
>> class MyActor extends Actor {
>>   val queue = new ListBuffer[Any]()
>>
>>   override def preStart {
>>     self ! 'Replay
>>     subscribe()
>>   }
>>
>>   def subscribe() {} //Your external stuff
>>   def allOldMessages() = List("foo", 5, "bar", "pigdog", true) //Your
>> retrieval of prior messages
>>
>>   def receive = {
>>     case 'Replay =>
>>       allOldMessages() foreach process
>>       become  {
>>         case 'GoAhead =>
>>           queue foreach process
>>           queue.clear
>>           become {
>>             case msg => process(msg)
>>           }
>>         case msg =>
>>           queue += msg //Here you have full control, you can handle
>> overflow etc
>>       }
>>   }
>>
>>   def process(msg: Any): Unit = println("processing: " + msg)
>> }
>>
>>
>>
>>
>> On Fri, Jan 21, 2011 at 4:12 PM, Chris Marshall
>> wrote:
>>>
>>> So a common use-case for me is to execute a subscribe-and-replay on some
>>> feed with a monotonically increasing message sequence ID. That is, I start
>>> up at some point during the day and want to recover all messages sent since
>>> the start of the day and subscribe to new ones, with no loss (i.e. I need to
>>> subscribe before querying). On top of this, I must wait for some external
>>> indication to begin:
>>>
>>> def act() = {
>>>     sys.subscribe() //THE CURRENT Actor WILL NOW START TO RECEIVE
>>> MsgEvents
>>>     var lastEv = none[Int]
>>>     def process(e : MsgEvent) = { lastEv = some(e.sequence) ; doStuff }
>>>     sys.queryToday foreach process //PROCESS RESULTS FROM QUERY
>>>     react { //WAIT UNTIL UP TO DATE BEFORE PROCESSING EVENTS FROM THE
>>> SUBSCRIBE
>>>       case SomeExternalGoAhead =>
>>>         loop {
>>>           react {
>>>             case m @ MsgEvent(seq, _) if lastEv.forall(_ < seq) =>
>>> process(m)
>>>             case ExternalInstruction(e)                         =>
>>> doSomethingElse(e)
>>>           }
>>>         }
>>>     }
>>> }
>>>
>>> (I hope you are following this so far). How would I recreate this flow in
>>> Akka?
>>> Chris
>>>
>>> > Date: Fri, 21 Jan 2011 14:35:28 +0100
>>> > Subject: Re: [scala-user] Should Scala's native actors library be
>>> > marked obsolete.
>>> > From: lists@jonasboner.com
>>> > To: tiark.rompf@epfl.ch
>>> > CC: viktor.klang@gmail.com; oxbow_lakes@hotmail.com;
>>> > ray.racine@gmail.com; dcsobral@gmail.com; joshua.suereth@gmail.com;
>>> > crosson.david@gmail.com; sadek.drobi@gmail.com; scala-user@listes.epfl.ch
>>> >
>>> > On 21 January 2011 12:43, Tiark Rompf wrote:
>>> > >> Indeed - this goes a long way towards solving the issue! I take it
>>> > >> that it
>>> > >> is possible to nest these "become" functions?
>>> > >
>>> > > Yes, but what it won't do is to leak memory, i.e. disregard messages
>>> > > that
>>> > > doesn't fit the current behavior.
>>> > >
>>> > > So what happens to those messages that don't fit the current
>>> > > behavior? Are
>>> > > they silently discarded? Or is there some kind of exception?
>>> >
>>> > 1. You can test an Actor for the message:
>>> > actorRef.isDefinedAt(msg)
>>> >
>>> > 2. You can implement a handler for unhandled message:
>>> > class A extends Actor {
>>> > override def unhandled(msg: Any) = { ... }
>>> > ...
>>> > }
>>>
>>
>>
>>
>> --
>> Viktor Klang,
>> Code Connoisseur
>> Work:   Scalable Solutions
>> Code:   github.com/viktorklang
>> Follow: twitter.com/viktorklang
>> Read:   klangism.tumblr.com
>>
>
>
>
> --
> Viktor Klang,
> Code Connoisseur
> Work:   Scalable Solutions
> Code:   github.com/viktorklang
> Follow: twitter.com/viktorklang
> Read:   klangism.tumblr.com
>
>