Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi Alex,
the main concern you express is that messages sent from an
EventsourcedProcessor are eventually delivered to their recipients, which is
what a durable message queue (formerly called PersistentChannel) is for. The
main use of the non-persistent Channel is to deduplicate messages, but it
fundamentally cannot do that reliably in any case (since a confirmation may
have been on its way when it crashed).
In the solution you describe, if your Earnings must make sure to send to the
Aggregator, then they will in either case need to resend the message
periodically until confirmed, not only during restart, otherwise the message
can be deferred indefinitely; this is the same regardless of which transport
helper is used. My concrete proposal would be to store unconfirmed outbound
messages in the Earnings’ state and resend based on a timer tick—this extends
naturally to recovery after a machine crash.
I think we’ll see this resending functionality factored out in a common trait
soon as more people start building software this way.
Regards,
Roland
21 maj 2014 kl. 15:30 skrev ahjohannessen ahjohannes...@gmail.com:
Hi Roland,
You state the following:
...talks about Channel since that was only needed to contain the
side-effecting replay nature of command sourced processors.
A channel is also needed when sending events from an eventsourced processor
to another actor when one needs at-least-once delivery rather
than at-most-once:
def receiveRecover: Receive = {
case event: String = handleEvent(event)
}
def handleEvent(event: String) = {
// update state
// ...
// reliably deliver events
channel ! Deliver(Persistent(event), destination.path)
// alternatively something that encapsulates this pair
}
We are dependent on this very functionality for reliable coordination in our
apps and removing Channel leaves us worried.
...Your description below is rather terse, so it is not fully clear to me
how you are using Channel in this case and what a replacement should be, can
you elaborate?
As stated earlier, we have many eventsourced processors of same type, e.g.
1 instances of Earnings, that are loaded on demand by a supervisor
when a command enters into the domain. When an instance is loaded the command
is forwarded to this guy and when the command
results in domain events we acknowledge to sender in the persist callback
*but* also forward the persistent message to another actor, let's call it
stream,
that needs to react to this. It ensures that a calculation is initiated by
delivering a message to a change reactor via a unique channel.
Furthermore stream also ensures that a message is delivered, via another
unique channel, to an EarningsAggregator that essentially replicates all of
those 1 instances' events, because we need a global view in order to
maintain read models.
In receiveRecover we *also* forward replayed events to stream in order to
ensure that messages get delivered, via channels, to the respective
destinations,
in the case of a JVM crash.
During system start up we start all recently active (say last 24 hours)
Earnings instances to ensure that all calculations are triggered and that our
EarningsAggregator
gets the event, again in the name of crash paranoia. These instances shut
themselves down after a reasonable receive timeout in order to keep memory
footprint low.
This roughly happens by sending a passivate me message to their supervisor
which in turn ensures a proper shutdown and all of the instance's messages
are
processed by using a combination of poison pill, become, stash and listening
to terminated.
In the above I mention Earnings eventsourced processor, however we have
around 10 similar types under same supervisor that are similarly structured
and have the same
need of what a channel gives us.
Other usages of channels that we have are communication among processes.
Often here it is perfectly fine for us to use channels because it ensures
that something eventually
will happen, some eventsourced processor emits an event to reactor (ordinary
actor) via a channel (also during receiveRecover) that transforms the event
to a command in the
language of another eventsourced processor. All of such processes are
idempotent and maintaining an queue on both sides is just a lot of useless
busywork in most of our
use cases.
I have no idea of what a replacement of Channel would be because I do not
have an issue with it and think it is a good primitive that solves many of
our use cases in ways
that are satisfying and saves us a lot of work trying to re-implement the
same functionality.
...My motivation here is to not remove needed functionality without improved
replacement.
That is good to know :)
On Tuesday, May 20, 2014 7:32:38 PM UTC+1, rkuhn wrote:
Hi Alex,
I have filed the ticket for Processor’s removal
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Also +1 for PersistentActor Am Dienstag, 20. Mai 2014 22:50:48 UTC+2 schrieb rkuhn: Hi Odd, that is a very good question: I was operating under the premise that EventsourcedProcessor is used quite a bit by now and renaming it might not be met with unlimited enthusiasm. The replacement for PersistentChannel will need to be named differently since the “persistent” in the name is confusing, but the details will have to wait until we have settled on its precise nature. Perhaps we can do a “quick deprecation” for EventsourcedProcessor in 2.4-M1 (since it is marked “experimental” for this very reason), aliasing it until removal. I quite like PersistentActor, Processor is too generic. Opinions? Regards, Roland 20 maj 2014 kl. 22:39 skrev Odd Möller odd.m...@gmail.com javascript:: Hi! Just wanted to say that I love the idea of simplifying the abstractions as suggested in this thread (all our processors are already of the event sourced kind). One thing that occurred to me is if a similar simplification can be done on the naming of the concepts: now that the names Processor and Channel are unused, should the remaining concept still be called EventsourcedProcessor? What about calling it Processor, PersistentActor or EventsourcedActor instead? Ditto regarding the reborn PersistentChannel. Greetings Odd On Tue, May 20, 2014 at 8:47 PM, 何品 hepi...@gmail.com javascript:wrote: I am using the persistent channel as a durable queue,and for it was not recommend ,I switch to redis . 在 2014年5月21日星期三UTC+8上午2时32分38秒，rkuhn写道： Hi Alex, I have filed the ticket for Processor’s removal ( https://github.com/akka/akka/issues/15230), which also talks about Channel since that was only needed to contain the side-effecting replay nature of command sourced processors. Your description below is rather terse, so it is not fully clear to me how you are using Channel in this case and what a replacement should be, can you elaborate? There is also the discussion ticket for reinventing PersistentChannel ( https://github.com/akka/akka/issues/15231) which might be of interest in this context. My motivation here is to not remove needed functionality without improved replacement. Regards, Roland 9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.com: Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi Roland,
You state the following:
*...talks about Channel since that was only needed to contain the
side-effecting replay nature of command sourced processors.*
A channel is also needed when sending events from an eventsourced processor
to another actor when one needs at-least-once delivery rather
than at-most-once:
def receiveRecover: Receive = {
case event: String = handleEvent(event)
}
def handleEvent(event: String) = {
// update state
// ...
// reliably deliver events
channel ! Deliver(Persistent(event), destination.path)
// alternatively something that encapsulates this pair
}
We are dependent on this very functionality for reliable coordination in
our apps and removing Channel leaves us worried.
*...Your description below is rather terse, so it is not fully clear to me
how you are using Channel in this case and what a replacement should be,
can you elaborate?*
As stated earlier, we have many eventsourced processors of same type, e.g.
1 instances of Earnings, that are loaded on demand by a supervisor
when a command enters into the domain. When an instance is loaded the
command is forwarded to this guy and when the command
results in domain events we acknowledge to sender in the persist callback
*but* also forward the persistent message to another actor, let's call it
stream,
that needs to react to this. It ensures that a calculation is initiated by
delivering a message to a change reactor via a unique channel.
Furthermore stream also ensures that a message is delivered, via another
unique channel, to an EarningsAggregator that essentially replicates all of
those 1 instances' events, because we need a global view in order to
maintain read models.
In receiveRecover we *also* forward replayed events to stream in order to
ensure that messages get delivered, via channels, to the respective
destinations,
in the case of a JVM crash.
During system start up we start all recently active (say last 24 hours)
Earnings instances to ensure that all calculations are triggered and that
our EarningsAggregator
gets the event, again in the name of crash paranoia. These instances shut
themselves down after a reasonable receive timeout in order to keep memory
footprint low.
This roughly happens by sending a passivate me message to their
supervisor which in turn ensures a proper shutdown and all of the
instance's messages are
processed by using a combination of poison pill, become, stash and
listening to terminated.
In the above I mention Earnings eventsourced processor, however we have
around 10 similar types under same supervisor that are similarly structured
and have the same
need of what a channel gives us.
Other usages of channels that we have are communication among processes.
Often here it is perfectly fine for us to use channels because it ensures
that something eventually
will happen, some eventsourced processor emits an event to reactor
(ordinary actor) via a channel (also during receiveRecover) that transforms
the event to a command in the
language of another eventsourced processor. All of such processes are
idempotent and maintaining an queue on both sides is just a lot of useless
busywork in most of our
use cases.
I have no idea of what a replacement of Channel would be because I do not
have an issue with it and think it is a good primitive that solves many of
our use cases in ways
that are satisfying and saves us a lot of work trying to re-implement the
same functionality.
*...My motivation here is to not remove needed functionality without
improved replacement.*
That is good to know :)
On Tuesday, May 20, 2014 7:32:38 PM UTC+1, rkuhn wrote:
Hi Alex,
I have filed the ticket for Processor’s removal (
https://github.com/akka/akka/issues/15230), which also talks about
Channel since that was only needed to contain the side-effecting replay
nature of command sourced processors. Your description below is rather
terse, so it is not fully clear to me how you are using Channel in this
case and what a replacement should be, can you elaborate?
There is also the discussion ticket for reinventing PersistentChannel (
https://github.com/akka/akka/issues/15231) which might be of interest in
this context. My motivation here is to not remove needed functionality
without improved replacement.
Regards,
Roland
9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.comjavascript:
:
Hi Roland,
We use Channel in conjunction with Eventsourced Processor (EP) in our
applications in receiveRecover.
It would be sad to see it go away without a reasonable alternative.
One scenario in our apps is that we use DDD/ES and have a lot of EPs of
same type, e.g. 1 instances,
that are loaded on demand by a supervisor.
In order to have a single view on all of these, we inject an actor that
wraps a single channel / aggregator EP combo
into these instances on creation. This makes it possible to react to
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi Alex, I have filed the ticket for Processor’s removal (https://github.com/akka/akka/issues/15230), which also talks about Channel since that was only needed to contain the side-effecting replay nature of command sourced processors. Your description below is rather terse, so it is not fully clear to me how you are using Channel in this case and what a replacement should be, can you elaborate? There is also the discussion ticket for reinventing PersistentChannel (https://github.com/akka/akka/issues/15231) which might be of interest in this context. My motivation here is to not remove needed functionality without improved replacement. Regards, Roland 9 maj 2014 kl. 12:15 skrev ahjohannessen ahjohannes...@gmail.com: Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve - repeatable reads - low read latency and - high write throughput reads can go to the STM refs directly and EP must update the STM ref only after having persisted the events. If one *additionally* wants to achieve - read-your-own-write consistency (assuming a client issues an update command, immediately followed by a read command) one would need a way to loop read commands through the journal as well before serving them (which probably requires an addition to the API then). Alternatively, a client only issues a read after having received a write-ack (at the cost of an
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
I am using the persistent channel as a durable queue,and for it was not recommend ,I switch to redis . 在 2014年5月21日星期三UTC+8上午2时32分38秒，rkuhn写道： Hi Alex, I have filed the ticket for Processor’s removal ( https://github.com/akka/akka/issues/15230), which also talks about Channel since that was only needed to contain the side-effecting replay nature of command sourced processors. Your description below is rather terse, so it is not fully clear to me how you are using Channel in this case and what a replacement should be, can you elaborate? There is also the discussion ticket for reinventing PersistentChannel ( https://github.com/akka/akka/issues/15231) which might be of interest in this context. My motivation here is to not remove needed functionality without improved replacement. Regards, Roland 9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.comjavascript: : Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve - repeatable reads - low read latency and - high write throughput reads can go to the STM refs directly and EP must update the STM ref only after having persisted the events. If one *additionally* wants to achieve - read-your-own-write consistency (assuming a client issues an update command, immediately followed by a read command) one would need a way to loop read commands through the journal as well
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi Odd, that is a very good question: I was operating under the premise that EventsourcedProcessor is used quite a bit by now and renaming it might not be met with unlimited enthusiasm. The replacement for PersistentChannel will need to be named differently since the “persistent” in the name is confusing, but the details will have to wait until we have settled on its precise nature. Perhaps we can do a “quick deprecation” for EventsourcedProcessor in 2.4-M1 (since it is marked “experimental” for this very reason), aliasing it until removal. I quite like PersistentActor, Processor is too generic. Opinions? Regards, Roland 20 maj 2014 kl. 22:39 skrev Odd Möller odd.mol...@gmail.com: Hi! Just wanted to say that I love the idea of simplifying the abstractions as suggested in this thread (all our processors are already of the event sourced kind). One thing that occurred to me is if a similar simplification can be done on the naming of the concepts: now that the names Processor and Channel are unused, should the remaining concept still be called EventsourcedProcessor? What about calling it Processor, PersistentActor or EventsourcedActor instead? Ditto regarding the reborn PersistentChannel. Greetings Odd On Tue, May 20, 2014 at 8:47 PM, 何品 hepin1...@gmail.com wrote: I am using the persistent channel as a durable queue,and for it was not recommend ,I switch to redis . 在 2014年5月21日星期三UTC+8上午2时32分38秒，rkuhn写道： Hi Alex, I have filed the ticket for Processor’s removal (https://github.com/akka/akka/issues/15230), which also talks about Channel since that was only needed to contain the side-effecting replay nature of command sourced processors. Your description below is rather terse, so it is not fully clear to me how you are using Channel in this case and what a replacement should be, can you elaborate? There is also the discussion ticket for reinventing PersistentChannel (https://github.com/akka/akka/issues/15231) which might be of interest in this context. My motivation here is to not remove needed functionality without improved replacement. Regards, Roland 9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.com: Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
+1 for PersistentActor Heiko On Tue, May 20, 2014 at 10:50 PM, Roland Kuhn goo...@rkuhn.info wrote: Hi Odd, that is a very good question: I was operating under the premise that EventsourcedProcessor is used quite a bit by now and renaming it might not be met with unlimited enthusiasm. The replacement for PersistentChannel will need to be named differently since the “persistent” in the name is confusing, but the details will have to wait until we have settled on its precise nature. Perhaps we can do a “quick deprecation” for EventsourcedProcessor in 2.4-M1 (since it is marked “experimental” for this very reason), aliasing it until removal. I quite like PersistentActor, Processor is too generic. Opinions? Regards, Roland 20 maj 2014 kl. 22:39 skrev Odd Möller odd.mol...@gmail.com: Hi! Just wanted to say that I love the idea of simplifying the abstractions as suggested in this thread (all our processors are already of the event sourced kind). One thing that occurred to me is if a similar simplification can be done on the naming of the concepts: now that the names Processor and Channel are unused, should the remaining concept still be called EventsourcedProcessor? What about calling it Processor, PersistentActor or EventsourcedActor instead? Ditto regarding the reborn PersistentChannel. Greetings Odd On Tue, May 20, 2014 at 8:47 PM, 何品 hepin1...@gmail.com wrote: I am using the persistent channel as a durable queue,and for it was not recommend ,I switch to redis . 在 2014年5月21日星期三UTC+8上午2时32分38秒，rkuhn写道： Hi Alex, I have filed the ticket for Processor’s removal ( https://github.com/akka/akka/issues/15230), which also talks about Channel since that was only needed to contain the side-effecting replay nature of command sourced processors. Your description below is rather terse, so it is not fully clear to me how you are using Channel in this case and what a replacement should be, can you elaborate? There is also the discussion ticket for reinventing PersistentChannel ( https://github.com/akka/akka/issues/15231) which might be of interest in this context. My motivation here is to not remove needed functionality without improved replacement. Regards, Roland 9 maj 2014 kl. 12:15 skrev ahjohannessen ahjoha...@gmail.com: Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser krass...@googlemail.com mailto:krass...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser krass...@googlemail.com mailto:krass...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve - repeatable reads - low read latency and - high write throughput reads can go to the STM refs directly and EP must update the STM ref only after having persisted the events. If one *additionally* wants to achieve - read-your-own-write consistency (assuming a client issues an update command, immediately followed by a read command) one would need a way to loop read commands through the journal as well before serving them (which probably requires an addition to the API then). Alternatively, a client only issues a read after having received a write-ack (at the cost of an additional roundtrip). Anyway, I think you convinced me, as usual :) Great proposal, Dr Kuhn! Cheers, Martin -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
9 maj 2014 kl. 09:58 skrev Martin Krasser krass...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser krass...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser krass...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve - repeatable reads - low read latency and - high write throughput reads can go to the STM refs directly and EP must update the STM ref only after having persisted the events. If one *additionally* wants to achieve - read-your-own-write consistency (assuming a client issues an update command, immediately followed by a read command) one would need a way to loop read commands through the journal as well before serving them (which probably requires an addition to the API then). Alternatively, a client only issues a read after having received a write-ack (at the cost of an additional roundtrip). This is an interesting remark: normally read-your-writes is only guaranteed for reads submitted after having received the ACK for the write, so what we are providing here is actually a qualitative improvement on that status quo that is only possible in Reactive systems (normally the ACK is signaled by a synchronous non-exceptional method return). Anyway, I think you convinced me, as usual :) Great proposal, Dr Kuhn! And as usual you helped in refining the proposal: the addition of looping non-persistent events through the journal is an important one, thanks for providing the use-case! So, to summarize, we can incorporate all current functionality provided by Processor and Channel into EventsourcedProcessor by adding the following two features: the ability to opt out of stashing everything while waiting for persist()ing the ability to loop non-persistent events through the journal Everyone, please consider what this would mean for your code base and comment, now is the right time to speak up! The same goes for opinions on whether PersistentChannel pulls its weight or not (as argued earlier in this thread). Regards, Roland Cheers, Martin -- 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
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.comjavascript: : On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.comjavascript: : On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.comjavascript: : Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve - repeatable reads - low read latency and - high write throughput reads can go to the STM refs directly and EP must update the STM ref only after having persisted the events. If one *additionally* wants to achieve - read-your-own-write consistency (assuming a client issues an update command, immediately followed by a read command) one would need a way to loop read commands through the journal as well before serving them (which probably requires an addition to the API then). Alternatively, a client only issues a read after having received a write-ack (at the cost of an additional roundtrip). This is an interesting remark: normally read-your-writes is only guaranteed for reads submitted after having received the ACK for the write, so what we are providing here is actually a qualitative improvement on that status quo that is only possible in Reactive systems (normally the ACK is signaled by a synchronous non-exceptional method return). Anyway, I think you convinced me, as usual :) Great proposal, Dr Kuhn! And as usual you helped in refining the proposal: the addition of looping non-persistent events through the journal is an important one, thanks for providing the use-case! So, to summarize, we can incorporate all current functionality provided
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Hi all, Interesting discussion. I have no problem removing command sourced Processor from user API, with the added capabilities of EventsourcedProcessor. I have thought of P as a low level building block and only to be used for simple write-ahead-log scenarios. External side-effects during replay makes me shiver. I'm not so sure about removing PersistentChannel. It's a useful at-least-once delivery tool. It is not that easy to implement this stuff yourself. For example, how to handle unbounded number of unacknowledged requests? PersistentChannel does not store everything in memory. How to avoid flooding slow consumers? My canonical use case for PersistentChannel is the safe-handoff between system/component boundaries. Frontend server provides REST endpoint to external system. When it replies OK 200 it means that it has taken over responsibility for the request. When it replies ERR 5xx it means that the responsibility is still at the requesting system, i.e. it has to retry later. The replies must be done within milliseconds. Frontend endpoint sends the request to backend service via a PersistentChannel, and when it has received the ACK from the PersistentChannel it can reply. Isn't this (and variations of it) something that we should provide a tool for? Cheers, Patrik On Fri, May 9, 2014 at 12:15 PM, ahjohannessen ahjohannes...@gmail.comwrote: Hi Roland, We use Channel in conjunction with Eventsourced Processor (EP) in our applications in receiveRecover. It would be sad to see it go away without a reasonable alternative. One scenario in our apps is that we use DDD/ES and have a lot of EPs of same type, e.g. 1 instances, that are loaded on demand by a supervisor. In order to have a single view on all of these, we inject an actor that wraps a single channel / aggregator EP combo into these instances on creation. This makes it possible to react to changes, even in case of JVM crashes, in that family of EPs as well as having a global view of that family. On Friday, May 9, 2014 9:13:17 AM UTC+1, rkuhn wrote: 9 maj 2014 kl. 09:58 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 09:25, Roland Kuhn wrote: 9 maj 2014 kl. 09:08 skrev Martin Krasser kras...@googlemail.com: On 09.05.14 08:41, Roland Kuhn wrote: Hi Martin, 9 maj 2014 kl. 08:05 skrev Martin Krasser kras...@googlemail.com: Hi Roland, thanks for starting a discussion on this. Here are some initial thoughts on your proposal: ... very same throughput optimization by applying the state changes before persisting them ... I think we agree that whatever changes are going to be made in the future, we must keep the throughput optimizations (by batching writes/updates). As you said, with an EP, this can only be achieved by applying events to current state *before* persisting them. Furthermore, to enable batching, an EP must therefore be able to process new commands while (previous) events are about to be persisted. This however has a very important consequence for commands that read current state. If we allow events to be applied to current state *before* persisting them, we allow clients to read state from that EP that may not be re-readable after a crash. For example: - EP receives update command, derives event and applies it immediately to current state - EP (asynchronously) persists event - EP receives a read command (while event persistence is in progress) - EP (successfully) returns read response to requestor - EP JVM crashes before event was successfully persisted - EP state cannot be reconstructed i.e. previous read cannot be repeated. This is only true if the recovery is incomplete: the update command will not have been acknowledged at this point, so if someone cared about it they will send it again during recovery and the EP will eventually end up in a state where the read will return the same value again. If this type of consistency is not good enough, then you can always defer reads within the write model until after persistence is completed, meaning that the read is only performed once a corresponding read “event” has gone through the journal. We could allow events that are only looped through to make this work, just like non-Persistent commands are looped today (and for the same reason). Delaying reads is only an option when reads are made via messages to a (E)P. If my processor manages state via an STM ref where only the processor updates the STM ref but reads go directly to the STM ref, then you cannot delay reads. In this scenario you would delay updating the STM ref until after the persistence loop, which is exactly the same as for a current command-sourced Processor: the read gets delayed until after the writes are processed, in the same way the STM ref update gets delayed by the write having to go through the journal. Effects, consistency and latency are the same in both implementations. That's true. So, to achieve -
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
9 maj 2014 kl. 14:57 skrev Chanan Braunstein chanan.braunst...@pearson.com:
Since you asked for feedback:
We are using EventsourcedProcessor and have no plans to use Processor. We saw
the benchmarks and read the docs that Processor is faster, but choose to
model our system using traditional DDD. We understood the trade-off we were
making. The proposal to add something like async=true is perfect for us. We
can then decide which aggregates should have full consistency (even down to
the event level although, I imagine we would keep it at the aggregate level)
and which we can live with less consistency but gain speed. I think it makes
the choice very clear and explicit.
Thanks for confirming!
I am not clear on what the ability to loop non-persistent events through the
journal this means exactly. Can you elaborate?
In response to a read request your EP does not immediately respond, rather it
invokes the currently fictitious method “loopback(myReadEvent){ sender() !
theResult }”, which will ensure that the read only occurs after all previously
processed writes have been properly persisted. This means that you can keep
full read consistency without having to incur the write performance overhead of
async=false. It does however depend on the architecture surrounding the EP to
resend things after a crash, which is why async=false might still make sense in
some scenarios.
Lastly views. Currently they are too limiting to be very useful. The idea is
a good one, but without being able to project over multiple EP/Ps it is too
limiting for anything real (At least in our application). Currently in
order to have a view that works on EP1 and EP2 I would need to send both sets
of events to EP3, re-persist them and create a V over it. So for us, views
would only be useful if we could go over multiple EP/P. If the reactive
streams would allow that it would be great! To add to that, the stream
semantic makes sense for what a View is meant to be (in my eyes). The name
View is misleading and makes you think of a snapshot in time. In my eyes, a
View should be a way to look into the Stream of persisted events, allowing
you to do some sort of processing over it.
Yes, exactly, that is where we should be headed!
Regards,
Roland
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn
--
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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Of course, but if the channel-internal ACK has already arrived, why should we require another application-level one that might get lost? Heiko On Mon, May 5, 2014 at 4:25 PM, Martin Krasser krass...@googlemail.comwrote: On 05.05.14 14:59, Heiko Seeberger wrote: On the other hand, an application level ACK is an additional message that might get lost ... The same is true for the channel-internal ACK. Heiko On Sun, May 4, 2014 at 8:06 PM, Heiko Seeberger heiko.seeber...@gmail.com wrote: Maybe yes. Heiko On Sun, May 4, 2014 at 12:57 PM, Martin Krasser krass...@googlemail.comwrote: 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 krass...@googlemail.com 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 krass...@googlemail.com 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 -- 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
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
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. Thanks Heiko -- 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.comwrote: 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 ;-) Is it possible to add a feature like a deliverSuccessListener in the future? 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
On 04.05.14 10:07, Heiko Seeberger wrote: On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.com mailto:krass...@googlemail.com 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
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 krass...@googlemail.com mailto:krass...@googlemail.com 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
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. Heiko On Sun, May 4, 2014 at 10:41 AM, Martin Krasser krass...@googlemail.comwrote: 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 krass...@googlemail.comwrote: 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 -- 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
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 krass...@googlemail.com mailto:krass...@googlemail.com 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 krass...@googlemail.com mailto:krass...@googlemail.com 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com mailto:akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com mailto:akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com
Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
Maybe yes. Heiko On Sun, May 4, 2014 at 12:57 PM, Martin Krasser krass...@googlemail.comwrote: 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 krass...@googlemail.comwrote: 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 krass...@googlemail.comwrote: 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. 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 -- 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 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
[akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?
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. Thanks Heiko -- Heiko Seeberger Twitter: @hseeberger Blog: 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
