[jira] Commented: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893935#action_12893935
 ] 

Patrick Hunt commented on ZOOKEEPER-829:


Perhaps we should think of it as close or disconnect rather than 
expire/disconnect. We already have this feature in JMX btw (just not as easily 
accessible) and you can also do it by connecting a new session with the same 
id/pass and then closing that...

> Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
> -
>
> Key: ZOOKEEPER-829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Todd Lipcon
>
> For some use cases in HBase (HBASE-1316 in particular) we'd like the ability 
> to forcible expire someone else's ZK session. Patrick and I discussed on IRC 
> and came up with an idea of creating nodes in /zookeeper/sessions/ id> that can be read in order to get basic stats about a session, and written 
> in order to manipulate one. The manipulation we need in HBase is the ability 
> to write a command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Todd Lipcon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893919#action_12893919
 ] 

Todd Lipcon commented on ZOOKEEPER-829:
---

The feature we need in HBase is the ability to kill it immediately (and hence 
fence it from making any further actions in ZK)

> Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
> -
>
> Key: ZOOKEEPER-829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Todd Lipcon
>
> For some use cases in HBase (HBASE-1316 in particular) we'd like the ability 
> to forcible expire someone else's ZK session. Patrick and I discussed on IRC 
> and came up with an idea of creating nodes in /zookeeper/sessions/ id> that can be read in order to get basic stats about a session, and written 
> in order to manipulate one. The manipulation we need in HBase is the ability 
> to write a command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893910#action_12893910
 ] 

Benjamin Reed commented on ZOOKEEPER-829:
-

should we kill the session immediately or wait until the sessionTimeout. 
killing it immediate seems like it is violating a contract.

> Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
> -
>
> Key: ZOOKEEPER-829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Todd Lipcon
>
> For some use cases in HBase (HBASE-1316 in particular) we'd like the ability 
> to forcible expire someone else's ZK session. Patrick and I discussed on IRC 
> and came up with an idea of creating nodes in /zookeeper/sessions/ id> that can be read in order to get basic stats about a session, and written 
> in order to manipulate one. The manipulation we need in HBase is the ability 
> to write a command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Applying ZooKeeper patch

[Vishal K]

Hi Patrick, Mahadev,

We would like to apply critical patches asap. For example, this bug was
preventing a failed node to rejoin the cluster. In such cases, it won't be
possible to wait for the next version. What process do you suggest to be
follow in such a case?  I am not restricting the discussion to this
particular bug (say I was using 3.2.2 or older version).

Thanks.
-Vishal

On Thu, Jul 29, 2010 at 6:12 PM, Patrick Hunt  wrote:

> To be clear we are shooting for a release candidate next week, it will take
> a few days after that to go through the process before an official release
> is available.
>
> Patrick
>
>
> On 07/29/2010 02:22 PM, Mahadev Konar wrote:
>
>> HI Vishal,
>>   There is patch available for 3.3 branch which I think should apply.
>>
>>
>> https://issues.apache.org/jira/secure/attachment/12450761/ZOOKEEPER-790-3.3
>> .
>> v2.patch
>>
>> On the other hand its not a good idea to have run your own patched version
>> of ZooKeeper in production. 3.3.2 should be out by next week, you might
>> want
>> to wait for that and then use it.
>>
>> Thanks
>> mahadev
>>
>>
>> On 7/29/10 1:48 PM, "Vishal K"  wrote:
>>
>>  Hi,
>>>
>>> What would be the right way to apply a zookeeper patch. For instance, if
>>> I
>>> am using zookeeper-3-3.0 and I would like to apply a patch for
>>> ZOOKEEPER-790
>>> to this version.
>>> However, I presume that the patch that I have is generate from the trunk.
>>> Is
>>> there a way I can get a patch specific to zookeeper-3-3.0?
>>>
>>> Thanks.
>>> -Vishal
>>>
>>
>>

Re: Applying ZooKeeper patch

[Patrick Hunt]

To be clear we are shooting for a release candidate next week, it will 
take a few days after that to go through the process before an official 
release is available.


