[infinispan-dev] ISPN-118 - DefaultCacheManager already marked as MBean
Mircea Markus
mircea.markus at jboss.com
Thu Sep 10 10:42:10 EDT 2009
On Sep 9, 2009, at 5:55 PM, Galder Zamarreno wrote:
> Mircea, this is also related to the "Should
> CacheManagerJmxRegistration.start() be associated with
> CacheManager.start() ?" email thread/
>
> On 07/27/2009 01:18 PM, Manik Surtani wrote:
>> Yes, JMX should be for reporting only. Not as a registry to obtain a
>> component instance.
>>
>> Operations like starting and stopping a cache should be exposed
>> though,
>> perhaps via a Cache MBean (by annotating CacheDelegate?)
>
> I've been looking into this and here're some thoughts:
>
> The way I see such start/stop methods working is the following:
>
> 1. CacheManager needs to be registered when the CacheManager is
> started,
> not when the first cache is started, otherwise, how are you gonna
> start
> the default cache instance via jmx??
+1
>
> 2. Currently, when a cache is stopped, it's removed from JMX, so
> either:
> - You still leave it registered in JMX so that you can start it
> afterwards or
> - Enable some way for the a Cache to be started via the CacheManager's
> JMX API (getCache method name does not suit as JMX method that
> starts a
> given cache) or
> - Both actually. A way to start a brand new, uncreated, cache via
> CacheManager and also a way to restart a cache that was previously
> started. The latter would be done via Cache.start() but this requires
> Cache MBean not to be unregistered upon stop and this only to happen
> when the CacheManager is stopped.
>
> So, to summarise:
>
> - Implement my suggested change in ""Should
> CacheManagerJmxRegistration.start() be associated with
> CacheManager.start() ?" email thread so that DefaultCacheManager is
> registered in JMX when the CacheManager is started and not when the
> 1st
> cache is started.
>
> - Add two @ManagedOperation to DefaultCacheManager for
> startCache(String) and startCache(). These methods would likely call
> DefaultCacheManager's private createCache(String) method and return
> void.
>
> - Upon stopping a Cache instance, unregister all MBean except the
> CacheDelegate @MBean so that we can start()/stop() the cache from JMX
> without any probs.
>
> - Upon stopping the DefaultCacheManager, make sure all CacheDelegate
> @MBean instances are unregistered.
>
> Thoughts?
Wouldn't it be simpler to only have one way of starting the cache
(through CM)?
IMO, after the cache is stopped the system should be in the same state
as before starting it: no jmx registered. This would keep things
clearer.
>>
>>
>> On 24 Jul 2009, at 09:55, Galder Zamarreno wrote:
>>
>>> Hi,
>>>
>>> Re: https://jira.jboss.org/jira/browse/ISPN-118
>>>
>>> It turns out that since rev.454, DefaultCacheManager has already
>>> been
>>> marked as an MBean
>>> (http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/infinispan/manager/DefaultCacheManager.java?r=454
>>> )
>>>
>>>
>>> Currently, none of the getCache() methods are marked as MBean
>>> operations
>>> and I wanted to get confirmation on whether it should leave as it
>>> is. I
>>> mean, in AS6, I suppose people will be able to use the JNDI method
>>> to
>>> get access to the CacheManager and get the cache from there
>>> (http://tinyurl.com/lq688t section 11.2). Anyone running
>>> standalone can
>>> simply instantiate the cache manager.
>>>
>>> Thoughts?
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
More information about the infinispan-dev
mailing list