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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 >> >> >> >> On Sep 20, 2017, at 3:10 PM, Raúl Gutiérrez Segalés <[email protected]> >> wrote: >> >> On 20 September 2017 at 12:54, Camille Fournier <[email protected]> >> 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" <[email protected]> >>> 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#initializeN >>> extSession() >>> > 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 <[email protected]> >>> wrote: >>> > >>> > Would you rather roll back the feature or put in a fix? >>> > >>> > On Sep 20, 2017 3:44 PM, "Jordan Zimmerman" < >>> [email protected]> >>> > 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 < >>> [email protected]> >>> >> wrote: >>> >> >>> >> See: 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 >>> >> >>> >> >>> >> >>> > >>> >> >> >> >> > > >
