Akka typed - first impressions

[Tal Pressman]

I finally had the chance to use Akka Typed, and wanted to share my experience. So basically, I took a small demo project that was based on untyped actors, and implemented it using typed ones. (This is based on 2.4.8, but I think most of it is still relevant)

To start off with the good things:
* Typed actors completely eliminated bugs involving mixing up `ActorRef`s - passing wrong refs, mixing up order of parameters, sending responses to the wrong place.
* The functional approach taken for typed actors (behaviors returning the next behavior) also eliminated bugs that revolved around "doing stuff from `Future` callbacks".
* The thing I was probably worried about most - not having `sender` any more - turned out to be a non-issue. In fact, because now it has to be on the received message, it makes it immutable, thus helping with the `Future`-related bugs.

Now for the "annoyances" (in no specific order):
* Using the various factory methods to create behaviors means you don't have direct access to "protected" behavior methods, most notably the ActorContext. If you need it, you either use `Actor.immutable` and get a "new" context with each message, or you use Actor.deferred which is a bit more clunky (you need a function that returns a behavior, which is itself a function).
* This is more of a Scala type-inference issue, but having to specify the type when using `ask` is pretty annoying. What seems to work best for me is having utility methods
on the "actor" that return `ActorRef[Response] => Message`, but it's a bit boilerplatey.
* Another issue related to asking is that there is no equivalent to untyped ask's Status.Failure. If the "request" can fail, this has to be modeled in the response (replying with a `Try`, or something equivalent), and means that now the caller has 3 cases to handle instead of 2. So now instead of ask-map-pipe in one line, it turns into
ask-transform(3 cases)-foreach.
* No "easy" access to logging - there's already a PR waiting for this, so not really an issue.

Overall, though, I have to say it's shaping up real nicely. I'm looking forward to see what happens to it next.

Tal

[Patrik Nordwall]

Hi Tal,

Thanks a lot for taking it for a spin and sharing feedback. Comments inline...

sön 28 jan. 2018 kl. 14:10 skrev Tal Pressman <kir...@gmail.com>:

I finally had the chance to use Akka Typed, and wanted to share my experience. So basically, I took a small demo project that was based on untyped actors, and implemented it using typed ones. (This is based on 2.4.8, but I think most of it is still relevant)

To start off with the good things:
* Typed actors completely eliminated bugs involving mixing up `ActorRef`s - passing wrong refs, mixing up order of parameters, sending responses to the wrong place.
* The functional approach taken for typed actors (behaviors returning the next behavior) also eliminated bugs that revolved around "doing stuff from `Future` callbacks".
* The thing I was probably worried about most - not having `sender` any more - turned out to be a non-issue. In fact, because now it has to be on the received message, it makes it immutable, thus helping with the `Future`-related bugs.

Now for the "annoyances" (in no specific order):
* Using the various factory methods to create behaviors means you don't have direct access to "protected" behavior methods, most notably the ActorContext. If you need it, you either use `Actor.immutable` and get a "new" context with each message, or you use Actor.deferred which is a bit more clunky (you need a function that returns a behavior, which is itself a function).

That is “only” when you need the context when the actor is started. When receiving messages the context is always there as a parameter.

One  perhaps related thing is that for a “more complicated” actor you typically want to break it up in many methods/functions and you have to pass a lot of parameters around to all. I’m not sure if that is only me that see that as somewhat annoying. One way is to anyway create an exclosing class and keeping such common parameters there. Especially in Java I think that will often be used. (Or use mutable behavior).

* This is more of a Scala type-inference issue, but having to specify the type when using `ask` is pretty annoying. What seems to work best for me is having utility methods
on the "actor" that return `ActorRef[Response] => Message`, but it's a bit boilerplatey.

There is a new actor-to-actor ask. Would be interesting to hear what you think of that.

https://github.com/akka/akka/pull/24335

* Another issue related to asking is that there is no equivalent to untyped ask's Status.Failure. If the "request" can fail, this has to be modeled in the response (replying with a `Try`, or something equivalent), and means that now the caller has 3 cases to handle instead of 2. So now instead of ask-map-pipe in one line, it turns into
ask-transform(3 cases)-foreach.

Failure case is only for timeout, and in the actor-to-actor ask that is represented as a specific message that you define.

* No "easy" access to logging - there's already a PR waiting for this, so not really an issue.

Overall, though, I have to say it's shaping up real nicely. I'm looking forward to see what happens to it next.

