On 29.04.14 17:00, Jacek Dąbrowski wrote:
I've expressed it in the wrong way:
The exceptions are obviously my fault (Replay failure
java.io.InvalidClassException local class incompatible: stream
classdesc serialVersionUID = -7798536210032631982, local class
serialVersionUID = -4274187902074218830).
But my question was - is it expected behavior that they get swallowed
silently instead of escalating?
This is a failure occuring in the journal which is just reported to the
view. As such it makes sense that the view doesn't throw that exception
but retry later (which only makes sense for temporary journal failures,
of course). Ticket #13944 <https://github.com/akka/akka/issues/13944>
should improve on that, allowing users to pattern-match against failure
messages (similar to PersistenceFailure received by Processors). Anyway,
the error should have be logged by the view (ticket created
<https://github.com/akka/akka/issues/15094>).
Only after I've overridden the onReplayFailure have I noticed them
occurring.
Best,
--
Jacek
On Tuesday, April 29, 2014 4:46:54 PM UTC+2, Martin Krasser wrote:
On 29.04.14 15:00, Jacek Dąbrowski wrote:
Hi Martin,
This helped, thank you very much!
Glad to hear. You're welcome!
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?
No, this is not expected and I cannot reproduce.
Can't say more without seeing stacktraces/examples. Are you using
a custom serializer?
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
<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
<http://doc.akka.io/docs/akka/current/additional/faq.html>
>>>>>>>>>> Search the archives:
https://groups.google.com/group/akka-user
<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
<http://groups.google.com/group/akka-user>.
For more options, visit https://groups.google.com/d/optout
<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
--
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 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.
