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ł On Sunday, 4 February 2018 12:19:54 UTC, Tal Pressman wrote: > > 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 > <https://github.com/talpr/nex-akka-workshop/blob/d74619487bf85dfe449d01b03e2d44e3f346211a/server/src/main/scala/com/traiana/nagger/akka/ApiActor.scala#L156> > > 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 > > > > On Friday, February 2, 2018 at 7:37:05 PM UTC+2, Patrik Nordwall wrote: >> >> 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 >> >> >> On Tue, Jan 30, 2018 at 10:27 AM, Tal Pressman <kir...@gmail.com> wrote: >> >>> 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 >>> >>> >>> >>> On Sunday, January 28, 2018 at 5:49:53 PM UTC+2, Patrik Nordwall wrote: >>>> >>>> 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. >>>>> >>>> -- >>> >>>>>>>>>> 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. >>> >> >> >> >> -- >> >> Patrik Nordwall >> Akka Tech Lead >> Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM >> Twitter: @patriknw >> >> -- >>>>>>>>>> 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+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
