Greetings,
When I look at standard examples with Akka we always see very specific
typed actors that handle messages of a certain type and return certain
values. This tends to lead to big recieve methods with large amounts of
code in them or a plethora of helper messages. I got to thinking about why
we didn't simply package up the functionality inside the message as a means
to implement the code. Its a slightly different architecture but might have
some merits and I wanted to get your comments on it. For reference consider
the following:
case class DoSomethingMessage(msg: String)
class SomeActor extends Actor {
val log = Logging(context.system, this)
override def receive: Receive = {
case DoSomethingMessage(msg) =>
log.info(s"Message had ${msg.length} chars and had text '$msg'")
// do other stuff
sender ! "thanks"
case msg => log.error(s"received unknown message of type ${msg.getClass}")
}
}
This is the standard way things are done. Now imagine that the do other
stuff is performing 30 lines of code to accomplish something. However,
consider the following architecture:
case class DoSomethingElseMessage(msg: String) extends
Function1[LoggingAdapter, String] {
override def apply(log: LoggingAdapter): String = {
log.info(s"Message had ${msg.length} chars and had text '$msg'")
// do other stuff
"Thanks"
}
}
class SomeOtherActor extends Actor {
val log = Logging(context.system, this)
override def receive: Receive = {
case f: Function1[LoggingAdapter, _] =>
sender ! f.apply(log)
case msg => log.error(s"received unknown message of type ${msg.getClass}")
}
}
This is interesting to me because I can define specific untyped actors that
simply process 'smart' messages sent to them and to accomplish the task
they execute the code in the apply method. The concept can be extended to
any other type of Callable, Runnable, or Function you wish. This would
allow the actors to be generic and isolate the code to the messages. What
is more the messages could be declared inside domain objects and thus have
access to private internals of the class. This would allow the messages to
do certain things while denying that functionality to other users. Finally
it would allow me to cut down on the number of case blocks in the actor in
the case of having hundreds of different message types (which on occasion
we do.)
So is there any reason why such an architecture would be a bad thing? I
know you would not get some of the become() functionality of the actor but
such things could be done in specialized subclasses of this actor if they
are needed for the particular use case. Again that would mean that we can
reduce the number of handlers to only these special messages.
Comments on the idea? Id love to hear from those with a lot more Akka
experience than I.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
