Going back to your original question Galder, the exception is most
likely thrown because of this sequence of events:
0. Given a cluster {A, B}, a key k and a node C joining.
1. Put acquires the "transaction lock" on node A (blocking rehashing)
2. Put acquires lock for key k on node A
3. Rehashing starts on node B, blocking transactions
4. Put tries to acquire transaction lock on node B
Since it's impossible to finish rehashing while the put operation
keeps the transaction lock on node A, the best option was to kill the
put operation by throwing a RehashInProgressException.
I was thinking in the context of transactions when I wrote this code
(see
https://github.com/danberindei/infinispan/commit/6ed94d3b2e184d4a48d4e781db8d404baf5915a3,
this scenario became just a footnote to the generic case with multiple
caches), but the scenario also occurs without transactions. Actually I
renamed it "state transfer lock" and I moved it to a separate
interceptor in my ISPN-1194 branch.
Maybe the locking changes in 5.1 will eliminate this scenario, but
otherwise we could improve the user experience by retrying the command
after the rehashing finishes.
Dan
On Tue, Sep 13, 2011 at 8:11 PM, Galder Zamarreño <gal...@redhat.com> wrote:
>
> On Sep 13, 2011, at 6:38 PM, Mircea Markus wrote:
>
>>
>> On 13 Sep 2011, at 17:22, Galder Zamarreño wrote:
>>
>>> Hi,
>>>
>>> I'm looking at this failure http://goo.gl/NQw4h and I'm wondering why
>>> "org.infinispan.distribution.RehashInProgressException: Timed out waiting
>>> for the transaction lock" is thrown?
>>>
>>> This is thrown DistTxInterceptor which is added by the
>>> InterceptorChainFactory:
>>>
>>> if (configuration.getCacheMode().isDistributed())
>>>
>>> interceptorChain.appendInterceptor(createInterceptor(DistTxInterceptor.class));
>>> else
>>>
>>> interceptorChain.appendInterceptor(createInterceptor(TxInterceptor.class));
>>>
>>> However, this is a Hot Rod test and the cache is not configured with a
>>> transaction manager, so is DistTxInterceptor really needed?
>>>
>>> In fact, why a TxInterceptor if no transaction manager is configured? (this
>>> kinda goes back to Mircea's email earlier today about a transactions
>>> enabled/disabled flag)
>> All valid concerns, IMO.
>> 5.1 will clarify this by not adding Tx interceptors for non tx caches.
>
> Is this captured in some other JIRA? I'd like to reference the test and the
> JIRA from ISPN-1123 (stabilising testsuite jira)
>
>>
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
