[infinispan-dev] JMX stuff in infinispan

Galder Zamarreno galder.zamarreno at redhat.com
Tue Mar 31 12:52:43 EDT 2009 


Mircea Markus wrote:
> Brian Stansberry wrote:
>> Mircea Markus wrote:
>>> Manik Surtani wrote:
>>>>
>>>> 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 think mandatory indexes would confuse users, as they configured an 
>>> jmxDomain in clear text and see an different on the server. Even 
>>> more, they might want to enforce an domainName for other reasons 
>>> (e.g. thay have other modules expose under that domain name etc).
>>> I would like the user to be aware of the fact that there is an 
>>> conflict and take action, rather than dig through logs first and then 
>>> curse the developer who wrote the code.
>>> What about:
>>> 1) forbid a registration under same domain. Cache won't start as 
>>> registration is done at startup, an exception will be thrown.
>>> 2) add an configuration attribute named forceAutoIncrement 
>>> (default=false). The user would have to manually enable it.Also, the 
>>> error message at 1) would inform him about this attribute, so the 
>>> change should be quite straight
>>
>> I think an option to name the manager is needed. I'll be running 
>> multiple managers in the same AS, and people are going to need to be 
>> able to access them by name, not by a number that varies based on what 
>> order the managers are started in.
> I think jmxDomain does just that, i.e. groups all element from a 
> CacheManager under the same common structure.
> The scenario we're talking about is when people configure the same name 
> (or do not configure anything and same default is used), what will 
> happen with the second cache manager?

Not sure that should be allowed. JMX implementations do moan (via a 
InstanceAlreadyExistsException) when the name already exists, why 
shouldn't we? You know have the opportunity to give it a different name 
(side: we couldn't with JBC - 
https://jira.jboss.org/jira/browse/JBCACHE-1485), so people should make 
use of it IMO.

>>
>>>> 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 <mailto: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 <mailto: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 <mailto:manik at jboss.org>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat

More information about the infinispan-dev mailing list