[JBoss JIRA] Created: (EJBTHREE-766) InstanceNotFoundExceptions while undeploying @Service beans
by Jeff Schnitzer (JIRA)
InstanceNotFoundExceptions while undeploying @Service beans
-----------------------------------------------------------
Key: EJBTHREE-766
URL: http://jira.jboss.com/jira/browse/EJBTHREE-766
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC9 - FD
Environment: JBoss 4.0.5.GA
Reporter: Jeff Schnitzer
For a trivial @Service pojo packaged in a JAR in an EAR, jboss prints InstanceNotFoundExceptions in the logs while undeploying. These exceptions do not appear in 4.0.4.GA. It looks like JBoss is trying to undeploy the service twice.
The log messages (and exceptions) are noted below. The service is a trivial POJO with start() and stop() methods that do nothing but log. I can attach the test case if you want but it's pretty simple.
-----
2006-10-29 19:29:25,287 DEBUG [org.jboss.deployment.MainDeployer] Undeploying file:/C:/java/jboss-4.0.5.GA/server/default/deploy/ContainerTest.ear, isShutdown=true
2006-10-29 19:29:25,287 DEBUG [org.jboss.deployment.MainDeployer] Stopping sub deployment: file:/C:/java/jboss-4.0.5.GA/server/default/tmp/deploy/tmp4969ContainerTest.ear-contents/ContainerTest.jar
2006-10-29 19:29:25,287 DEBUG [org.jboss.ws.integration.jboss.DeployerInterceptorEJB3] stop: file:/C:/java/jboss-4.0.5.GA/server/default/tmp/deploy/tmp4969ContainerTest.ear-contents/ContainerTest.jar
2006-10-29 19:29:25,287 DEBUG [org.jboss.ejb3.EJB3Deployer] init, ContainerTest.jar
2006-10-29 19:29:25,287 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,287 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.j2ee:service=EJB3,module=ContainerTest.jar dependent services are: []
2006-10-29 19:29:25,287 DEBUG [org.jboss.ejb3.Ejb3Module] Stopping jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,287 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,287 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3 dependent services are: []
2006-10-29 19:29:25,287 DEBUG [org.jboss.ejb3.ServiceDelegateWrapper] Stopping jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,297 DEBUG [org.jboss.ejb.txtimer.EJBTimerServiceImpl] removeTimerService: org.jboss.ejb.txtimer.TimerServiceImpl@172bab9
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] stopping service: x:service=Go
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: x:service=Go dependent services are: []
2006-10-29 19:29:25,297 DEBUG [test.GoBean] stop()
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] destroying service: x:service=Go
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] destroying dependent services for: x:service=Go dependent services are: []
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] removing service: x:service=Go
2006-10-29 19:29:25,297 DEBUG [org.jboss.system.ServiceController] removing x:service=Go from server
2006-10-29 19:29:25,297 WARN [org.jboss.ejb3.ServiceDelegateWrapper] Stopping failed jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
java.lang.RuntimeException: javax.management.InstanceNotFoundException: x:service=Go is not registered.
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:159)
at org.jboss.ejb3.service.ServiceContainer.stop(ServiceContainer.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.ejb3.ServiceDelegateWrapper.stopService(ServiceDelegateWrapper.java:118)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy67.stop(Unknown Source)
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:151)
at org.jboss.ejb3.JmxKernelAbstraction.uninstall(JmxKernelAbstraction.java:175)
at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:501)
at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy37.stop(Unknown Source)
at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy38.stop(Unknown Source)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:659)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:516)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:1050)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1025)
at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:988)
Caused by: javax.management.InstanceNotFoundException: x:service=Go is not registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:155)
... 97 more
2006-10-29 19:29:25,307 DEBUG [org.jboss.system.ServiceController] destroying service: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,307 DEBUG [org.jboss.system.ServiceController] destroying dependent services for: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3 dependent services are: []
2006-10-29 19:29:25,307 DEBUG [org.jboss.ejb3.ServiceDelegateWrapper] Destroying jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,307 DEBUG [org.jboss.ejb3.ServiceDelegateWrapper] Destroyed jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,307 DEBUG [org.jboss.system.ServiceController] removing service: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3
2006-10-29 19:29:25,307 DEBUG [org.jboss.system.ServiceController] removing jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3 from server
2006-10-29 19:29:25,307 DEBUG [org.jboss.ejb3.Ejb3Deployment] error trying to shut down ejb container
java.lang.RuntimeException: javax.management.InstanceNotFoundException: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3 is not registered.
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:159)
at org.jboss.ejb3.JmxKernelAbstraction.uninstall(JmxKernelAbstraction.java:175)
at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:501)
at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.stop(Unknown Source)
at org.jboss.system.ServiceController.stop(ServiceController.java:508)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy37.stop(Unknown Source)
at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy38.stop(Unknown Source)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:659)
at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:516)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:1050)
at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:1025)
at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:988)
Caused by: javax.management.InstanceNotFoundException: jboss.j2ee:ear=ContainerTest.ear,jar=ContainerTest.jar,name=Go,service=EJB3 is not registered.
at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:523)
at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:383)
at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:155)
... 66 more
2006-10-29 19:29:25,317 DEBUG [org.jboss.ejb3.Ejb3Module] Stopped jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.j2ee:service=EARDeployment,url='ContainerTest.ear'
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.j2ee:service=EARDeployment,url='ContainerTest.ear' dependent services are: []
2006-10-29 19:29:25,317 DEBUG [org.jboss.deployment.EARDeployment] Stopping jboss.j2ee:service=EARDeployment,url='ContainerTest.ear'
2006-10-29 19:29:25,317 DEBUG [org.jboss.deployment.EARDeployment] Stopped jboss.j2ee:service=EARDeployment,url='ContainerTest.ear'
2006-10-29 19:29:25,317 DEBUG [org.jboss.deployment.MainDeployer] Destroying sub deployment: file:/C:/java/jboss-4.0.5.GA/server/default/tmp/deploy/tmp4969ContainerTest.ear-contents/ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.ws.integration.jboss.DeployerInterceptorEJB3] destroy: file:/C:/java/jboss-4.0.5.GA/server/default/tmp/deploy/tmp4969ContainerTest.ear-contents/ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] destroying service: jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] destroying dependent services for: jboss.j2ee:service=EJB3,module=ContainerTest.jar dependent services are: []
2006-10-29 19:29:25,317 DEBUG [org.jboss.ejb3.Ejb3Module] Destroying jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.ejb3.Ejb3Module] Destroyed jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] removing service: jboss.j2ee:service=EJB3,module=ContainerTest.jar
2006-10-29 19:29:25,317 DEBUG [org.jboss.system.ServiceController] removing jboss.j2ee:service=EJB3,module=ContainerTest.jar from server
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBCACHE-823) Refactor eviction configuration away from EvictionConfiguration interface
by Brian Stansberry (JIRA)
Refactor eviction configuration away from EvictionConfiguration interface
-------------------------------------------------------------------------
Key: JBCACHE-823
URL: http://jira.jboss.com/jira/browse/JBCACHE-823
Project: JBoss Cache
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: 2.0.0.GA
The EvictionConfiguration interface presumes that objects that represent a policy configuration should be able to parse their XML config themselves. We don't want that; parsing of the legacy XML configs should be handled by XmlConfigurationParser and policy config objects should be configurable by the MC without their having any internal expectation of being passed a DOM element.
To do this:
1) Create interface EvictionPolicyConfig. This is used internally (e.g. in the RegionManager and Region classes) in place of EvictionConfiguration.
2) All of the config classes for the standard eviction policies now implement EvictionPolicyConfig instead of EvictionConfiguration.
To support old custom policies:
1) EvictionConfiguration still exists but is deprecated.
2) EvictionConfiguration now extends EvictionPolicyConfig. So, custom impls *will* need to be modified to implement EvictionPolicyConfig's 2 methods.
3) XmlConfigurationParser when trying to configure a policy config object will check if it implements EvictionConfiguration. If it does, the legacy parseXmlConfig(Element) method will be called. Otherwise it will be configured via reflection.
Need to decided exactly how to handle the old public EvictionConfiguration Region.getEvictionConfiguration() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBCACHE-822) Reconsider validation of EvictionPolicyConfig objects
by Brian Stansberry (JIRA)
Reconsider validation of EvictionPolicyConfig objects
-----------------------------------------------------
Key: JBCACHE-822
URL: http://jira.jboss.com/jira/browse/JBCACHE-822
Project: JBoss Cache
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
In the legacy code, various impls of EvictionConfiguration would validate input during calls to parseXmlConfig. Problem is that if a config was instantiated and configured programatically, no validation occurred. Further the old parseXmlConfig validations basically just tested whether a configuration element was present, not whether it had a reasonable value.
The new validate() methods really should just test for reasonable values; whether the value was configured externally or was there by default is irrelevant.
Main task here is to remove some old unit tests that checked whether a value was set or not during xml parsing and replace with tests that check whether the reasonable value requirement is enforced.
Probably will do this after alpha.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JGRP-348) UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other
by Bela Ban (JIRA)
UNICAST: incorrect sequence numbers after merge if subgroups didn't completely exclude each other
-------------------------------------------------------------------------------------------------
Key: JGRP-348
URL: http://jira.jboss.com/jira/browse/JGRP-348
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
Mail from David Foregt:
Hi Bela,
Still have an issue with JGroup 2.4 with UNICAST after applying your
recommended settings. We spent more time analyzing the issue and found the
exact scenario that cause the problem:
- We have multiple nodes running on machine A (a1, a2, a3, a4...a15) an one
node running on machine B (b1).
- b1 node is started first (coord) then all a's nodes are started.
When all nodes are active in the group we disconnected machine A from the
network.
- After ~10 sec all a's see b1 as dead and a new view is propagated to all
a's nodes and connection table for b1 entry is cleared for all a's nodes.
- b1 start seeing a's node as dead one by one every ~10 sec (as define by FD
/ VERIFY_SUSPECT) after 30 sec b1's view is (a4, a5...a15) and we
reconnected the network cable on machine A. (b1 connection table was cleared
for only a1...a3)
- After A reconnect to the network a merge was done and all nodes are back
in the group and are able to exchange Multicast message.
- Because b1 did not detect a4...a15 as dead when it send a unicast message
to those nodes the seqno has not been reset to 1. When a4 receive the first
unicast message from b1 (because its connection table was cleared for b1) it
create at line 453 of UNICAST a new AckReceiverWindow with initial_seqno = 1
and add the received message (that has a seqno > 1) in the new
AckReceiverWindow then all subsequent unicast message received from b1 are
added in this new AckReceiverWindow and when remove is called at line 470 of
UNICAST it always return null because the AckReceiverWindow::next_to_remove
is equal to 1 and the message that we are adding to AckReceiverWindow have a
seqno > 1.
The result is that a4...a15 will never be able to receive any other unicast
msg from b1. This is reproducible all the time.
Our quick fix that look to work fine is to change UNICAST line 453 as
following (I am not sure about potential bug introduce by this):
entry.received_msgs=new AckReceiverWindow(seqno);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3777) Cannot get client cerfiticate when using IIS 6
by Tomaz Cerar (JIRA)
Cannot get client cerfiticate when using IIS 6
----------------------------------------------
Key: JBAS-3777
URL: http://jira.jboss.com/jira/browse/JBAS-3777
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.3 SP1
Environment: Windows 2003 SP1, IIS 6, Tomcat connector 1.2.19
Reporter: Tomaz Cerar
Assigned To: Remy Maucherat
We have an application where user can authenticate himself with Client certificate.
SSL and authentication is done by IIS 6.
The problem is that after auth is successful but I don't get client certificate in servlet.
request.getAttribute("javax.servlet.request.X509Certificate") returns null
The same application with same configuration works ok on IIS 5(old production box) and IIS 5.1 (development)
I have tried with various versions of JK and JK2 and same result, doesn't work in IIS 6.
I have tried to run IIS in IIS 5 isolation mode and without, and results are same.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (EJBTHREE-736) Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
by Piotr Tabor (JIRA)
Duplicating _$$_javassist_ classes after remote - call - OutOfMemory: PermGen
-----------------------------------------------------------------------------
Key: EJBTHREE-736
URL: http://jira.jboss.com/jira/browse/EJBTHREE-736
Project: EJB 3.0
Issue Type: Bug
Components: Documentation
Affects Versions: EJB 3.0 RC9 - FD
Environment: Linux Gentoo 2.6.18, JVM 1.5.0.08, 1.5.0.09, amd64
RedHat Linux EE 4.0. JVM 1.5.0.09, intel
Reporter: Piotr Tabor
I got the same problem...
PermGen in EJB3 client aplication by remote interface.
The application is as sample as it can be:
-get remote interface of stateless EJB3 (by JNDI)
- ask 1000 times to get a Collection of 10 EntityBeans.
After 255 there is OutOfMemory: PermGen.
JVM options changes nothing (eventualy more PermSpace => longer run).
The reason looks like the Javassist create lazyinitializer classes for every EntityBean retrived from the server.
So: When I debug on server-side, I got before sending Entity to client:
I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_7> 13434
...
myEntity[0].user=<UserEntity_$$_javassist_15>...
myEntity[0].stage=<StageEntity_$$_javassist_17>...
And every remote call the class names (name)_$..._javassist_(index) got the same
indexes (7,15,17) on server side (end every entity in returned collections of entities)
But when I debug on client site - after return from remote call - the indexes of
all returned entities are different (Each next increments index).
So after first call I got:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_0>...
...
myEntity[0].user=<UserEntity_$$_javassist_1>...
myEntity[0].stage=<StageEntity_$$_javassist_2>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_3>
...
myEntity[1].user=<UserEntity_$$_javassist_4>...
myEntity[1].stage=<StageEntity_$$_javassist_5>...
...
After secund call:
myEntity[0].id=143534
myEntity[0].flow=<FlowEntity_$$_javassist_6>...
...
myEntity[0].user=<UserEntity_$$_javassist_7>...
myEntity[0].stage=<StageEntity_$$_javassist_8>...
...
myEntity[1].id=143534
myEntity[1].flow=<FlowEntity_$$_javassist_9>
...
myEntity[1].user=<UserEntity_$$_javassist_10>...
myEntity[1].stage=<StageEntity_$$_javassist_11>...
...
And so on... ... and permGen after 260 iterations...
I have not idea, how to deal with that...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JGRP-344) Ignore bind address for (receive) sockets
by Bela Ban (JIRA)
Ignore bind address for (receive) sockets
-----------------------------------------
Key: JGRP-344
URL: http://jira.jboss.com/jira/browse/JGRP-344
Project: JGroups
Issue Type: Task
Affects Versions: 2.4
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.5
For multicast sockets, bind address defines the NIC which will be used to receive and send IP multicast packets. For unicast sockets (e.g. ServerSocket), this is an unnecessary restriction and bind address should be ignored. For example, if we define bind_addr=1.2.3.4, then we will be able to only receive packets on 1.2.3.4, but not 5.6.7.8 etc.
However, currently bind_addr is used to define the *identity* of a member, so we still need to use it (although not set it in a socket). This will be easier once we have logical addresses.
Email by Satya:
Hi,
I have found an issue which is to be fixed in 2.5. I
want to know if my issue is realted to this issue.
The description is as follows:
If -Dbind.address or bind_addr are not set, JGroups
picks the NIC to bind sockets to itself. However,
especially for ServerSockets, this may not be
desirable because we may want to have ServerSockets be
able to receive packets through all interfaces, e.g.
- NICs are 192.168.5.2, 192.168.0.2 and 127.0.0.1
(loopback)
- When the bind address is set to 192.168.5.2, a given
ServerSocket on port 7500 will *only accept packets
from this NIC*
- If someone connects to 192.168.0.2:7500 or
127.0.0.1:7500, the client will not be able to
establish a connection because nobody is listening on
those ports on the given NICs
- If bind address was not set, this would be possible
- Affected: FD_SOCK, FD_PING, TCP, TCP_NIO etc
- We need to think about semantics for
MulticastSockets where a wildcard address (not setting
the bind address) means that the operating system
picks the NIC, and *not* that the MulticastSocket will
listen on all interfaces for incoming packets
Regards,
Satya.
--- satya narayana <satya_461(a)yahoo.com> wrote:
> > Hi Bela,
> >
> > It worked for me as long as I was stopping the NIC's
> > which GMS address doesn't correspond.
> >
> > When I stopped the NIC which has the GMS Address
> > specified by the member, I see them not
> > communicating.
> >
> > If u have tried this and working for you , can you
> > tell me the properties and options which u have
> > specified to your demo ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months