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.