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?

Cheers Manik -- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org <mailto:manik@jboss.org>

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?

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(a)jboss.org <mailto:manik@jboss.org> >> >> >> >> > -- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org <mailto:manik@jboss.org>

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.

my 2p.. -Adrian On Wed, Mar 25, 2009 at 12:47 PM, Mircea Markus <mircea.markus(a)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(a)jboss.org <mailto:manik@jboss.org> >>>> >>>> >>>> >>>> >>> >> >> -- >> Manik Surtani >> Lead, JBoss Cache >> http://www.jbosscache.org >> manik(a)jboss.org <mailto:manik@jboss.org> >> >> >> >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >

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 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(a)jboss.com <mailto:mircea.markus@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(a)jboss.org <mailto:manik@jboss.org> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Manik Surtani >>>> Lead, JBoss Cache >>>> http://www.jbosscache.org >>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> > > -- > Manik Surtani > Lead, JBoss Cache > http://www.jbosscache.org > manik(a)jboss.org <mailto:manik@jboss.org> > > > > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 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(a)jboss.com <mailto:mircea.markus@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(a)jboss.org <mailto:manik@jboss.org> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Manik Surtani >>>>> Lead, JBoss Cache >>>>> http://www.jbosscache.org >>>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >> >> -- >> Manik Surtani >> Lead, JBoss Cache >> http://www.jbosscache.org >> manik(a)jboss.org <mailto:manik@jboss.org> >> >> >> >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.com <mailto:mircea.markus@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(a)jboss.org <mailto:manik@jboss.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Manik Surtani >>>>>>> Lead, JBoss Cache >>>>>>> http://www.jbosscache.org >>>>>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>> >>>> >>>> -- >>>> Manik Surtani >>>> Lead, JBoss Cache >>>> http://www.jbosscache.org >>>> manik(a)jboss.org <mailto:manik@jboss.org> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 1 Apr 2009, at 11:16, Mircea Markus wrote: > Galder Zamarreno wrote: >> >>> <SNIP /> >> >> 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) >> <https://jira.jboss.org/jira/browse/JBCACHE-1485%29>;, so people >> should make use of it IMO. > This is the default behavior: if a second instance is stared under > the same domain, then an exception is being thrown indicating that > (during cache startup). At this point the user can change domain > name, or just enable "forceAutoIncrement" (which is "try using the > configured domain, but if it is already taken try using the next > one"). Either way, the user *is notified* that a domain conflict > exist and he *must take action* in order to avoid that - nothing done > under the hood. I like the fact that everything is explicit here. What is the configuration element/attrib to allow dupe domains?

-- Manik Surtani Lead, JBoss Cache http://www.jbosscache.org manik(a)jboss.org <mailto:manik@jboss.org>