The MonitorableThreadFactory.copy method does not take into account the
counter:AtomicLong field, which then always starts out at zero for every
new dispatcher; the PinnedDispatcher creates one dispatcher per actor,
hence resulting in identical thread names if used by multiple actors.
Solution: add the counter to the case class’ arguments
- parent just checked for system messages and finds none
- Supervise is enqueued to parent
- Failed is enqueued to the parent
- Failed is processed before Supervise and thus dropped due to
non-matching UID
remedy is to enqueue NullMessage after enqueuing Supervise but before
really starting the actor, so that if NullMessage overtakes Supervise
the loop in processMailbox will then pick up Supervise next
- every ActorCell has a UID which is generated from ThreadLocalRandom
and also sent with Supervise and Failed messages, and the supervisor
simply does not act upon failures from children whose UID does not
match
This has brought to light some interesting effects (aka bugs) both in
the general implementation as well as in previous fixes.
SupervisorHierarchySpec is without TODOs now and GREEN.
- always suspend/resume for Suspend/Resume/Recreate, no matter which
state the actor is in, to keep the counter balanced
- preRestart failures are logged but otherwise ignored; there’s nothing
else (apart from terminating the actor) which we could do at that
point
- preRestart/postRestart exceptions have their own distinguishable
subtype of ActorKilledException now
- fix some race conditions in tests to make them produce fewer false
failures
- remove cruft from SupervisorStrategy and add methods which can
actually be used to implement your own (with proper warning signs)
- introducing RepointableActorRef, which starts out with an
UnstartedActorCell which can cheaply be created; the Supervise()
message will trigger child.activate() in the supervisor, which means
that the actual creation (now with normal ActorCell) happens exactly
in the right place and with the right semantics. Messages which were
enqueued to the dummy cell are transferred atomically into the
ActorCell (using normal .tell()), so message sends keep working
exactly as they used to
- this enables getting rid of the brittle synchronization around
RoutedActorRef by replacing that one with a RepointableActorRef
subclass which creates RoutedActorCells upon activate(), with the nice
benefit that there is no hurry then to get it right because the new
cell is constructed “on the side”
misc fixes:
- InvalidMessageException is now actually enforced when trying to send
“null”
- Mailboxes may be created without having an ActorCell, which can come
in handy later, because the cell is only needed when this mailbox is
going to be scheduled on some executor
- remove occurrences of Props(), which is equivalent to Props[Nothing],
which is equivalent to «bug»
- add test case which verifies that context.actorOf is still synchronous
- plus all the stuff I have forgotten.
- extend systemDrain to take the new contents which shall be switched in
- make NoMessage placeholder which will signal final closing of the
mailbox
- put that in when cleaning up, and check it when enqueuing
- ActorCell.stop(actor) removed the actor from childrenRefs before
handleChildTerminated, leading to removing from Locker immediately
after adding it in
- intercept ChildTerminated message in RemoteTransport.receive if
destination is not found (i.e. isTerminate==true) and re-route to
Locker, which was changed to support path-based lookup to find the
parent and funnel the ChildTerminated to its intended destination
- add Locker.shutdown() to detach remaining actors from their
dispatchers upon system termination.
split systemDispatch(Create()) into systemEnqueue(Create()) directly
after createMailbox and registerForExecution from within
Dispatcher.attach() (resp. CallingThreadDispatcher.register() does its
own thing)