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

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(a)jboss.org >>>> Lead, Infinispan >>>> Lead, JBoss Cache >>>> http://www.infinispan.org >>>> http://www.jbosscache.org >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev