> --
> 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
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...
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.
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....
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
blog: http://jonasboner.com
twitter: @jboner
> 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.
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.
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.
--
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.
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...
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.
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.
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.
>
>
--
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!
--
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.
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.
Perhaps cleanest.