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

[Manik Surtani]

On 12 Nov 2009, at 17:54, Galder Zamarreno wrote:

> 
> 
> On 11/12/2009 06:48 PM, Manik Surtani wrote:
>> 
>> On 12 Nov 2009, at 16:20, Galder Zamarreno wrote:
>> 
>>> 
>>> 
>>> 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.
>> 
>> ok
>> 
>>> 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.
>> 
>> It could be much simpler, as Mircea suggested, by enabling dupe domains in all unit test configs since they are created in 1 place.  :)  Want to give this a try instead?
> 
> Hmmmm, I suppose that if dups where allowed, those tests that relied on 
> non dup mbean names will fail, so I think it's pushing the issue 
> somewhere else. IOW, if all test assume there're no dups, they will be 
> looking up infinispan:* mbeans. But if dups appear, the mbean looked up 
> might belong to a different test, a test that might not have 
> unregistered the mbean and the result will be rather confusing. Does 
> this make any sense?

Yeah but there is probably only 1 test like that, right?  And for that test we could specify a custom config to override the JMX domain and the duplicity flag.

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