0
votes

I have an application which runs an actor system with a supervisor that can receive messages via akka remoting. Messages that are sent from the remote actor system are case classes, example:

case class SupervisorStartChannel(channelName: String) extends SupervisorRequest

case class SupervisorShutdown() extends SupervisorRequest

Within my receive, I have the following:

def receive: Actor.Receive = LoggingReceive ({
    case SupervisorListChannels =>
      listChannels()

    case SupervisorReportComponents =>
      sender ! loadConfiguredComponents()

    case SupervisorStartChannel(channelName) =>
      sender ! startChannelByName(channelName)

    case SupervisorShutdown =>
      log.info("Shutdown received.")
      sender ! SupervisorAck
      context.system.terminate()

    case _ =>
      replayError(s"$supervisorName can't process an empty command.")

}: Receive) andThen metered.Receive

If I send a SupervisorShutdown from inside the same actor system where the supervisor is running, it enters the correct case, however when sending the SupervisorShutdown() from the remote system it enters the case _. While sending a SupervisorStartChannel(channel1) works perfectly.

EDIT: After running some tests I found that the issue comes from the serialization of that case class SupervisorShutdown() extends SupervisorRequest. Akka uses the default Java serializer for remoting and that is causing it.

Any idea what could be causing this?

1
Did you try to add brackets to your case clause: case SupervisorShutdown() => or use object instead of case class: object SupervisorShutdown? - dyrkin
@dyrkin yes I did, and since internal messages (within the same actor system) do work, makes me believe this is an issue with remoting. - Fede E.
After additional tests I found that this is an issue with the serializations. ActorSystem -> ActorSystem messages are being serialized. And since that case class SupervisorShutdown() extends SupervisorRequest is serialized with the default Java serializer is not being properly received. - Fede E.

1 Answers

-1
votes

As @dyrkin suggested, after running a couple tests, this was solved by using SupervisorShutdown() instead of SupervisorShutdown, and then matching also with the SupervisorShutdown().