geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan José Ramos Cassella (JIRA) <>
Subject [jira] [Created] (GEODE-7062) CI Failure: DistributedLockServiceDUnitTest.testSuspendLockingBlocksUntilNoLocks
Date Thu, 08 Aug 2019 15:07:00 GMT
Juan José Ramos Cassella created GEODE-7062:

             Summary: CI Failure: DistributedLockServiceDUnitTest.testSuspendLockingBlocksUntilNoLocks
                 Key: GEODE-7062
             Project: Geode
          Issue Type: Bug
          Components: tests
            Reporter: Juan José Ramos Cassella

The test {{testSuspendLockingBlocksUntilNoLocks}} from class {{DistributedLockServiceDUnitTest}}
failed twice in CI runs [967|]
and [969|].
Results for the first failure are available [here|]
and for the second one [here|].
Archived artifacts for the first failure are available [here|]
and for the second one [here|].

The issue appears to be a race condition while firing an asynchronous thread on a remote {{VM}}
through the following code:
    VM vm1 = getVM(1);
    vm1.invokeAsync(new SerializableRunnable("Lock & unlock in vm1") {
      public void run() {
        DistributedLockService service2 = getServiceNamed(name);
        assertThat(service2.lock("lock", -1, -1)).isTrue();
        synchronized (monitor) {
          try {
          } catch (InterruptedException ex) {
            out.println("Unexpected InterruptedException");
    // Let vm1's thread get the lock and go into wait()

If the thread is not launched on the remote {{VM}} after sleeping for 100 milliseconds, the
test will fail as the thread on the local {{VM}} will be able to invoke {{suspendLocking}}
right away:
    Thread thread = new Thread(new Runnable() {
      public void run() {

    // Let thread start, make sure it's blocked in suspendLocking
    assertThat(getGot() || getDone())
        .withFailMessage("Before release, got: " + getGot() + ", done: " + getDone()).isFalse();

Increasing the sleep time might help to reduce possible re occurrences of the issue, another
option would be to investigate how to make the test wait *unti* the asynchronous invocation
has been started on the remote {{VM}} instead of arbitrarily sleeping 100 milliseconds.

This message was sent by Atlassian JIRA

View raw message