scala - Is TestActorRef deadlock possibility still relevant? -


in akka 2.3.9 documentation there warning:

any message send testprobe actor runs on callingthreaddispatcher runs risk of dead-lock, if other actor might send probe. implementation of testprobe.watch , testprobe.unwatch send message watchee, means dangerous try watching e.g. testactorref testprobe.

i tried reproduce described deadlock situation in test using testprobe , testactorref both using callingthreaddispatcher

class deadlocktest extends testkit(actorsystem()) funsuitelike {   test("deadlock attempt") {     val b = testprobe()     val = testactorref(new actor {       override def prestart() = b.ref ! "pre"       def receive = {         case msg =>           sender ! msg           context.stop(self)       }     })     b.watch(a)     b.send(a, "foo")     b.expectmsg("pre")     b.expectmsg("foo")     b.expectterminated(a)     b.unwatch(a)   } } 

i expected test hang passed.

is warning still relevant , possibility of deadlock high or outdated?

the race condition warning speaks inherent in testprobe’s design probability of hitting deadlock rather small, watch must occur @ same time sending message in other direction , both must happen in different threads. latter can in rare cases observed due way top-level actors created.

all of rather tricky , none of applies way tests written , conducted akka typed, i'm looking forward when mode used.


Comments

Popular posts from this blog

java - Custom OutputStreamAppender not run: LOGBACK: No context given for <MYAPPENDER> -

java - UML - How would you draw a try catch in a sequence diagram? -

c++ - No viable overloaded operator for references a map -