6 Replies Latest reply on May 17, 2011 9:55 AM by galder.zamarreno

    Redployment issues

    omerzohar

      my project's working fine when i start the server (jboss as 6 + infinispan), infinspan works and all.

      when i make some changes to my EAR  and redeploy (by touching application.xml for instance), application is reloaded, no errors

      but when time comes to (re)load infinispan's Manager i get the following error:

       

      [org.infinispan.jmx.CacheManagerJmxRegistration] There's already an cache manager instance registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element

       

      ST:

      ctch.modules] UrlWorkflowStarterModule -> Error Occured during bean initalization. Reason:org.infinispan.jmx.JmxDomainConflictException: There's already an cache manager instance registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element. Bean will function in relay mode. stack trace: org.infinispan.jmx.JmxDomainConflictException: There's already an cache manager instance registered under 'org.infinispan' JMX domain. If you want to allow multiple instances configured with same JMX domain enable 'allowDuplicateDomains' attribute in 'globalJmxStatistics' config element -> ST: org.infinispan.jmx.CacheManagerJmxRegistration.updateDomain(CacheManagerJmxRegistration.java:77) -> org.infinispan.jmx.CacheManagerJmxRegistration.buildRegistrar(CacheManagerJmxRegistration.java:64) -> org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:51) -> org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:40) -> org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:524) -> org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:260) -> org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:229) -> ctch.cache.CachingBlackBoxSingleton.init_s(CachingBlackBoxSingleton.java:39) -> ctch.cache.CachingBlackBoxSingleton.init(CachingBlackBoxSingleton.java:50) -> ctch.cache.CachingBlackBoxSingleton.getCacheInstance(CachingBlackBoxSingleton.java:76) -> ctch.cache.CachingBlackBoxSingleton.getDataCache(CachingBlackBoxSingleton.java:87) -> ctch.cache.CachingBlackBoxSingleton.dataCacheInstance(CachingBlackBoxSingleton.java:95) -> ctch.modules.AbstractMessageBean.<init>(AbstractMessageBean.java:69) -> ctch.modules.workflows.urlWorkflow.UrlWorkflowStarterModule.<init>(UrlWorkflowStarterModule.java:46) -> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) -> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) -> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) -> java.lang.reflect.Constructor.newInstance(Constructor.java:513) -> java.lang.Class.newInstance0(Class.java:355) -> java.lang.Class.newInstance(Class.java:308) -> org.jboss.ejb3.instantiator.impl.Ejb31SpecBeanInstantiator.create(Ejb31SpecBeanInstantiator.java:80) -> org.jboss.ejb3.EJBContainer.construct(EJBContainer.java:1048) -> org.jboss.ejb3.mdb.MessagingContainer.createBeanContext(MessagingContainer.java:102) -> org.jboss.ejb3.pool.AbstractPool.createBeanContext(AbstractPool.java:94) -> org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:81) -> org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:75) -> org.jboss.ejb3.pool.StrictMaxPool.get(StrictMaxPool.java:153) -> org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:58) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.core.context.InvocationContextAdapter.proceed(InvocationContextAdapter.java:70) -> org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:247) -> org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:349) -> org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) -> org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:79) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) -> org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) -> org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:306) -> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:299) -> org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:152) -> $Proxy233.onMessage(Unknown Source) -> org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:256) -> org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822) -> org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46) -> org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940) -> org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) -> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) -> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) -> java.lang.Thread.run(Thread.java:619) ->
      
      

       

       

      ... and of course i can't use the cache.

       

      any idea why?

      note: dont know if it's any help but im loading infinispan with my own config. using jboss's infinspan-config was doing a lot of problems...

        • 1. Redployment issues
          dan.berindei

          Looks like the old cache manager is still up by the time the new cache manager starts.

           

          Most likely you need to add a ServletContextListener to your app to stop the cache manager on undeploy, something like this:

          https://github.com/infinispan/infinispan/blob/master/demos/ec2-ui/src/main/java/org/infinispan/ec2demo/web/CacheServletListener.java

          • 2. Redployment issues
            omerzohar

            this idea is nice but it doesnt work for me. i tried doing it with using a servlet, but the contextDestroyed is being invoked all the time, even though it's not a redeployment.

            Why does it have to be a on a servlet though? Isnt there a listener for an underployment event?

            • 3. Re: Redployment issues
              dan.berindei

              The class name is a bit misleading, although it's called CacheServletListener it's a listener on the "servlet context", i.e. the app.

               

              How did you try to do it using a servlet? A ServletContextListener is supposed to be registered in web.xml, something like this:

               

              {code:xml}

                  <listener>

                      <listener-class>org.infinispan.ec2demo.web.CacheServletListener</listener-class>

                  </listener>

              {code}

              • 4. Re: Redployment issues
                omerzohar

                this is exactly what i did. sorry if i confused you. problem with this method is that for some reason the method has fired off in the middle of the workflow, even though i was not redeploying or shutting down, which of course caused all the work with the caches to fail...

                 

                is there a way to register the cache manager to a JDNI name, and then look it up after redployment. i mean something of the sort this pseudo code:

                 

                if (manager = lookup_JNDI (CACHE_MANAGER_NAME) != NULL)

                     return manager;

                else  {

                     manager = new DefaultCacheManager (conf_file);

                     JNDI_BIND(CACHE_MANAGER_NAME,manager);

                     return manager

                }

                • 5. Re: Redployment issues
                  dan.berindei

                  I think something could be wrong with your deployment, I see no reason why AS would call your ServletContextListener while the app is still deployed.

                   

                  Re: registering the cache manager in JNDI, have a look here:

                  http://community.jboss.org/wiki/InfinispanTechnicalFAQs#Can_I_bind_Cache_or_CacheManager_to_JNDI

                   

                  Note that you still wouldn't want to keep the cache manager alive across redeployments, because objects stored by the old version of your app won't be usable by the new version (as they have different classloaders).

                  1 of 1 people found this helpful
                  • 6. Redployment issues
                    galder.zamarreno

                    Yeah, as Dan said, if you start a CacheManager on deployment, upon undeployment you should stop it.

                    1 of 1 people found this helpful