> > Hey, I wanted to know why we have the SerializableSerializer when we > > encounter an unregistered class and what advantage we get by using it over > > the FieldsSerializer from kryo.
I may not be recalling correctly, so take this with a grain of salt: >From my memory it was not there for performance reasons but for ease of use. The fields-based serializer is probably what one would prefer, but from my vague memory, it has to be told how to serialize. To get up-and-running quickly, there was a default serializer. Once you know what you're doing, you certainly should use something more performant. Others please correct me if I am misremembering. -- Derek On Fri, Jan 31, 2025 at 10:27:18AM +0100, Richard Zowalla wrote: > Hi, > > Actually, no idea because that particularly class dates back to 2012: > https://github.com/apache/storm/commit/4debef138e90053e692f72a761e3a3b6692ebe90 > So 12+ years old ;-) - FieldSerializer in Kryo was introduced in 2012 too. > > If you look into the mail archive, there is only a link towards: > https://issues.apache.org/jira/browse/STORM-333 which makes a guess regarding > thread safety. > > If you go into the really legacy archive, you find a few interesting threads: > > - https://groups.google.com/g/storm-user/search?q=SerializableSerializer > > From a quick glimpse it seems it was done on purpose related to thread safety. > > Gruß > Richard > > > > > > Am 27.01.2025 um 11:06 schrieb Mahesh Aravind V > > <mahesharavindvenkat...@gmail.com>: > > > > Hey, I wanted to know why we have the SerializableSerializer when we > > encounter an unregistered class and what advantage we get by using it over > > the FieldsSerializer from kryo. > > I did some very basic performance testing and the FieldsSerializer seems to > > perform better than SerializableSerializer. I could not get context on why > > the SerializableSerializer came to be from the git history. Would > > appreciate any insights. TIA. > > > > Regards, > > Mahesh >
