Actually it is set properly. Do NOT change it. It works just fine the way it is.
$ git checkout f6f35dd98d2492a38aa4d61da7f6caee4ec2f31a # The git version right before this change on branch-1.x $ mvn clean install -DskipTests $ serialver -classpath ./storm-core/target/storm-core-1.1.0-SNAPSHOT.jar org.apache.storm.tuple.Fields org.apache.storm.tuple.Fields: private static final long serialVersionUID = -3377931843059975424L; This is the same version that we set it to as a part of the change. - Bobby On Fri, Feb 9, 2018 at 3:00 PM Bobby Evans <[email protected]> wrote: > Fields changing will cause problems if it is serialized as part of a > bolt/spout or as part of a custom grouping. I have not checked explicitly, > but removing that line is the wrong thing to do. By default the > serialVersionUID > is generated from the class itself, so removing it, but leaving in the > modified code would still break backwards compatibility. > > I'll take a look and see what you need to set it to so you don't break > backwards compatibility on 1.x > > On Fri, Feb 9, 2018 at 10:19 AM P. Taylor Goetz <[email protected]> wrote: > >> What are others’ opinions on removing the serialversionUid an moving >> ahead with an RC4? >> >> -Taylor >> >> > On Feb 9, 2018, at 7:21 AM, Jungtaek Lim <[email protected]> wrote: >> > >> > I just went ahead verifying current RC except serialization UID issue in >> > Fields. I could also vote for RC4 immediately if necessary. >> > >> > +1 (binding) >> > >> >> source >> > >> > - verify file (signature, MD5, SHA) >> > -- source, tar.gz : OK >> > -- source, zip : OK >> > >> > - extract file >> > -- source, tar.gz : OK >> > -- source, zip : OK >> > >> > - diff-ing extracted files between tar.gz and zip : OK >> > >> > - build source with JDK 7 >> > -- source, tar.gz : OK >> > >> > - build source dist >> > -- source, tar.gz : OK >> > >> > - build binary dist >> > -- source, tar.gz : OK >> > >> >> binary >> > >> > - verify file (signature, MD5, SHA) >> > -- binary, tar.gz : OK >> > -- binary, zip : OK >> > >> > - extract file >> > -- binary, tar.gz : OK >> > -- binary, zip : OK >> > >> > - diff-ing extracted files between tar.gz and zip : OK >> > >> > - launch daemons : OK >> > >> > - run RollingTopWords (local) : OK >> > >> > - run RollingTopWords (remote) : OK >> > - activate / deactivate / rebalance / kill : OK >> > - logviewer (worker dir, daemon dir) : OK >> > - change log level : OK >> > - thread dump, heap dump, restart worker : OK >> > - log search : OK >> > >> > Thanks, >> > Jungtaek Lim (HeartSaVioR) >> > >> > 2018년 2월 9일 (금) 오후 6:18, Erik Weathers <[email protected]>님이 >> 작성: >> > >> >> 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 >> >>>>>> >> >>> >> >> >> >>
