Skip to content
This repository

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock! #267

Open
jacum opened this Issue September 07, 2012 · 47 comments
Jacum ICT

Running load tests on our application using Oracle JDK 1.7.0-05 (Linux x86-64) and Hazelcast 2.2 got the following error:

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:717)
at sun.reflect.GeneratedMethodAccessor462.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.hazelcast.impl.MProxyImpl$DynamicInvoker.invoke(MProxyImpl.java:66)
at $Proxy514.unlock(Unknown Source)
at com.hazelcast.impl.MProxyImpl.unlock(MProxyImpl.java:405)
at com.hazelcast.impl.LockProxyImpl$LockProxyBase.unlock(LockProxyImpl.java:202)
at com.hazelcast.impl.LockProxyImpl.unlock(LockProxyImpl.java:116)

Running the same application in production (similar load) using Oracle JDK 1.6.0-29 (Linux x86-64) and Hazelcast 2.2 got no error.

UPDATE: highly concurrent load test does reproduce this issue on JDK 1.6 too.

Found this discussion:
https://groups.google.com/forum/#!msg/hazelcast/euqNF45jL6Q/LZd9m3a_RZ4J

Shall

Jacum ICT

The code calling the lock is located within a JSP

Lock lock = Hazelcast.getLock("some.jsp");
try {
lock.lock();

     // .. 
     // do some rather specific logics, that is important to be handled only one at a time
     // also including database access 

} finally {
lock.unlock();
}

Peter Veentjer
Owner
Jacum ICT
Peter Veentjer
Owner
Peter Veentjer
Owner
Jacum ICT

Thanks for you suggestion, will try that.

Still, doing static code analysis, I'm puzzled: if lock.lock() fails, it must leave some traces.
This is just try { } finally { } construction, if an exception is thrown, it must show up as a stacktrace elsewhere - and it does not. So if lock.lock() does not acquire the said lock, it happens somehow quietly.

Peter Veentjer
Owner
Peter Veentjer
Owner
Jacum ICT

Thank you Peter, I learned something new again. ;)

Unfortunately, moving lock.lock() out of the try {} block didn't help.

We were running test with Hazelcast 2.3, there are far less occurences of the issue, however not zero.

There are still cases like this:

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:731)
at sun.reflect.GeneratedMethodAccessor464.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.hazelcast.impl.MProxyImpl$DynamicInvoker.invoke(MProxyImpl.java:66)
at $Proxy514.unlock(Unknown Source)

while no exception is seen thrown by lock.lock() - obviously, otherwise unlock() won't be reached.

This is a highly concurrent test with ~2000 simulated clients and for ~300000 invocations of the same code only 4 occurences if this issue, so this must be quite elusive race condition.

For the whole test, absolutely no exceptions were seen thrown by lock.lock().

Is there any logging on current state of the distributed locks in Hazelcast that we could switch on?
E.g. which thread is holding that failed lock, exactly?

Mehmet Dogan
Owner

Can you post the code of invocations? Let us see if we can reproduce on our side.

Jacum ICT

The invocation code is like it was written above:

Lock lock = Hazelcast.getLock("some.jsp");
lock.lock();
try {
// ..
// do some rather specific logics, that is important to be handled only one at a time
// also including database access
} finally {
lock.unlock(); // here it throws an exception
}

We have noticed that issue only recently, when we were doing tests with JDK 1.7
We will try once again with JDK 1.6 and Hazelcast 2.3, and let you know if there are any occurences.

Also: it seems like Hazelcast 2.3 has much less of these errors than 2.2.
Though this is not very exact science: so far we did just one run with each.

Jacum ICT

More observations I could add:
1) this is massively parallel test, sometimes with up to 20+ threads competing for the same lock - (observed in cases the IllegalMonitorStateException has been thrown)
2) the test is running on just one node and just one Hazelcast instance, so issues with inter-node communication, network glitches etc. are not applicable heere.

Mehmet Dogan
Owner
Jacum ICT

Yes, this matches our today's observations: we also reproduced the same issue on JDK6.

Thank you for quick reaction.

Jacum ICT

Hi Mehmet, have you got any updates on this?
Any workarounds?

Mehmet Dogan
Owner
Mehmet Dogan mdogan closed this issue from a commit September 11, 2012
Mehmet Dogan Fixes #267.
Fixes #268.
7c4cfb2
Mehmet Dogan mdogan closed this in 7c4cfb2 September 22, 2012
Jacum ICT
Mehmet Dogan
Owner
Jacum ICT

