Deadlock while acquiring and releasing lock in HazelcastClusterManager in vertx 3.3.2

[pkadam1989]

public class Test {

public static void main (String[] args)  {
        Vertx.clusteredVertx(new VertxOptions(), result -> testFunction(result.result()));
}

private static void testFunction(Vertx vertx) {
    Context context = vertx.getOrCreateContext();
    context.runOnContext(v -> testFunctionOnContext(vertx,"r1"));
    context.runOnContext(v -> testFunctionOnContext(vertx,"r2"));
    context.runOnContext(v -> vertx.setTimer(20000L, event -> context.runOnContext(v1 -> testFunctionOnContext(vertx,"r3"))));
}


private static void testFunctionOnContext(Vertx vertx, String req) {
    System.out.println("************ TRY TO GET LOCK "+req +" ************");
    vertx.sharedData().getLockWithTimeout("abc",15000L, lockResult -> {
            if (lockResult.succeeded()) {
                    System.out.println("************ "+req +" GOT LOCK ************");
                    vertx.setTimer(10000L, event -> {
                        System.out.println("************ "+req +" TRYING TO RELEASE LOCK ************");
                        lockResult.result().release();
                    });
            }
            else{
                lockResult.cause().printStackTrace();
            }
        });
}

}

Using vertx 3.3.2

In the above case getLockWithTimeout and release call on lock both are using executeBlocking with ordering = true by default.
We are running on a single context.

So,
When r1 tries to get lock, it will get the lock for abc and will start doing its work, assume it does some work which takes 10 secs.

When r2 tries to get lock, simultaneously before, r1 finishes its work, r2 will not get a lock and will be waiting 15 secs for r1 to release the lock.

But r1 is waiting for r2 to get lock since it is executeBlocking with ordering true.

So r2 will never get the lock, and fail with timeout exception even though r1 had finished the work in 10 secs. After r2 fails with timeout exception r1 will release the lock, since it was waiting for r2 executeBlocking to get over.

This will work if we have ordering false in executeBlocking. Why is the ordering true by default, which makes it sequential execution of executeBlocking ?
In that case, I will not be able to use lock on single context, when there are multiple requests coming for the same resource.

[pkadam1989]

This issue was not seen in Vertx version 3.2.1

[vietj]

note of what using executeBlocking=false might improve : #43