My upcoming book Reactive Messaging Patterns with the Actor Model
discusses the use of PersistentView to support a Durable Subsriber.
On May 10, 2015 4:00 PM, Alejandro López ale64...@gmail.com wrote:
@Olger Thanks for the detailed explanation of your approach. As Richard
mentioned, it looks
@Olger Thanks for the detailed explanation of your approach. As Richard
mentioned, it looks indeed like using persistent actor as durable queue.
Is there any concrete effort started already in the direction of supporting
this in Akka? Or at least there's some example implementations on this
Thanks. So I guess you're basically using a persistent actor as a durable
queue, in place of something like a Kafka topic, and a single message on
the queue can include ids of multiple aggregates.
On Sat, May 9, 2015 at 10:51 AM, Olger Warnier ol...@spectare.nl wrote:
Hi Richard,
I use the
Hi Richard,
I use the akka cluster sharding mechanism to start instances of a
PersistentActor.
This actor stands for a single instance of an AggregateRoot (DDD concept)
This specific instance contains the logic required to run.
For instance this can be a UserAccount instance of a
Hi Alejandro,
You have a number of options
- when you have a single persistence Id, write a view for that
- when you want to aggregate events of several persistence ids, you can do so
via the event store (approach of Martin (with Kafka) and Greg (event store) )
Or you can aggregate the
Right now, what would be the best alternative in order to create
projections, allowing views to subscribe to arbitrary events as described
by Roland above? (or at least a coarse approximation)
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi Olger
Could you please elaborate a bit on your appoach? I'm not sure I follow.
Thanks.
On Fri, May 8, 2015 at 4:17 AM, Olger Warnier ol...@spectare.nl wrote:
Hi Alejandro,
You have a number of options
- when you have a single persistence Id, write a view for that
- when you want to
Hi Magnus,
Thanks for your extended answer.
Currently, I've solved it with application code and this thread and the
thread before was about finding ways to support more use cases with akka
persistence. The DDD Aggregate Root is one of them and that needs quite
some plumbing to get it going.
Greg, I agree with you there. I do not disagree with convenience. :)
But where are different kinds of convenience:
As a devops person I want to minimize shared state in order to have pieces
of software that can fail and start independently. I want to sleep at night
and have free weekends.
So
OK, then at least I know that much. :) I'll be staying tuned then for when
things are picked up again. Thanks. /Magnus
2015-04-17 16:14 GMT+02:00 Patrik Nordwall patrik.nordw...@gmail.com:
On Thu, Apr 16, 2015 at 10:32 AM, Magnus Andersson
magnus.anders...@mollyware.se wrote:
Hi
Sorry
On Thu, Apr 16, 2015 at 10:32 AM, Magnus Andersson
magnus.anders...@mollyware.se wrote:
Hi
Sorry for being late to the party. I hope you don't mind a question around
the PersistentView part:
The way I read it the default interaction would be the following:
case class
Hi
Sorry for being late to the party. I hope you don't mind a question around
the PersistentView part:
The way I read it the default interaction would be the following:
case class QueryByPersistenceId(id: String, fromSeqNr: Long, toSeqNr: Long)
case class EventStreamOffer(metadata:
Hello Roland,
Any news on this please. When we can expect implementation roughly? Your
response will be really appreciated.
Regards
Murali
On Wednesday, 27 August 2014 20:04:30 UTC+5:30, rkuhn wrote:
Dear hakkers,
there have been several very interesting, educational and productive
Will updated read side include ability to replay views from multiple
streams? It's common scenario when view may need to handle events of some
types from multiple different event sources. I think main problem here is
causal ordering of events across multiple streams. And as I understand such
Most systems that store state say ORM and publish events are just really
broken (in a subtle way). They have the problem of two sources of truth
(what if they disagree?)
On Monday, September 1, 2014 6:58:56 AM UTC+1, Ashley Aitken wrote:
Thank you Markus for a very useful contribution.
I
Hi Roland,
sounds great that you are pushing for the whole CQRS story.
I'm just experimenting with akka and CQRS and have no production
experience, but I'm thinking about the concepts since some time. So please
take my comments with a big grain of salt and forgive me for making it
sound
Thank you Markus for a very useful contribution.
I too included a link to that architecture diagram in a previous post in
another thread. I think the provision of an eventbus for CQRS to
integrate with other bounded contexts on the write-side and, of course, the
read-side is very important
Hi Ashley,
Personally I'm having a little trouble understanding how your three points
differ much. Couldn't you extend PersistentActor as something like
TopicEnricher and make it's enrich method call persist? I see your need,
but I think it's enough out of the scope of ES that it is probably more
Hi Roland,
I went through important discussion on querying
at https://groups.google.com/forum/#!msg/akka-user/SL5vEVW7aTo/KfqAXAmzol0J.
But it did not take me to any conclusion. Thanks for this conclusion post.
Journal will always have the history of events. Why one will query for
history of
Hi Roland,
thanks for the summary, I think that's the right direction.
In your summary, the only query command type pre-defined in
akka-persistence is QueryByPersistenceId. I'd find it useful to further
pre-define other query command types in akka-persistence to cover the
most common use
Hi Martin,
On Thursday, August 28, 2014 8:01:43 AM UTC+1, Martin Krasser wrote:
In your summary, the only query command type pre-defined in
akka-persistence is QueryByPersistenceId. I'd find it useful to further
pre-define other query command types in akka-persistence to cover the most
I am unable to understand, How for business specific querying event stream
will function?
Journal will always have the history of events. Why one will query for
history of events? Most of the queries will require current state.
I linked a video in this thread that covers some such reasons
On
Hi Roland,
great conclusion, with everything said till now in mind. I'd like to
mention a view points and like to hear if this matches your thoughts:
The QueryByTypeDeterministic(type, from, to) mentioned by Martin matches
with the way I've been using DDD+CQRS for last 2 years.
Meaning that
Hi Roland,
It's a good summary. As far as I can see it looks very complete and allows
for a lot of flexibility between scalability and ease of use.
I will add that I am interested to see Martin's causal consistency with
zero application-specific hints or code (unless its just obvious previous
A few things.
First, while it is common that a projection is interested in only events
from a type of producer (aggregate/actor/etc) it's also quite common they
need to listen from many types.
I believe that it is quite important to have these API case classes
standardized as much as is
Thank you Roland and team for listening and sharing your ideas and plans.
As I have said, I think there are three different but related areas of
functionality being discussed here: 1) Actor Persistence, 2)
Publish-Subcribe (to Topics), and 3) Full CQRS support.
Conceptually, for CQRS (3), I
26 matches
Mail list logo
