Best way to test unit akka actors
Nick Kasvosve
But how to do unit testing without firing up the whole akka framework (this reminds me of J2EE containers and unit testing problems, or is my analogy flawed?)
I will kindly appreciate any guidance on unit testing isolated actors.
Thanks guys
Jonas Bonér
(new MyActor).receive(message)
?
--
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
twtr: @jboner
"Nick Kasvosve" <nkas...@gmail.com> skrev:
>--
>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.
Nick Kasvosve
√iktor Klang
Yes. Just to verify the correct messages are defined for the actor without actually firing up the whole framework
You don't really need to "fire up the whole framework", the only thing you need to do is:
val a = actorOf[FooActor].start
a.isDefinedAt(someMessage)
a.isDefinedAt(someOtherMessage)
...
a.stop
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Geir Hedemark
When invoking new on an actor class, akka goes:
[error] You can not create an instance of an actor explicitly using 'new MyActor'.
[error] You have to use one of the factory methods in the 'Actor' object to create a new actor.
[error] Either use:
[error] 'val actor = Actor.actorOf[MyActor]', or
[error] 'val actor = Actor.actorOf(new MyActor(..))', or
[error] 'val actor = Actor.actor { case msg => .. } }'
[error] null
and throws an actorinitializationexception.
1.0-M1, by the way.
Test code is
val myActor = new AmazonActor
val mockService = mock(classOf[MyService])
(...)
myActor.mockService = mockService
myActor.receive(...)
What am I doing wrong?
yours
Geir
Jonas Bonér
> Had a chance to try this today.
>
> When invoking new on an actor class, akka goes:
>
> [error] You can not create an instance of an actor explicitly using 'new MyActor'.
> [error] You have to use one of the factory methods in the 'Actor' object to create a new actor.
> [error] Either use:
> [error] 'val actor = Actor.actorOf[MyActor]', or
> [error] 'val actor = Actor.actorOf(new MyActor(..))', or
> [error] 'val actor = Actor.actor { case msg => .. } }'
> [error] null
>
> and throws an actorinitializationexception.
>
> 1.0-M1, by the way.
>
> Test code is
> val myActor = new AmazonActor
> val mockService = mock(classOf[MyService])
> (...)
> myActor.mockService = mockService
> myActor.receive(...)
>
> What am I doing wrong?
You can't create an actor with 'new', but only in the scope of
Actor.actorOf. It checks that when the 'self' val is initialized in
the Actor class.
I see the problem. Wonder if we should have a "test" flag in config
that allowed creating actor with 'new', but then 'self' in the actor
would be 'null'.
--
Jonas Bonér
blog: http://jonasboner.com
twtr: @jboner
Geir Hedemark
Make this a warning where you list what will break. I hate sealed designs like these. It makes using the stuff harder than it needs to be, and in this case forces me to start an actor in my tests, which exposes my tests to race conditions and all kinds of other fluff I don't want to deal with.
(Another minor question is why the Actor needs a reference to the ActorRef, which is the calling side, and which it calls "self" even if it is a completely different type. Smells bad to me. Oh, well.)
yours
Geir
Jonas Bonér
you) to not shoot themselves in the foot by violating the actor model
contract, which have happened way too many times in the past with the
previous more "open" designs.
Geir Hedemark
How would you write a unit test of an actor that subclasses the Actor class, and which encapsulates some service? I would like you to mock out the service, and verify that a method in the service is called when a message is sent to the actor. Use Mockito for preference, but anything goes if it works.
Then extend the actor under test to send a message back to another actor with a string that is returned from the service that was called. Mock out the receiving actor and verify that the message was sent.
Something like
val myActor = new MyActor
val mockService = mock(classOf[MyService])
myActor.service = mockService
myActor ! "Message"
verify(mockService).doStuff(any())
for the first case and
val myActor = new MyActor
val mockService = mock(classOf[MyService])
val mockActor = mock(classOf[ActorRef])
when(mockService).doStuff("Message").thenReturn("Returnvalue)
myActor.service=mockService
myActor.returnActor=mockActor
myActor ! "Message"
verify(mockActor).!("Returnvalue")
for the second case.
These two scenarios are pretty basic, and I can't see an efficient way of getting them to work right, probably because I don't know the design of Akka well enough. Please help.
yours
Geir
√iktor Klang
You are, of course, right. There are good reasons for controlling what a user does. I appreciate the effort put into helping me not make silly mistakes.
How would you write a unit test of an actor that subclasses the Actor class, and which encapsulates some service? I would like you to mock out the service, and verify that a method in the service is called when a message is sent to the actor. Use Mockito for preference, but anything goes if it works.
Then extend the actor under test to send a message back to another actor with a string that is returned from the service that was called. Mock out the receiving actor and verify that the message was sent.
You mean shared-mutable-state?
Like, the kind that the Actor model is here to replace?
I honestly think that mocking can be good for single-threaded OO á la Java/C# code, but have no place in a multithreaded setting.
--
Jonas Bonér
>
>
> On Mon, Feb 7, 2011 at 4:48 PM, Geir Hedemark <geir.h...@gmail.com>
> wrote:
>>
>> You are, of course, right. There are good reasons for controlling what a
>> user does. I appreciate the effort put into helping me not make silly
>> mistakes.
>>
>> How would you write a unit test of an actor that subclasses the Actor
>> class, and which encapsulates some service? I would like you to mock out the
>> service, and verify that a method in the service is called when a message is
>> sent to the actor. Use Mockito for preference, but anything goes if it
>> works.
>>
>> Then extend the actor under test to send a message back to another actor
>> with a string that is returned from the service that was called. Mock out
>> the receiving actor and verify that the message was sent.
>
> You mean shared-mutable-state?
> Like, the kind that the Actor model is here to replace?
>
> I honestly think that mocking can be good for single-threaded OO á la
> Java/C# code, but have no place in a multithreaded setting.
>
I can understand the need to unit test the internal behavior in an actor.
Best way to do that would be to decouple it from the Actor by putting
it in a regular class/trait, test that, and then mix in the Actor
trait when you want to create actors.
// test this
class MyLogic {
def blabla
}
// run this
actorOf(new MyLogic with Actor {
def receive = {
case Bla => blabla
}
})
Or create a stand-alone MyLogicActor class.
√iktor Klang
On 7 February 2011 17:01, √iktor Klang <viktor...@gmail.com> wrote:I can understand the need to unit test the internal behavior in an actor.
>
>
> On Mon, Feb 7, 2011 at 4:48 PM, Geir Hedemark <geir.h...@gmail.com>
> wrote:
>>
>> You are, of course, right. There are good reasons for controlling what a
>> user does. I appreciate the effort put into helping me not make silly
>> mistakes.
>>
>> How would you write a unit test of an actor that subclasses the Actor
>> class, and which encapsulates some service? I would like you to mock out the
>> service, and verify that a method in the service is called when a message is
>> sent to the actor. Use Mockito for preference, but anything goes if it
>> works.
>>
>> Then extend the actor under test to send a message back to another actor
>> with a string that is returned from the service that was called. Mock out
>> the receiving actor and verify that the message was sent.
>
> You mean shared-mutable-state?
> Like, the kind that the Actor model is here to replace?
>
> I honestly think that mocking can be good for single-threaded OO á la
> Java/C# code, but have no place in a multithreaded setting.
>
Best way to do that would be to decouple it from the Actor by putting
it in a regular class/trait, test that, and then mix in the Actor
trait when you want to create actors.
But if that logic sends messages to other actors?
Jonas Bonér
You can't test anything that involves 'self' or other actors, e.g. no
actor interaction behavior. So of very limited use indeed.
Geir Hedemark
> You mean shared-mutable-state?
> Like, the kind that the Actor model is here to replace?
The Actor model will sadly not replace any of the services I need to call out to in order to have things performed on my behalf.
yours
Geir
Geir Hedemark
> I can understand the need to unit test the internal behavior in an actor.
> Best way to do that would be to decouple it from the Actor by putting
> it in a regular class/trait, test that, and then mix in the Actor
> trait when you want to create actors.
>
> // test this
> class MyLogic {
> def blabla
> }
>
> // run this
> actorOf(new MyLogic with Actor {
> def receive = {
> case Bla => blabla
> }
> })
>
> Or create a stand-alone MyLogicActor class.
That is a really, really good idea. Thanks. I nominate this for inclusion on the doc site.
yours
Geir
Jonas Bonér
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
twtr: @jboner
On 2011, Feb 7, at 5:07 PM, Jonas Bonér wrote:
> I can understand the need to unit test the internal behavior in an actor.
> Best way to do that would be to decouple it from the Actor by putting
> it in a regular class/trait, test that, and then mix in the Actor
> trait when you want to create actors.
>
> // test this
> class MyLogic {
> def blabla
> }
>
> // run this
> actorOf(new MyLogic with Actor {
> def receive = {
> case Bla => blabla
> }
> })
>
> Or create a stand-alone MyLogicActor class.
That is a really, really good idea. Thanks. I nominate this for inclusion on the doc site.
yours
Geir
--
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.
Christer Sandberg
--
√iktor Klang
A little sidenote though, the changes made to "actor" in the Thread of the actor dispatcher may, or may not, ever be visible to other threads.
Christer Sandberg
Jonas Bonér
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
twtr: @jboner
√iktor Klang
Don't really understand what that means for us, but I hope we're not doing anything stupid ;)This is only a fast way to make Jetty happy (i.e. returning a marker interface) without having to senda message to the actor which returns its self.
Modifications in one Thread is not guaranteed to be seen by other Threads, that's why volatile and synchronized (and Locks) syncs local read and writes with main memory.
Jonas Bonér
Jonas Bonér
Specialist at Large
work: http://scalablesolutions.se
code: http://akka.io
twtr: @jboner
√iktor Klang
On the other hand it is way faster.
Indeed. You just need to know when you need what. ;)
√iktor Klang
Christer Sandberg
√iktor Klang
I like it alot. Now we don't need the actor to handle an ad hoc message just to get a handle to it.
Yeah, it looks very clean. Good tip!
Irmo Manie
Don't think many people have seen this yet.
https://github.com/jboner/akka/blob/master/akka-actor/src/main/scala/akka/util/TestKit.scala
Example usage:
https://github.com/jboner/akka/blob/master/akka-actor/src/test/scala/akka/actor/actor/FSMTimingSpec.scala
Maybe that is of help here?
- Irmo
Jonas Bonér
Roland Kuhn
surroundings, meaning they are fully started and communicated with only
by passing messages. This usually involves asynchronous behavior, which
is also captured by the TestKit's "within" method, but if I understand
the OP's intent correctly, in his case the focus is on testing the
receive() PartialFunction in isolation. I think that these two aspects
complement each other in a variety of usage scenarios, so it might be
worthwhile to allow that without any special gymnastics, i.e. expose the
actor behavior directly through the ActorRef in addition to its isDefinedAt.
I have had this idea nagging at the back of my mind: how about adding a
mode where all actor invocations are synchronous and on the calling
thread? This would allow easier testing, but I was also thinking of a
different benefit, namely that stack traces would be much more
informative during integration testing. Of course there are limits, e.g.
when a message is sent to an actor which is already active but "blocked"
on the current thread; in this case traditional scheduling is necessary
in order to retain original code semantics.
What do you think?
BTW: I'm Roland ;-)
√iktor Klang
The TestKit is for testing complete actors within their intended surroundings, meaning they are fully started and communicated with only by passing messages. This usually involves asynchronous behavior, which is also captured by the TestKit's "within" method, but if I understand the OP's intent correctly, in his case the focus is on testing the receive() PartialFunction in isolation. I think that these two aspects complement each other in a variety of usage scenarios, so it might be worthwhile to allow that without any special gymnastics, i.e. expose the actor behavior directly through the ActorRef in addition to its isDefinedAt.
I have had this idea nagging at the back of my mind: how about adding a mode where all actor invocations are synchronous and on the calling thread? This would allow easier testing, but I was also thinking of a different benefit, namely that stack traces would be much more informative during integration testing. Of course there are limits, e.g. when a message is sent to an actor which is already active but "blocked" on the current thread; in this case traditional scheduling is necessary in order to retain original code semantics.
I challenge you to write a CallingThreadDispatcher.
You don't even need to write a unit-test, you can reuse the common dispatcher test suite:
https://github.com/jboner/akka/blob/master/akka-actor/src/test/scala/akka/dispatch/ActorModelSpec.scala#L301
WDYT? :-)
Cheers,
Roland Kuhn
√iktor Klang
What shall I say, other than that I feel compelled to accept the challenge. However, it will probably take some time, given my other work load.
I'm cool with that :-)
Geir Hedemark
> I have had this idea nagging at the back of my mind: how about adding a mode where all actor invocations are synchronous and on the calling thread? This would allow easier testing, but I was also thinking of a different benefit, namely that stack traces would be much more informative during integration testing. Of course there are limits, e.g. when a message is sent to an actor which is already active but "blocked" on the current thread; in this case traditional scheduling is necessary in order to retain original code semantics.
>
> What do you think?
+1 for the synchronous idea.
(But I still think it would be neat to be able to test an actor class easily)
I also think it would be a really good idea to be able to block messages being sent (to "single-step" a system, if you will) and to be able to inspect messages that have been sent.
yours
Geir
Roland Kuhn
interactive inspection, e.g. in a debugger. It should be possible to
find the right break point to set in the dispatcher to this effect. If
you are unsure, you can subclass your own dispatcher and debug that.
As for automated testing, I don't see an advantage here, because with a
non-trivial actor setup you probably will have some variance in the
sequence of invocation for the different actors, so it will probably be
easier to inject "probe" actors and expect the right results there
within the allotted time. I usually feed those results back into the
central test routine using BlockingQueues.
Regards,
Roland
Geir Hedemark
>> I also think it would be a really good idea to be able to block messages being sent (to "single-step" a system, if you will) and to be able to inspect messages that have been sent.
> Trying to guess what you mean: this sounds like it is only useful for interactive inspection, e.g. in a debugger. It should be possible to find the right break point to set in the dispatcher to this effect. If you are unsure, you can subclass your own dispatcher and debug that.
Actually, it would also be helpful when following message flows.
I come from a hardware design background, and have written my fair share of VHDL, which is sort-of-like a language where you describe parallel computing using an imperative language. For loops get unrolled to several instances, and/or/not get turned into gates and so on, there are constructs for latches, flipflops and so on.
That kind of code gets tested in a simulator. All simulators are built on a lock-step operating principle. You apply stimulus, you want until all activity dies out, and then you inspect what happened. You can stop signals traveling along paths until you say it is ok for them to pass. Then you wait until all activity dies out, and so on.
As a testing paradigm, this kind of simulator is very powerful. And of course, I know how it works, which is probably why I am going on about it. It would be cool to be able to do something similar-ish to test system level behaviour in actor-based systems.
> As for automated testing, I don't see an advantage here, because with a non-trivial actor setup you probably will have some variance in the sequence of invocation for the different actors, so it will probably be easier to inject "probe" actors and expect the right results there within the allotted time. I usually feed those results back into the central test routine using BlockingQueues.
If you have variance in the invocation of your actors and that affects the end result of whatever you are trying to do, it would be called a race condition. Those bits are part of why almost nobody does async designs in hardware - they are bloody hard to get right. The only successful example I can think of is the ARM range of microprocessors, where some async designs are used in order to lower power consumption significantly. ARM employs some of the best hardware designers in the world to accomplish this.
Software designs will be subject to the same kinds of design hazards. To top it off, virtualization makes guesses at relative runtimes between actors impossible. Any nontrivial systems will have to handle these design issues in some way. I would have hoped we managed to dream up some testing structures that could help us detect and correct these problems outside a production environment. I don't really see asynchronous designs becoming big until we at least are able to control these kinds of problems.
In case anybody has started to sweat about their project: Only actors with branching signal flows are subject to these problems.
There probably is at least a masters degree hidden here somewhere, and I have a day job already. *sigh*
yours
Geir
√iktor Klang
CQRS makes for a very good model there:
Given Entity in state X, sent the command Y, I expect the following Events to be produced.
yours
Geir
--
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.
--
Roland Kuhn
> On 2011, Feb 8, at 9:27 PM, Roland Kuhn wrote:
>>> I also think it would be a really good idea to be able to block messages being sent (to "single-step" a system, if you will) and to be able to inspect messages that have been sent.
>> Trying to guess what you mean: this sounds like it is only useful for interactive inspection, e.g. in a debugger. It should be possible to find the right break point to set in the dispatcher to this effect. If you are unsure, you can subclass your own dispatcher and debug that.
> Actually, it would also be helpful when following message flows.
>
> I come from a hardware design background, and have written my fair share of VHDL, which is sort-of-like a language where you describe parallel computing using an imperative language. For loops get unrolled to several instances, and/or/not get turned into gates and so on, there are constructs for latches, flipflops and so on.
>
wizards for some time, so I do know what you are talking about, although
I have never actually used such a simulator myself.
> That kind of code gets tested in a simulator. All simulators are built on a lock-step operating principle. You apply stimulus, you want until all activity dies out, and then you inspect what happened. You can stop signals traveling along paths until you say it is ok for them to pass. Then you wait until all activity dies out, and so on.
>
> As a testing paradigm, this kind of simulator is very powerful. And of course, I know how it works, which is probably why I am going on about it. It would be cool to be able to do something similar-ish to test system level behaviour in actor-based systems.
>
Seeing it from your vantage point it certainly looks cool, but I have to
think quite hard to transform this into my usual perspective. In a
network of actors, applying stimulus means sending some message(s), so
waiting for activity to die out means what exactly? It can be as simple
as "no messages queued anywhere", but don't forget about calls blocked
in Future.await(timeout) or some scheduled actions. The concept of
"lock-step operation" is not always built in.
But getting back to more concrete grounds: would it suffice for your
idea if actors could be suspended, then examined (state, mailbox, etc.)
and finally released for the next step? One problem is that I don't see
a way around manually choosing the points where progress shall be blocked.
I think that my TestKit is a simple approximation of this testing
principle for those straight cases which do not need artificial blocking.
>> As for automated testing, I don't see an advantage here, because with a non-trivial actor setup you probably will have some variance in the sequence of invocation for the different actors, so it will probably be easier to inject "probe" actors and expect the right results there within the allotted time. I usually feed those results back into the central test routine using BlockingQueues.
> If you have variance in the invocation of your actors and that affects the end result of whatever you are trying to do, it would be called a race condition. Those bits are part of why almost nobody does async designs in hardware - they are bloody hard to get right. The only successful example I can think of is the ARM range of microprocessors, where some async designs are used in order to lower power consumption significantly. ARM employs some of the best hardware designers in the world to accomplish this.
>
I was not referring to race conditions, I was thinking of the order of
unrelated message invocations, where the end result is not influenced
but intermediate states may not be strictly determined, thus
complicating the assessment of correctness by an automated process.
> Software designs will be subject to the same kinds of design hazards. To top it off, virtualization makes guesses at relative runtimes between actors impossible. Any nontrivial systems will have to handle these design issues in some way. I would have hoped we managed to dream up some testing structures that could help us detect and correct these problems outside a production environment. I don't really see asynchronous designs becoming big until we at least are able to control these kinds of problems.
>
Hmm, good point. Unit tests tend to reduce the "background noise" and
hence usually do not cover the full phase space. Maybe it would be good
to have a RandomlyUnfairSometimesBlockingDispatcher for catching some of
those issues.
> In case anybody has started to sweat about their project: Only actors with branching signal flows are subject to these problems.
>
The branching might be well-hidden beneath some library callbacks or so;
best to test aggressively.
Regards,
Roland
√iktor Klang
Am 08.02.2011 21:54, schrieb Geir Hedemark:Now it all makes sense :-) I have been working close to some VHDL wizards for some time, so I do know what you are talking about, although I have never actually used such a simulator myself.
On 2011, Feb 8, at 9:27 PM, Roland Kuhn wrote:
Actually, it would also be helpful when following message flows.I also think it would be a really good idea to be able to block messages being sent (to "single-step" a system, if you will) and to be able to inspect messages that have been sent.Trying to guess what you mean: this sounds like it is only useful for interactive inspection, e.g. in a debugger. It should be possible to find the right break point to set in the dispatcher to this effect. If you are unsure, you can subclass your own dispatcher and debug that.
I come from a hardware design background, and have written my fair share of VHDL, which is sort-of-like a language where you describe parallel computing using an imperative language. For loops get unrolled to several instances, and/or/not get turned into gates and so on, there are constructs for latches, flipflops and so on.
Seeing it from your vantage point it certainly looks cool, but I have to think quite hard to transform this into my usual perspective. In a network of actors, applying stimulus means sending some message(s), so waiting for activity to die out means what exactly? It can be as simple as "no messages queued anywhere", but don't forget about calls blocked in Future.await(timeout) or some scheduled actions. The concept of "lock-step operation" is not always built in.
That kind of code gets tested in a simulator. All simulators are built on a lock-step operating principle. You apply stimulus, you want until all activity dies out, and then you inspect what happened. You can stop signals traveling along paths until you say it is ok for them to pass. Then you wait until all activity dies out, and so on.
As a testing paradigm, this kind of simulator is very powerful. And of course, I know how it works, which is probably why I am going on about it. It would be cool to be able to do something similar-ish to test system level behaviour in actor-based systems.
But getting back to more concrete grounds: would it suffice for your idea if actors could be suspended, then examined (state, mailbox, etc.) and finally released for the next step? One problem is that I don't see a way around manually choosing the points where progress shall be blocked.
def receive = {
case Foo => /*logic*/
dispatcher.suspend(self)
}
...
actorRef.dispatcher.resume(actorRef)
I think that my TestKit is a simple approximation of this testing principle for those straight cases which do not need artificial blocking.I was not referring to race conditions, I was thinking of the order of unrelated message invocations, where the end result is not influenced but intermediate states may not be strictly determined, thus complicating the assessment of correctness by an automated process.
As for automated testing, I don't see an advantage here, because with a non-trivial actor setup you probably will have some variance in the sequence of invocation for the different actors, so it will probably be easier to inject "probe" actors and expect the right results there within the allotted time. I usually feed those results back into the central test routine using BlockingQueues.If you have variance in the invocation of your actors and that affects the end result of whatever you are trying to do, it would be called a race condition. Those bits are part of why almost nobody does async designs in hardware - they are bloody hard to get right. The only successful example I can think of is the ARM range of microprocessors, where some async designs are used in order to lower power consumption significantly. ARM employs some of the best hardware designers in the world to accomplish this.
Hmm, good point. Unit tests tend to reduce the "background noise" and hence usually do not cover the full phase space. Maybe it would be good to have a RandomlyUnfairSometimesBlockingDispatcher for catching some of those issues.
Software designs will be subject to the same kinds of design hazards. To top it off, virtualization makes guesses at relative runtimes between actors impossible. Any nontrivial systems will have to handle these design issues in some way. I would have hoped we managed to dream up some testing structures that could help us detect and correct these problems outside a production environment. I don't really see asynchronous designs becoming big until we at least are able to control these kinds of problems.
The branching might be well-hidden beneath some library callbacks or so; best to test aggressively.
In case anybody has started to sweat about their project: Only actors with branching signal flows are subject to these problems.
Regards,
Roland
--
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.
Geir Hedemark
> CQRS makes for a very good model there:
> Given Entity in state X, sent the command Y, I expect the following Events to be produced.
This would be a similar model, yes, even if I am not a believer in CQRS itself.
yours
Geir
Geir Hedemark
> Seeing it from your vantage point it certainly looks cool, but I have to think quite hard to transform this into my usual perspective. In a network of actors, applying stimulus means sending some message(s), so waiting for activity to die out means what exactly? It can be as simple as "no messages queued anywhere", but don't forget about calls blocked in Future.await(timeout) or some scheduled actions. The concept of "lock-step operation" is not always built in.
It means that no actor threads are running, and no queues have messages. Hard to get more happening in that state.
> But getting back to more concrete grounds: would it suffice for your idea if actors could be suspended, then examined (state, mailbox, etc.) and finally released for the next step? One problem is that I don't see a way around manually choosing the points where progress shall be blocked.
This is true.
What we are doing now is a bit of a hack. We have an aspect around the bang methods. The aspect blocks all messages and keeps them in a queue until we say it is ok to send them on. If several functional units are present in the same pipeline, we can throw out the messages that are not relevant.
We have been having some un-nice race conditions while finding out if an actor is finished with its work, though. It is very hard to get at the time spent by Akka itself. If the actor was running in the same thread this problem would go away. We are using some awful heuristics to get at this issue right now.
> Hmm, good point. Unit tests tend to reduce the "background noise" and hence usually do not cover the full phase space. Maybe it would be good to have a RandomlyUnfairSometimesBlockingDispatcher for catching some of those issues.
More heuristics. Yay! :)
>> In case anybody has started to sweat about their project: Only actors with branching signal flows are subject to these problems.
> The branching might be well-hidden beneath some library callbacks or so; best to test aggressively.
... or by a database not being committed when a message is sent, which means the state of the system is dirty.
In a slow enough system, these issues go away.
yours
Geir
Roland Kuhn
1) A CallingThreadDispatcher is only possible if there is no shared mutable state. However, ActorModelSpec.dispatcherShouldProcessMessagesOneAtATime relies upon a CountDownLatch being changed while the actor is blocking on it. I have looked into what is documented for the Java platform and didn't find a way to intercept any blocking calls, suspend the thread with all its calling context and start a new one which returns early from the ActorRef.! method. This might be hackable (in the worst way) in C++ on Linux, but not on the JVM.
2) The closest match I could find goes along the lines of creating a new thread for each invocation, waiting (for a configurable time) within the Dispatcher.dispatch method for the thread to finish, receiving any uncaught exceptions with their stack trace and re-throwing them. If the invocation takes too long, then Dispatcher.dispatch returns "early" and the benefits are lost. This costs one thread per depth of the actor processing chain, but it gives serialized execution and complete stack traces (as far as possible). Which debug cases match this behavior?
3) A more lightweight approach for tracking message exchanges would be to tag each invocation with the message which triggered it, if any. This would probably have to be done using ThreadLocals, because an actor might call into some other class to do the sending. There would need to be a cut-off in the resulting chain of tags, of course configurable.
Concerning the single-stepping thrown in by Geir, I have as of yet been unable to come up with a consistent image how this should be used. Again, the problem is that actors may block, which makes the system unpredictable. If we could (with the help of Scala 4.0) assert via the type system that something does not depend on shared mutable state, then many a thing would be easier.
Geir Hedemark
> 1) A CallingThreadDispatcher is only possible if there is no shared mutable state. However, ActorModelSpec.dispatcherShouldProcessMessagesOneAtATime relies upon a CountDownLatch being changed while the actor is blocking on it. I have looked into what is documented for the Java platform and didn't find a way to intercept any blocking calls, suspend the thread with all its calling context and start a new one which returns early from the ActorRef.! method. This might be hackable (in the worst way) in C++ on Linux, but not on the JVM.
Um, are you talking about shared mutable state between actors now, or is there something really basic I am not catching? If actors share mutable state, why are they actors at all? I don't see the use case for this.
Or are you talking about calling out to something that blocks within an actor? In which case, it would probably be covered by some of my nonfunctional requirements if it didn't return within x milliseconds?
Please help, I am feeling dense...
yours
Geir
Roland Kuhn
> On 2011, Feb 18, at 4:01 PM, Roland Kuhn wrote:
>> 1) A CallingThreadDispatcher is only possible if there is no shared mutable state. However, ActorModelSpec.dispatcherShouldProcessMessagesOneAtATime relies upon a CountDownLatch being changed while the actor is blocking on it. I have looked into what is documented for the Java platform and didn't find a way to intercept any blocking calls, suspend the thread with all its calling context and start a new one which returns early from the ActorRef.! method. This might be hackable (in the worst way) in C++ on Linux, but not on the JVM.
> Um, are you talking about shared mutable state between actors now, or is there something really basic I am not catching? If actors share mutable state, why are they actors at all? I don't see the use case for this.
>
> Or are you talking about calling out to something that blocks within an actor? In which case, it would probably be covered by some of my nonfunctional requirements if it didn't return within x milliseconds?
>
> Please help, I am feeling dense...
I agree with your sentiment, which is why I started this investigation.
Then I looked at the test case I mention above:
@Test def dispatcherShouldProcessMessagesOneAtATime {
implicit val dispatcher = newInterceptedDispatcher
val a = newTestActor
val start,step1,step2,oneAtATime = new CountDownLatch(1)
a.start
a ! CountDown(start)
assertCountDown(start,3000, "Should process first message within 3
seconds")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 1,
msgsProcessed = 1)
a ! Meet(step1,step2)
assertCountDown(step1,3000, "Didn't process the Meet message in 3
seocnds")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 2,
msgsProcessed = 2)
a ! CountDown(oneAtATime)
assertNoCountDown(oneAtATime,500,"Processed message when not
allowed to")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 3,
msgsProcessed = 2)
step2.countDown()
assertCountDown(oneAtATime,500,"Processed message when allowed")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 3,
msgsProcessed = 3)
a.stop
assertRefDefaultZero(a)(registers = 1, unregisters = 1,
msgsReceived = 3, msgsProcessed = 3)
}
The point is that the actor shall block until step2.countDown(), which
obviously does not work with a CallingThreadDispatcher. The problem is,
as you say, that the actor blocks; for this to eventually stop,
something has to change, which I call shared mutable state (the
CountDownLatch is shared between test and actor and is mutated for
effect). While I would not design an actor like this, the test case
seems to make it clear that this should be allowed with Akka.
One could say that a CallingThreadDispatcher would be a special tool for
verifying non-blockingness (at least the wrong kind; waiting for a fixed
time span would still work); not general purpose, only for certain
tests. Hence my question: is it worthwhile?
Regards,
Roland
√iktor Klang
Am 18.02.2011 18:41, schrieb Geir Hedemark:Me neither, but see below.
On 2011, Feb 18, at 4:01 PM, Roland Kuhn wrote:
1) A CallingThreadDispatcher is only possible if there is no shared mutable state. However, ActorModelSpec.dispatcherShouldProcessMessagesOneAtATime relies upon a CountDownLatch being changed while the actor is blocking on it. I have looked into what is documented for the Java platform and didn't find a way to intercept any blocking calls, suspend the thread with all its calling context and start a new one which returns early from the ActorRef.! method. This might be hackable (in the worst way) in C++ on Linux, but not on the JVM.Um, are you talking about shared mutable state between actors now, or is there something really basic I am not catching? If actors share mutable state, why are they actors at all? I don't see the use case for this.
Guys, you're talking about internal Akka tests, and the most central ones, the ones that tests the actor model.
I agree with your sentiment, which is why I started this investigation. Then I looked at the test case I mention above:
Or are you talking about calling out to something that blocks within an actor? In which case, it would probably be covered by some of my nonfunctional requirements if it didn't return within x milliseconds?
Please help, I am feeling dense...
@Test def dispatcherShouldProcessMessagesOneAtATime {
implicit val dispatcher = newInterceptedDispatcher
val a = newTestActor
val start,step1,step2,oneAtATime = new CountDownLatch(1)
a.start
a ! CountDown(start)
assertCountDown(start,3000, "Should process first message within 3 seconds")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 1, msgsProcessed = 1)
a ! Meet(step1,step2)
assertCountDown(step1,3000, "Didn't process the Meet message in 3 seocnds")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 2, msgsProcessed = 2)
a ! CountDown(oneAtATime)
assertNoCountDown(oneAtATime,500,"Processed message when not allowed to")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 3, msgsProcessed = 2)
step2.countDown()
assertCountDown(oneAtATime,500,"Processed message when allowed")
assertRefDefaultZero(a)(registers = 1, msgsReceived = 3, msgsProcessed = 3)
a.stop
assertRefDefaultZero(a)(registers = 1, unregisters = 1, msgsReceived = 3, msgsProcessed = 3)
}
The point is that the actor shall block until step2.countDown(), which obviously does not work with a CallingThreadDispatcher. The problem is, as you say, that the actor blocks; for this to eventually stop, something has to change, which I call shared mutable state (the CountDownLatch is shared between test and actor and is mutated for effect). While I would not design an actor like this, the test case seems to make it clear that this should be allowed with Akka.
No.
What it says is that it tries to enforce the actor model, which requires some magic to test the system within the system. If you can rewrite the tests not to use CountDownLatch, feel free to do so.
Does that help?
Cheers,
One could say that a CallingThreadDispatcher would be a special tool for verifying non-blockingness (at least the wrong kind; waiting for a fixed time span would still work); not general purpose, only for certain tests. Hence my question: is it worthwhile?
Regards,
Roland
--
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.
Roland Kuhn
Regards,
Roland
√iktor Klang
The downside there is that the test will always take at least 3 seconds to run.
Regards,
Roland
Roland Kuhn
So, what about that challenge? It seems possible to do, although it's probably some work. Shall it be done?
Regards,
Roland
√iktor Klang
Sure, create a patch, I'd love to have a look at it
Regards,
Roland
--
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.
Geir Hedemark
Yes, definitely! As you say, this really is at the core of it, so I didn't even contemplate the possibility of changing this test. I'd think that changing the blocking to the benign type (Thread.sleep(3000)) should work, I'll try it on a branch. So, that changes the complete picture. I'll be back...The downside there is that the test will always take at least 3 seconds to run.
√iktor Klang
As I said, testing the actor model using actors is nontrivial and really is not a problem with a testing framework here.
Instead of provocative testing I actually make the test deterministic, which is the way I want tests for concurrent code.
Cheers,
On Feb 19, 2011 5:01 AM, "Geir Hedemark" <geir.h...@gmail.com> wrote:
On 2011, Feb 18, at 11:12 PM, √iktor Klang wrote:
>>
>> Yes, definitely! As you say, this really is ...
This is at the core of why I hate the actor test support out there (Akka is not the worst). We have to rely on heuristics, which seems to me a bit 1980-ish.Geir
--
You received this message because you are subscribed to the Google Groups "Akka User List" group...