Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[ahjohannessen]

Hi Roland,

All good and thanks for being helpful. That clears things up :) 

Btw, PersistentActor has a good ring to it.


On Tuesday, May 27, 2014 8:44:11 AM UTC+1, rkuhn wrote:
>
> Hi Alex,
>
> 26 maj 2014 kl. 21:57 skrev ahjohannessen 
> >:
>
> Hi Roland,
>
> 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).
>
>
> I don't follow your train of thought here. We use 
> *apply-event-and-notify-via-channel" during normal operation *and* recovery 
> in Earnings. I don't see how making Earnings concern itself with maintaing 
> state of acks for each and every domain event improves matters - that is 
> what persistent.confirms + channel during recovery is useful for in this 
> case. Earnings' journal is *the* durable message queue here because we just 
> want to make sure that events from it are replicated in a corresponding 
> aggregator due to the fact that there is currently no way to get a global 
> view of EPs of same type.
>
> Earnings itself does not care whether Aggregator gets its messages, it is 
> just a technical workaround for missing global views for EPs of same type. 
> The calculation triggering I mentioned in an earlier post can easily be 
> changed to an EarningsAggregator View based approach, but using a separate 
> channel was less work.
>
> A separate durable message queue seems overkill for our use case.
>
>
> I think we are talking past each other: let’s make up a name for the new 
> PersistentChannel that will be efficient at redelivery and also clear its 
> state from old messages that are already confirmed (since our Persistence 
> journals are not made for this use-case), say we call it X. Instead of 
> using a Channel, you would continue to do the same thing with an X, X will 
> fully replace both Channel and PersistentChannel.
>
> In addition you will not need this workaround anymore because we will 
> allow you to reliably subscribe to and merge the event streams from any 
> number of PersistentActors.
>
> Does this clear things up, or am I still missing something?
>
> My explanation below, which I can see now must have been confusing to you, 
> was about implementing guaranteed, lossless delivery of events within a 
> PersistentActor network. As I tried to point out, just sending to a Channel 
> does not necessarily achieve the same thing, even if you also do it during 
> recovery, since recovery may never happen (i.e. Channel fails, but actor 
> does not). For replication of events from the journal we can make it work, 
> because the journal will then be the sender (so we can implement retries).
>
> Regards,
>
> Roland
>
>
> This is the general flow we have for all of our registrators, Earnings is 
> one of those:
>
> trait RegistrationFlow[ST] extends EventsourcedProcessor {
>   this: RegistrationBehavior[ST] ⇒
>
>   val pid: String
>   override val processorId: String = pid
>
>   def stream: ActorRef
>
>   final def receiveCommand = commands orElse questions
>   final def receiveRecover = recover
>
>   private def questions: Receive = {
> case q: Question if questionHandler.isDefinedAt(q) ⇒
>   sender() ! questionHandler(q)(state)
>   }
>
>   private def commands: Receive = {
> case c: Command if commandHandler.isDefinedAt(c) ⇒
>   commandHandler(c)(state) match {
> case Success(events)  ⇒ handleEvents(events)(sender() ! 
> ACK(c.correlationId))
> case Failure(failure) ⇒ sender() ! NACK(failure, c.correlationId)
> }
>   }
>
>   private def recover: Receive = {
> case e: Event ⇒ applyAndEmit(e)
>   }
>
>   private def handleEvents(events: Seq[Event])(doneSignal: ⇒ Unit) = {
> if(events.isEmpty) doneSignal else {
>   val lastEventToPersist = events.last
>   persist(events) { pe ⇒
> applyAndEmit(pe)
> if(pe == lastEventToPersist) doneSignal
>   }
> }
>   }
>
>   private def applyAndEmit(e: Event) = {
> apply(e)
> currentPersistentMessage foreach(stream ! _)
>   }
>
>   private def apply(e: Event) = {
> if (eventHandler.isDefinedAt(e))
>   state = eventHandler(e)(state)
>   }
>
>   private var state = stateBuilder
> }
>
>
>  
>
> 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 

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Roland Kuhn]

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 :

