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
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
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
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
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
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
+1 for PersistentActor
Heiko
On Tue, May 20, 2014 at 10:50 PM, Roland Kuhn goo...@rkuhn.info wrote:
Hi Odd,
that is a very good question: I was operating under the premise that
EventsourcedProcessor is used quite a bit by now and renaming it might not
be met with unlimited enthusiasm. The
On 09.05.14 09:25, Roland Kuhn wrote:
9 maj 2014 kl. 09:08 skrev Martin Krasser krass...@googlemail.com
mailto:krass...@googlemail.com:
On 09.05.14 08:41, Roland Kuhn wrote:
Hi Martin,
9 maj 2014 kl. 08:05 skrev Martin Krasser krass...@googlemail.com
mailto:krass...@googlemail.com:
9 maj 2014 kl. 09:58 skrev Martin Krasser krass...@googlemail.com:
On 09.05.14 09:25, Roland Kuhn wrote:
9 maj 2014 kl. 09:08 skrev Martin Krasser krass...@googlemail.com:
On 09.05.14 08:41, Roland Kuhn wrote:
Hi Martin,
9 maj 2014 kl. 08:05 skrev Martin Krasser
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
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
9 maj 2014 kl. 14:57 skrev Chanan Braunstein chanan.braunst...@pearson.com:
Since you asked for feedback:
We are using EventsourcedProcessor and have no plans to use Processor. We saw
the benchmarks and read the docs that Processor is faster, but choose to
model our system using
Of course, but if the channel-internal ACK has already arrived, why should
we require another application-level one that might get lost?
Heiko
On Mon, May 5, 2014 at 4:25 PM, Martin Krasser krass...@googlemail.comwrote:
On 05.05.14 14:59, Heiko Seeberger wrote:
On the other hand, an
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
On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.comwrote:
Hi Heiko,
On 03.05.14 06:58, Heiko Seeberger wrote:
Hi,
A short-lived actor A should send a result message to some other actor
B before it terminates itself. As it is important that this message gets
On 04.05.14 10:07, Heiko Seeberger wrote:
On Sun, May 4, 2014 at 9:55 AM, Martin Krasser
krass...@googlemail.com mailto:krass...@googlemail.com wrote:
Hi Heiko,
On 03.05.14 06:58, Heiko Seeberger wrote:
Hi,
A short-lived actor A should send a result message to some
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
Not all communication follows the request-response pattern. In my case
there's no need for an application level response, its only purpose is the
technical ACK.
Heiko
On Sun, May 4, 2014 at 10:41 AM, Martin Krasser krass...@googlemail.comwrote:
Maybe a confirm(reply: Any) method would make
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
Maybe yes.
Heiko
On Sun, May 4, 2014 at 12:57 PM, Martin Krasser krass...@googlemail.comwrote:
On 04.05.14 11:00, Heiko Seeberger wrote:
Not all communication follows the request-response pattern. In my case
there's no need for an application level response, its only purpose is the
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
21 matches
Mail list logo
