On 04.05.14 11:00, Heiko Seeberger wrote:
Not all communication follows the request-response pattern. In my case there's no need for an application level response, its only purpose is the technical ACK.

Isn't that a special case of request-response?


Heiko


On Sun, May 4, 2014 at 10:41 AM, Martin Krasser <[email protected] <mailto:[email protected]>> wrote:

    Maybe a confirm(reply: Any) method would make sense, where reply
    is sent to the sender of the Persistent message. This would also
    allow for some internal optimizations.


    On 04.05.14 10:18, Martin Krasser wrote:

    On 04.05.14 10:07, Heiko Seeberger wrote:
    On Sun, May 4, 2014 at 9:55 AM, Martin Krasser
    <[email protected] <mailto:[email protected]>> wrote:

        Hi Heiko,


        On 03.05.14 06:58, Heiko Seeberger wrote:
        Hi,

        A short-lived actor A should send a "result" message to
        some other actor B before it terminates itself. As it is
        important that this message gets delivered, I would like to
        use a channel in order to retry message delivery. In case
        of permanent delivery failure (redeliverMax exceeded) the
        short-lived actor A would send the message to some other
        actor C which would know what to do. This can be
        implemented using a redeliverFailureListener.

        My question is: How can the short-lived actor A know that
        the message has been delivered, i.e. the
        ConfirmablePersistent message has been confirmed? AFAIK
        there's no deliverSuccessListener or such.

        Actor B should send an application-level reply to actor A.
        Channels preserve sender references.


    Well, that's how I have already implemented it without channels.
    I was hoping that channels would make that easier ;-)

    The purpose of a channel is to make delivery of a message from A
    -> B more reliable (by implementing a retry-ack protocol where
    the ack is generated by the receiver by calling confirm()) and it
    shouldn't hide an application-level conversation between actors A
    and B which also includes the reply from B to A. You'd also send
    a reply if A sends a message to B without using a channel. Hence,
    when using a channel, B should confirm delivery *in addition* to
    sending a reply.


    Is it possible to add a feature like a deliverSuccessListener in
    the future?

    It's not a big deal to add that but I'm not sure if it's a good
    idea from a design perspective. Curious what others think ...


    Thanks
    Heiko

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

-- Martin Krasser

    blog:http://krasserm.blogspot.com
    code:http://github.com/krasserm
    twitter:http://twitter.com/mrt1nz

-- Martin Krasser

    blog:http://krasserm.blogspot.com
    code:http://github.com/krasserm
    twitter:http://twitter.com/mrt1nz

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




--

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name <http://blog.heikoseeberger.name>
--
>>>>>>>>>> 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] <mailto:[email protected]>. To post to this group, send email to [email protected] <mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

--
Martin Krasser

blog:    http://krasserm.blogspot.com
code:    http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--
     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.

Reply via email to