I pulled in the build file changes and that fixed the tests - good news. So, https://github.com/apache/zookeeper/pull/377 <https://github.com/apache/zookeeper/pull/377> is ready.
-Jordan > On Sep 27, 2017, at 11:07 PM, Jordan Zimmerman <jor...@jordanzimmerman.com> > wrote: > > This is on Jenkins. > > https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1051/testReport/ > > <https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1051/testReport/> > >> On Sep 27, 2017, at 11:06 PM, Patrick Hunt <ph...@apache.org> wrote: >> >> Check your classpath (typ the build/libs and build/test/libs directories) - >> how many log4j jar files do you have? Are there conflicting versions? (same >> jar diff versions I mean). >> >> Patrick >> >> On Wed, Sep 27, 2017 at 8:57 PM, Jordan Zimmerman >> <jor...@jordanzimmerman.com <mailto:jor...@jordanzimmerman.com>> wrote: >> Now I'm getting a different error: >> >> 2017-09-28 03:47:24,878 [myid:2] - ERROR [Thread-1:AppenderDynamicMBean@209] >> - Could not add DynamicLayoutMBean for >> [CONSOLE,layout=org.apache.log4j.PatternLayout]. >> javax.management.InstanceAlreadyExistsException: >> log4j:appender=CONSOLE,layout=org.apache.log4j.PatternLayout >> >> >>> On Sep 27, 2017, at 1:17 PM, Jordan Zimmerman <jor...@jordanzimmerman.com >>> <mailto:jor...@jordanzimmerman.com>> wrote: >>> >>> I didn't change anything. I branched from master. What should I do any >>> ideas? >>> >>>> On Sep 27, 2017, at 1:15 PM, Patrick Hunt <ph...@apache.org >>>> <mailto:ph...@apache.org>> wrote: >>>> >>>> Has the log4j configuration changed at all? iirc the console appender >>>> needs to be setup for those tests to function. >>>> >>>> Patrick >>>> >>>> On Sat, Sep 23, 2017 at 8:01 AM, Jordan Zimmerman >>>> <jor...@jordanzimmerman.com <mailto:jor...@jordanzimmerman.com>> wrote: >>>> There are 4 tests throwing NPEs in Jenkins due to: >>>> >>>> Layout layout = Logger.getRootLogger().getAppender("CONSOLE") >>>> .getLayout(); >>>> >>>> Is this a known issue? Any workaround? >>>> >>>> -Jordan >>>> >>>>> On Sep 21, 2017, at 9:17 AM, Jordan Zimmerman <jor...@jordanzimmerman.com >>>>> <mailto:jor...@jordanzimmerman.com>> wrote: >>>>> >>>>> In LeaderSessionTracker.java there is this bit of code: >>>>> >>>>> if (!localSessionsEnabled >>>>> || (getServerIdFromSessionId(sessionId) == serverId)) { >>>>> throw new SessionExpiredException(); >>>>> } >>>>> >>>>> "serverId" is a long. This can only work if Server IDs are 255 or less. I >>>>> realize this is in the docs. But is it enforced? See: >>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2503 >>>>> <https://issues.apache.org/jira/browse/ZOOKEEPER-2503> >>>>> >>>>> >>>>> >>>>>> On Sep 20, 2017, at 3:10 PM, Raúl Gutiérrez Segalés >>>>>> <r...@itevenworks.net <mailto:r...@itevenworks.net>> wrote: >>>>>> >>>>>> On 20 September 2017 at 12:54, Camille Fournier <cami...@apache.org >>>>>> <mailto:cami...@apache.org>> wrote: >>>>>> Ok let's take this back to either public mailing list or jira. I'd write >>>>>> up >>>>>> thoughts on jira and ask there+ml to look. I'll try to look tonight >>>>>> >>>>>> Thanks Camille! >>>>>> >>>>>> Also, I merged this originally so I will work with Jordan on getting >>>>>> this fixed. Let me know >>>>>> when you have a write up of your proposed solution and I'll take a look. >>>>>> Thanks! >>>>>> >>>>>> >>>>>> -rgs >>>>>> >>>>>> >>>>>> >>>>>> On Sep 20, 2017 3:52 PM, "Jordan Zimmerman" <jor...@jordanzimmerman.com >>>>>> <mailto:jor...@jordanzimmerman.com>> >>>>>> wrote: >>>>>> >>>>>> > I'd like to fix it as my company and probably many others are now >>>>>> > using it >>>>>> > in production. The question is how to fix it safely and correctly. Is >>>>>> > email >>>>>> > the best way to discuss this? Jira? Something else? >>>>>> > >>>>>> > I must say that there appears to be a trivial fix but I need the ZK >>>>>> > committers to think about this. In >>>>>> > SessionTrackerImpl#initializeNextSession() >>>>>> > only some of the server ID bits are used. We could easily just mask >>>>>> > the 2 >>>>>> > high bits as well. But, what are the implications of this? Where is >>>>>> > this >>>>>> > serverId byte used? What must be double checked? >>>>>> > >>>>>> > -Jordan >>>>>> > >>>>>> > On Sep 20, 2017, at 2:46 PM, Camille Fournier <cami...@apache.org >>>>>> > <mailto:cami...@apache.org>> wrote: >>>>>> > >>>>>> > Would you rather roll back the feature or put in a fix? >>>>>> > >>>>>> > On Sep 20, 2017 3:44 PM, "Jordan Zimmerman" >>>>>> > <jor...@jordanzimmerman.com <mailto:jor...@jordanzimmerman.com>> >>>>>> > wrote: >>>>>> > >>>>>> >> Hey Folks, >>>>>> >> >>>>>> >> This is very serious. Please - let's discuss immediately. I'm not >>>>>> >> certain >>>>>> >> how to fix this. >>>>>> >> >>>>>> >> -JZ >>>>>> >> >>>>>> >> On Sep 20, 2017, at 2:17 PM, Jordan Zimmerman >>>>>> >> <jor...@jordanzimmerman.com <mailto:jor...@jordanzimmerman.com>> >>>>>> >> wrote: >>>>>> >> >>>>>> >> See: https://issues.apache.org/jira/browse/ZOOKEEPER-2901 >>>>>> >> <https://issues.apache.org/jira/browse/ZOOKEEPER-2901> >>>>>> >> >>>>>> >> It appears that the high order byte of a session ID is reserved for >>>>>> >> the >>>>>> >> ServerID. I don't know how I could have missed this or how this got >>>>>> >> by code >>>>>> >> review, but Container Nodes and TTL nodes are using the 2 high bits to >>>>>> >> denote container/TTL. I'll work on a fix ASAP. But, can someone >>>>>> >> validate >>>>>> >> this? >>>>>> >> >>>>>> >> -Jordan >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> > >>>>>> >>>>> >>>> >>>> >>> >> >> >
