[infinispan-issues] [JBoss JIRA] Resolved: (ISPN-294) Stop exposing getCache(*) via JMX and instead create new startCache(*) JMX methods

Stop exposing getCache(*) via JMX and instead create new startCache(*) JMX methods ---------------------------------------------------------------------------------- Key: ISPN-294 URL: https://jira.jboss.org/jira/browse/ISPN-294 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 4.0.0.CR2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR3 In summary: Stop exposing getCache(*) methods via JMX and instead create managed startCache(*) methods to control Cache lifecycles via JMX. > On 30 Nov 2009, at 15:37, Brian Stansberry wrote: > >> On 11/26/2009 07:57 AM, Galder Zamarreno wrote: >>> >>> >>> On 11/26/2009 12:34 PM, Manik Surtani wrote: >>>> >>>> On 25 Nov 2009, at 21:08, Brian Stansberry wrote: >>>> >>>>> FYI; $subject is an interesting aspect of how we manage JBC >>>>> instances. This impacts things like ClusteredSingleSignOn and >>>>> clustered web session failover[1]. >>>>> >>>>> AIUI, this is less of an issue with Infinispan, since Cache instances >>>>> aren't shared (unless of course the code that asked for a Cache >>>>> passes around refs). Dunno if there is any equivalent to the >>>>> CacheJmxWrapperMBean.getCache() method though. >>>> >>>> Infinispan's CacheManager does this... >>> >>> Indeed. getCache() methods are exposed by JMX in order to start Cache >>> instances. If returning a Cache ref is a problem from a JMX perspective, >>> we can add remove @ManagedOperation from getCache() calls and add 2 >>> managed equivalent methods called something like startCache() that are >>> exposed via JMX. >>> >> >> That sounds like a good change just from an API point-of-view, at least if you don't really want to expose the cache via JMX. > > Yes, I agree with this. Galder, is there any reason other than controlling lifecycle that you expose a Cache via JMX? If there isn't any other reason then lets expose lifecycle helpers via the CacheManager. Much more robust IMO. To clarify, we only expose the Cache via JMX as a side effect of want to control lifecycle. I didn't do this on purpouse. We discussed it in the dev list and found using the getCache(*) method as a good way to solve the problem at the time which was controlling lifecycle, not to expose the Caches in any way. So, I'm all in to expose startCache(*) like methods for JMX and that way we don't leak Cache. I'll get this done asap.