I think the implementation will create a new id if not provided. The new tracer interceptor outputs a formatting with the node id that gets generated a new uid for optional ids.
Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: William Tam [mailto:[EMAIL PROTECTED] Sent: 7. juli 2008 07:33 To: [email protected] Subject: Re: Starting Camel context causes JMX exception. the only thing is node id is optional. :-) On Mon, Jul 7, 2008 at 1:25 AM, William Tam <[EMAIL PROTECTED]> wrote: > yea, we should definitely include node id in processor's objectname. > > On Mon, Jul 7, 2008 at 1:14 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote: >> Hi William >> >> Yes that is definitely an oversight the bean should be registered twice if >> it's defined in the 2 times. >> >> I do think there is something about a node id you can get from the route >> context. Each processor types has an id that is unique within the camel >> context and we could use that as some kind of uid for the mbean name. >> >> public ObjectName getObjectName(RouteContext routeContext, >> ProcessorType processor) throws MalformedObjectNameException { >> >> Try to experiment with this method on the CamelNamingStrategy and append the >> node id: >> >> Something like this: >> >> buffer.append("id=" + processor.getId() + ","); etc. >> >> >> >> Med venlig hilsen >> >> Claus Ibsen >> ...................................... >> Silverbullet >> Skovsgårdsvænget 21 >> 8362 Hørning >> Tlf. +45 2962 7576 >> Web: www.silverbullet.dk >> >> -----Original Message----- >> From: William Tam [mailto:[EMAIL PROTECTED] >> Sent: 7. juli 2008 06:56 >> To: [email protected] >> Subject: Re: Starting Camel context causes JMX exception. >> >> Hi Claus, >> >> Camel does keep track of mbeans that it registers in order to >> unregister them. However, as we have seen in deploying camel in >> websphere, the mbean server could register a mbean under a different >> objectname than we specify. Say, we want to register a mbean with >> objectname "endpoint=abc". We check our registered objectnames map >> first. If the objectname is there, then don't try to register. The >> check won't work in the websphere's case because websphere mbean >> server always adds (cell, server, etc) to the objectname. >> >> After looking at it, I think we should register the repeated processor >> (generate a new objectname) found in a route because the repeated >> processor is actually different instance. If we don't register it, we >> won't see it's performance counter. So, if you send an exchange to >> the route from("direct:start").to("bean:test").to("bean:test"), we >> only see one exchange processed by "bean:test". If we register both >> instance, at least we can see one exchange processed by each instance. >> >> - William >> >> >> On Mon, Jul 7, 2008 at 12:10 AM, Claus Ibsen <[EMAIL PROTECTED]> wrote: >>> Hi >>> >>> When people see stracktraces in log files they immediately assume its an >>> ERROR. >>> >>> I am wondering if Camel should be smarter there and keep an internal map of >>> what mbean names it have registerered and if there is a duplication >>> exception (if we get an expilicit exception about this) then it should not >>> log it at WARN level with stacktraces etcs. But either: >>> - WARN without stacktrace >>> - DEBUG with stacktrace >>> - SKIP the error all together. >>> >>> I would appreciate if Camel is able to startup without any stacktraces in >>> its logging. >>> >>> Any thoughts? >>> >>> >>> Med venlig hilsen >>> >>> Claus Ibsen >>> ...................................... >>> Silverbullet >>> Skovsgårdsvænget 21 >>> 8362 Hørning >>> Tlf. +45 2962 7576 >>> Web: www.silverbullet.dk >>> >>> -----Original Message----- >>> From: William Tam [mailto:[EMAIL PROTECTED] >>> Sent: 7. juli 2008 05:52 >>> To: [email protected] >>> Subject: Re: Starting Camel context causes JMX exception. >>> >>> Sergey, I don't need to see your routes. The exception was thrown >>> during registering (duplicated) processors wthin route. Again, it is >>> a warning not an error. >>> >>> On Sun, Jul 6, 2008 at 11:24 PM, William Tam <[EMAIL PROTECTED]> wrote: >>>> Sergey, >>>> >>>> Actually, the above is a warning message and it does continue. The >>>> stacktrace shows that the failure was caused by a duplicated >>>> ManagedRoute mbean. Is it possible to send me the routes within your >>>> camel context? Perhaps, the camel naming strategy that generates >>>> objectnames for routes needs some tweaking. >>>> >>>> Thanks, >>>> William >>>> >>>> On Sun, Jul 6, 2008 at 9:37 PM, William Tam <[EMAIL PROTECTED]> wrote: >>>>> Hi Sergey, >>>>> >>>>> It looks like the instrumentation agent should handle mbeans that have >>>>> already been registered. It should catch the >>>>> InstanceAlreadyExistsException and continue. I'll open a JIRA. BTW, >>>>> the reason you start seeing the exception in 1.4 is because JMX is now >>>>> enabled by default. If you need to disable it, please follow the wiki >>>>> http://activemq.apache.org/camel/camel-jmx.html. >>>>> >>>>> Thanks, >>>>> William >>>>> >>>>> >>>>> On Sun, Jul 6, 2008 at 2:46 PM, S.R. <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> When Camel context is starting >>>>>> javax.management.InstanceAlreadyExistsException is thrown. >>>>>> >>>>>> This happens ONLY for 1.4.0 version AND if the route has 2 equal bean >>>>>> endpoints, for example: >>>>>> from("jms:queue").to("bean:testBean?methodName=test").to("bean:testBean?methodName=test") >>>>>> or >>>>>> from("jms:queue").to("bean:testBean").to("bean:testBean"). >>>>>> >>>>>> However, the following example doesn't cause that exception: >>>>>> from("jms:queue").to("bean:testBean?methodName=test1").to("bean:testBean?methodName=test2"). >>>>>> >>>>>> Original stack trace: >>>>>> WARNING: Could not register Counter MBean >>>>>> javax.management.InstanceAlreadyExistsException: >>>>>> org.apache.camel:context=srassokhin-pc/camelContext,[EMAIL >>>>>> PROTECTED],type=processor,name="To[bean:systemReplyBean\?methodName=replyLogin]" >>>>>> at >>>>>> com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) >>>>>> at >>>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484) >>>>>> at >>>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963) >>>>>> at >>>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) >>>>>> at >>>>>> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) >>>>>> at >>>>>> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) >>>>>> at >>>>>> org.apache.camel.management.DefaultInstrumentationAgent.registerMBeanWithServer(DefaultInstrumentationAgent.java:224) >>>>>> at >>>>>> org.apache.camel.management.DefaultInstrumentationAgent.register(DefaultInstrumentationAgent.java:165) >>>>>> at >>>>>> org.apache.camel.management.DefaultInstrumentationAgent.register(DefaultInstrumentationAgent.java:146) >>>>>> at >>>>>> org.apache.camel.management.InstrumentationLifecycleStrategy.onRouteContextCreate(InstrumentationLifecycleStrategy.java:173) >>>>>> at org.apache.camel.model.RouteType.addRoutes(RouteType.java:216) >>>>>> at org.apache.camel.model.RouteType.addRoutes(RouteType.java:90) >>>>>> at >>>>>> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:520) >>>>>> at >>>>>> org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:512) >>>>>> at >>>>>> org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:149) >>>>>> at >>>>>> org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:47) >>>>>> at >>>>>> org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:103) >>>>>> at >>>>>> org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) >>>>>> at >>>>>> org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) >>>>>> at >>>>>> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) >>>>>> at >>>>>> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:275) >>>>>> at >>>>>> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:737) >>>>>> at >>>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:384) >>>>>> at >>>>>> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139) >>>>>> at >>>>>> org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93) >>>>>> >>>>>> Sergey >>>>>> >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/Starting-Camel-context-causes-JMX-exception.-tp18304692s22882p18304692.html >>>>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>> >>>> >>> >> >
