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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...