zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: Major issue with Container Nodes/TTL nodes!!!
Date Thu, 28 Sep 2017 04:07:53 GMT
This is on Jenkins. 

https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1051/testReport/

> On Sep 27, 2017, at 11:06 PM, Patrick Hunt <phunt@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 <jordan@jordanzimmerman.com <mailto:jordan@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 <jordan@jordanzimmerman.com <mailto:jordan@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 <phunt@apache.org <mailto:phunt@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 <jordan@jordanzimmerman.com
<mailto:jordan@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 <jordan@jordanzimmerman.com
<mailto:jordan@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 <rgs@itevenworks.net
<mailto:rgs@itevenworks.net>> wrote:
>>>>> 
>>>>> On 20 September 2017 at 12:54, Camille Fournier <camille@apache.org
<mailto:camille@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" <jordan@jordanzimmerman.com
<mailto:jordan@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 <camille@apache.org
<mailto:camille@apache.org>> wrote:
>>>>> >
>>>>> > Would you rather roll back the feature or put in a fix?
>>>>> >
>>>>> > On Sep 20, 2017 3:44 PM, "Jordan Zimmerman" <jordan@jordanzimmerman.com
<mailto:jordan@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 <jordan@jordanzimmerman.com
<mailto:jordan@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
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message