[
https://issues.apache.org/jira/browse/ZOOKEEPER-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328384#comment-15328384
]
Michael Han commented on ZOOKEEPER-1485:
----------------------------------------
Should we add a test case about this if there is no existing tests? We could
add a "test only" method like set_xid if it is hard to simulate the overflow
condition in a test.
I am also wondering what is the performance implication by changing get_xid
from using a compiler intrinsic / atomic operation to use explicit locks. I
think it is possible to implement the same 'wrap if overflow' operation using
CAS. Generally lock free atomic operation provides better performance comparing
to locks, but it of course depends on the use cases such as the level of
contention / number of threads, so without benchmark in a specific context it
might hard to tell. Not saying we should over optimize, just want to bring this
up see if this is a real concern or not.
> 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)
