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

[Galder Zamarreno (JIRA)]

     [ https://jira.jboss.org/jira/browse/ISPN-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreno resolved ISPN-294.
-----------------------------------

    Fix Version/s: 4.0.0.CR3
                       (was: 4.0.0.GA)
       Resolution: Done


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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira