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.