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/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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+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.
>



-- 

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.

Reply via email to