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

[Scott Marlow]

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 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
>