[infinispan-dev] possible bug in TreeCache.put(Fqn fqn, Map<? extends K, ? extends V> data) when passed an empty map

Galder Zamarreño galder at redhat.com
Tue Sep 14 06:08:06 EDT 2010


On Sep 13, 2010, at 7:07 PM, Manik Surtani wrote:

> 
> On 10 Sep 2010, at 15:10, Scott Marlow wrote:
> 
>> Great, thanks for the response Mircea!
>> 
>> That leaves the concurrency concern raised by Galder (also on IRC). The
>> concern of locking TreeCache parents and children.  
>> 
>> I don't think we need or want more than weak consistency for our
>> clustered JNDI implementation.  
> 
> Are you referring to not locking a node when adding or removing a child node?

This comes from a conversation we had online where I was checking whether there was a real need for TreeCache in this use case.

IIRC, parents used to be locked for writing when adding/removing children. Looking at the Infinispan code, this might not be the case any more:

            // don't lock parents for child insert/removes!
            icc.getInvocationContext().setFlags(Flag.SKIP_LOCKING);
            parentStructure.put(fqn.getLastElement(), fqn);

I see we don't have anything in http://community.jboss.org/wiki/Infinispan wrt the tree module. I think it'd be interesting to explain what the lock semantics are in the tree module and how different these are with JBoss Cache. Thoughts?

> 
>> 
>> Are there any API or configuration tweaks that I should try to reduce
>> the locking with TreeCache?  The current configuration is under
>> ha-partition here http://pastebin.com/uum95GTG
>> 
>> What do you think?
>> 
>> On Fri, 2010-09-10 at 14:38 +0100, Mircea Markus wrote:
>>> You should be able to do that; i.e. pass a empty map to the TreeCache. I thought the call was caused by like put(k, null).
>>> On 10 Sep 2010, at 14:19, Scott Marlow wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I am porting some legacy JBC code (JBoss AS ha-jndi) to Infinispan
>>>> (http://anonsvn.jboss.org/repos/jbossas/projects/cluster/ha-server-cache-ispn/trunk/src/main/java/org/jboss/ha/jndi/ispn/DistributedTreeManager.java) and ran into a problem that Mircea created ISPN-639 for.  
>>>> 
>>>> In discussing ISPN-639 on IRC, Mircea said in reference to ISPN-639 "the
>>>> condition only happen in very special situations when a put is not
>>>> valid. Are you adding e.g. a null key or a null value in this
>>>> operation?"
>>>> 
>>>> Could someone clarify whether it is legal to pass an empty map to
>>>> TreeCache.put(Fqn, Map).
>>>> 
>>>> I am currently calling TreeCache.put as follows (in
>>>> DistributedTreeManager.createSubcontext(Name name)):
>>>> 
>>>> this.cache.put(newf, new HashMap<String, Binding>());
>>>> 
>>>> newf is a Fqn (I believe it is a valid one).  However, I'm now worried
>>>> about passing the empty HashMap as that is probably triggering ISPN-639.
>>>> 
>>>> Thanks,
>>>> Scott
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list