ctubbsii commented on issue #1893: URL: https://github.com/apache/accumulo/issues/1893#issuecomment-771150438
> It seems that there were multiple packaging decisions that were originally made with the FATE design - I believe the stated goal was that FATEs could become a stand-alone product outside of Accumulo. While that may have been something that was considered, the implementation was, and has always been, very tightly coupled to Accumulo itself. > Should we revisit that? If moving the method would impact FATE serialization should other changes be made concurrently so that FATE serialization would only change once? The problem is that we use Java serialization (in hindsight, a bad choice), and therefore, lots of Java objects can accidentally leak into our serialized FaTE objects. We have, for example, unintentionally serialized Thrift objects (I believe TInfo was one). I don't know of any currently active proposals to redesign FaTE to decouple it from Accumulo, or to change how we serialize objects there any time soon. I don't see any compelling reason to revisit FaTE serialization at this time. But, if we did do something like that, it certainly would be better to do it across the board all at once. One future compelling reason might be the introduction of record objects in a future Java release, which may have safe and reliable serialization strategies. Another compelling reason would be to take advantage of some protobuf or thrift serialization for storage efficiency or performance, or something else. However, libraries like protobuf and thrift are notoriously problematic with dependency convergence. > Also, I believe that during upgrades it is necessary to insure that no FATE transactions are pending or the upgrade aborts - so changes in serialization should not be a factor between upgrades. In general, that is true for major releases, but not for patch/bugfix releases. I don't know off the top of my head what we've done for minor releases, or what our current upgrade code would expect before upgrading from 2.0 to 2.1. However, the more incompatibilities we avoid, the easier our upgrade code and testing paths are. In any case, I think it should be fine to relocate UtilWaitThread, though I don't see a huge value in it. I'm just suggesting caution whenever relocating any object that has potential to be serialized. Classes in packages marked as "fate" have a higher likelihood of being serialized, but they are not the only objects that could be affected by class relocations. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
