EHC ❯ MBeans from multiple CacheManagers in same VM will have name collisions during tunnelling
-
Bug
-
Status: Closed
-
1 Critical
-
Resolution: Fixed
-
ehcache-core
-
-
asingh
-
Reporter: amiller
-
September 22, 2009
-
0
-
Watchers: 1
-
July 27, 2012
-
September 25, 2009
Description
From Tim: The initial problem is pretty straightforward – as soon as a second L1 starts up there are ObjectName conflicts. It’d be nice if we could use an isolated MBeanServer for each L1, but then I’m not sure how we could tunnel the ehcache beans. Perhaps when we sort out exactly who is going to be registering the ehcache beans then maybe this approach might work. It’s really easy in the code to have a separate MBeanServer created per L1 (just call Manager.initForTests() from DSOContextImpl.createStandaloneContext()).
Assuming that we have to use the platform MBeanServer, we have to do something to make the names unique. Just adding in the ChannelID (like the server does) isn’t quite enough since there can still be conflicts if the L1s are talking to different L2 servers. In that case two L1s in the same VM could easily be given the same ChannelID. This seems to imply some sort unique server identifier in the L1 names. One place where this seems to complicate matters is when the L2 queries back on the L1 for beans matching a pattern. Right now we just query everything available on the L1 matching our domains. That obviously needs to be narrowed.
It is worth mentioning that this problem isn’t new with ehcache standalone. I think we have the same issues with standalone hibernate, we just didn’t realize it.
Fixed. When a name is already used, it will iteratively try to find a unique name by appending counters in the name till a maximum number of retries is exceeded or a unique name is found.