[infinispan-dev] JMX stuff in infinispan

[Manik Surtani]

On 25 Mar 2009, at 13:19, Adrian Cole wrote:

> tough call..  the jmx user may not have access to the log to see the
> warning anyway.
>
> I would prefer an info notification of coarse registration events then
> warn or trace depending on whether the name is overloaded.  That would
> seem more grep friendly for unixy folks who scrape logs for things.  I
> think a mandatory index would me simpler in that case, although
> slightly confusing for folks who don't have more then one.

+1 on the mandatory index.

I am guessing this is in CacheJmxRegistration.getJmxDomain()?  Why  
does index start at '2' ?  :-)  Ah I see - so you would have  
"cacheDomain", "cacheDomain2", "cacheDomain3", etc.

Hmm... I still prefer "cacheDomain:0", "cacheDomain:1", etc.  More  
consistent.


>
>
> my 2p..
> -Adrian
>
> On Wed, Mar 25, 2009 at 12:47 PM, Mircea Markus <mircea.markus at jboss.com 
> > wrote:
>> Manik Surtani wrote:
>>>
>>> When running the test suite I see:
>>>
>>> WARN  [ComponentsJmxRegistration] (pool-1-thread-9) Jmx domain  
>>> already in
>>> use
>>>
>>> Is this as severe a problem as a WARN?  It should be entirely  
>>> possible
>>> that people register > 1 cache managers with the same MBean  
>>> Server.  Perhaps
>>> rather than log such a severe warning, we should use a counter if  
>>> the domain
>>> is repeated?  E.g.,
>>> jmxDomain:<managerInstanceNumber>:global:<componentName>
>>> jmxDomain:<managerInstanceNumber>:<cachename>:<componentName>
>>>
>>> WDYT?
>>
>> that's already there ;) an index is appended to the domain name, if  
>> the
>> domain is already registered(same as you suggested, only that first  
>> domain
>> won't have any index).
>> Phaps I can drop the warning (replace with trace), but I still  
>> might want
>> people to know that there is a name conflict : e.g. they might  
>> lookup the
>> cache in JMX programmatically and work with a totally different cache
>> instance..
>>>
>>> Cheers
>>> Manik
>>>
>>> On 25 Mar 2009, at 10:45, Mircea Markus wrote:
>>>
>>>> Manik Surtani wrote:
>>>>>
>>>>> On 25 Mar 2009, at 06:22, Mircea Markus wrote:
>>>>>
>>>>>> implementation finished.
>>>>>> Following features were added, compared with JBossCache:
>>>>>> 1) jmx domain care be specified now.
>>>>>> 2) an MBeanServer lookup can be configured, to lookup the  
>>>>>> server on
>>>>>> which the components will be registered - in prev version the
>>>>>> PlatformMBeanServer was hardcoded (now it's only an default)
>>>>>> 3) missing unit tests were added for all the annotated MBeans
>>>>>> 4) jmx is now configured in two places:
>>>>>>  - in global section: to enable exposure of shared information  
>>>>>> (rpc
>>>>>> manager info, cache manager info)
>>>>>>  e.g <globalJmxStatistics enabled="true" jmxDomain="infinispan"
>>>>>> mBeanServerLookup="org.infinispan.jmx.PerThreadMBeanServerLookup" />
>>>>>>
>>>>>>  - for each cache, where cache specific info is configured(mainly
>>>>>> interceptors, which now are cache specific)
>>>>>> e.g. <jmxStatistics enabled="false"/>
>>>>>
>>>>> How are objects registered in JMX?  I'm guessing  
>>>>> jmxDomain:<component>
>>>>> for stuff on the cache manager, and  
>>>>> jmxDomain:<cacheName>:<component> for
>>>>> cache-level components?
>>>>
>>>> jmxDomain:global: [component name] for cache manager stuff
>>>> for cache level is as you mentioned.
>>>>>
>>>>> Cheers
>>>>> Manik
>>>>>
>>>>> --
>>>>> Manik Surtani
>>>>> Lead, JBoss Cache
>>>>> http://www.jbosscache.org
>>>>> manik at jboss.org <mailto:manik at jboss.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Manik Surtani
>>> Lead, JBoss Cache
>>> http://www.jbosscache.org
>>> manik at jboss.org <mailto:manik at jboss.org>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090325/385ffa72/attachment-0001.html