Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2.1.GA
    • Fix Version/s: None
    • Component/s: Locking
    • Labels:
      None

      Description

      User reports getting timeout exceptions w/ 0 ms timeouts despite configuring JBC for longer timeouts. See forum thread for specific details. Key bit is here:

      > The 0 ms is coming from MVCCLockInterceptor:
      >
      > Code:
      >
      > @Override
      > public Object handleInvalidateCommand(InvocationContext ctx, InvalidateCommand command) throws Throwable
      >

      { > // this should be handled the same as a recursive evict command. > ctx.getOptionOverrides().setLockAcquisitionTimeout(0); > if (!command.getFqn().isRoot()) helper.wrapNodesRecursivelyForRemoval(ctx, command.getFqn()); > return invokeNextInterceptor(ctx, command); > }


      >
      >
      >
      > I personally don't understand the reasoning behind that; the semantics of an invalidation are not the same as an evict, since an invalidation is concerned with data correctness while an evict is concerned with the > lesser issue of managing memory.
      >
      > Perhaps some of the folks who wrote this piece can comment?
      >
      > This exception is thrown when a lock is attempted on a remote node. One thing I can think of is that with INVALIDATION_SYNC there is no point waiting more than 0 ms to acquire the lock since whatever is holding > the lock on this node is before releasing it also going to send an invalidation message. Which won't succeed because whatever sent this message will be holding a lock. So might as well fail promptly.
      >
      > The above logic doesn't hold true with INVALIDATION_ASYNC though.

      Galder and I just had a further discussion:

      Brian: ok, so i think the logical flaw is just that 0 ms isn't correct for ASYNC
      Galder: hmmm
      Galder: why?
      Galder: oh, because they could cross earch other?
      Brian: well, first off, w/ ASYNC the TimeoutException won't propagate back to the sender, so only issue is what's the best state for the caches to end up in
      Brian: so, yeah, they'll cross each other and both will invalidate
      Brian: result is both caches are invalidated
      Galder: but that's fine
      Galder: they'll go back to db and get stuff from there
      Brian: yep
      Brian: w/ 0 ms timeout, whatever was holding the lock will succeed
      Brian: because the invalidation msg from the other node will not succeed
      Brian: so on one node you have potentially inconsistent data left in the cache
      Galder: oh yeah, the remaining node has stale data
      Galder: but u have the same problem with sync
      Brian: w/ sync the TimeoutException propagates, allowing the caller to deal with it
      Galder: yeah, the failure is at least known
      Galder: the 2nd node could still succeed but you know the 1st did not
      Galder: whereas with async, you don't know which one won
      Brian: right

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                manik Manik Surtani
                Reporter:
                brian.stansberry Brian Stansberry
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: