[
https://issues.apache.org/jira/browse/ZOOKEEPER-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andre Esteve updated ZOOKEEPER-645:
-----------------------------------
Attachment: ZOOKEEPER-645-compareTo.patch
compareTo.patch aims to correct ordering of ZNodeName objects used to validate
lock ownership.
The code at WriteLock gets a list of znodes and for each znode creates a
ZNodeName object which is added to a sorted list.
The sorting was based on the full znode name, i.e.
x-sessionID-ephemeral_number. As earlier connected clients appear to have lower
sessionID values than those which connected latter, who connects first gets the
lock disregarding anyone who has already the lock.
This patch simply changes compareTo overload at ZNodeName to just consider the
sequence number instead of the full znode name, as this class' objects are used
only for this purpose, this seems to have done the trick =)
However, getSessionID not being thread-safe is still an issue.
Could someone try it out and post the results?
[A discussion about this bug and some other issues on lock recipe, as well as
this patch contributors, can be found here (in Portuguese)
http://www.lsd.ic.unicamp.br/mc715-1s2011/index.php/Grupo01]
> Bug in WriteLock recipe implementation?
> ---------------------------------------
>
> Key: ZOOKEEPER-645
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-645
> Project: ZooKeeper
> Issue Type: Bug
> Components: recipes
> Affects Versions: 3.2.2
> Environment: 3.2.2 java 1.6.0_12
> Reporter: Jaakko Laine
> Assignee: Mahadev konar
> Priority: Minor
> Fix For: 3.4.0
>
> Attachments: 645-fix-findPrefixInChildren.patch,
> ZOOKEEPER-645-compareTo.patch
>
>
> Not sure, but there seem to be two issues in the example WriteLock:
> (1) ZNodeName is sorted according to session ID first, and then according to
> znode sequence number. This might cause starvation as lower session IDs
> always get priority. WriteLock is not thread-safe in the first place, so
> having session ID involved in compare operation does not seem to make sense.
> (2) if findPrefixInChildren finds previous ID, it should add dir in front of
> the ID
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
