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

[Galder Zamarreno]

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?

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