The 0 ms is coming from MVCCLockInterceptor:
| @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.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267549#4267549
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267549
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
