On 5/30/18 9:08 AM, Keith Turner wrote:
On Wed, May 30, 2018 at 12:16 AM, Christopher <[email protected]> wrote:
I thought this was interesting:
https://www.infoworld.com/article/3275924/java/oracle-plans-to-dump-risky-java-serialization.html
If the long-term plan is to remove serialization from Java classes (in
favor of a lightweight, possibly pluggable, "Records" serialization
framework), we should begin thinking about how we use serialization in
Accumulo's code today. At the very least, we should try to avoid any
reliance on it in any future persistence of objects in Accumulo. If we see
an opportunity to remove it in our current code anywhere, it might be worth
spending the time to do follow through with such a change.
Of course, this is probably going to be a *very* long time before it is
actually dropped from Java, but it's not going to hurt to start thinking
about it now.
(Accumulo uses Java serialization for storing FaTE transaction information,
and perhaps elsewhere.)
We currently do not support FaTE transactions across minor versions.
The upgrade code checks for any outstanding FaTE transactions. So
this makes it easier to upgrade on a minor version. I would like to
see FaTE use a human readable format like Json because it would make
debugging easier.
I'd strongly suggest against using JSON as you it forces the application
to know how to handle drift in "schema". It would be nice to avoid the
need to flush the outstanding fate txns on upgrade.
If you just want a JSON-ish way to look at the data, I'd suggest moving
over to protobuf3 and check out the support they have around JSON.
https://developers.google.com/protocol-buffers/docs/proto3#json