> 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, rk

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[ahjohannessen]

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 
> >:
>
> 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 p

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Carsten Saathoff]

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 >:
>
> 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, 何品 >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 :
>>>
>>> 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 :

  
 On 09.05.14 09:25, Roland Kuhn wrote:
  

  9 maj 2014 kl. 09:08 skrev Martin Krasser :

  
 On 09.05.14 08:41, Roland Kuhn wrote:
  
 Hi Martin, 

  9 maj 2014 kl. 08:05 skrev Martin Krasser :

  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 someo

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

+1 for PersistentActor

Heiko


On Tue, May 20, 2014 at 10:50 PM, Roland Kuhn  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 :
>
> 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, 何品  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 :
>>>
>>> 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 :


 On 09.05.14 09:25, Roland Kuhn wrote:


  9 maj 2014 kl. 09:08 skrev Martin Krasser :


 On 09.05.14 08:41, Roland Kuhn wrote:

 Hi Martin,

  9 maj 2014 kl. 08:05 skrev Martin Krasser :

  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

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Roland Kuhn]

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 :

> 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, 何品  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 :
> 
>> 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 :
>> 
>>> 
>>> On 09.05.14 09:25, Roland Kuhn wrote:
 
 9 maj 2014 kl. 09:08 skrev Martin Krasser :
 
> 
> On 09.05.14 08:41, Roland Kuhn wrote:
>> Hi Martin,
>> 
>> 9 maj 2014 kl. 08:05 skrev Martin Krasser :
>> 
>>> 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 st

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Odd Möller]

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, 何品  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 :
>>
>> 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 :
>>>
>>>
>>> On 09.05.14 09:25, Roland Kuhn wrote:
>>>
>>>
>>>  9 maj 2014 kl. 09:08 skrev Martin Krasser :
>>>
>>>
>>> On 09.05.14 08:41, Roland Kuhn wrote:
>>>
>>> Hi Martin,
>>>
>>>  9 maj 2014 kl. 08:05 skrev Martin Krasser :
>>>
>>>  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
>>

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 
> >:
>
> 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 :
>>
>>  
>> On 09.05.14 09:25, Roland Kuhn wrote:
>>  
>>
>>  9 maj 2014 kl. 09:08 skrev Martin Krasser :
>>
>>  
>> On 09.05.14 08:41, Roland Kuhn wrote:
>>  
>> Hi Martin, 
>>
>>  9 maj 2014 kl. 08:05 skrev Martin Krasser :
>>
>>  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, immediate

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Roland Kuhn]

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 :

> 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 :
> 
>> 
>> On 09.05.14 09:25, Roland Kuhn wrote:
>>> 
>>> 9 maj 2014 kl. 09:08 skrev Martin Krasser :
>>> 
 
 On 09.05.14 08:41, Roland Kuhn wrote:
> Hi Martin,
> 
> 9 maj 2014 kl. 08:05 skrev Martin Krasser :
> 
>> 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)
>

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Roland Kuhn]

9 maj 2014 kl. 14:57 skrev Chanan Braunstein :

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

[Chanan Braunstein]

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.

I am not clear on what "the ability to loop non-persistent events through 
the journal" this means exactly. Can you elaborate?

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.


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

[Jonas Bonér]

I think this is an excellent proposal.

I've been out there talking to lots of users that are using (or want to
use) Akka Persistence and most of them are struggling with the current
complexity of the Processor/Channel/Persistent combo and when to use it and
when to rely on EventsourcedProcessor instead. I also find it a lot more
natural and intuitive to explain how pure event sourcing works since it
makes the concepts and design very clean; what is side-effects, what is
state change and what is a fact—and not having to expose persistence to the
client. To be honest, EP is the only thing I've been willing to talk about
and recommend up to now. I'd be very happy to see P/C go. That would make
Akka Persistence really simple actually.

I also agree with Patrik. I've seen PersistentChannel as something very
separate from P/C/EP, with very different use-cases. We need to fully
understand what we are getting rid of and what the alternatives are if we
remove it.



