Usage of TimeUnit class is inverted, causing incorrect conversions between time units ------------------------------------------------------------------------------------- Key: JGRP-1277 URL: https://issues.jboss.org/browse/JGRP-1277 Project: JGroups Issue Type: Bug Affects Versions: 2.12 Reporter: William Burns Assignee: Bela Ban Priority: Minor I have tried posting something to the blog at http://belaban.blogspot.com/2011/01/new-distributed-locking-service-in.html but it hasn't put up my comment yet, so I decided to create a JIRA as well. I have taken the latest 2.12 build of Beta1 which includes the new LockService class. This class is so much of an improvement how the DistributedLockManager was; great work! But anyways I found that when you try to acquire a lock with a wait, it is not converting the timeunits correctly unless it is in MILLISECONDS. This cannot be reproduced with the demo class since it always uses MILLISECONDS. The code in question is found on the Locking$ClientLock inner class. {code} public boolean tryLock(long time, TimeUnit unit) throws InterruptedException { return acquireTryLock(unit.convert(time, TimeUnit.MILLISECONDS), true); } {code} The way this is, the code will convert the time value passed in as MILLISECONDS to the passed in TimeUnit. This simply needs to change to make the TimeUnit.MILLISECONDS the object of which the convert method is being called on and having unit as the second argument. {code} public boolean tryLock(long time, TimeUnit unit) throws InterruptedException { return acquireTryLock(TimeUnit.MILLISECONDS.convert(time, unit), true); } {code} This obviously has a simple workaround of _always_ passing in a TimeUnit of MILLISECONDS and having the time value already adjusted. And again this new feature looks to be very promising. Also when just checking the jgroups code base there are 3 other references to convert, 2 of which are also broken in this fashion. {quote} HashedTimingWheel.schedule TimeScheduler2.schedule {quote} Both of these references in the jgroup code base are always passed MILLISECONDS, so it would only be seen if client code were to interact with them somehow. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira