jsr-333
  1. jsr-333
  2. JSR_333-74

Potential deadlock in ObservationManager.removeEventListener()

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: api
    • Labels:
      None

      Description

      As discussed in https://issues.apache.org/jira/browse/OAK-1290, the ObservationManager.removeEventListener() method can lead to a deadlock because it "will block until the listener has completed executing." The deadlock occurs if the thread that calls this method holds a lock that the event listener is trying to acquire. The relevant javadoc paragraph is:

      A listener may be deregistered while it is being executed. The deregistration method will block until the listener has completed executing. An exception to this rule is a listener which deregisters itself from within the onEvent method. In this case, the deregistration method returns immediately, but deregistration will effectively be delayed until the listener completes.

      I see two ways to avoid this deadlock scenario:

      1. Keep the behavior as-is, but add documentation that informs clients about this problem: "... To avoid potential deadlocks, the caller of this method should not hold any locks that the event listener might try to acquire."
      2. Change the contract so that the method should not block indefinitely: "A listener may be deregistered while it is being executed. No more events will be delivered to the listener once this method has returned. An implementation should not block until the listener has completed executing. An exception to this rule is a listener which deregisters itself from within the onEvent method. In this case, the deregistration method returns immediately, but deregistration will effectively be delayed until the listener completes. To avoid potential deadlocks with implementations that might block, the caller of this method should not hold any locks that the event listener might try to acquire."

      The first is fully backwards compatible, the second safer. I'm not sure if there are any clients out there that rely on the specified blocking behavior.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            jukka.zitting
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: