Howdy All,
This is my first post and I am new to Akka and Scala but very excited about
using Akka Persistence and CQRS / ES for a new Web application I am
developing. I have been reading a lot about CQRS / ES and playing around
with Akka Persistence and have a few questions I hope you can
I thought reactive applications were all event-based and, in particular,
events could be generated and flow through an application from GUI back to
GUI.
Does the way Akka Persistence Views work prevent this (since they are, if I
understand correctly, essentially polling for events)?
Can
I believe Martin may have kindly answered, at least part of, this question
in another thread.
If I may paraphrase him: the way Akka Persistence Views work currently
(polling) is an implementation detail and later versions of Akka
Persistence may provide a push-based approach as well.
If
On Tuesday, 6 May 2014 15:18:29 UTC+8, Martin Krasser wrote:
The availability of (new) events in the journal is also an event. Whether
a view is actively notified about their availability (= push) or if the
view tries to find out itself (= pull) is rather a technical detail. A
pull-based
Thanks again Martin.
On Tuesday, 6 May 2014 14:37:48 UTC+8, Martin Krasser wrote:
Good so I am on the write track. I am confused a little about the Views
keeping stage in memory and with snapshots. What state would this be?
Surely the read model itself is maintaining most of the state,
Thanks Martin.
On Tuesday, 6 May 2014 15:53:28 UTC+8, Martin Krasser wrote:
On 06.05.14 09:31, Ashley Aitken wrote:
Reactive I take to mean push, the events are driving action in the system,
from GUI to GUI.
From a user's (= API) perspective, a View will always receive Persistent
Sorry for the delay in responding - I had lots of work work to attend to.
Vaughn - thank you for your suggestion regarding the EventBus. To be
honest, as I am new to Akka I was not really aware that the EventBus even
existed. Now that I am, I still need to get my head around the use of
Martin kindly explained:
Each processor has its own logical journal, although journal plugins
maintain them in a single physical backend store (replicated or not). This
is not a requirement but all plugins follow this pattern so far. So, from a
physical viewpoint there's a single big
Howdy All,
I've been reading lots of threads on the Akka User mailing list and pull
requests and blog posts within the community but I am confused about what
currently are the best practices for:
1. Distributed and Resilient Pub-Sub within Akka
It seems to me that a resilient pub-sub is a
Hi Patrick,
On Wednesday, 13 November 2013 03:19:08 UTC+8, Patrik Nordwall wrote:
The order could, in our case, as well be claim-earnings-2 events followed
by claim-earnings-1 events.
Ok, then it can be implemented on top of existing processor building block.
Can you please give me a
Thank you for your post Endre.
On Friday, 20 June 2014 16:39:46 UTC+8, Akka Team wrote:
Can you please give me a quick idea of how this could be implemented
effectively now (i.e. a View with a known set of Processors to follow)?
A View corresponds to one processorId but you can have for
Sorry to bring this thread up again but I am still trying to work out the
read model in CQRS with Akka Persistence.
On Tuesday, 6 May 2014 15:18:29 UTC+8, Martin Krasser wrote:
The availability of (new) events in the journal is also an event. Whether
a view is actively notified about
Hi Jeroen,
On Friday, 27 June 2014 05:13:54 UTC+8, Jeroen Gordijn wrote:
Why do you need a view that watches multiple Processors? This can already
be achieved. You create a child View for every Processor you would like to
watch. The child simply forwards all messages to its parent.
There
A couple of quick questions about passivate and PersistentActors:
Can other actors still send messages to persistent actors that have been
passivated?
Will these messages cause the persistent actor to be reactivated?
I am asking about this in single node and clustered context.
I saw
I think this is a fantastic development (if I understand it correctly).
From my reading and basic understanding I had concerns about the need for
two event infrastructures to 1) implement more complex view models in CQRS
because currently Views can't follow more than one PersistentActor, and
My use-case is for denormalised PersistentViews (possibly stored in a
Document Store).
Will it be possible for a persistent view to follow all persistent actors
of a specific type? For example, CustomerViewManager to follow all events
for all Customers so that when an event comes in for a
A few things I have noted when re-reading Exploring CQRS and Event
Sourcing http://msdn.microsoft.com/en-us/library/jj554200.aspx :
A. Events can play two different roles in a CQRS implementation: 1) Event
Sourcing - as a.p provides to persist the state of an aggregate root, and
2)
Thanks for your post Vaughn.
On Monday, 11 August 2014 05:57:05 UTC+8, Vaughn Vernon wrote:
None of this stuff is easy to do, and even harder to do right.
I am the first to agree with that.
Your post gives away the main problem with getting this to work correctly,
because Actor Model
I've been thinking about how Akka Persistence could possibly be improved
for CQRS and *persistent* stream or log processing more generally.
Here's my stream (no pun intended) of thought:
Currently, PersistentActor is focussed on persisting state changes for an
Actor (persistenceId) but why
it
is reactivated. If a PersistentActor is really a “LogProducer” creating a
large log of events, it doesn’t want to have to trundle through all of
those events each time it is reactivated.
Sorry for such long posts :-(
Cheers,
Ashley.
--
Dr Ashley Aitken
Running Code Productions
LinkedIn
Sorry, another question.
It seems to me that currently PersistentViews recover by reprocessing (or
at least considering) all their PersistentActor's events each time they are
created.
Please correct me if I am wrong?
If this is true, is there any way to have PersistentViews not do this, i.e.
Now we often mention causal ordering as something that would be a great
goal for a distributed system, sometime in the future, but never seem to
talk about achieving it. To that end I would like to naively suggest a way
that it may possibly be implemented.
The implementation is to simply
it, as usual ;-)
Regards,
Roland
12 aug 2014 kl. 18:10 skrev Ashley Aitken amai...@gmail.com javascript:
:
Thanks for your post Vaughn.
On Monday, 11 August 2014 05:57:05 UTC+8, Vaughn Vernon wrote:
None of this stuff is easy to do, and even harder to do right.
I am the first to agree
Sorry about that formatting, something happened (with the EOLs) when I
pasted from a text editor.
--
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
I'm keen to hear other people's thoughts on the choice of an event store
for Akka Persistence for doing CQRS.
As mentioned in my other post, I believe that Akka Persistence only
provides part of the story for CQRS (but a very important part) and that
other stores will most likely be needed
here is available today via akka.persistence + event
store adapter a durable subscription (akka event store client) on the
read model side.
On Monday, August 18, 2014 12:01:36 PM UTC-4, Ashley Aitken wrote:
Hi Roland (and everyone),
Welcome back Roland - I hope you had a great vacation
On Tuesday, 19 August 2014 14:51:42 UTC+8, Martin Krasser wrote:
For full CQRS support, the discussions so far (in several other threads)
make the assumption that both write and read models are backed by the same
backend store (assuming read models are maintained by PersistentView actor,
On Tuesday, 19 August 2014 16:53:46 UTC+8, Martin Krasser wrote:
journal - akka actor(s) - read model datastore
when I can do this much more efficiently via
journal - spark - read model datastore
directly, for example
I am confused, are you suggesting that spark is talking to the
On Tuesday, 19 August 2014 19:33:55 UTC+8, Martin Krasser wrote:
If so, it sounds like a great solution but why would that require an
extension to the Akka Persistence design/API?
Because transformed/joined/... event streams in backend store on the read
side must be consumable by
On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote:
18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com javascript:
:
I believe Akka needs to allow actors to:
(i) persist events with as much information as efficiently possible on the
write side to allow the store
definitions in the list archives. My main question
is: what is that other pattern that shall be called a Saga?
Regards,
Roland
On Wed, Aug 20, 2014 at 4:16 AM, Roland Kuhn goo...@rkuhn.info
javascript: wrote:
19 aug 2014 kl. 18:59 skrev Ashley Aitken amai...@gmail.com javascript
Now we often mention causal ordering as something that would be a great goal
for a distributed system, sometime in the future, but never seem to talk about
achieving it. To that end I would like to naively suggest a way that it may
possibly be implemented.
The implementation is to simply
Ashley Aitken amait...@gmail.com:
Thanks for your post Vaughn.
On Monday, 11 August 2014 05:57:05 UTC+8, Vaughn Vernon wrote:
None of this stuff is easy to do, and even harder to do right.
I am the first to agree with that.
Your post gives away the main problem with getting this to work
skrev Ashley Aitken amait...@gmail.com:
Thanks for your post Vaughn.
On Monday, 11 August 2014 05:57:05 UTC+8, Vaughn Vernon wrote:
None of this stuff is easy to do, and even harder to do right.
I am the first to agree with that.
Your post gives away the main problem with getting
Martin,
Thank you very much for your most interesting and useful post.
I think many of us benefit considerably from you sharing your practical
experience with Akka Persistence and CQRS.
It's probably too early for best practices but knowing what may work well
(or not) in real-world
On Wednesday, 27 August 2014 23:08:27 UTC+8, rkuhn wrote:
In theory if Client sends a command to A which in order to fulfill it will
need to send a command to B then A’s response to the Client will contain
B’s reply in some capacity. Whether there are cases where this structure
becomes
Can anyone please comment further on Cassandra as the event store?
I haven't got my head fully around column stores as yet but the Web site
mentions the performance of log-structured updates which downs good for
the write-side but also strong support for denormalization and
materialised
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
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
Thanks Martynas.
I am also interested in this.
Besides ordering, is there any other problem with having multiple
PersistentActors with the same persistenceId?
E.g. could events be lost or corrupted?
Cheers,
Ashley.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Thanks for your post Olger.
On Monday, 8 September 2014 14:11:14 UTC+8, Olger Warnier wrote:
Events are assigned the same number as each instance starts counting in the
same way. It appears that the last one written with a specific sequence
number is eventually kept.
That's unfortunate (I
Hi All,
Has anyone had success running Akka Microkernel in Docker Container (using
SBT-Native-Packager Docker)?
I am getting a ClassNotFoundException when the jars containing the class
are in the class path etc.
Below is the stack trace and the starting script.
UserCreated is in
It doesn't look like it has anything to do with Docker.
If I just do sbt stage I get the same problem when I try to run the same
startup script bin/a3-write-back
I tried changing the order of the contracts jar to before the
a3-write-back jar in the class path.
I tried Java 7 and 8.
--
Solution found (by Pawel Kaczor):
JSON serialisation config needed to use mangled class name for Scala
package classes.
All fixed thank you.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the
Howdy All,
Has anyone had any experience getting an Akka Cluster and Cluster Client
running on Kubernetes, e.g. on Google Container Engine (GCE)?
I note the problem with Akka dropping messages when the host IP address
doesn't match the container virtual IP address.
I note the solution in
May I please ask if there has been any progress on this by anyone? We need
durable timeouts for sagas in CQRS.
Thanks,
Ashley.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
not have the time to play around with, it is
> not perfect and comes with no warranties.
>
> Ruben
>
> Am Montag, 18. Juli 2016 17:24:34 UTC+2 schrieb Mahmoud Atef:
>>
>> Did it work with you, I mean Akka cluster over kubernetes?
>>
>>
>> On M
This looks very interesting:
https://github.com/vyshane/klusterd
Thanks to VYShane.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives:
Hi Evgeny,
Could you briefly describe what you did (or is it exactly as described in
links)? I am interested in doing this too and like you would (have)
like(d) to not use another service and zookeeper etc.
I may have been thinking along the same lines as you as well, i.e. having
the seed
as we will start having multiple instances - AKKA cluster
> should work
>
>
> неділя, 5 березня 2017 р. 18:27:03 UTC+2 користувач Ashley Aitken написав:
>
> So you run ConstructR and Zookeeper on all nodes, just manager nodes?
>
> You are still using Docker Swarm?
>
50 matches
Mail list logo