Mehmet, we have repeated the test with Hazelcast bulld made from 2.3.2 master (about a week ago), and there are still occurrences of this:

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:731)
at sun.reflect.GeneratedMethodAccessor621.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.hazelcast.impl.MProxyImpl$DynamicInvoker.invoke(MProxyImpl.java:66)
at $Proxy526.unlock(Unknown Source)
at com.hazelcast.impl.MProxyImpl.unlock(MProxyImpl.java:412)
at com.hazelcast.impl.LockProxyImpl$LockProxyBase.unlock(LockProxyImpl.java:202)
at com.hazelcast.impl.LockProxyImpl.unlock(LockProxyImpl.java:116)

The code using Lock API didn't change since last try, and the stats are much better this time (used to be 4/300000, now the test has been running for about 100 hours and we got just 2 occurrences on ~2,6 million requests) but the problem is still not solved completely.

Mike Jensen

I just reproduced this again with 2.4.1

The code is pretty simple as described above:
jobLock.lock();
try {
// add to a distributed IMap
} finally {
jobLock.unlock();
}

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:731)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at com.hazelcast.impl.MProxyImpl$DynamicInvoker.invoke(MProxyImpl.java:66)
at $Proxy0.unlock(Unknown Source)
at com.hazelcast.impl.MProxyImpl.unlock(MProxyImpl.java:412)
at com.hazelcast.impl.LockProxyImpl$LockProxyBase.unlock(LockProxyImpl.java:202)
at com.hazelcast.impl.LockProxyImpl.unlock(LockProxyImpl.java:116)

This was on open JDK 1.6...Let me know if I can provide any more details

miky.zf

the same Problem

code like this

    public void run() { 

        for (;;) {

            try {
                RedisBean bean = redisQueue.take();
                final String url = bean.getCQ_SOURCE_URL();
                final String key = MD5.getMD5(url);

                MyHazelcast.defaultMap.tryLock(key);

                    if(!MyHazelcast.defaultMap.containsKey(key)){
                        MyHazelcast.defaultMap.put(key, 0);

                              ...................
                        // 存储日志
                        ApperLog.recordLog(bean);
                    }
                MyHazelcast.defaultMap.unlock(key);

                //System.out.println(bean.getCQ_SOURCE_URL());
            }catch (Exception e) {
                log.error(e.getMessage(),e);
            }
        }

    }

basic in jdk 1.7 ,and the hazelcast version is 2.5

java.lang.RuntimeException: Current thread is not owner of the lock!
at com.hazelcast.impl.ClientServiceException.readData(ClientServiceException.java:63)
at com.hazelcast.nio.Serializer$DataSerializer.read(Serializer.java:104)
at com.hazelcast.nio.Serializer$DataSerializer.read(Serializer.java:79)
at com.hazelcast.nio.AbstractSerializer.toObject(AbstractSerializer.java:121)
at com.hazelcast.nio.AbstractSerializer.toObject(AbstractSerializer.java:156)
at com.hazelcast.client.ClientThreadContext.toObject(ClientThreadContext.java:72)
at com.hazelcast.client.IOUtil.toObject(IOUtil.java:34)
at com.hazelcast.client.ProxyHelper.getValue(ProxyHelper.java:186)
at com.hazelcast.client.ProxyHelper.doOp(ProxyHelper.java:146)
at com.hazelcast.client.ProxyHelper.doOp(ProxyHelper.java:140)
at com.hazelcast.client.MapClientProxy.unlock(MapClientProxy.java:193)
at com.loongtao.secrawler.MyRunnable$SaveOf.run(MyRunnable.java:60)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

ib84
ib84 commented April 12, 2013

I agree with fridgebuzz, this issue is not fixed as of version 2.5 and should be reopened

Enes Akar enesakar reopened this April 12, 2013
Yoram Kulbak
ykulbak commented May 12, 2013

Does this issue mean that locks are broken and should not be used?
Thanks,
yoram

Mike Jensen
jentfoo commented May 13, 2013

ykulbak, No, it does not mean that at all. Locking is absolutely necessary to accomplish some things. This exception that gets thrown is invalid, but locking from a cluster perspective still works correctly as far as I can tell. I tried to see if I could find the issue in code, but the problem is definitely not obvious.

So what I did is I built a wrapper around the hazelcast lock that addresses this issue. The wrapper tracks locking from a local perspective, and if this exception is thrown at a point where the local locking looks correct, the wrapper just swallows the exception. It's a complete hack to work around this problem, but it does work, and it does prevent my other code from having to deal with these exceptions when they are thrown incorrectly.

