Cool - thanks for validation and tips.
Andrew
On Tuesday, 14 April 2015 09:20:09 UTC+1, Patrik Nordwall wrote:
Hi Andrew,
I think your reasoning is correct. A way to implement the de-duping (if db
operations are not idempotent by themselves) is to save the sequence number
in the external
Hi Andrew,
I think your reasoning is correct. A way to implement the de-duping (if db
operations are not idempotent by themselves) is to save the sequence number
in the external db together with the writes. When starting up, before
replaying, you load the latest seq num from the db and then you
On Thu, Jan 22, 2015 at 9:01 PM, Yann Simon yann.simon...@gmail.com wrote:
Hi Patrick,
Le dimanche 20 avril 2014 16:59:22 UTC+2, Patrik Nordwall a écrit :
On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier ol...@spectare.nl wrote:
Hi Patrick,
Sounds like an interesting approach, storing
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
The User actor persist FirstNameChanged, and inside the persist block it
sends a Persistent(FirstNameChanged) message to the AllUsers Processor. On
the query side we have a AllUsersView connected to that processor. When
On Friday, May 9, 2014 4:37:16 PM UTC+2, Olger Warnier wrote:
On Friday, May 9, 2014 4:29:32 PM UTC+2, Paweł Kaczor wrote:
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
The User actor persist FirstNameChanged, and inside the persist block it
sends a
On Friday, May 9, 2014 5:58:42 PM UTC+2, Paweł Kaczor wrote:
On Friday, May 9, 2014 4:37:16 PM UTC+2, Olger Warnier wrote:
On Friday, May 9, 2014 4:29:32 PM UTC+2, Paweł Kaczor wrote:
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
The User actor persist
On Tue, Apr 22, 2014 at 9:43 PM, Olger Warnier ol...@spectare.nl wrote:
Based on all your remarks, I found the way to get this organised using the
Views for scanning changes and thereafter starting an actor with the
specific actorpath of the sharded eventsourced instance in order to process
On Monday, April 21, 2014 9:07:03 AM UTC+2, Patrik Nordwall wrote:
On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier ol...@spectare.nljavascript:
wrote:
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier ol...@spectare.nlwrote:
Based on all your remarks, I found the way to get this organised using the
Views for scanning changes and thereafter starting an actor with the
specific actorpath of the sharded eventsourced instance in order to process
all changes (the meta-data option as you called it). As said, that solves
On Sun, Apr 20, 2014 at 6:05 PM, Olger Warnier ol...@spectare.nl wrote:
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier ol...@spectare.nl wrote:
Hi Patrick,
Sounds like an interesting approach, storing some meta-data at
Hi Olger,
What if you keep the sharded event sourced actors (+10k), but let them also
send the events to one or a few processors. Then you can connect the
views/streams to these processors.
If you don't like storing the events twice you can instead store some meta-data
(processor-id,
Hi Patrick,
Sounds like an interesting approach, storing some meta-data at the view may
help to check / show the reliability of the system.
At this moment the events are sent to a processor per node that publishes
the event (distributed pub sub)
When you talk about view, that's the
On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier ol...@spectare.nl wrote:
Hi Patrick,
Sounds like an interesting approach, storing some meta-data at the view
may help to check / show the reliability of the system.
At this moment the events are sent to a processor per node that publishes
the
On Sunday, April 20, 2014 4:59:22 PM UTC+2, Patrik Nordwall wrote:
On Sun, Apr 20, 2014 at 2:47 PM, Olger Warnier ol...@spectare.nljavascript:
wrote:
Hi Patrick,
Sounds like an interesting approach, storing some meta-data at the view
may help to check / show the reliability of the
Hello,
problems using a view for multiple processors have been discussed before,
e.g.:
https://groups.google.com/d/msg/akka-user/Tb1Qqh4ZMmo/ssqiBEQ_Eb0J
It would still be a great feature to have though(when you need an
aggregated view on events of multiple processors).
The solution to send the
Hi Patrik,
Sure and if that is how akka-persistence stays, that is what we will end up
doing. But since persistence was marked as experimental, and it was stated
that it will changed based on community feedback, I thought I would mention
this feature that seems useful and powerful to me and
On Mon, Apr 14, 2014 at 2:48 PM, Chanan Braunstein
chanan.braunst...@pearson.com wrote:
Hi Patrik,
Sure and if that is how akka-persistence stays, that is what we will end
up doing. But since persistence was marked as experimental, and it was
stated that it will changed based on community
Hi Patrik,
That would be perfect for the needs I was thinking of. I hope that makes it
in to a future version.
On Monday, April 14, 2014 9:22:17 AM UTC-4, Patrik Nordwall wrote:
On Mon, Apr 14, 2014 at 2:48 PM, Chanan Braunstein
chanan.b...@pearson.com javascript: wrote:
Hi Patrik,
On Mon, Apr 14, 2014 at 3:25 PM, Chanan Braunstein
chanan.braunst...@pearson.com wrote:
Hi Patrik,
That would be perfect for the needs I was thinking of. I hope that makes
it in to a future version.
Please create a
tickethttp://doc.akka.io/docs/akka/current/project/issue-tracking.html(now
Entered: https://github.com/akka/akka/issues/15004
--
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
Hello,
We are trying to evaluate using Akka persistence to use going forward in
our new platform. It seems to us that views could be a very powerful way to
do some of the things we need to do but it can only act on one stream of
events. An interesting feature, I think, would be to have a view
21 matches
Mail list logo