On Fri, May 9, 2014 at 1:16 PM, Patrik Nordwall
wrote:

> 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 wrote:
>
>> 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 :
>>>
>>>
>>> On 09.05.14 09:25, Roland Kuhn wrote:
>>>
>>>
>>>  9 maj 2014 kl. 09:08 skrev Martin Krasser :
>>>
>>>
>>> On 09.05.14 08:41, Roland Kuhn wrote:
>>>
>>> Hi Martin,
>>>
>>>  9 maj 2014 kl. 08:05 skrev Martin Krasser :
>>>
>>>  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 d

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Patrik Nordwall]

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 wrote:

> 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 :
>>
>>
>> On 09.05.14 09:25, Roland Kuhn wrote:
>>
>>
>>  9 maj 2014 kl. 09:08 skrev Martin Krasser :
>>
>>
>> On 09.05.14 08:41, Roland Kuhn wrote:
>>
>> Hi Martin,
>>
>>  9 maj 2014 kl. 08:05 skrev Martin Krasser :
>>
>>  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 

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[ahjohannessen]

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 
> >:
>
>  
> On 09.05.14 09:25, Roland Kuhn wrote:
>  
>
>  9 maj 2014 kl. 09:08 skrev Martin Krasser 
> 
> >:
>
>  
> On 09.05.14 08:41, Roland Kuhn wrote:
>  
> Hi Martin, 
>
>  9 maj 2014 kl. 08:05 skrev Martin Krasser 
> 
> >:
>
>  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 functionali

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Roland Kuhn]

9 maj 2014 kl. 09:58 skrev Martin Krasser :

> 
> On 09.05.14 09:25, Roland Kuhn wrote:
>> 
>> 9 maj 2014 kl. 09:08 skrev Martin Krasser :
>> 
>>> 
>>> On 09.05.14 08:41, Roland Kuhn wrote:
 Hi Martin,
 
 9 maj 2014 kl. 08:05 skrev Martin Krasser :
 
> 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/
> >

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Martin Krasser]

On 09.05.14 09:25, Roland Kuhn wrote:


9 maj 2014 kl. 09:08 skrev Martin Krasser >:




On 09.05.14 08:41, Roland Kuhn wrote:

Hi Martin,

9 maj 2014 kl. 08:05 skrev Martin Krasser >:



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?

[Heiko Seeberger]

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 wrote:

>
> 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  > wrote:
>
>> Maybe yes.
>>
>>  Heiko
>>
>>
>> On Sun, May 4, 2014 at 12:57 PM, Martin Krasser 
>> wrote:
>>
>>>
>>> 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 >> > 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 >>> > 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
>>> Twit

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Martin Krasser]

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 
mailto:heiko.seeber...@gmail.com>> wrote:


Maybe yes.

Heiko


On Sun, May 4, 2014 at 12:57 PM, Martin Krasser
mailto:krass...@googlemail.com>> wrote:


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

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

On the other hand, an application level ACK is an additional message that
might get lost ...

Heiko


On Sun, May 4, 2014 at 8:06 PM, Heiko Seeberger
wrote:

> Maybe yes.
>
> Heiko
>
>
> On Sun, May 4, 2014 at 12:57 PM, Martin Krasser 
> wrote:
>
>>
>> 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 
>> 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 
>>> 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 ak

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

Maybe yes.

Heiko


On Sun, May 4, 2014 at 12:57 PM, Martin Krasser wrote:

>
> 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 
> 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 
>> 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 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://git

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Martin Krasser]

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

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

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

[Martin Krasser]

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

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Martin Krasser]

On 04.05.14 10:07, Heiko Seeberger wrote:
On Sun, May 4, 2014 at 9:55 AM, Martin Krasser 
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 
.
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 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?

[Heiko Seeberger]

On Sun, May 4, 2014 at 9:55 AM, Martin Krasser 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 ;-)

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?

[Martin Krasser]

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