Re: [akka-user] Using stash with become
Luis,
As an actor only handles one message at a time, the order of `unstashAll` and
`context.become` doesn't matter at all: Both happen while processing the
current message which means that no other message gets processed until both
methods (and the rest of the current behavior) have been executed. Then, when
the next message is about to get processed, both methods have already been
executed.
BTW, I have seen many who have been thinking along the same lines ;-)
Cheers
Heiko
On 19 Aug 2014, at 19:09, Luis Medina lu4...@gmail.com wrote:
Hi all,
I'm working on implementing retry functionality in one of my actor's that
will retry writing a message to RabbitMQ if the original write fails. This
looks something like this:
private String retryMessage;
private void processMessage(String message) {
try {
writer.write(message);
} catch (IOException e) {
LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
retryMessage = message;
context().become(retry);
sendTimeout();
}
}
private PartialFunctionObject, BoxedUnit retry = ReceiveBuilder
.match(String.class, message - stash())
.match(ReceiveTimeout.class, receiveTimeout - retryMessage())
.build();
private void sendTimeout() {
long waitTime = getWaitTime();
context().setReceiveTimeout(Duration.Undefined());
context().setReceiveTimeout(Duration.create(waitTime,
TimeUnit.MILLISECONDS));
}
private void retryMessage() {
try {
writer.write(retryMessage);
context().setReceiveTimeout(Duration.Undefined());
context().unbecome();
unstashAll();
} catch (IOException e) {
LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
sendTimeout();
}
}
As you can see, when the write fails, the actor switches to a retry mode.
In this retry mode, it will stash any incoming messages that are meant to be
written until it can successfully write the original message that it failed
on. To do a retry, I set a ReceiveTimeout that whose duration increases
exponentially with each failure. When the actor receives a ReceiveTimeout, it
simply tries to write it again. Now the part that I'm curious about has to do
with unstashing all of the messages and unbecoming its retry mode.
In the retryMessage() method, if the write is successful, the ReceiveTimeout
will be shut off, the actor will revert back to its original state, and any
messages that were stashed during this time will be unstashed. In terms of
reverting back to its original state and unstashing messages, is this the
right order in which to do this? In all of the examples that I've seen, I
noticed that the unstashAll() always came before the context().unbecome()
which is what I originally had. After giving it some thought, however, I
started to wonder if having this order would cause me to lose any messages if
they arrived in between the unstashAll() and context().unbecome() operations
thus causing them to get stashed but never becoming unstashed again. This is
why I ended up reversing their order. Is my thinking correct?
Luis
--
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.
--
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.
[akka-user] Re: Cassandra Journal v2.0.3?
Thanks Mathew, We have been trying to do the same and did a quick testing by making the below changes 1. Changed the datastax cassandra-driver-core to version 2.0.1 from 2.0.3. Version 2.0.1 supports 1.2+ ( we user C* 1.2.x.x) that works with CQL3 2. Got rid of the IF NOT EXISTS clause ( via exception handling) 3. replaced BATCHSTATEMENTS which is not supported by C* protocol version 1 with BOUNDSTATEMENTS. With init testing done with changed jar, our application could startup with out any errors and we had the keyspace and tables created. I have created an issue in GITHUB to seek some help from Martin as we need to use this plugin as our Product has only Cassandra plugged in as Database. Thanks Ratika On Wednesday, August 20, 2014 1:17:53 AM UTC+5:30, Matthew Howard wrote: Hi - no we haven't implemented this yet... we wound up getting sidetracked by some other priorities. But we are going to need to implement this at some point. It's been a bit since I've looked into the details but as I remember there were 2 key changes needed for C* 1.2: 1. C* 2.0 introduced the IF NOT EXISTS clause - so in CassandraStatements.scala https://github.com/krasserm/akka-persistence-cassandra/blob/master/src/main/scala/akka/persistence/cassandra/journal/CassandraStatements.scala (both in snapshot and journal files) that would need to be removed... which obviously means those will fail if the keyspaces/columnfamilies exist. I was thinking of just catching the exception in CassandraJournal.scala https://github.com/krasserm/akka-persistence-cassandra/blob/f6c885fe943aaa898a3d191083368ecab6e1ddc0/src/main/scala/akka/persistence/cassandra/journal/CassandraJournal.scala#L27 (again would also need the same in CassandraSnapshotStore.scala ) 2. The Datastax 2.0 driver doesn't support C* 1.2, so that would need to be downgraded to the 1.0 driver. I believe this means the inserts currently using the BatchStatement will need to change... this will probably be the tricky part, although depending on your throughput needs it might be fine to just execute the prepared statements without batching. See http://www.datastax.com/dev/blog/client-side-improvements-in-cassandra-2-0 for a description of the new BatchStatement in the datastax driver. By looking at the old PreparedStatement you can see the types of changes that would need to be made. Ignore my comments above regarding the composite keys of processor_id and partition_nr... Cassandra 1.2 should support the composite PK as defined in this journal. So at first glance the changes for C* 1.2 seem not too bad - I would only be worried about any hidden gotchas that I haven't noticed regarding the 1.0 driver, and about the potential performance hit of not being able to use the BatchStatement. I don't know when we will take this on, but I'll post back to this thread when we do. On Thursday, August 14, 2014 12:35:27 AM UTC-4, ratika...@razorthink.net wrote: Hi Mathew, We also need to use the akka persistence journal plugin for older version of Cassandra v 1.2.x, hoever the plugin available works for version 2.0.3 or higher. Came across your post, did you happen to implement/tweak the journal for older version of Cassandra ? If yes would share it with us or let us know what were the tweaks required. Thanks for your help. --Ratika On Tuesday, May 6, 2014 12:51:25 AM UTC+5:30, Matthew Howard wrote: Has anyone implemented an akka persistence journal for older versions of Cassandra? I see the current journal is dependent on C* v2.0.3 or higher ( https://github.com/krasserm/akka-persistence-cassandra) but my app is currently on 1.1.9 and we are only actively planning to upgrade to v1.2 (just found this out - I thought we were moving to 2). I'm guessing there isn't one already out there, but thought I'd ask before attempting to implement one. Assuming I would need to implement it (probably a question for Martin directly) any warnings or recommendations? At first glance I'd obviously need to tweak the create keyspace/columnfamily commands (and change the driver), but I'm not seeing anything that appears to be too wildly dependent on C* v2.0.3 features. The handling of the partition_nr seems to be the biggest issue - I'm thinking we could just create the rowkey as a concatenation of the processor_id and partition_nr (e.g. myprocessor-0, myprocessor-1, etc... ). But I think/hope? otherwise the composite columns should work the same and I'm not going to get myself into a rabbit hole... Thanks in advance, Matt Howard -- 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.
Re: [akka-user] Event Stores for Akka Persistence for CQRS?
Team, Consider I have domain model Bank Customer'*s* Account's Bank object will have many customers. Every customer will have multiple accounts. Consider I implement the above model using akka persistence. For the sake of discussion consider I make each as different Aggregate Roots using PersistentActor's. I want to implement a query : Give my all customers whose balance is less then 100$. Do you mean, 1. Create one PersistentView XYZ. 2. This XYZ will listen from all 3 AR's. 3. PersistentView XYZ will replicate these events as state to some DB consider cassandra. 4. Client will query directly cassandra to find all customers whose balance is less then 100$. Is my understanding correct? If not, can you let me know how to achieve this using PersistentView? -Prakhyat M M On Tuesday, 19 August 2014 22:49:14 UTC+5:30, Martin Krasser wrote: On 19.08.14 18:48, delasoul wrote: As I am no Spark expert - will it be used only as kind of messaging(streaming) middleware to sync write and read store or also to somehow change/merge/ filter the events it gets/pulls from the write store usually, to process (transform/aggregate/filter/...) these events. or is this all done via the plugin for PersistentViews? (I guess it has to be like this, otherwise using only one backend store cannot be supported?) thanks, michael On Tuesday, 19 August 2014 17:48:16 UTC+2, Martin Krasser wrote: On 19.08.14 17:41, Ashley Aitken wrote: 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 PersistentViews (for creating read models). I still see this backend store to maintain changes (= transformed/joined/... events) instead of current state. I am sorry I still don't see this. This suggests to me that spark is talking directly to the read model datastore (e.g. graph database, MongoDB, SQL database). So are you suggesting: 1. journal - spark - Akka actors (like PersistentView) - read model data store or 2. journal - spark - read model data store (like graph database, MongoDb, SQL database) - Akka actors - Queries I was suggesting 2. I see PersistentView(for generalised topics) as the glue between the Akka journal (write store) and read stores (1.). Thanks for your patience. Cheers, Ashley. -- 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+...@googlegroups.com. To post to this group, send email to akka...@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+...@googlegroups.com javascript:. To post to this group, send email to akka...@googlegroups.com javascript:. 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] Improving Akka Persistence wrt CQRS/ES/DDD
19 aug 2014 kl. 16:27 skrev Greg Young gregoryyou...@gmail.com: I am not responding to this one post just a reply towards the end and will discuss a few posts from earlier. To start I have to agree with some of the posters that premature scaling can cause many issues. This actually reminds me of the CQRS journey which people mentioned earlier. One of the main criticisms of the CQRS Journey is that it prematurely took scaling constraints which causes the code to be much much more complex than it needs to be. This was partially due to it being a sample app of something larger and partially due to the pp team also showing azure at the same time. Because they wanted to distribute and show Azure at the same time the team took cloud constraints as a given. This caused for instance every handler in the system to need to be idempotent. While seemingly a small constraint this actually adds a significant amount of complexity to the system. The same problem exists in what is being discussed today. For 95+% of systems it is totally reasonable that when I write a projection I expect my events to have assured ordering. As Vaughn mentioned a few hundred events/second is the vast majority of systems. Systems like these can be completely linearized and ordering assurances are not an issue. This removes a LOT of complexity in projections code as you don't have to handle hundreds to thousands of edge cases in your read models where you get events out of order. Saying that ordering assurances are not needed and everyone should use casual consistency is really saying we don't care about the bottom 95% of users. As noted earlier we are in agreement on this: providing projections (which I also called Queries in this thread) without strict ordering would be meaningless because reliable consumption would only be possible from start to finish. The ability to remember a stream position and restart replay from there implies linearization. We also all agree that this feature cannot be supported by a back-end store that is scalable beyond a single partition (i.e. when multiple distributed nodes are concurrently written to). And we agree that this restriction is tolerable in a large number of relevant use-cases. RKuhn had mentioned doing joins. You are correct in this is how we do it now. We offer historically perfect joins but in live there is no way to do a live perfect join via queries. We do however support another mechanism for this that will assure that your live join will always match your historical. We allow you to precalculate and save the results of the join. This produces a stream full of stream links which can then be replayed as many times (perfectly) as you want. There was some discussion above about using precalculated topics to handle projections. I believe the terminology was called tags. The general idea if I can repeat it is to write an event FooOccurred and to include upon it some tags (foo, bar, baz) which would map it to topics that could then be replayed as a whole. This on the outset seems like a good idea but will not work well in production. The place where it will run into a problem is that I cannot know when writing the events all mappings that any future projections may wish to have. Tomorrow my business could ask me for a report that looks at a completely new way of partitioning the events and I will be unable to do it. This is a crucial point which implies that Akka Persistence cannot generically provide meaningful projections (or Queries) without relying on a linearizable back-end store. As I mentioned previously in a quick comment. What is being asked for today is actually already supported with akka,persistence providing you are using event store as your backend (for those interested today is the release of the final RC of 3.0 which has all of the support for the akka,perisistence client (binaries are for win/linux/max)). Basically what you would do is run akka.persistence on your write side but *not* use it for supporting your read models. Instead when dealing with your read models you would use a catchupsubscription for what you are interested in. I do not see anything inherently wrong with this way of doing things and it begs the question of whether this is actually a more appropriate way to deal with eventsourced systems using akka,.persistence. eg use native storage directly if it supports it. Taking together the conclusions so far I tend to agree with this assessment. Akka Persistence can provide designated event streams with proper ordering (per persistenceId or Topic) while projections or Queries depend on the underlying storage technology. A potential compromise would be to offer generic but inefficient Queries for those Journals that can provide everything in-order; otherwise we would need to standardize on a query language and that prospect makes me shiver …
[akka-user] Difference between PersistentView and Projections
Team, I want to understand difference between PersistentView and Projections. I have gone through lot of posts on both these topics.How both differ in addressing querying/searching/Complex reporting in application. -Prakhyat M M -- 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] Improving Akka Persistence wrt CQRS/ES/DDD
19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. (iii) read from (and replay) streams of events on the read and write side according to a range of criteria supported and defined within the store or via the store API (e.g. using a DSL), and This is the unclear point: who defines the query and when? What are the consistency guarantees for the generated event stream? I suggest the developers of the read side specify the queries directly to the event store but this may be after the events have initially been persisted. The event store produces the query stream (if it can) and a PersistentView can be setup to read from that named query. With regards to consistency guarantees - my understanding is that these streams are used to eventually guarantee that the query model will be consistent with the write model, i.e. all the events will get across. With regards to ordering I think the event store does the best it can to provide consistent ordering, e.g. total ordering if there was no distribution and causal ordering, where possible, if there was ordering. The developer would need to understand the limitations of how the query store is configured and queried. As I answered to Greg already, I think that this should not be a core concern of Akka Persistence; as you note it relies on features provided by the underlying event store, and those features are not necessary to achieve the goal of making actors persistent. (iv) reliably (at least once) deliver information to other read side store(s) and systems above and beyond the store used for persisting the events. This is PersistentView, so “check!” (As argued previously “reliably” translates to “persistent”.) As I asked in another thread (I think) I am not sure how PersistentView can do this when PersistentActor is the one that can mixin AtLeastOnceDelivery? I think we need a PeristentView that can guarantee AtLeastOnceDelivery to an actor representing a query store. This would seem to require a PersistentViewActor ;-) that can read from a persistent query and also persist its state to provide guaranteed delivery. My lack of knowledge of Scala and Akka may be showing here. My current impression is that PersistentView needs to be re-thought: instead of tying it to a persistenceId like we do now we should just provide an API for subscribing to named topics in the Journal—be that persistenceIds of some PersistentActors or synthetic ones. One Actor should be able to subscribe to any number of them, but the onus will be on it to keep track of the positions up to which it has consumed from all of them. This does not preclude the Journal from providing a synthetic topic
Re: [akka-user] Difference between PersistentView and Projections
It’s a naming thingy. PersistentView is our concrete implementation of something that reads events given a persistenceId”. Current discussions involve making PersistentView more usable and powerful, as the current impl does not cover many use cases. Projections in general are simply “the read side”. Could be a persistent view, or anything else that given some events projects the data onto some other value like the average for example (think “projection” as in maths). Read up on DDD concepts, it should help you follow these discussions: * http://www.amazon.co.uk/Domain-driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_2?ie=UTF8qid=1408523383sr=8-2keywords=ddd * http://www.amazon.co.uk/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/ref=sr_1_1?ie=UTF8qid=1408523383sr=8-1keywords=ddd * http://msdn.microsoft.com/en-us/library/jj554200.aspx Cheers. -- Konrad 'ktoso' Malawski hAkker @ typesafe http://akka.io -- 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] Improving Akka Persistence wrt CQRS/ES/DDD
20 aug 2014 kl. 10:43 skrev Martin Krasser krass...@googlemail.com: On 20.08.14 10:16, Roland Kuhn wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. akka.dispatch.Envelope could carry additional information, so that user-collaboration is not needed Well, actually Envelope is going to go away in Akka Gålbma (a.k.a. Akka 3). (iii) read from (and replay) streams of events on the read and write side according to a range of criteria supported and defined within the store or via the store API (e.g. using a DSL), and This is the unclear point: who defines the query and when? What are the consistency guarantees for the generated event stream? I suggest the developers of the read side specify the queries directly to the event store but this may be after the events have initially been persisted. The event store produces the query stream (if it can) and a PersistentView can be setup to read from that named query. With regards to consistency guarantees - my understanding is that these streams are used to eventually guarantee that the query model will be consistent with the write model, i.e. all the events will get across. With regards to ordering I think the event store does the best it can to provide consistent ordering, e.g. total ordering if there was no distribution and causal ordering, where possible, if there was ordering. The developer would need to understand the limitations of how the query store is configured and queried. As I answered to Greg already, I think that this should not be a core concern of Akka Persistence; as you note it relies on features provided by the underlying event store, and those features are not necessary to achieve the goal of making actors persistent. (iv) reliably (at least once) deliver information to other read side store(s) and systems above and beyond the store used for persisting the events. This is PersistentView, so “check!” (As argued previously “reliably” translates to “persistent”.) As I asked in another thread (I think) I am not sure how PersistentView can do this when PersistentActor is the one that can mixin AtLeastOnceDelivery? I think we need a PeristentView that can guarantee AtLeastOnceDelivery to an actor representing a query store. This would seem to require a PersistentViewActor ;-) that can read from a persistent query and also persist its state to provide guaranteed delivery. My lack of knowledge of Scala and Akka may be showing here. My current impression is that PersistentView needs to be re-thought: instead of tying it to a persistenceId like we do now we should just provide an API for subscribing to named
Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD
Am 20.08.2014 13:33 schrieb Roland Kuhn goo...@rkuhn.info: 20 aug 2014 kl. 10:43 skrev Martin Krasser krass...@googlemail.com: On 20.08.14 10:16, Roland Kuhn wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. akka.dispatch.Envelope could carry additional information, so that user-collaboration is not needed Well, actually Envelope is going to go away in Akka Gålbma (a.k.a. Akka 3). My point was that causal consistency can be achieved without forcing users to do extra work, as tracing dependencies can be done completely within Akka, and there are several possible ways to implement that. (iii) read from (and replay) streams of events on the read and write side according to a range of criteria supported and defined within the store or via the store API (e.g. using a DSL), and This is the unclear point: who defines the query and when? What are the consistency guarantees for the generated event stream? I suggest the developers of the read side specify the queries directly to the event store but this may be after the events have initially been persisted. The event store produces the query stream (if it can) and a PersistentView can be setup to read from that named query. With regards to consistency guarantees - my understanding is that these streams are used to eventually guarantee that the query model will be consistent with the write model, i.e. all the events will get across. With regards to ordering I think the event store does the best it can to provide consistent ordering, e.g. total ordering if there was no distribution and causal ordering, where possible, if there was ordering. The developer would need to understand the limitations of how the query store is configured and queried. As I answered to Greg already, I think that this should not be a core concern of Akka Persistence; as you note it relies on features provided by the underlying event store, and those features are not necessary to achieve the goal of making actors persistent. (iv) reliably (at least once) deliver information to other read side store(s) and systems above and beyond the store used for persisting the events. This is PersistentView, so “check!” (As argued previously “reliably” translates to “persistent”.) As I asked in another thread (I think) I am not sure how PersistentView can do this when PersistentActor is the one that can mixin AtLeastOnceDelivery? I think we need a PeristentView that can guarantee AtLeastOnceDelivery to an actor representing a query store. This would seem to require a PersistentViewActor ;-) that can read from a persistent query and also persist its state to provide guaranteed delivery. My lack of knowledge of Scala and Akka may be showing here. My current
[akka-user] Re: [akka-stream] : Streaming large file from 1 server to 1 client
Hello Viktor,
Thanks a lot for your answer. I've tried your solution and passed from
version 0.3 to 0.5 of akka-stream modules. But problem is still there. I've
extracted part of the code into a
Gist. https://gist.github.com/xbucchiotty/3fab493607588dec0ac8
Streaming a file of 10.MB with a chunkSize of 3.MB fails. Some chunks
didn't arrived to the receiver once the flow on the receiver side is
completed. The greater the chunkSize is, the more the delta is important.
3.MB is huge for a chunkSize production. It was detected with Scalacheck
tests.
To launch the test, I use sbt + consoleQuick. The very first time I launch
the test, it fails. But in the same Scala REPL session, if I try again, it
passes
Another point that may be important (can't see why yet). Senders and
receivers are actors in our code. On the flow of connection, we make some
stuff as:
foreach{conn = self ! conn}
Problems come with even smaller files within this contexts of actors.
Any clue ?
--
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] Improving Akka Persistence wrt CQRS/ES/DDD
Please stop using the terminology of saga and replace usage with process manager what people (largely influenced by nservicebus call a saga is actually a process manager and a saga is a different pattern). Its bad enough the .net community does this the last thing we need is for the akka community to start doing the same :) On Wed, Aug 20, 2014 at 4:16 AM, Roland Kuhn goo...@rkuhn.info wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. (iii) read from (and replay) streams of events on the read and write side according to a range of criteria supported and defined within the store or via the store API (e.g. using a DSL), and This is the unclear point: who defines the query and when? What are the consistency guarantees for the generated event stream? I suggest the developers of the read side specify the queries directly to the event store but this may be after the events have initially been persisted. The event store produces the query stream (if it can) and a PersistentView can be setup to read from that named query. With regards to consistency guarantees - my understanding is that these streams are used to eventually guarantee that the query model will be consistent with the write model, i.e. all the events will get across. With regards to ordering I think the event store does the best it can to provide consistent ordering, e.g. total ordering if there was no distribution and causal ordering, where possible, if there was ordering. The developer would need to understand the limitations of how the query store is configured and queried. As I answered to Greg already, I think that this should not be a core concern of Akka Persistence; as you note it relies on features provided by the underlying event store, and those features are not necessary to achieve the goal of making actors persistent. (iv) reliably (at least once) deliver information to other read side store(s) and systems above and beyond the store used for persisting the events. This is PersistentView, so “check!” (As argued previously “reliably” translates to “persistent”.) As I asked in another thread (I think) I am not sure how PersistentView can do this when PersistentActor is the one that can mixin AtLeastOnceDelivery? I think we need a PeristentView that can guarantee AtLeastOnceDelivery to an actor representing a query store. This would seem to require a PersistentViewActor ;-) that can read from a persistent query and also persist its state to provide guaranteed delivery. My lack of knowledge of Scala and Akka may be showing here. My current impression is that PersistentView needs to be re-thought: instead of tying it to a persistenceId like we do now we should
Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD
I held the same issue with ms pnp Clarifying the terminology The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this: There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact. Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition. The term saga, in relation to distributed systems, was originally defined in the paper Sagas by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction. On Wed, Aug 20, 2014 at 10:31 AM, Roland Kuhn goo...@rkuhn.info wrote: 20 aug 2014 kl. 16:16 skrev Greg Young gregoryyou...@gmail.com: Please stop using the terminology of saga and replace usage with process manager what people (largely influenced by nservicebus call a saga is actually a process manager and a saga is a different pattern). Its bad enough the .net community does this the last thing we need is for the akka community to start doing the same :) Sure, but please do educate us as to the right use of these two words so we persist the correct 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 wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. (iii) read from (and replay) streams of events on the read and write side according to a range of criteria supported and defined within the store or via the store API (e.g. using a DSL), and This is the unclear point: who defines the query and when? What are the consistency guarantees for
Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD
further explanation http://soa.dzone.com/news/are-sagas-and-workflows-same-t On Wed, Aug 20, 2014 at 10:39 AM, Greg Young gregoryyou...@gmail.com wrote: I held the same issue with ms pnp Clarifying the terminology The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this: There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact. Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition. The term saga, in relation to distributed systems, was originally defined in the paper Sagas by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction. On Wed, Aug 20, 2014 at 10:31 AM, Roland Kuhn goo...@rkuhn.info wrote: 20 aug 2014 kl. 16:16 skrev Greg Young gregoryyou...@gmail.com: Please stop using the terminology of saga and replace usage with process manager what people (largely influenced by nservicebus call a saga is actually a process manager and a saga is a different pattern). Its bad enough the .net community does this the last thing we need is for the akka community to start doing the same :) Sure, but please do educate us as to the right use of these two words so we persist the correct 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 wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amait...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed something initially, and if the mechanism is baked into the Akka Persistence Journal SPI then fixing it will take a very long time (until plugins are migrated and your OPS guys allow you to use it etc.). My recommendation is to use a serialization mechanism that fits the Journal, allowing it to understand the events and provide semantic features on top. Both (Journal and serialization) are configured in the same file, so I submit that coupling them is a valid approach. On causal consistency: I am still unconvinced that it is worth pursuing, and I am certain that you are vastly underestimating the amount of data and effort involved. And it cannot be done without collaboration from the user since a single inter-Actor message outside of the traced system (i.e. not using a PersistenceEnvelope of sorts) would hamper or destroy it. (iii) read from (and replay) streams of events on the read and write side according to a range of criteria
Re: [akka-user] Re: [akka-stream] : Streaming large file from 1 server to 1 client
Hi Xavier,
seems like a potential bug related to the TcpStream and not the chunker:
This works for me:
def testNoNetwork(fileLength: Int, chunkSize: Int) {
implicit val actorSystem = ActorSystem(test,
ConfigFactory.parseString( akka {
| log-dead-letters = 0
| log-dead-letters-during-shutdown = off
|}.stripMargin))
val settings = MaterializerSettings()
val materializer = FlowMaterializer(settings)
def bytes = Iterator.fill(fileLength)(1.toByte)
val testComplete = Flow(bytes).grouped(chunkSize).map(
bytesIt = {
val b = new ByteStringBuilder()
b.sizeHint(chunkSize)
b ++= bytesIt
b.result()
}
).fold(0)({ _ + _.length }).map({
case completed @ `fileLength` =
s transfer OK: $fileLength/$completed, chunkSize: $chunkSize
case completed =
throw new RuntimeException(s transfer KO. expected:
$fileLength got: $completed diff: ${fileLength - completed})
}).toFuture(materializer).andThen({ case _ =
actorSystem.shutdown()
actorSystem.awaitTermination(3.seconds)
})(ExecutionContext.global)
println(Await.result(testComplete, atMost = 30.second))
}
scala testNoNetwork(10 * 1024 * 1024, 3 * 1024 * 1024)
transfer OK: 10485760/10485760, chunkSize: 3145728
On Wed, Aug 20, 2014 at 3:49 PM, Xavier Bucchiotty xbucchio...@xebia.fr
wrote:
Hello Viktor,
Thanks a lot for your answer. I've tried your solution and passed from
version 0.3 to 0.5 of akka-stream modules. But problem is still there. I've
extracted part of the code into a Gist.
https://gist.github.com/xbucchiotty/3fab493607588dec0ac8
Streaming a file of 10.MB with a chunkSize of 3.MB fails. Some chunks
didn't arrived to the receiver once the flow on the receiver side is
completed. The greater the chunkSize is, the more the delta is important.
3.MB is huge for a chunkSize production. It was detected with Scalacheck
tests.
To launch the test, I use sbt + consoleQuick. The very first time I launch
the test, it fails. But in the same Scala REPL session, if I try again, it
passes
Another point that may be important (can't see why yet). Senders and
receivers are actors in our code. On the flow of connection, we make some
stuff as:
foreach{conn = self ! conn}
Problems come with even smaller files within this contexts of actors.
Any clue ?
--
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.
--
Cheers,
√
--
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.
[akka-user] Testing parent/child behaviors
I've already looked at all the links from https://www.assembla.com/spaces/akka/tickets/3043#/activity/ticket: as well as http://hs.ljungblad.nu/post/69922869833/testing-parent-child-relationships-in-akka Still no closer to actually finding a working solution for testing an actor which spawns a child itself. The latter method appears to be the most elegant, but I simply do not understand what is being done in the Bar class with this, and whether or not it's crucial to the overall implementation. The method using ActorRefFactory as linked from the doc ticket is clear, but it doesn't seem that you can name the Actor being created in this manner, and my use case requires that we be able to do so. My actual use case is a FSM that spawns a child actor; for testing I do want to use TestFSMRef in TestKit, but I want to avoid spawning a real child during the test. Tom Sorensen -- 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.
[akka-user] Re: [akka-stream] : Streaming large file from 1 server to 1 client
Thanks I check this, I also compute a checksum on the fly with a closed value inside the map. I've seend it's a bad practice and will refactored it in this way: https://groups.google.com/forum/#!topic/akka-user/i21YLDj5YTw (post about lost data in TCP Echo) I keep you informed asap Le mardi 19 août 2014 16:08:54 UTC+2, Xavier Bucchiotty a écrit : Hello HakKers, I need to transfer larges files (~GB) between 2 distants VM. I first used akka.io module which works great. I currently take a look a akka-stream-experimental module to benefit from precious asynchronous backpressure. But when I create a Flow from a Stream[ByteString], it keeps a reference on it. And because of Scala Stream memoization == OutOfMemory. I tried with an iterator instead. But then my integrations tests fails. Seems to be that some chunk have disappeared or some concurrent access to the datasource. From reading the documentation of Flow in scaladsl package, I begin to think that streaming a file from 1 point to another is not a use case covered by reactive streams. Am I correct? Can I expect some improvement in next release on this way? To help, here is the code: // streamer is an implements Iterable[Byte] and reads the file byte by byte. val byteStream = new Streamer(buffStream) // toStream is needed there to pass from Iterator[Iterable[Byte]] to Iterable[Iterable[Byte]] // because we need a flow of an Iterable[ByteString] byteStream.grouped(chunkSize).toStream.map(_.toArray) .map(ByteString.fromArray) Flow(bytes).produceTo(materializer, client.outputStream) Thanks for your help -- 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] Using stash with become
Hi Heiko,
That actually makes a lot of sense. I keep forgetting that things within an
actor happen on a message by message basis. Thanks for the clarification!
Luis
On Tuesday, August 19, 2014 10:59:36 PM UTC-7, Heiko Seeberger wrote:
Luis,
As an actor only handles one message at a time, the order of `unstashAll`
and `context.become` doesn’t matter at all: Both happen while processing
the current message which means that no other message gets processed until
both methods (and the rest of the current behavior) have been executed.
Then, when the next message is about to get processed, both methods have
already been executed.
BTW, I have seen many who have been thinking along the same lines ;-)
Cheers
Heiko
On 19 Aug 2014, at 19:09, Luis Medina lu4...@gmail.com javascript:
wrote:
Hi all,
I'm working on implementing retry functionality in one of my actor's that
will retry writing a message to RabbitMQ if the original write fails. This
looks something like this:
private String retryMessage;
private void processMessage(String message) {
try {
writer.write(message);
} catch (IOException e) {
LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
retryMessage = message;
context().become(retry);
sendTimeout();
}
}
private PartialFunctionObject, BoxedUnit retry = ReceiveBuilder
.match(String.class, message - stash())
.match(ReceiveTimeout.class, receiveTimeout - retryMessage())
.build();
private void sendTimeout() {
long waitTime = getWaitTime();
context().setReceiveTimeout(Duration.Undefined());
context().setReceiveTimeout(Duration.create(waitTime,
TimeUnit.MILLISECONDS));
}
private void retryMessage() {
try {
writer.write(retryMessage);
context().setReceiveTimeout(Duration.Undefined());
context().unbecome();
unstashAll();
} catch (IOException e) {
LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
sendTimeout();
}
}
As you can see, when the write fails, the actor switches to a retry
mode. In this retry mode, it will stash any incoming messages that are
meant to be written until it can successfully write the original message
that it failed on. To do a retry, I set a ReceiveTimeout that whose
duration increases exponentially with each failure. When the actor receives
a ReceiveTimeout, it simply tries to write it again. Now the part that I'm
curious about has to do with unstashing all of the messages and unbecoming
its retry mode.
In the retryMessage() method, if the write is successful, the
ReceiveTimeout will be shut off, the actor will revert back to its original
state, and any messages that were stashed during this time will be
unstashed. In terms of reverting back to its original state and unstashing
messages, is this the right order in which to do this? In all of the
examples that I've seen, I noticed that the unstashAll() always came
before the context().unbecome() which is what I originally had. After
giving it some thought, however, I started to wonder if having this order
would cause me to lose any messages if they arrived in between the
unstashAll() and context().unbecome() operations thus causing them to get
stashed but never becoming unstashed again. This is why I ended up
reversing their order. Is my thinking correct?
Luis
--
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+...@googlegroups.com javascript:.
To post to this group, send email to akka...@googlegroups.com
javascript:.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
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] Testing parent/child behaviors
Tom, Why don't you use a protected factory method (`def createChild: ActorRef = ...`) in the parent to create your child actor instead of doing it inline? Then override it the way you want in the tests. Sometimes good old OO (I know that Alan Kay not necessarily meant inheritance when inventing OO) does the trick ;-) Heiko On 20 Aug 2014, at 17:00, Tom Sorensen tsoren...@gmail.com wrote: I've already looked at all the links from https://www.assembla.com/spaces/akka/tickets/3043#/activity/ticket: as well as http://hs.ljungblad.nu/post/69922869833/testing-parent-child-relationships-in-akka Still no closer to actually finding a working solution for testing an actor which spawns a child itself. The latter method appears to be the most elegant, but I simply do not understand what is being done in the Bar class with this, and whether or not it's crucial to the overall implementation. The method using ActorRefFactory as linked from the doc ticket is clear, but it doesn't seem that you can name the Actor being created in this manner, and my use case requires that we be able to do so. My actual use case is a FSM that spawns a child actor; for testing I do want to use TestFSMRef in TestKit, but I want to avoid spawning a real child during the test. Tom Sorensen -- 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. -- 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] Improving Akka Persistence wrt CQRS/ES/DDD
Whilst we are talking about s... process managers I would like to include this simple way of understanding them I found on the web: Process Managers produce commands and consume events, whereas Aggregate Roots consume commands and produce events. The truth is a bit more complicated I believe in that Process Managers can also consume commands (e.g. to stop the process). Further, whilst I would like to accept Roland's view that both commands and events can be communicated by sending messages (since, as he suggests, it would make things a lot simpler and lighter on the write side), I am concerned that there are use-cases for process managers that involve them listening for events from ARs they have not sent a command message to. Can anyone confirm/deny? Thanks, Ashley. On Wednesday, 20 August 2014 23:01:41 UTC+8, Greg Young wrote: further explanation http://soa.dzone.com/news/are-sagas-and-workflows-same-t On Wed, Aug 20, 2014 at 10:39 AM, Greg Young gregor...@gmail.com javascript: wrote: I held the same issue with ms pnp Clarifying the terminology The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this: There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact. Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition. The term saga, in relation to distributed systems, was originally defined in the paper Sagas by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction. On Wed, Aug 20, 2014 at 10:31 AM, Roland Kuhn goo...@rkuhn.info javascript: wrote: 20 aug 2014 kl. 16:16 skrev Greg Young gregor...@gmail.com javascript: : Please stop using the terminology of saga and replace usage with process manager what people (largely influenced by nservicebus call a saga is actually a process manager and a saga is a different pattern). Its bad enough the .net community does this the last thing we need is for the akka community to start doing the same :) Sure, but please do educate us as to the right use of these two words so we persist the correct 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: : On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like Kafka may replicate the events into separate topics based on this information), others (like Event Store) may use this information later to form streams of links to the original events. The event store has the full event available, which is all the information there is: gathering or duplicating arbitrary parts of the information is likely not going to help, because you will discover later that you missed
[akka-user] Question about: Make entries of shards persistent
Hi, I saw this tweet by Patrik: 'Fantastic #Akka https://twitter.com/hashtag/Akka?src=hash contribution by Dominic Black merged to master. Cluster sharding remembers active entries. https:// github.com/akka/akka/pull/15597 … https://t.co/P32NbQQokG' I think it is a really cool feature to be able to reactivate active entities in a cluster when rebalancing occurs. So thanks to Dominic for the great work! I will benefit a lot from this feature. However I am wondering about fault tolerance. One would typically use sharding when the actors doesn't fit on one machine (CPU or Memory) right? So restarting the sharded entries eagerly could end up in a software solution that will be unable to restart again, or will tear down the whole cluster when rebalancing. I guess we need some strategy to prevent this eager restarting when there are not enough (how do we now what is enough) nodes in the cluster. This will keep the cluster alive. How do the NoSQL Databases that support sharding do this? Is there already a strategy to prevent eager restarting to make this feature fault tolerant? Cheers, Jeroen -- 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] Improving Akka Persistence wrt CQRS/ES/DDD
You can relatively easily support process managers on top (event store assures idempotency) On Wed, Aug 20, 2014 at 5:46 PM, Gary Malouf malouf.g...@gmail.com wrote: Greg - if one uses the current Akka Persistence with eventstore as the backend, is it possible/what are the challenges in getting safe 'process managers' to work as one would expect? I would think you'd want event store feeding a different Akka Persistence processor. On Wed, Aug 20, 2014 at 2:10 PM, Ashley Aitken amait...@gmail.com wrote: Whilst we are talking about s... process managers I would like to include this simple way of understanding them I found on the web: Process Managers produce commands and consume events, whereas Aggregate Roots consume commands and produce events. The truth is a bit more complicated I believe in that Process Managers can also consume commands (e.g. to stop the process). Further, whilst I would like to accept Roland's view that both commands and events can be communicated by sending messages (since, as he suggests, it would make things a lot simpler and lighter on the write side), I am concerned that there are use-cases for process managers that involve them listening for events from ARs they have not sent a command message to. Can anyone confirm/deny? Thanks, Ashley. On Wednesday, 20 August 2014 23:01:41 UTC+8, Greg Young wrote: further explanation http://soa.dzone.com/news/are-sagas-and- workflows-same-t On Wed, Aug 20, 2014 at 10:39 AM, Greg Young gregor...@gmail.com wrote: I held the same issue with ms pnp Clarifying the terminology The term saga is commonly used in discussions of CQRS to refer to a piece of code that coordinates and routes messages between bounded contexts and aggregates. However, for the purposes of this guidance we prefer to use the term process manager to refer to this type of code artifact. There are two reasons for this: There is a well-known, pre-existing definition of the term saga that has a different meaning from the one generally understood in relation to CQRS. The term process manager is a better description of the role performed by this type of code artifact. Although the term saga is often used in the context of the CQRS pattern, it has a pre-existing definition. We have chosen to use the term process manager in this guidance to avoid confusion with this pre-existing definition. The term saga, in relation to distributed systems, was originally defined in the paper Sagas by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction. On Wed, Aug 20, 2014 at 10:31 AM, Roland Kuhn goo...@rkuhn.info wrote: 20 aug 2014 kl. 16:16 skrev Greg Young gregor...@gmail.com: Please stop using the terminology of saga and replace usage with process manager what people (largely influenced by nservicebus call a saga is actually a process manager and a saga is a different pattern). Its bad enough the .net community does this the last thing we need is for the akka community to start doing the same :) Sure, but please do educate us as to the right use of these two words so we persist the correct 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 wrote: 19 aug 2014 kl. 18:59 skrev Ashley Aitken amai...@gmail.com: On Tuesday, 19 August 2014 21:14:17 UTC+8, rkuhn wrote: 18 aug 2014 kl. 18:01 skrev Ashley Aitken amai...@gmail.com: 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 to facilitate the read side extracting them according to what criteria is needed, This is a convoluted way of saying that Events must be self-contained, right? In that case: check! No, I don't think so. As I understand it now, the only thing the event store knows about each event is the persistenceId and a chunk of opaque data. It doesn't know the type of the event, the type of the message, any time information, any causal dependency etc. I guess what I am saying is that the events need to include as much metadata as possible so that the event store can provide the necessary synthetic streams if they are requested by the read side. As I mentioned later, some event stores (like
