[
https://issues.apache.org/jira/browse/ZOOKEEPER-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15365326#comment-15365326
]
Michael Han commented on ZOOKEEPER-1485:
----------------------------------------
bq. I'm concerned that this approach of allowing the same xid to appear twice
in a session could create problems.
Another potential problem I am thinking is if we allow repeatable xids then we
would not easily figure out the system state (as we don't record how many times
the id has been wrapped so far) from server logs which I am not sure is a real
problem but a little bit concerning to me. I think the design of not allowing
repeatable xid is better from the perspective of making the system behavior
explicit and easier to understand.
bq. What if we fix by not making the xid static in the C client and getting a
new handle?
I think this should work - I don't see a reason why xid can't be made as a
member of zk handle in C as in Java client. So whenever overflow happens, we
simply close the session on server side. Client has to then handle the session
close, more work on client but sounds reasonable as client has to deal with
session close event anyway.
Alternatively, we could add another counter in client code that records how
many times a wrap happen. This effectively make the real xid (xid + INT_MAX *
counter) not repeatable on client side. The counter could be sneaked into the
OpCode field (as we don't use all the bits so far) of the request header so the
times to wrap has a paper trail on server side as well.
> 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: Martin Kuchta
> Attachments: ZOOKEEPER-1485.patch
>
>
> 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)