Glad to hear that. Yes, we agree, it’s going to be awesome.

/Patrik

Tal

--
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[Tal Pressman]

Hi Patrik,

Thanks for pointing me at the actor-to-actor pull request - it seems like it would be very useful in "pipe to self" use-cases. It makes me wonder, though, if it wouldn't be possible to do something similar while "piping" to other actors.

In my experience (which admittedly, may not be representative), I have found that I use pipeTo(sender) much more than pipeTo(self). The main use-case where I see this is something like this:

• "Client" actor sends a request to some "singleton" actor.
• The "Singleton" actor routes the request to the appropriate destination. There are a few variations on these actors - sometimes they transform the requests/responses, sometimes they create child actors to route the request to. The important thing is they don't change state/behavior based on the response.
• A single "request" flow can have several of these "singleton" actors, each considering the previous one the "client".

In such cases, I much prefer transforming the future and piping back to the sender, as that keeps all the code in one place (in contrast, pipe-to-self breaks up the message flow and makes it hard to find the connection between the original request and its response).

A possible solution to this could be to allow spawning adapters for other ActorRefs other than 'self'.

Another thing regarding this API is that it hides the Future, making some patterns much more complicated (combining multiple asks, for example). This is probably fine, since you can still use the "external ask" API, but it's something to think about.

(As an aside, the PR also drew my attention to the fact that I was leaking adapters, so that's something...)

Tal

[Patrik Nordwall]

I have published a snapshot of latest Akka Typed progress if you would like to try it out. Version 2.5-20180202-180000 in repo https://repo.akka.io/snapshots/

Latest documentation: https://doc.akka.io/docs/akka/snapshot/typed/index.html

Cheers,

Patrik

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.

To post to this group, send email to akka...@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--

Patrik Nordwall
Akka Tech Lead
Lightbend -  Reactive apps on the JVM
Twitter: @patriknw

[Tal Pressman]

Thanks!
I switched my code over to the new version, and once I got past all the Actor -> Behaviors changes everything seems to work very nicely.

If you're interested, you can see the code here (it's part of a course, so there isn't much code there ^_^ ): https://github.com/talpr/nex-akka-workshop/tree/akka-snapshot-ask

As I originally thought, the "actor ask" provides a nice API over `spawnAdater`, but there are quite a few places where it is quite restrictive. Specifically, things like this where I need to combine several responses and then transform them before sending the final response back (without having to process it in the "current" actor). But this is just some points for thought, overall it's really nice!

Tal

Patrik Nordwall
Akka Tech Lead

[Michal Borowiecki]

Hi Patrik,

Thanks for the latest snapshot. I've been trying to play around with akka typed by migrating the project I'm working on and previously I'd been stuck at implementing stashing. Now with the StashBuffer it got simple.

Overall I'm really happy. It took a lot of time but I managed to migrate and test the system (all written in java) and all seems good. It's over a dozen actors and > 100 different message types. Most of them I turned into mutable behaviors as typically they have a lot of state. On the few smallest ones, I tried out the immutable style. The integration with akka-streams and akka-http was straightforward but we're not using persistence or clustering in this project, so haven't played with those in their typed variants yet. Overall, the contracts between actors got move apparent now and I even found one bug where an actor ref to the wrong actor was being passed into a method in our old code.

Beside all the positives, there are really only 2 things that I struggled with, that I'd like to share:

* routers - to migrate our RoundRobinPool routers, I followed the example from your blog (the immutable variant). What caused me problems was how to implement broadcast. I ended up defining a parent Broadcast class that holds the actual message and then subclassed it for each router so as to also implement the interface that's the type-parameter of the target behavior. I don't currently see a way to remove this duplication, so I wonder if you can offer any better advice?

* testing - the docs suggest to subclass TestKit and use a @AfterClass method to shut it down, however, that didn't work. JUnit requires @BeforeClass and @AfterClass annotated methods to be static. I worked around this in 2 different ways depending on complexity of the test. If the test suite creates some actors in the @BeforeClass method, then I do not subclass TestKit but just create an instance of it in a static field and call the various methods on that instance, including shutdown from the @AfterClass. In tests that don't need a TestKit instance in their @BeforeClass initialization, I do extend TestKit for convenience and then simply never call shutdown on it. I haven't seen that cause any problems so far. 

Thanks again for all the hard work going into akka-typed. Hope to see the latest improvements come out in a release soon :-)

Cheers,

Michał