I'm fine submitting a PR to back that line out (or any of you committer folks could just rip it out).
But I'd like to understand Storm a bit better as part of making this decision. :-) Am I correct in assuming it would only be a problem if the serialized Fields were stored somewhere (e.g., ZooKeeper, local filesystem) and then read back in after the Nimbus/Workers are brought back up after the upgrade? Seems Fields is used in a *lot* of places, and I don't know precisely what is serialized for reused upon Storm Nimbus/Worker daemon restarts. I believe there are examples of Fields being used to create Spout or Bolt objects that are used to create the StormTopology object, which I believe is serialized into ZooKeeper. But I'm not clear if it's directly the Fields object itself or some kind of translation from that into the thrift objects that make up StormTopology. I also don't know exactly when kryo is applicable in Storm. I've never done anything with kryo directly. - Erik On Thu, Feb 8, 2018 at 10:00 PM, P. Taylor Goetz <[email protected]> wrote: > *serialized* ;) > > > On Feb 9, 2018, at 12:48 AM, P. Taylor Goetz <[email protected]> wrote: > > > > I’d have to check (can’t right now), but I think that class gets > sterilized via kryo. If that’s not the case, yes, it could cause problems. > > > > I think the safest option would be to remove the serialversionuid. > > > > -Taylor > > > >> On Feb 8, 2018, at 5:36 PM, Erik Weathers <[email protected]> > wrote: > >> > >> Something I just realized -- in the storm-kafka-client stomping into > >> 1.0.x-branch PR, I backported a change to Fields.java which added a > >> serialVersionUID. > >> Could that potentially break topologies when you upgrade storm-core on > the > >> servers (nimbus, workers) from 1.0.{1..5} to 1.0.6? I'm not super > >> familiar with the serialization that occurs in Storm and whether that > could > >> break people. > >> > >> https://github.com/apache/storm/pull/2550/files#diff-71a428d > 508c4f5af0bfe3cc186e8edcf > >> > >> - Erik > >> > >>> On Thu, Feb 8, 2018 at 1:25 PM, Bobby Evans <[email protected]> > wrote: > >>> > >>> +1 I built the code from the git tag, ran all the unit tests (which > passed > >>> the first time), and ran some tests on a single node cluster. > >>> > >>> It all looked good. > >>> > >>> - Bobby > >>> > >>>> On Thu, Feb 8, 2018 at 1:22 PM P. Taylor Goetz <[email protected]> > wrote: > >>>> > >>>> This is a call to vote on releasing Apache Storm 1.0.6 (rc3) > >>>> > >>>> Full list of changes in this release: > >>>> > >>>> > >>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1. > >>> 0.6-rc3/RELEASE_NOTES.html > >>>> > >>>> The tag/commit to be voted upon is v1.0.6: > >>>> > >>>> > >>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h= > >>> e68365f9f947ddd1794b2edef2149fdfaa1590a2;hb=7993db01580ce62d > 44866dc00e0a72 > >>> 66984638d0 > >>>> > >>>> The source archive being voted upon can be found here: > >>>> > >>>> > >>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1. > >>> 0.6-rc3/apache-storm-1.0.6-src.tar.gz > >>>> > >>>> Other release files, signatures and digests can be found here: > >>>> > >>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.0.6-rc3/ > >>>> > >>>> The release artifacts are signed with the following key: > >>>> > >>>> > >>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_ > >>> plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd > >>>> > >>>> The Nexus staging repository for this release is: > >>>> > >>>> https://repository.apache.org/content/repositories/orgapache > storm-1060 > >>>> > >>>> Please vote on releasing this package as Apache Storm 1.0.6. > >>>> > >>>> When voting, please list the actions taken to verify the release. > >>>> > >>>> This vote will be open for at least 72 hours. > >>>> > >>>> [ ] +1 Release this package as Apache Storm 1.0.6 > >>>> [ ] 0 No opinion > >>>> [ ] -1 Do not release this package because... > >>>> > >>>> Thanks to everyone who contributed to this release. > >>>> > >>>> -Taylor > >>> >