Patrick

On 07/29/2010 02:22 PM, Mahadev Konar wrote:

HI Vishal,
   There is patch available for 3.3 branch which I think should apply.

https://issues.apache.org/jira/secure/attachment/12450761/ZOOKEEPER-790-3.3.
v2.patch

On the other hand its not a good idea to have run your own patched version
of ZooKeeper in production. 3.3.2 should be out by next week, you might want
to wait for that and then use it.

Thanks
mahadev


On 7/29/10 1:48 PM, "Vishal K"  wrote:


Hi,

What would be the right way to apply a zookeeper patch. For instance, if I
am using zookeeper-3-3.0 and I would like to apply a patch for ZOOKEEPER-790
to this version.
However, I presume that the patch that I have is generate from the trunk. Is
there a way I can get a patch specific to zookeeper-3-3.0?

Thanks.
-Vishal

Re: Applying ZooKeeper patch

[Mahadev Konar]

HI Vishal,
  There is patch available for 3.3 branch which I think should apply.

https://issues.apache.org/jira/secure/attachment/12450761/ZOOKEEPER-790-3.3.
v2.patch

On the other hand its not a good idea to have run your own patched version
of ZooKeeper in production. 3.3.2 should be out by next week, you might want
to wait for that and then use it.

Thanks
mahadev


On 7/29/10 1:48 PM, "Vishal K"  wrote:

> Hi,
> 
> What would be the right way to apply a zookeeper patch. For instance, if I
> am using zookeeper-3-3.0 and I would like to apply a patch for ZOOKEEPER-790
> to this version.
> However, I presume that the patch that I have is generate from the trunk. Is
> there a way I can get a patch specific to zookeeper-3-3.0?
> 
> Thanks.
> -Vishal

[jira] Updated: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership

[Mahadev konar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mahadev konar updated ZOOKEEPER-790:


Status: Resolved  (was: Patch Available)
Resolution: Fixed

I just committed this. thanks flavio and others!


> Last processed zxid set prematurely while establishing leadership
> -
>
> Key: ZOOKEEPER-790
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.3.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, 
> ZOOKEEPER-790-3.3.v2.patch, ZOOKEEPER-790-follower-request-NPE.log, 
> ZOOKEEPER-790-test.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.travis.log.bz2, ZOOKEEPER-790.v2.patch, ZOOKEEPER-790.v2.patch, 
> ZOOKEEPER-790.v2.patch
>
>
> The leader code is setting the last processed zxid to the first of the new 
> epoch even before connecting to a quorum of followers. Because the leader 
> code sets this value before connecting to a quorum of followers 
> (Leader.java:281) and the follower code throws an IOException 
> (Follower.java:73) if the leader epoch is smaller, we have that when the 
> false leader drops leadership and becomes a follower, it finds a smaller 
> epoch and kills itself.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership

[Mahadev konar (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893816#action_12893816
 ] 

Mahadev konar commented on ZOOKEEPER-790:
-

+1 the patch looks good. I will go ahead and commit it.



> Last processed zxid set prematurely while establishing leadership
> -
>
> Key: ZOOKEEPER-790
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.3.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, 
> ZOOKEEPER-790-3.3.v2.patch, ZOOKEEPER-790-follower-request-NPE.log, 
> ZOOKEEPER-790-test.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.travis.log.bz2, ZOOKEEPER-790.v2.patch, ZOOKEEPER-790.v2.patch, 
> ZOOKEEPER-790.v2.patch
>
>
> The leader code is setting the last processed zxid to the first of the new 
> epoch even before connecting to a quorum of followers. Because the leader 
> code sets this value before connecting to a quorum of followers 
> (Leader.java:281) and the follower code throws an IOException 
> (Follower.java:73) if the leader epoch is smaller, we have that when the 
> false leader drops leadership and becomes a follower, it finds a smaller 
> epoch and kills itself.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Applying ZooKeeper patch

[Vishal K]

Hi,

What would be the right way to apply a zookeeper patch. For instance, if I
am using zookeeper-3-3.0 and I would like to apply a patch for ZOOKEEPER-790
to this version.
However, I presume that the patch that I have is generate from the trunk. Is
there a way I can get a patch specific to zookeeper-3-3.0?

Thanks.
-Vishal

[jira] Commented: (ZOOKEEPER-790) Last processed zxid set prematurely while establishing leadership

[Vishal K (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893776#action_12893776
 ] 

Vishal K commented on ZOOKEEPER-790:


Hi,

I tested the patch and it works really well. I have a test that fails and 
restarts zookeeper server in a loop. I kept it going for 150 rounds and found 
no issues.
Thanks a lot.

-Vishal

> Last processed zxid set prematurely while establishing leadership
> -
>
> Key: ZOOKEEPER-790
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-790
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.3.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-790-3.3.patch, ZOOKEEPER-790-3.3.patch, 
> ZOOKEEPER-790-3.3.v2.patch, ZOOKEEPER-790-follower-request-NPE.log, 
> ZOOKEEPER-790-test.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, ZOOKEEPER-790.patch, 
> ZOOKEEPER-790.travis.log.bz2, ZOOKEEPER-790.v2.patch, ZOOKEEPER-790.v2.patch, 
> ZOOKEEPER-790.v2.patch
>
>
> The leader code is setting the last processed zxid to the first of the new 
> epoch even before connecting to a quorum of followers. Because the leader 
> code sets this value before connecting to a quorum of followers 
> (Leader.java:281) and the follower code throws an IOException 
> (Follower.java:73) if the leader epoch is smaller, we have that when the 
> false leader drops leadership and becomes a follower, it finds a smaller 
> epoch and kills itself.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-811) Failure Detector Model: Refactor server to server monitoring

[Abmar Barros (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abmar Barros updated ZOOKEEPER-811:
---

Attachment: ZOOKEEPER-811.patch

In this patch:
 * Leaders use the FailureDetector interface to monitor learners.
 * Added learners failure detector options to server configuration file.

> Failure Detector Model: Refactor server to server monitoring
> 
>
> Key: ZOOKEEPER-811
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-811
> Project: Zookeeper
>  Issue Type: Sub-task
>Reporter: Abmar Barros
>Assignee: Abmar Barros
> Attachments: ZOOKEEPER-811.patch
>
>
> Refactor server to server failure detection code to use the FailureDetector 
> interface proposed in the parent JIRA. The failure detection method and its 
> parameters should also be configurable in this case. 
> Patches submitted in this JIRA use the latest patch of the parent JIRA as 
> baseline.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-702) GSoC 2010: Failure Detector Model

[Abmar Barros (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abmar Barros updated ZOOKEEPER-702:
---

Attachment: ZOOKEEPER-702.patch

In this patch I removed some tests modifications that were not intended to be 
committed.

> GSoC 2010: Failure Detector Model
> -
>
> Key: ZOOKEEPER-702
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-702
> Project: Zookeeper
>  Issue Type: Wish
>Reporter: Henry Robinson
>Assignee: Abmar Barros
> Attachments: bertier-pseudo.txt, bertier-pseudo.txt, chen-pseudo.txt, 
> chen-pseudo.txt, phiaccrual-pseudo.txt, phiaccrual-pseudo.txt, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, ZOOKEEPER-702.patch, 
> ZOOKEEPER-702.patch
>
>
> Failure Detector Module
> Possible Mentor
> Henry Robinson (henry at apache dot org)
> Requirements
> Java, some distributed systems knowledge, comfort implementing distributed 
> systems protocols
> Description
> ZooKeeper servers detects the failure of other servers and clients by 
> counting the number of 'ticks' for which it doesn't get a heartbeat from 
> other machines. This is the 'timeout' method of failure detection and works 
> very well; however it is possible that it is too aggressive and not easily 
> tuned for some more unusual ZooKeeper installations (such as in a wide-area 
> network, or even in a mobile ad-hoc network).
> This project would abstract the notion of failure detection to a dedicated 
> Java module, and implement several failure detectors to compare and contrast 
> their appropriateness for ZooKeeper. For example, Apache Cassandra uses a 
> phi-accrual failure detector (http://ddsg.jaist.ac.jp/pub/HDY+04.pdf) which 
> is much more tunable and has some very interesting properties. This is a 
> great project if you are interested in distributed algorithms, or want to 
> help re-factor some of ZooKeeper's internal code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893736#action_12893736
 ] 

Patrick Hunt commented on ZOOKEEPER-829:


btw, a getData on one of these znodes should return useful information about 
the session - similar to "cons" 4letter word I would think. (but not limited to)

> Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
> -
>
> Key: ZOOKEEPER-829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Todd Lipcon
>
> For some use cases in HBase (HBASE-1316 in particular) we'd like the ability 
> to forcible expire someone else's ZK session. Patrick and I discussed on IRC 
> and came up with an idea of creating nodes in /zookeeper/sessions/ id> that can be read in order to get basic stats about a session, and written 
> in order to manipulate one. The manipulation we need in HBase is the ability 
> to write a command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893729#action_12893729
 ] 

Patrick Hunt commented on ZOOKEEPER-829:


Implementing as part of /zookeeper (a znode) allows us to easily add this 
feature (vs changing the wire protocol). Integration with existing zk 
clients/libs/bindings/etc... will be simplified. Also we get ACLs in the 
bargain.

Note that this also solves a lot of problems wrt client side testing - session 
expiration and disconnection will both be easy features to provide.

I suggest we use commands like "expire" and "disconnect" rather than "kill"

Another idea comes to mind - we might have /zookeeper/sessions/ and also 
/zookeeper//sessions/, this second option would allow for a 
"supervisory" process to monitor load on the servers and forcibly disconnect 
clients, thereby redistributing the load. This has been a bane for us 
(equitable load distribution on the servers) and a feature like this seems like 
a great solution.

> Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
> -
>
> Key: ZOOKEEPER-829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Todd Lipcon
>
> For some use cases in HBase (HBASE-1316 in particular) we'd like the ability 
> to forcible expire someone else's ZK session. Patrick and I discussed on IRC 
> and came up with an idea of creating nodes in /zookeeper/sessions/ id> that can be read in order to get basic stats about a session, and written 
> in order to manipulate one. The manipulation we need in HBase is the ability 
> to write a command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (ZOOKEEPER-829) Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions

[Todd Lipcon (JIRA)]

Add /zookeeper/sessions/* to allow inspection/manipulation of client sessions
-

 Key: ZOOKEEPER-829
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-829
 Project: Zookeeper
  Issue Type: New Feature
  Components: server
Reporter: Todd Lipcon


For some use cases in HBase (HBASE-1316 in particular) we'd like the ability to 
forcible expire someone else's ZK session. Patrick and I discussed on IRC and 
came up with an idea of creating nodes in /zookeeper/sessions/ that 
can be read in order to get basic stats about a session, and written in order 
to manipulate one. The manipulation we need in HBase is the ability to write a 
command like "kill", but others might be useful as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-794) Callbacks are not invoked when the client is closed

[Alexis Midon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexis Midon updated ZOOKEEPER-794:
---

Status: Patch Available  (was: Open)

> Callbacks are not invoked when the client is closed
> ---
>
> Key: ZOOKEEPER-794
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-794
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Alexis Midon
>Assignee: Alexis Midon
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-794.patch.txt, ZOOKEEPER-794.txt, 
> ZOOKEEPER-794_2.patch, ZOOKEEPER-794_3.patch
>
>
> I noticed that ZooKeeper has different behaviors when calling synchronous or 
> asynchronous actions on a closed ZooKeeper client.
> Actually a synchronous call will throw a "session expired" exception while an 
> asynchronous call will do nothing. No exception, no callback invocation.
> Actually, even if the EventThread receives the Packet with the session 
> expired err code, the packet is never processed since the thread has been 
> killed by the ventOfDeath. So the call back is not invoked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-794) Callbacks are not invoked when the client is closed

[Alexis Midon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexis Midon updated ZOOKEEPER-794:
---

Status: Open  (was: Patch Available)

> Callbacks are not invoked when the client is closed
> ---
>
> Key: ZOOKEEPER-794
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-794
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Alexis Midon
>Assignee: Alexis Midon
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-794.patch.txt, ZOOKEEPER-794.txt, 
> ZOOKEEPER-794_2.patch, ZOOKEEPER-794_3.patch
>
>
> I noticed that ZooKeeper has different behaviors when calling synchronous or 
> asynchronous actions on a closed ZooKeeper client.
> Actually a synchronous call will throw a "session expired" exception while an 
> asynchronous call will do nothing. No exception, no callback invocation.
> Actually, even if the EventThread receives the Packet with the session 
> expired err code, the packet is never processed since the thread has been 
> killed by the ventOfDeath. So the call back is not invoked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-794) Callbacks are not invoked when the client is closed

[Alexis Midon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexis Midon updated ZOOKEEPER-794:
---

Attachment: ZOOKEEPER-794_3.patch

> Callbacks are not invoked when the client is closed
> ---
>
> Key: ZOOKEEPER-794
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-794
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Alexis Midon
>Assignee: Alexis Midon
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-794.patch.txt, ZOOKEEPER-794.txt, 
> ZOOKEEPER-794_2.patch, ZOOKEEPER-794_3.patch
>
>
> I noticed that ZooKeeper has different behaviors when calling synchronous or 
> asynchronous actions on a closed ZooKeeper client.
> Actually a synchronous call will throw a "session expired" exception while an 
> asynchronous call will do nothing. No exception, no callback invocation.
> Actually, even if the EventThread receives the Packet with the session 
> expired err code, the packet is never processed since the thread has been 
> killed by the ventOfDeath. So the call back is not invoked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ZOOKEEPER-794) Callbacks are not invoked when the client is closed

[Alexis Midon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893618#action_12893618
 ] 

Alexis Midon commented on ZOOKEEPER-794:


Hi Benjamin,
thanks a lot for the review.
One thing I noticed is that setting wasKilled in the method queueEventOfDeath 
might affect the order in which events are processed. Actually if 
queueEventOfDeath is invoked while the waitingEvents queue is not empty, any 
subsequent calls to queuePacket might  invoke processEvent for the received 
Packet before the packets already queued are processed (since wasKilled is 
true).
I guess this could happened if there are a lot of events queued in 
waitingEvents.

0. Let's assume that, initially, the queue waitingEvents contains N events: 
Event-0,...,Event-N
1. queueEventOfDeath is invoked, wasKilled is now true and the queue contains: 
Event-k,...,Event-N, Event-Death
2. a new Packet comes in, queuePacket is invoked. Since wasKilled is true, the 
new event Event-N+1 is processed right away before Event-N might have been 
processed.

On the other hand, my initial patch will let Event-N+1 in the queue and it will 
never get processed since the event of death will break the loop. Which is 
worse.

I attached a new patch that aims to fix the ordering issue. The idea is to keep 
queueing Event-N+i until the event of death has been processed and the queue is 
empty. I see one downside with this approach: if events keep coming in, the 
EventThread might not stop since the queue will never get empty.
Please review.

Alexis

> Callbacks are not invoked when the client is closed
> ---
>
> Key: ZOOKEEPER-794
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-794
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.3.1
>Reporter: Alexis Midon
>Assignee: Alexis Midon
> Fix For: 3.3.2, 3.4.0
>
> Attachments: ZOOKEEPER-794.patch.txt, ZOOKEEPER-794.txt, 
> ZOOKEEPER-794_2.patch, ZOOKEEPER-794_3.patch
>
>
> I noticed that ZooKeeper has different behaviors when calling synchronous or 
> asynchronous actions on a closed ZooKeeper client.
> Actually a synchronous call will throw a "session expired" exception while an 
> asynchronous call will do nothing. No exception, no callback invocation.
> Actually, even if the EventThread receives the Packet with the session 
> expired err code, the packet is never processed since the thread has been 
> killed by the ventOfDeath. So the call back is not invoked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Build failed in Hudson: ZooKeeper-trunk #889

[Apache Hudson Server]

See 

--
[...truncated 117699 lines...]
[junit] at 
java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:342)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:570)
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-674:quorumcnxmanager$sendwor...@581] - Interrupted while waiting for 
message on queue
[junit] java.lang.InterruptedException
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1899)
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1976)
[junit] at 
java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:342)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:570)
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-710:quorumcnxmanager$sendwor...@581] - Interrupted while waiting for 
message on queue
[junit] java.lang.InterruptedException
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1899)
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1976)
[junit] at 
java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:342)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:570)
[junit] 2010-07-29 11:58:59,564 [myid:] - WARN  
[Thread-674:quorumcnxmanager$sendwor...@589] - Send worker leaving thread
[junit] 2010-07-29 11:58:59,564 [myid:] - WARN  
[Thread-684:quorumcnxmanager$sendwor...@589] - Send worker leaving thread
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-712:quorumcnxmanager$recvwor...@658] - Connection broken: 
[junit] java.nio.channels.AsynchronousCloseException
[junit] at 
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:185)
[junit] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:263)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:629)
[junit] 2010-07-29 11:58:59,563 [myid:] - INFO  [main:quorumb...@326] - 
Waiting for QuorumPeer:/0:0:0:0:0:0:0:0:11234 to exit thread
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-694:quorumcnxmanager$sendwor...@581] - Interrupted while waiting for 
message on queue
[junit] java.lang.InterruptedException
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1899)
[junit] at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1976)
[junit] at 
java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:342)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:570)
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-696:quorumcnxmanager$recvwor...@658] - Connection broken: 
[junit] java.io.IOException: Channel eof
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:630)
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-695:quorumcnxmanager$recvwor...@658] - Connection broken: 
[junit] java.nio.channels.AsynchronousCloseException
[junit] at 
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:185)
[junit] at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:263)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:629)
[junit] 2010-07-29 11:58:59,563 [myid:] - WARN  
[Thread-685:quorumcnxmanager$recvwor...@658] - Connection broken: 
[junit] java.io.IOException: Channel eof
[junit] at 
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:630)
[junit] 2010-07-29 11:58:59,565 [myid:] - WARN  
[Thread-694:quorumcnxmanager$sendwor...@589] - Send worker leaving thread
[junit] 2010-07-29 11:58:59,564 [myid:] - WARN  
[Thread-710:quorumcnxmanager$sendwor...@589] - Send worker leaving thread
[junit] 2010-07-29 11:59:00,558 [myid:] - INFO  
[QuorumPeer:/0:0:0:0:0:0:0:0:11234:follo...@166] - shutdown called
[junit] java.lang.Exception: shutdown Follower
[junit] at 
org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:166)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:648)
[junit] 2010-07-29 11:59:00,558 [myid:] 

[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

[Andrei Savu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Savu updated ZOOKEEPER-780:
--

Attachment: ZOOKEEPER-780.patch

Fixed typo failes -> failed. 

> zkCli.sh  generates a ArrayIndexOutOfBoundsException 
> -
>
> Key: ZOOKEEPER-780
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
> Project: Zookeeper
>  Issue Type: Bug
>  Components: scripts
>Affects Versions: 3.3.1
> Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
>Reporter: Miguel Correia
>Assignee: Andrei Savu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
> ZOOKEEPER-780.patch
>
>
> I'm starting to play with Zookeeper so I'm still running it in standalone 
> mode. This is not a big issue, but here it goes for the records. 
> I've run zkCli.sh to run some commands in the server. I created a znode 
> /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
> include the data: an exception was generated and zkCli-sh crashed, instead of 
> just showing an error. I tried a few variations and it seems like the problem 
> is not including the data.
> A copy of the screen:
> [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
> Created /groups
> [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

[Andrei Savu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Savu updated ZOOKEEPER-780:
--

Status: Patch Available  (was: Open)

> zkCli.sh  generates a ArrayIndexOutOfBoundsException 
> -
>
> Key: ZOOKEEPER-780
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
> Project: Zookeeper
>  Issue Type: Bug
>  Components: scripts
>Affects Versions: 3.3.1
> Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
>Reporter: Miguel Correia
>Assignee: Andrei Savu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, 
> ZOOKEEPER-780.patch
>
>
> I'm starting to play with Zookeeper so I'm still running it in standalone 
> mode. This is not a big issue, but here it goes for the records. 
> I've run zkCli.sh to run some commands in the server. I created a znode 
> /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
> include the data: an exception was generated and zkCli-sh crashed, instead of 
> just showing an error. I tried a few variations and it seems like the problem 
> is not including the data.
> A copy of the screen:
> [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
> Created /groups
> [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

[Andrei Savu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Savu updated ZOOKEEPER-780:
--

Status: Open  (was: Patch Available)

found a typo. will resubmit patch

> zkCli.sh  generates a ArrayIndexOutOfBoundsException 
> -
>
> Key: ZOOKEEPER-780
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
> Project: Zookeeper
>  Issue Type: Bug
>  Components: scripts
>Affects Versions: 3.3.1
> Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
>Reporter: Miguel Correia
>Assignee: Andrei Savu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch
>
>
> I'm starting to play with Zookeeper so I'm still running it in standalone 
> mode. This is not a big issue, but here it goes for the records. 
> I've run zkCli.sh to run some commands in the server. I created a znode 
> /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
> include the data: an exception was generated and zkCli-sh crashed, instead of 
> just showing an error. I tried a few variations and it seems like the problem 
> is not including the data.
> A copy of the screen:
> [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
> Created /groups
> [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

[Andrei Savu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Savu updated ZOOKEEPER-780:
--

Attachment: ZOOKEEPER-780.patch

Added a generic exception handler for all kinds of unexpected errors. 

Output:

[zk: (CLOSED) 1] connect localhost2181
2010-07-29 15:13:32,364 [myid:] - INFO  [main:zookee...@375] - Initiating 
client connection, connectString=localhost2181 sessionTimeout=3 
watcher=org.apache.zookeeper.zookeepermain$mywatc...@209f4e
Command failes: java.net.UnknownHostException: localhost2181

This should make the CLI interface much more robust. 

> zkCli.sh  generates a ArrayIndexOutOfBoundsException 
> -
>
> Key: ZOOKEEPER-780
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
> Project: Zookeeper
>  Issue Type: Bug
>  Components: scripts
>Affects Versions: 3.3.1
> Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
>Reporter: Miguel Correia
>Assignee: Andrei Savu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch
>
>
> I'm starting to play with Zookeeper so I'm still running it in standalone 
> mode. This is not a big issue, but here it goes for the records. 
> I've run zkCli.sh to run some commands in the server. I created a znode 
> /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
> include the data: an exception was generated and zkCli-sh crashed, instead of 
> just showing an error. I tried a few variations and it seems like the problem 
> is not including the data.
> A copy of the screen:
> [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
> Created /groups
> [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException

[Andrei Savu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Savu updated ZOOKEEPER-780:
--

Status: Patch Available  (was: Open)

> zkCli.sh  generates a ArrayIndexOutOfBoundsException 
> -
>
> Key: ZOOKEEPER-780
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780
> Project: Zookeeper
>  Issue Type: Bug
>  Components: scripts
>Affects Versions: 3.3.1
> Environment: Linux Ubuntu running in VMPlayer on top of Windows XP
>Reporter: Miguel Correia
>Assignee: Andrei Savu
>Priority: Minor
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch
>
>
> I'm starting to play with Zookeeper so I'm still running it in standalone 
> mode. This is not a big issue, but here it goes for the records. 
> I've run zkCli.sh to run some commands in the server. I created a znode 
> /groups. When I tried to create a znode client_1 inside /groups, I forgot to 
> include the data: an exception was generated and zkCli-sh crashed, instead of 
> just showing an error. I tried a few variations and it seems like the problem 
> is not including the data.
> A copy of the screen:
> [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup
> Created /groups
> [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.