Hi Paul,
You raise a valid point about still using java serialization in some places
by default.
In general we strongly advertise against using the java serializer (slow,
and schema evolution hostile) - which again is the culprit here...
You're right however that it's one of our internal classes and we could
handle this better.
Not very far away in time we're planning to rewrite the remoting protocol (
https://github.com/akka/akka/issues/12481 ),
in which we would also address the stabilise protocols issues like this
one.
This won't happen in the upcoming minor releases though, it needs a major
one.
For persistence we have applied an interesting byte patching trick to
deserializing objects stored and then retrieved in different scala versions
recently:
https://github.com/akka/akka/pull/16660/files which allows reading/storing
Option between scala versions (2.10 / 2.11).
We're considering if it may be worthwhile to use it here as well, not sure
yet.
// Slightly related - in rolling upgrades being serialization compatible is
the easy part, semantic compatibility is the real killer, here's a very
interesting horror story when a deployment of mixed instances got things
400-million $ wrong: Doug Seven: Knightmare - a devops cautionary tale
http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale (SEC
post mortem here http://www.sec.gov/litigation/admin/2013/34-70694.pdf)
--
Konrad
--
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.