Akka 2.6.6: context.log.error("string") failed

Akka Libraries
1

Switched from 2.6.5 to 2.6.6 and I get the following error when I use context.log.It started working again after I removed the log statement. Was that use incorrect? Thanks for 2.6.6, especially with the SplitBrainResolver.

2020-06-13T08:12:40.692+0000 ERROR <.api-akka.actor.default-dispatcher-178> [dispatch.Dispatcher]   Unsupported access to ActorContext from the outside of Actor[akka://api/system/singletonManagerapi/api#664341361]. No message is currently processed by the actor, but ActorContext was called from Thread[api-akka.cluster-dispatcher-21,5,main].
java.lang.UnsupportedOperationException: Unsupported access to ActorContext from the outside of Actor[akka://api/system/singletonManagerapi/api#664341361]. No message is currently processed by the actor, but ActorContext was called from Thread[api-akka.cluster-dispatcher-21,5,main].
	at akka.actor.typed.internal.ActorContextImpl(ActorContextImpl.scala:317) ?[sd-0.1.jar:?]
	at akka.actor.typed.internal.ActorContextImpl(ActorContextImpl.scala:305) ?[sd-0.1.jar:?]
	at akka.actor.typed.internal.adapter.ActorContextAdapter(ActorContextAdapter.scala:49) ?[sd-0.1.jar:?]
	at akka.actor.typed.internal.ActorContextImpl(ActorContextImpl.scala:161) ?[sd-0.1.jar:?]
	at akka.actor.typed.internal.ActorContextImpl(ActorContextImpl.scala:160) ?[sd-0.1.jar:?]
	at akka.actor.typed.internal.adapter.ActorContextAdapter(ActorContextAdapter.scala:49) ?[sd-0.1.jar:?]
2

context.log is not thread-safe and should only be accessed from the message processing thread, or setup, of the actor with that context.

Typical invalid usages are:

  • from a Future callback
  • from Akka streams operators
  • from wrong actor, eg child actor accessing context of parent actor

If you can’t figure out what is wrong you can show what your code looks like and we might be able to spot it.

This runtime check is new in 2.6.6, so that’s why you haven’t seen it before.

3

Got the same problem where I was using ctx.log.info(…) from inside a stream which was running inside an actor.

The newly introduced error makes sense, but do you have any guidance on how you could do ad-hoc logging from inside an akka stream? This could also apply to any async callback where the callback is executing outside the normal message handling.

4

The newly introduced error makes sense, but do you have any guidance on how you could do ad-hoc logging from inside an akka stream?

Create your own org.slf4j.Logger with org.slf4j.LoggerFactory instead of using the logger that is owned by the actor.

2 Likes
5

I was under impression that the Future’s callback which uses the actor’s ExecutionContext should be called by the actor’s scheduler, similar to a message, thread-safe to the actor’s state? Is it wrong assumption?

Is the “pipe to self” the only thread-safe way to schedule the callback to be able to mutate the actor’s state?

6

I was under impression that the Future’s callback which uses the actor’s ExecutionContext should be called by the actor’s scheduler, similar to a message, thread-safe to the actor’s state? Is it wrong assumption?

Yes, that assumption is wrong.

The only way to safely execute and touch mutable actor state is through a message. Using the context.executionContext/dispatcher only allows you to share the same dispatcher that the actor is using, any work scheduled there will still run independently of the actor.

pipeTo self of futures (and sometimes, when pipeTo is a bad fit, explicit tell in callbacks) is the safe way.