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

[Manik Surtani]

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?  :)

> 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




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