drithdx
drithdx commented May 30, 2013

As I really depend on distributed locks here is a very simple way to reproduce the issue.
My specs:
Debian Wheezy 2.6.32-5-amd64
JDK 1.6.0_32
Hazelcast 2.5

The steps to reproduce:
1)Run two instances of server.sh to form a cluster.
2)Run this simple code and press enter a few times if you like but should block before unlock method.
3)Hit Ctrl+C on one of the nodes consoles.
4)Hit enter and there you go:java.lang.RuntimeException: Current thread is not owner of the lock!
WARNING: [192.168.100.90]:5702 [dev] exception during handling LOCK_UNLOCK: Current thread is not owner of the lock!
java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:731)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

The code to reproduce it:

public static void main(String[] args) {
ClientConfig clientConfig = new ClientConfig();
clientConfig.addAddress("Your IP here:5701");

HazelcastInstance client = HazelcastClient.newHazelcastClient(clientConfig);

final ILock lock = client.getLock("lock");

Scanner s = new Scanner(System.in);

while (true) {

    lock.lock();

    try {
    System.out.println("Locked now:");
    s.nextLine();
    } catch (Exception e) {

    } finally {
    try {
        lock.unlock();
    } catch (Exception e) {
        e.printStackTrace();
    }
    }

}

}
Mike Jensen
jentfoo commented May 31, 2013

Since this issue has continued to have responses from other people, I thought I would share a simplified version of what I did to work around this problem. Keep in mind that I reduced a lot of code and verification that needs to happen for my specific application, but in the general sense this wrapper has fully worked around this problem. But it is also a complete hack until this issue is solved.

The short version of what it does is attempt to track the lock ownership on a local level. If the exception is thrown but lock ownership from the local level appears correct, it just swallows the exception.

Hopefully this will help others:
https://gist.github.com/jentfoo/5687563

Feel free to send questions or problems my way.

Mehmet Dogan
Owner
mdogan commented June 03, 2013

@drithdx Thanks for the report. Issue, you've found involves Hazelcast client. Yes, this is also a bug but it's different than the original report, it's directly related to the client.
I've created a new issue for this bug -> #493

Is there anybody who can reproduce "java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!" without using client?

Mike Jensen

@mdogan I am definetly able to reproduce this without using the client (as can be seen from my stack trace above). Since my original post to this issue we have upgraded to 2.5, but still continue to see this lock issue. Which is why I had built the hack posed above. The hack for us has solved the issue, but it is only a hack.

I feel (not certain) that this issue is more reporduacable as nodes join and leave the cluster. We encountered this a lot during failover testing.

Charles Maheu

I ran into this stacktrace

calling forceUnlock instead of Unlock seem to get rid of the problem, but i'm not sure of differences between unlock and forceUnlock...

Mike Jensen

@chocmah that is because forceUnlock does not do that safety check. So if you were in fact using the lock incorrectly, you would never know it, and you may be unlocking a remote node that currently is holding the lock.

Mehmet Dogan
Owner
mdogan commented June 11, 2013
Peter Veentjer
Owner

This reproduces the issue:

package com.hazelcast;

import com.hazelcast.client.ClientConfig;
import com.hazelcast.client.HazelcastClient;
import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import com.hazelcast.core.ILock;

public class Test {
public static void main(String[] args) throws Exception {
HazelcastInstance hz1 = Hazelcast.newHazelcastInstance();
HazelcastInstance hz2 = Hazelcast.newHazelcastInstance();

    ClientConfig clientConfig = new ClientConfig();

    HazelcastInstance client = HazelcastClient.newHazelcastClient(clientConfig);
    final ILock lock = client.getLock("lock");
    //Scanner s = new Scanner(System.in);

    for (int k = 0; k < 100; k++) {
        lock.lock();
        try {
            Thread.sleep(100);
        } finally {
            lock.unlock();
        }
    }

    lock.lock();
    hz1.getLifecycleService().shutdown();
    lock.unlock();

}

}

Perhaps you need to run it a few times, but with me it failed on the first time with:

