[EJB 3.0] - EJB3 - Stale bean removal problem
by artd
I've noticed some near OOM issues on our production server that started the investigation.
I noticed that the SFSB's were being passivated accordingly, however, the stale/old beans were never removed from passivation.
Our production is using 4.2.1, and I've also verified on 4.2.2, although 4.2.2 seems to properly remove the SLSB's (or at least instruments them properly).
As with many others, we found the MaxSize in the ejb3-aop-interceptors.xml , which we reduced to 100, as well as configured the domain as such:
| <container-configuration>
| <container-name>Standard Stateful SessionBean</container-name>
| <call-logging>false</call-logging>
| <invoker-proxy-binding-name>stateful-unified-invoker</invoker-proxy-binding-name>
| <container-interceptors>
| <interceptor>org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor</interceptor>
| <interceptor>org.jboss.ejb.plugins.LogInterceptor</interceptor>
| <!-- CMT -->
| <interceptor transaction="Container">org.jboss.ejb.plugins.TxInterceptorCMT</interceptor>
| <interceptor transaction="Container">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
| <interceptor transaction="Container">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
| <!-- BMT -->
| <interceptor transaction="Bean">org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor</interceptor>
| <interceptor transaction="Bean">org.jboss.ejb.plugins.TxInterceptorBMT</interceptor>
| <interceptor transaction="Bean">org.jboss.ejb.plugins.CallValidationInterceptor</interceptor>
| <interceptor>org.jboss.resource.connectionmanager.CachedConnectionInterceptor</interceptor>
| <interceptor>org.jboss.ejb.plugins.SecurityInterceptor</interceptor>
| </container-interceptors>
| <instance-cache>org.jboss.ejb.plugins.StatefulSessionInstanceCache</instance-cache>
| <persistence-manager>org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager</persistence-manager>
| <container-cache-conf>
| <cache-policy>org.jboss.ejb.plugins.LRUStatefulContextCachePolicy</cache-policy>
| <cache-policy-conf>
| <min-capacity>5</min-capacity>
| <max-capacity>10</max-capacity>
| <remover-period>62</remover-period>
| <max-bean-life>61</max-bean-life>
| <overager-period>30</overager-period>
| <max-bean-age>60</max-bean-age>
| <resizer-period>40</resizer-period>
| <max-cache-miss-period>20</max-cache-miss-period>
| <min-cache-miss-period>1</min-cache-miss-period>
| <cache-load-factor>0.75</cache-load-factor>
| </cache-policy-conf>
| </container-cache-conf>
| <container-pool-conf>
| <MaximumSize>100</MaximumSize>
| </container-pool-conf>
| </container-configuration>
|
I've been running for over 2 hours now, and the SFSB CreateCount contionues to rise, as well as the passoviate count, however, the Remove count is never incremented (unless I explicitily call an @Remove annotated method).
Does anyone have any idea what is happening here?
The above configuration is only for testing, and doesn't reflect what we're looking for in a productin environment, I'm just not sure why the SFSB's are never removed from the passivated file store.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157810#4157810
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157810
18 years, 1 month
[Installation, Configuration & DEPLOYMENT] - Error {ProfileServiceBootstrap] Failed to load profile
by beyarecords
Hi,
I am receiving the following error messages when trying to deploy a cocoon.war. My development platform is as follows:
Jboss-5.0.0.CR1
JDK1.6.0_06
In the console the following error message is generated:
| vfsfile:/C:/Jboss/Jboss-5.0.0.CR1/server/default/deploy/cocoon.war/ -> org.jboss.deployers.spi.DeploymentException: URL vfsfile:/C:/Jboss/Jboss-5.0.0.CR1/server/default/deploy/cocoon.war/ deployment failed
|
In the server logs the following error is generated:
| 2008-06-12 20:12:35,140 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Creating ENC using ClassLoader: BaseClassLoader@1df0310{vfsfile:/C:/Jboss/jboss-5.0.0.CR1/server/default/deploy/jbossws.sar/jbossws-context.war/}
| 2008-06-12 20:12:35,171 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) Unable to retrieve orb
| javax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
| at org.jboss.mx.server.MBeanServerImpl.getAttribute(MBeanServerImpl.java:559)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment$EncListener.lifecycleEvent(TomcatDeployment.java:496)
| at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4351)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:346)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:139)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:431)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:112)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:90)
| 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:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| 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:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
| at $Proxy35.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:271)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:664)
| at org.jboss.system.ServiceController.start(ServiceController.java:436)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:150)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:108)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:991)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:257)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:135)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:544)
| at java.lang.Thread.run(Thread.java:619)
|
| ........
|
| 2008-06-12 20:12:38,375 DEBUG [org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory] (main) sql failed: CREATE TABLE QRTZ_JOB_DETAILS(JOB_NAME VARCHAR(80) NOT NULL, JOB_GROUP VARCHAR(80) NOT NULL, DESCRIPTION VARCHAR(120) NULL, JOB_CLASS_NAME VARCHAR(128) NOT NULL, IS_DURABLE VARCHAR(1) NOT NULL, IS_VOLATILE VARCHAR(1) NOT NULL, IS_STATEFUL VARCHAR(1) NOT NULL, REQUESTS_RECOVERY VARCHAR(1) NOT NULL, JOB_DATA BINARY NULL, PRIMARY KEY (JOB_NAME,JOB_GROUP))
| java.sql.SQLException: Table already exists: QRTZ_JOB_DETAILS in statement [CREATE TABLE QRTZ_JOB_DETAILS]
| at org.hsqldb.jdbc.Util.throwError(Unknown Source)
| at org.hsqldb.jdbc.jdbcPreparedStatement.execute(Unknown Source)
| at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.execute(CachedPreparedStatement.java:214)
| at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.execute(WrappedPreparedStatement.java:299)
| at org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.execute(QuartzTimerServiceFactory.java:173)
| at org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.createSchema(QuartzTimerServiceFactory.java:89)
| at org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.start(QuartzTimerServiceFactory.java:250)
| at org.jboss.ejb3.timerservice.quartz.jmx.EJB3TimerService.startService(EJB3TimerService.java:105)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
| at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
| at sun.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| 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:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189)
| at $Proxy35.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:271)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:664)
| at org.jboss.system.ServiceController.start(ServiceController.java:436)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:150)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:108)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:991)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:257)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:135)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:409)
| at org.jboss.Main.boot(Main.java:209)
| at org.jboss.Main$1.run(Main.java:544)
| at java.lang.Thread.run(Thread.java:619)
|
What is the issue here and how best to resolve it?
Many thanks in advance.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157798#4157798
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157798
18 years, 1 month
[JBoss Messaging] - Re: Clearing up confussion
by timfox
"ejb3workshop" wrote : But then it wouldn't be atomic, nor consistent or durable. What happens in this case if 3 should fail and the transaction has to be rolled back ?
|
Actually it is all three of those, and you missed the I (Isolated) ;)
In a 2pc protocol, all participants have already voted ok to prepare() by the time commit is called on them by the transaction manager.
If 3) fails then depending on why it failed, the transaction manager will kick int he recovery protocol, and retry calling commit on it until it eventually commits.
In some cases a "heuristic" outcome may be required - i.e. manually intervention to commit the branch.
But voting ok to prepare basically means "I have all the data I need to commit" so in principle I can commit.
As I say, this is all standard XA/JTA, nothing new here.
I'd suggest a look at the XA spec (it's not a fun read), but you can probably google and find lots of resources about 2PC, also recovery protocols.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157796#4157796
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157796
18 years, 1 month