Hi Martin, This helped, thank you very much!
Btw. after overriding onReplayFailure, I've realised that the View was constantly hitting it (deserialization exception) and it was getting swallowed silently. Is this the expected behavior? Best, -- Jacek On Tuesday, April 29, 2014 7:28:22 AM UTC+2, Martin Krasser wrote: > > > On 29.04.14 07:22, Martin Krasser wrote: > > Hi Jacek, > > you can achieve that by overriding the methods onReplaySuccess and > onReplayFailure in akka.persistence.View. Only problem is that their > visibility is private[persistence] in the latest release, so you'd need to > place your implementation class in the akka.persistence package as a > workaround. There is already a ticket > > > https://github.com/akka/akka/issues/13944 > > that discusses sending special messages to processors (and views) after > (incremental) message replays. This would then offer a public API for your > use case. > > With the described workaround: > > EVENT A = onReplayFailure call (several times, depending on how long the > backend store is unavailable) > EVENT B = first received message after backend store became available > again (0..n messages) > EVENT C = onReplaySuccess call > > Hope that helps. > > Cheers, > Martin > > On 28.04.14 21:38, Jacek Dąbrowski wrote: > > Hello, > > I'm trying to figure out, how to handle journal failures with > akka-persistence Views. > > Imagine the following scenario: > > 1. Processor (actor system 1) writes messages 1-10 > 2. Processor (actor system 1) writes messages 11-20 > 3. View (actor system 2) reads messages 1-10 > 4. Journal crashes > 5. <View: detect that journal is dead> - EVENT A > 6. <View: detect that journal is back up> - EVENT B > 7. <View: read messages 11-20 from the journal> - EVENT C > 8. <View: resume normal operation> - back to normal processing > > > The View is processing a slice of configuration that critically impacts > the program's main request handling function. What I'm trying to achieve is > to detect events: A, B and C, and wrap the programs logic around them, e.g. > enqueue requests between events A and C, perform some kind of reload on > event B. > > Is this possible with akka-persistence? If not, maybe at least detecting > journal failure after a couple of polling attempts fail? > > > Best regards, > > -- > Jacek > -- > >>>>>>>>>> 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] <javascript:>. > To post to this group, send email to [email protected]<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 > > > -- > 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 [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.