java.lang.IllegalMonitorStateException: Current thread is not owner of the lock!
at com.hazelcast.impl.MProxyImpl$MProxyReal.unlock(MProxyImpl.java:733)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.hazelcast.impl.MProxyImpl$DynamicInvoker.invoke(MProxyImpl.java:66)
at $Proxy0.unlock(Unknown Source)
at com.hazelcast.impl.MProxyImpl.unlock(MProxyImpl.java:412)
at com.hazelcast.impl.LockProxyImpl$LockProxyBase.unlock(LockProxyImpl.java:202)
at com.hazelcast.impl.LockProxyImpl.unlock(LockProxyImpl.java:116)
at com.hazelcast.impl.ClientHandlerService$UnlockOperationHandler.processCall(ClientHandlerService.java:1313)
at com.hazelcast.impl.ClientHandlerService$ClientOperationHandler.handle(ClientHandlerService.java:1574)
at com.hazelcast.impl.ClientRequestHandler$1.run(ClientRequestHandler.java:57)
at com.hazelcast.impl.ClientRequestHandler$1.run(ClientRequestHandler.java:54)
at com.hazelcast.impl.ClientRequestHandler.doRun(ClientRequestHandler.java:63)
at com.hazelcast.impl.FallThroughRunnable.run(FallThroughRunnable.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
at com.hazelcast.impl.ExecutorThreadFactory$1.run(ExecutorThreadFactory.java:45)

Exception in thread "main" java.lang.RuntimeException: Current thread is not owner of the lock!
at com.hazelcast.impl.ClientServiceException.readData(ClientServiceException.java:63)
at com.hazelcast.nio.Serializer$DataSerializer.read(Serializer.java:108)
at com.hazelcast.nio.Serializer$DataSerializer.read(Serializer.java:83)
at com.hazelcast.nio.AbstractSerializer.toObject(AbstractSerializer.java:121)
at com.hazelcast.nio.AbstractSerializer.toObject(AbstractSerializer.java:156)
at com.hazelcast.client.ClientThreadContext.toObject(ClientThreadContext.java:72)
at com.hazelcast.client.IOUtil.toObject(IOUtil.java:34)
at com.hazelcast.client.ProxyHelper.getValue(ProxyHelper.java:186)
at com.hazelcast.client.ProxyHelper.doOp(ProxyHelper.java:146)
at com.hazelcast.client.ProxyHelper.doOp(ProxyHelper.java:140)
at com.hazelcast.client.LockClientProxy.unlock(LockClientProxy.java:68)
at com.hazelcast.Test.main(Test.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Jul 06, 2013 4:46:18 PM com.hazelcast.impl.PartitionManager
INFO: [192.168.1.104]:5702 [dev] Total 0 partition replica diffs have been processed.
Jul 06, 2013 4:46:18 PM com.hazelcast.impl.PartitionManager
INFO: [192.168.1.104]:5702 [dev] Re-partitioning cluster data... Immediate-Tasks: 0, Scheduled-Tasks: 0

This is with the newest 2.6 branch.

Peter Veentjer
Owner

The cause is that the lock isn't locked at the moment unlock is called:

lock.lock();
hz1.getLifecycleService().shutdown();
lock.unlock(); <<--- the lock isn't locked here anymore.
Mehmet Dogan
Owner
mdogan commented July 08, 2013

@pveentjer, I guess (and as others pointed out) original issue is not related to client. So, I created another issue for that client case; #493.

Ali gurbuzali referenced this issue from a commit July 08, 2013
Ali Client Issue Test #267 e3f8904
efic1

I'm having the same issue with hazelcast 2.6 when calling the unlock method

Alex Oleynik

Also reproduced this issue with single node ver. 2.6.5

Thomas

hi,

Maybe a workaround on that is the following:

boolean locked = false;
try{
  locked = lock.trylock();
  if(locked){
     // do something
  }
} finally {
 if(locked){
  lock.unlock
 }
}
Devin Smith

I'm having the same issue with a 1 producer, n consumers setup... it triggers pretty fast. I am not using the client. Hazelcast 3.2. I am specifically using a Condition on the lock.

Consumer is basically:

    lock.lock();
    try {
        // maybe do work here
        condition.await(timeout, unit);
        // maybe do work here
    } finally {
        lock.unlock();
    }

This is a big bummer... this is only my first day using Hazelcast!

Exception in thread "Consumer-0" java.lang.IllegalMonitorStateException: Current thread is not owner of the lock! -> Owner: null, thread-id: 0
at com.hazelcast.concurrent.lock.operations.UnlockOperation.ensureUnlocked(UnlockOperation.java:70)
at com.hazelcast.concurrent.lock.operations.UnlockOperation.unlock(UnlockOperation.java:64)
at com.hazelcast.concurrent.lock.operations.UnlockOperation.run(UnlockOperation.java:56)
at com.hazelcast.spi.impl.BasicOperationService.processOperation(BasicOperationService.java:363)
at com.hazelcast.spi.impl.BasicOperationService.processPacket(BasicOperationService.java:309)
at com.hazelcast.spi.impl.BasicOperationService.access$400(BasicOperationService.java:102)
at com.hazelcast.spi.impl.BasicOperationService$BasicOperationProcessorImpl.process(BasicOperationService.java:756)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.process(BasicOperationScheduler.java:276)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.doRun(BasicOperationScheduler.java:270)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.run(BasicOperationScheduler.java:245)
at ------ End remote and begin local stack-trace ------.(Unknown Source)
at com.hazelcast.spi.impl.BasicInvocation$InvocationFuture.resolveResponse(BasicInvocation.java:836)
at com.hazelcast.spi.impl.BasicInvocation$InvocationFuture.resolveResponseOrThrowException(BasicInvocation.java:769)
at com.hazelcast.spi.impl.BasicInvocation$InvocationFuture.get(BasicInvocation.java:696)
at com.hazelcast.spi.impl.BasicInvocation$InvocationFuture.get(BasicInvocation.java:674)
at com.hazelcast.spi.impl.BasicInvocation$InvocationFuture.getSafely(BasicInvocation.java:687)
at com.hazelcast.concurrent.lock.LockProxySupport.unlock(LockProxySupport.java:113)
at com.hazelcast.concurrent.lock.LockProxy.unlock(LockProxy.java:97)

Devin Smith

Also, this:

Apr 10, 2014 1:49:05 PM com.hazelcast.concurrent.lock.operations.AwaitOperation
SEVERE: [10.200.2.113]:5701 [dev] [3.2] null
java.lang.IllegalStateException
at com.hazelcast.concurrent.lock.ConditionInfo.startWaiter(ConditionInfo.java:61)
at com.hazelcast.concurrent.lock.LockResourceImpl.startAwaiting(LockResourceImpl.java:180)
at com.hazelcast.concurrent.lock.LockStoreImpl.startAwaiting(LockStoreImpl.java:233)
at com.hazelcast.concurrent.lock.operations.AwaitOperation.beforeRun(AwaitOperation.java:50)
at com.hazelcast.spi.impl.BasicOperationService.processOperation(BasicOperationService.java:355)
at com.hazelcast.spi.impl.BasicOperationService.runOperation(BasicOperationService.java:228)
at com.hazelcast.concurrent.lock.operations.UnlockOperation.afterRun(UnlockOperation.java:85)
at com.hazelcast.spi.impl.BasicOperationService.processOperation(BasicOperationService.java:389)
at com.hazelcast.spi.impl.BasicOperationService.access$300(BasicOperationService.java:102)
at com.hazelcast.spi.impl.BasicOperationService$BasicOperationProcessorImpl.process(BasicOperationService.java:754)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.process(BasicOperationScheduler.java:276)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.doRun(BasicOperationScheduler.java:270)
at com.hazelcast.spi.impl.BasicOperationScheduler$PartitionThread.run(BasicOperationScheduler.java:245)

Peter Veentjer
Owner
Devin Smith

Ok, I've got a simple example that reproduces the problem:

https://github.com/devinrsmith/hazelcast_test

I know it's might be a little stupid to wrap up a hazelcast queue in a hazelcast lock, but it turns out it also exhibits the problem without the hazelcast queue (if you keep everything in process and pass in a singleton linked list).

It might take a few restarts. Only 1 process necessary.

Devin Smith

@pveentjer , have you been able to reproduce the issue?

Devin Smith

I've created a much more concise test that seems to trigger almost immediately every time:

https://github.com/devinrsmith/hazelcast_test/blob/master/src/main/java/org/devin/hazelcast/issue/SpamLockCondition.java

Devin Smith

For note: the SpamLockCondition test seems to be stable with 2 threads, but crashes with 3 or more threads.

Peter Veentjer
Owner
Christoph Engelbert
Collaborator

@pveentjer As far as I understood him on Skype he found the problem for the condition problem and prepares a PR for it. Maybe (hopefully) it is connected to your problem :)

patriziomunzi

We're having a related issue in a cluster failover test with HZ-2.6.8.
We're running a HZ cluster of 2 nodes.
Looks like if a key is locked from one of the two nodes and the same node is shut down before the unlock, the key remains locked forever.
It's like as the ownership of the lock doesn't get migrated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.