Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-1278

LockService lock, tryLock methods don't work well with interrupt

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.12
    • 2.12
    • None
    • Hide

      The following code will reproduce the problem. The issue is that if you try to lock something when your thread is already interrupted, then it will return and clear the interrupt status without acquiring the lock.

      JChannel channel = new JChannel(xml);
channel.connect(clusterName);
// Interrupt ourselves before trying to acquire lock
Thread.currentThread().interrupt();

Lock interrupt = lockService.getLock("interrupt-test");
interrupt.lock();
try {
    if (Thread.interrupted()) {
        System.out.println("We still have interrupt flag set, as it should be");
    }
    else {
        System.out.println("Interrupt status was lost - we don't want this!");
    }
    System.out.println("Locks we have: " + lockService.printLocks());
}
finally {
    lock.unlock();
}

      Here is the sample output when I ran this:

      Interrupt status was lost - we don't want this!
      Locks we have: server locks:

      my locks: interrupt-test (wburns-6277::1, unlocked)

      Note the interrupt was lost completely and also the lock is actually unlocked in code where we think it should be locked.

      Show
      The following code will reproduce the problem. The issue is that if you try to lock something when your thread is already interrupted, then it will return and clear the interrupt status without acquiring the lock. JChannel channel = new JChannel(xml); channel.connect(clusterName); // Interrupt ourselves before trying to acquire lock Thread .currentThread().interrupt(); Lock interrupt = lockService.getLock( "interrupt-test" ); interrupt.lock(); try { if ( Thread .interrupted()) { System .out.println( "We still have interrupt flag set, as it should be" ); } else { System .out.println( "Interrupt status was lost - we don't want this !" ); } System .out.println( "Locks we have: " + lockService.printLocks()); } finally { lock.unlock(); } Here is the sample output when I ran this: Interrupt status was lost - we don't want this! Locks we have: server locks: my locks: interrupt-test (wburns-6277::1, unlocked) Note the interrupt was lost completely and also the lock is actually unlocked in code where we think it should be locked.

      I have been trying out the new LockService class, which has been great to use.

      However I began looking into stuff around interrupts, and while glancing at the actual protocol code I became a little confused as to how the lock method would ignore an interrupt and still acquire the lock. So I wrote up a simple test case, which can be found in the Reproduce section.

      Needless to say the lock method behaves completely differently than how I would have expected if an interrupt was encountered. If the interrupt flag is set the lock method would return immediately, making the caller think the lock was retrieved. However the lock was not retrieved! Also not to mention the interrupt status was lost completely, further preventing the interrupt from being checked in a later part of code.

      Also the tryLock() method behaves somewhat in a similar fashion as lock. If the interrupt status is set it will return false immediately and clear the interrupt status. I would expect the code to still retrieve the lock if possible and leave the interrupt flag set afterwards just like I would in the case of lock.

      I did also test the lockInterruptibly, tryLock(long, TimeUnit) and those worked if the interrupt flag was set before invoking it, by throwing an InterruptedException as expected.

      I didn't test any of the methods in regards to an interrupt being done in the middle of waiting to acquire a lock.

        1. Locking.java.patch
          6 kB
          William Burns

              rhn-engineering-bban Bela Ban
              rpwburns William Burns (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: