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

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?

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