Hi Chanan,

what you are describing sounds like a perfect use-case for CQRS: the sources 
for commands and reads are not correlated, so it should not matter at which 
point in the sequence a query is executed. This means that you can create a 
View for you EP and ask that one from the Play side; here responsiveness should 
always be good, which is the motivation behind Segregating the Command and 
Query Responsibilities.

Another solution would be to throttle the updates, e.g. using an 
acknowledgement scheme. This would ensure that the EP mailbox is nearly always 
empty, meaning that a read would be served after at most one journal round-trip 
time.

This is another noteworthy point: a system should be designed such that all 
mailboxes are always nearly empty (or nearly always empty, preferably both).

Regards,

Roland

10 maj 2014 kl. 15:39 skrev Chanan Braunstein <[email protected]>:

> Hi Roland,
> 
> I will explain why I tried to use the priority mailbox, there may be better 
> ways of doing this.
> 
> I am creating a POC to see if we can (and how) use Akka-Pesistence 
> (EventSourcing to be specific) for a rewrite of our systems. I have an EP 
> that updates its state and returns data when queried. The query gets sent 
> from a Play controller with an ask. I also have an Actor that creates a bunch 
> of data by sending commands to the EPs. I noticed that during data creation 
> (i.e. when the journal is empty and I run the data creation actor - but also 
> most likely during recovery). My ask queries timeout. On a side note - this 
> could be fixed by the suggestion that were made in the other thread about 
> changes to EP/P to make some stuff async. Till then, I was looking for a 
> solution and the one I noticed from the docs was using a priority mailbox, 
> however, after reading when you mentioned with the Stash I understand why 
> that is not going to work. Now I admit, this is a complete artificial 
> situation that I created due to the data generation, however, we do think we 
> will have quite a bit of heavy traffic since we know our current load. Are 
> there any ways (Other than the changes discussed that may happen to Akka-P 
> that will help us with this problem) to currently get around this problem?
> 
> -- 
> >>>>>>>>>> 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 [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn


-- 
>>>>>>>>>>      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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to