[jbosscache-dev] JMX and MBeans in JBoss Cache 2.0.0

[Manik Surtani]

Good point - keep an eye out for my post.  :-)

--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 6 Sep 2006, at 17:12, Brian Stansberry wrote:

> Manik Surtani wrote:
>>> Brian Stansberry wrote:
>>>>
>>>> Now I'm no JMX expert and I may be talking nonsense here so feel
>>>> free to tear this apart.  Brian, how would something like this work
>>>> for you since AS clustering gets cache references from JMX? Do we
>>>> still need to extend ServiceMBean in AS5?
>>>
>>> AS 5 services should be able to handle injection of pojos, so a  
>>> cache
>>> instance won't even need to be an MBean.  I'll be dealing with the
>>> cache via the Cache interface.  The cache should just expose
>>> create(), start(), stop(), destroy().  Of course we want it to be an
>>> MBean for management purposes, but it doesn't have to be to be used
>>> by things like session replication.
>>>
>>
>> So is is just those 4 that we want to expose via JMX then?
>> Ok, here is what I propose we expose via JMX:
>>
>> 1) lifecycle, as mentioned above.
>> 2) API to get a List<ObjectName> of bound interceptor MBeans (is this
>> necessary/useful?) 3) API to get Configuration
>> 4) API to dump cache contents/printLockInfo()
>> 5) API to get a hold of the Cache interface, and using this
>> people have direct access to the cache rather than directly
>> exposing all of the cache methods via JMX.
>
> A difficulty with a limited JMX interface that exposes complex objects
> like Cache and Configuration is you have to be in the same JVM to make
> use of the complex objects.
>
> 1) No manipulation via a browser (aka jmx-console and web-console).
> 2) No manipulation via RMIAdaptor (remote interface to JMX server.)
> 3) Don't know how the ON guys deal with the cache -- probably through
> RMIAdaptor.
>
> If Configuration is serializable it can be accessed in a read-only way
> through RMIAdaptor.  But are there any config attributes that  
> should be
> changeable at runtime (e.g. timeouts, eviction policy configs)?
>
> Not being able to access the Cache via RMIAdaptor is going to break  
> some
> AS unit tests for sure.
>
> It is possible as a workaround to bind a proxy to the cache in JNDI  
> and
> access it that way.
>
> I'm sympathetic to the desire to reduce the # of exposed methods
> (particularly all the Configuration ones), but gotta point out the
> problems :)
>
> I think this is something that should be brought up on the user  
> forum so
> as many users as possible get a chance to comment on how they deal  
> with
> JBC via JMX.