Exhaustive receives?
Stefan
Thereby I ran into a problem with non exhaustive receives in akka.
The distributed sort app does somewhere in between the following:
There are N workers / actors. Each actor get's a pivots msg, calcs N
slices and sends one to each worker. Then he waits until he received N
slices and continues.
With scala actors, I used
def act = { loop { react {
state match { //more elegant with direct state switch?
case Init =>
initFun
case _:WaitingForPivots =>
pivotFun
case _:WaitingForPivotedSlices =>
pivotSliceFun
case x =>
throw new IllegalStateException(id+") in state("+state+")
received: "+x)
to take out messages when I need them (act doesn't need to be
exhaustive).
It seems to me that receives in akka must be exhaustive (Should be
mentioned in the documentation btw. ... if people worked with erlang /
scala actors, this is pretty surprising and finding out by reading the
documentation is better than the hard way).
What's akkas way to deal with that?
I've tried something ...
http://paste.pocoo.org/show/229490/
Jonas Bonér
not yield a matching error?
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
>
--
Jonas Bonér
work: http://jayway.com
code: http://akkasource.com
blog: http://jonasboner.com
twitter: @jboner
Stefan
receive method can't handle.
Jonas Bonér
Ok. What do you want me to do with them?
--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner
On 24 Jun 2010 23:08, "Stefan" <stef...@gmail.com> wrote:
I meant not taking out messages out of the mailbox the _current_
receive method can't handle.
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To...
Stefan
process these messages again. Thus, user code isn't cluttered by
storing messages the actor isn't currently interested in.
Actually I wanted to know if there's a pattern for how to handle this
in akka. In partical, e.g. if an Actor receives 'B messages, which he
needs later, but waits for an 'A message to start.
Since akkas semantic of the receive is different of these in scala-
actors or erlang OTP - in akka receives are partial functions but
mustn't be partial (or exhaustive) - I guess it would be worth
mentioning it in the documentation.
Jonas Bonér
I don't think the framework should bend over backwards to solve
application programming errors.
It also slows down performance a lot.
I could add it as an option, it would not take long. If people really want it.
For now you can just do:
def receive = {
case ...
case ...
case unknown => self.mailbox.add(unknown)
}
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
Jonas Bonér
I will either fix it as an option or document it. Thanks.
--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner
On 25 Jun 2010 12:06, "Jonas Bonér" <jo...@jonasboner.com> wrote:
I think it is a bad idea.
I don't think the framework should bend over backwards to solve
application programming errors.
It also slows down performance a lot.
I could add it as an option, it would not take long. If people really want it.
For now you can just do:
def receive = {
case ...
case ...
case unknown => self.mailbox.add(unknown)
}
On 25 June 2010 11:50, Stefan <stef...@gmail.com> wrote:
> Scala actors and erlang do wait unti...
--
Jonas Bonér
work: http://jayway.com
code: http://akkasource.com
blog: http://jonasboner....
Jonas Bonér
If you want to change the receive fun then it is easiest to use Akka HotSwap.
--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner
On 25 Jun 2010 12:11, "Jonas Bonér" <jo...@jonasboner.com> wrote:
I will either fix it as an option or document it. Thanks.
--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner
>
> On 25 Jun 2010 12:06, "Jonas Bonér" <jo...@jonasboner.com> wrote:
>
> I think it is a bad idea....
Jonas Bonér
--
Jonas Bonér
blog: http://jonasboner.com
twitter: @jboner
Stefan
> I don't think the framework should bend over backwards > to solve application programming errors.
application development easier, because you don't have to handle
messages you're currently not interested in(but later on). P. Haller
presented different mailboxes to reduce the performance impact of
their mailbox implementation. To me, this is a strong indicator that
they are very well aware of that performance / usability tradeof.
> case unknown => self.mailbox.add(unknown)
This looks like a busy wait to me. The snippet which I posted does the
same smarter, with the restriction that new receives must be
explicitly assigned to act.
> If you want to change the receive fun then it is > easiest to use Akka HotSwap.
to change actor behaviour. Adding new functionality (actor handles
additional messages / cases) seems dangerous. Imagine e.g. Howswapping
receive and adding case 'A => ..., then afterwards sending an 'A
message. This does not guarantee (especially in a network), that the
hotswap message is received/processed before the 'A message. Then, it
could result in match-exception. Therefore, it seems to me that the
current hotswap is of limited use.
Viktor Klang
> Added it to the docs: http://doc.akkasource.org/actorsThanks, I think this helps newcomers.
I don't think this is a programming error. For me, it makes
> I don't think the framework should bend over backwards > to solve application programming errors.
application development easier, because you don't have to handle
messages you're currently not interested in(but later on). P. Haller
presented different mailboxes to reduce the performance impact of
their mailbox implementation. To me, this is a strong indicator that
they are very well aware of that performance / usability tradeof.
But that's a silent memory leak as well.
This looks like a busy wait to me. The snippet which I posted does the
> case unknown => self.mailbox.add(unknown)
same smarter, with the restriction that new receives must be
explicitly assigned to act.
To me it sounds as an antipattern to juggle around with messages that the actor currently doesn't understand,
but given enough arguments I may sway.
With the current mailbox behaviour, I think hotswapping is just useful
> If you want to change the receive fun then it is > easiest to use Akka HotSwap.
to change actor behaviour. Adding new functionality (actor handles
additional messages / cases) seems dangerous. Imagine e.g. Howswapping
receive and adding case 'A => ..., then afterwards sending an 'A
message. This does not guarantee (especially in a network), that the
hotswap message is received/processed before the 'A message. Then, it
could result in match-exception. Therefore, it seems to me that the
current hotswap is of limited use.
I agree, using hotswap on oneself during a receive should be instant, i.e. the "become"-function as specified in the ActorsModel.
self become pf (available within the receive body)
self ! HotSwap (outside of receive body)
Dunno how that could be solved cleanly in the Akka code, but I'll think about it.
WDYT?
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang
Jonas Bonér
I added to the docs that Akka does NOT provide it. And that it differs from Erlang.
See my previous email for my thoughts on it.
Antipattern. I think so.
--
Jonas Bonér
http://jayway.com
http://akkasource.com
twitter: jboner
On 28 Jun 2010 15:09, "Viktor Klang" <viktor...@gmail.com> wrote:
On Mon, Jun 28, 2010 at 3:02 PM, Stefan <stef...@gmail.com> wrote:
>
> > Added it to the docs: htt...
But that's a silent memory leak as well.
>
>
> > case unknown => self.mailbox.add(unknown)
> This looks like a busy wait to me. The snippet ...
To me it sounds as an antipattern to juggle around with messages that the actor currently doesn't understand,
but given enough arguments I may sway.
>
>
> > If you want to change the receive fun then it is > easiest to use Akka HotSwap.
> With...
I agree, using hotswap on oneself during a receive should be instant, i.e. the "become"-function as specified in the ActorsModel.
self become pf (available within the receive body)
self ! HotSwap (outside of receive body)
Dunno how that could be solved cleanly in the Akka code, but I'll think about it.
WDYT?
--
> You received this message because you are subscribed to the Google Groups "Akka User List" group....
--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall
Akka - the Actor Kernel: Akkasource.org
Twttr: twitter.com/viktorklang
--
You received this message because you are subscribed to the Google Groups "Akka User List" gro...
Viktor Klang
I added to the docs that Akka does NOT provide it. And that it differs from Erlang.
See my previous email for my thoughts on it.
Antipattern. I think so.
What's your take on the instant hotswap?
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
Stefan
don't have to.
> To me it sounds as an antipattern to juggle around with messages that the actor currently doesn't understand, but given enough arguments I may sway.
akkas pattern for my usecase. Imagine: I have several(N) actors which
wait to receive an 'A, then they send a 'B to every other actor. An
actor can continue working if they received N-times 'B. So an actor
can receive 'B before he received 'A. With akka, I have to handle 'B
which I'm now not interested in, but I know I need them later.
If my receive methods are "stateless" (I have to handle every message
at every time) the easiest solution is to buffer the messages until I
need them. Doing this clutters my code - and I would have to do it for
every message or I have to spend time thinking about when this could
happen and hope I didn't miss a case.
Is there an alternative I missed?
Jonas Bonér
I can have two mailboxes, the regular one and one for
"not-yet-defined" messages.
if (receive.isDefinedAt(msg)) receive(msg)
else mailboxForNotYetDefinedMessages.add(msg)
Periodically do:
val msg = mailboxForNotYetDefinedMessages.poll
if (msg != null && receive.isDefinedAt(msg)) receive(msg)
Done.
Should we do that?
You can still use the default 'case _ => ..' and it will work as before.
/Jonas
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
>
--
Steven Shaw
On Mon, Jun 28, 2010 at 3:13 PM, Jonas Bonér <jo...@jonasboner.com> wrote:I added to the docs that Akka does NOT provide it. And that it differs from Erlang.
See my previous email for my thoughts on it.
Antipattern. I think so.Yes, definitely an antipattern!
I always wondered why Erlang had the model of looking through all the messaging in the mailbox for the receive pattern. It still bothers me but I hadn't thought about it much.
It does seem to provide a very simple RPC model without the need for futures:
echo ! "hi"
receive {case "hi" => println("got hi back!") }
echo1 ! "hi1"
echo2 ! "hi2"
echo3 ! "hi3"
receive {case "hi1" => println("got hi1") }
receive {case "hi2" => println("got hi2") }
receive {case "hi3" => println("got hi3") }
where presumably those replies needn't happen in the same order but because the system "digs into the mailbox", it doesn't hang waiting for "hi1" if another reply was first.
So, there does appear to be a certain kind of elegance to it. What do you guys reckon?
Jonas Bonér
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--
Stefan
nothing changed. The non-exhaustive receives give the programmer more
options. I do think the current akka implementation is more dangerous,
because the actor can be in every state when he must handle a message.
Viktor Klang
You convinced me that this is important for some advanced usages.
I've added this ticket:
https://www.assembla.com/spaces/akka/tickets/300-impl-non-exhaustive-actor-receive-as-optional-configuration
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>
>
--
Jonas Bonér
work: http://jayway.com
code: http://akkasource.com
blog: http://jonasboner.com
twitter: @jboner
--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
--
Jonas Bonér
> I'm thinking this could be solved as a new dispatcher that reschedules
> messages that aren't treatable by the actor in question.
Perhaps cleanest.