tag:blogger.com,1999:blog-19835054.post8079579309142659969..comments2024-03-16T13:42:14.318+01:00Comments on Belas Blog: New distributed locking service in JGroupsBela Banhttp://www.blogger.com/profile/01830789377474906550noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-19835054.post-89999180765312069462012-09-27T13:29:48.092+02:002012-09-27T13:29:48.092+02:00Take udp.xml or tcp.xml (shipped with JGroups) and...Take udp.xml or tcp.xml (shipped with JGroups) and add CENTRAL_LOCK to the top, e.g.<br /><br />.....<br /><FRAG2 frag_size="60K" /><br /><RSVP resend_interval="2000" timeout="10000"/><br /><pbcast.STATE_TRANSFER /><br /><CENTRAL_LOCK />Bela Banhttps://www.blogger.com/profile/01830789377474906550noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-23506622379940891872012-09-27T08:40:32.720+02:002012-09-27T08:40:32.720+02:00Can you share the lock.xml you have used in the ab...Can you share the lock.xml you have used in the above code?? Also, should this lock.xml file be a separate file from other conf xmls or it can be part of a existing xml file??Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19835054.post-38314652751461327672011-05-19T08:22:55.575+02:002011-05-19T08:22:55.575+02:00The locks held by the crashed member are removed a...The locks held by the crashed member are removed and can be acquired by other members.Bela Banhttps://www.blogger.com/profile/01830789377474906550noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-11552372595835216442011-05-18T07:16:58.477+02:002011-05-18T07:16:58.477+02:00What happens to a the lock if a node holding the l...What happens to a the lock if a node holding the lock crashes?<br /><br />It is not clear from the docs what happens to the lock.<br /><br />Thanks.matt giacominihttp://www.gltech.comnoreply@blogger.comtag:blogger.com,1999:blog-19835054.post-56363588759403102482011-01-22T03:58:10.873+01:002011-01-22T03:58:10.873+01:00Wow, thanks for finding this, William !
I saw tha...Wow, thanks for finding this, William !<br /><br />I saw that you opened a JIRA issue, this will get fixed asap.<br /><br />Another reiteration of the value of *open* source !<br /><br />Cheers,Bela Banhttps://www.blogger.com/profile/01830789377474906550noreply@blogger.comtag:blogger.com,1999:blog-19835054.post-3273268697153550482011-01-21T19:37:21.070+01:002011-01-21T19:37:21.070+01:00There appears to be a minor bug in the ClientLock ...There appears to be a minor bug in the ClientLock inner class of Locking.<br /><br />public boolean tryLock(long time, TimeUnit unit) throws InterruptedException {<br /> return acquireTryLock(unit.convert(time, TimeUnit.MILLISECONDS), true);<br />}<br /><br />The TimeUnit.MILLISECONDS and unit need to be switched around. Else it will attempt to convert the time value as MILLISECONDS to what you pass in. So in my case I tried 5 SECONDS and it converted 5 MILLISECONDS to 0 SECONDS instead of the inverse. This then cause it to immediately fail on the attempt to lock.<br /><br />Obviously an easy workaround is to always pass the values as MILLISECONDS.<br /><br />I also looked through rest of jgroups code very quickly and found that the same issue appears to be in HashedTimingWheel.schedule and TimeScheduler2.schedule methods.William Burnsnoreply@blogger.com