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

Flavio Junqueira commented on ZOOKEEPER-1485:
---------------------------------------------

[~marshall] The reasoning sounds right to me, resetting to 0 when overflowing 
should not cause a problem. The Java client also only checks if the expected 
and received xid values are the different in {{ClientCnxn.readResponse}}. 

This discussion actually made me think of ZOOKEEPER-22, which we should really 
finish up some day. In that jira, we want to avoid a duplicate execution of, 
e.g., when creating sequential znodes. I believe we will need to use the xid 
there as well to find the response for the request. The one problem I see is 
that a client that takes a really long time to reconnect might end up seeing a 
different response for its request if multiple requests can have the same xid. 
This is highly unlikely given that in practice it should take some time to 
wraparound and we might be able to play with zxids and such. I'd need to think 
again about that jira, though.

I'm also thinking that closing the session might be a better alternative to 
avoid the wraparound issue altogether. I'm not sure why the observation about 
the xid being a static variable stops us from doing it.  

> client xid overflow is not handled
> ----------------------------------
>
>                 Key: ZOOKEEPER-1485
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1485
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client, java client
>    Affects Versions: 3.4.3, 3.3.5
>            Reporter: Michi Mutsuzaki
>            Assignee: Bruce Gao
>
> Both Java and C clients use signed 32-bit int as XIDs. XIDs are assumed to be 
> non-negative, and zookeeper uses some negative values as special XIDs (e.g. 
> -2 for ping, -4 for auth). However, neither Java nor C client ensures the 
> XIDs it generates are non-negative, and the server doesn't reject negative 
> XIDs.
> Pat had some suggestions on how to fix this:
> - (bin-compat) Expire the session when the client sends a negative XID.
> - (bin-incompat) In addition to expiring the session, use 64-bit int for XID 
> so that overflow will practically never happen.
> --Michi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to