[
https://issues.apache.org/jira/browse/ZOOKEEPER-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308091#comment-15308091
]
Martin Kuchta commented on ZOOKEEPER-1485:
------------------------------------------
[~fpj], thanks for providing your thoughts.
To clarify a bit on the issue I had with just expiring the session:
In the C client, the only time the xid variable is initialized is when the
client process starts. Expiring the session would force the client to
reconnect, but I can't see how that would reset the xid since its lifetime is
tied to the process. In the Java client, the xid is a field in ClientCnxn,
which is a final field in the ZooKeeper class. Does session expiration force
you to construct a new ZooKeeper object? My understanding of this is probably
incomplete, but that's the angle I was looking at it from.
That's not to say that expiring the session is wrong if the client sends a
request with an invalid XID, but I still think the client itself needs to
handle overflow in some way.
> 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)
