[infinispan-dev] JMX and allowDuplicateDomains - should this be true by default?

[Galder Zamarreno]

On 11/12/2009 05:04 PM, Mircea Markus wrote:
> On Nov 12, 2009, at 3:08 PM, Manik Surtani wrote:
>
>> Any thoughts?  It would certainly help some occasional UT failures!
>> But UTs shouldn't be a reason to set a default
> this could be mitigated, as long as all the CacheManagers are being
> constructed using TestCacheManagerFactory (I think high majority of
> them do).
>> - I just wonder what's wrong with making this a default,
> the basic idea behind this was to allow it, but force the user to
> acknowledge that the domain is already taken, and be aware about the
> incrementing counter.

Yeah. I don't think I'd enable it by default, otherwise duplicate domain 
errors might be missed and having to enable it manually forces the 
client to at least thing of the consequences and understand the change 
in mbean names.

To get to the bottom of such UT failures, we could use an strategy like 
this during unit testing. When a jmx domain is created, store a 
stacktrace up to that point somewhere (maybe a ThreadLocal?) and when 
the jmx domain is cleared at stoppage time, clear it.

Then, if a duplicate is found when duplicates were not expected, throw 
this stacktrace indicating that someone created a jmx domain at that 
point but it does not appear to have been closed.

This is similar to what AS uses to see if any connections were left 
open. Obviously, this setting would only be enabled during unit tests.

Also, not to pollute production code, this could maybe be implemented 
with Byteman or similar so that we only keep this stuff separate and 
only enable it during UTs. THoughts?

I'm happy to look at this at some point.

>> since we do have an incrementing counter prepended to the domain
>> anyway?
>>
>> Cheers
>> --
>> 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
>
> _______________________________________________
> 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