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

Mircea Markus mircea.markus at jboss.com
Mon Nov 23 07:47:08 EST 2009 

On Nov 13, 2009, at 11:29 AM, Manik Surtani wrote:

> 
> On 13 Nov 2009, at 10:22, Mircea Markus wrote:
> 
>> 
>> On Nov 12, 2009, at 8:00 PM, Manik Surtani wrote:
>> 
>>> 
>>> 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.
>> What about generating unique domain names per cache manager vs enabling dupe domains. Or even disable jmx entirely for tests that don't need it.
> 
> That's not good enough - tests that *do* need it could still be scheduled to run in parallel and trip up.
> 
>> A possible solution would be:
>> - jmx disabled by default (The TestCacheManagerFactory might do this)
>> - new TestCacheManagerFactory method would receive the jmx domain. It will keep track of all active domains and won't allow two CacheManagers with same domain name.
> 
> That would work, care to take this on?  :)
I've created this and assigned to me.
https://jira.jboss.org/jira/browse/ISPN-285
> 
>> Wdyt?
>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20091123/a0da3ec8/attachment-0002.html

More information about the infinispan-dev mailing list