[JBoss JIRA] Created: (JBAS-3865) Recursive loop on shutdown
by Scott M Stark (JIRA)
Recursive loop on shutdown
--------------------------
Key: JBAS-3865
URL: http://jira.jboss.com/jira/browse/JBAS-3865
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: MicroContainer bus
Reporter: Scott M Stark
Assigned To: Adrian Brock
Fix For: JBossAS-5.0.0.Beta2
When shutting down the server mid startup after an error I have seen the server get into a state where it loops on this type of error:
09:29:21,803 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
09:29:21,906 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
09:29:21,906 ERROR [AbstractKernelController] INTERNAL ERROR: context not found in previous state Installed context=name=EJB3EntityCacheConfig state=Installedjava.lang.Exception: STACKTRACE
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:638)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:613)
at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:664)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
at org.jboss.system.ServiceController.doChange(ServiceController.java:656)
at org.jboss.system.ServiceController.stop(ServiceController.java:481)
at org.jboss.system.deployers.ServiceDeployer.stop(ServiceDeployer.java:131)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:111)
at org.jboss.system.deployers.ServiceDeployer.undeploy(ServiceDeployer.java:44)
at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.undeploy(AbstractSimpleRealDeployer.java:60)
at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.prepareUndeploy(AbstractSimpleDeployer.java:42)
at org.jboss.deployers.plugins.deployer.DeployerWrapper.prepareUndeploy(DeployerWrapper.java:105)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:419)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.prepareUndeploy(MainDeployerImpl.java:428)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:357)
at org.jboss.deployers.plugins.deployment.MainDeployerImpl.shutdown(MainDeployerImpl.java:482)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:739)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:721)
at org.jboss.system.server.profileservice.ServerImpl$ShutdownHook.run(ServerImpl.java:706)
A kill -9 is required to stop it after this.
--
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, 3 months
[JBoss JIRA] Created: (JBAS-3824) Fix environment context for EJB2.1 and Servlets
by Thomas Diesler (JIRA)
Fix environment context for EJB2.1 and Servlets
-----------------------------------------------
Key: JBAS-3824
URL: http://jira.jboss.com/jira/browse/JBAS-3824
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
Fix For: JBossAS-5.0.0.CR1
/home/tdiesler/svn/jbossws/trunk/src/test
[tdiesler@tdvaio test]$ ant -Dtest=jaxrpc/enventry test
tests-main:
[junit] Running org.jboss.test.ws.jaxrpc.enventry.EnvEntryEJBTestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.982 sec
[junit] Test org.jboss.test.ws.jaxrpc.enventry.EnvEntryEJBTestCase FAILED
[junit] Running org.jboss.test.ws.jaxrpc.enventry.EnvEntryJSETestCase
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 3 sec
[junit] Test org.jboss.test.ws.jaxrpc.enventry.EnvEntryJSETestCase FAILED
--
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, 3 months
[JBoss JIRA] Created: (JBCACHE-784) "Random" TimeoutException occurs after CacheLoader get() returns
by James Hickey (JIRA)
"Random" TimeoutException occurs after CacheLoader get() returns
----------------------------------------------------------------
Key: JBCACHE-784
URL: http://jira.jboss.com/jira/browse/JBCACHE-784
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1 instances (pessimistic locking), no eviction policy
Reporter: James Hickey
Assigned To: Manik Surtani
We experience a strange issue which happens every so often whereby shortly after one of our replicated cache instances calls it's CacheLoader.get() to populate a particular FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the scenario/stack trace follows:
The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's get() method successfully returns (can see this as we have debugging in the cache loader). Subsequent calls are instantaneously successful and do not result in a further call to the cacheloader.
It looks to me like it could possibly be some kind of tx/locking/thread contention issue, as it happens more often than not where we have approx 10-20 threads which have all resulted in a call to the cache loader in a short space of time.
Any advice/opinion would be appreciated
Thanks
James
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted@10e4fd3)
at org.jboss.cache.Node.acquire(Node.java:407)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
at org.jboss.cache.TreeCache.get(TreeCache.java:3453)
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-541) Avoid WeakHashmap for tracking working memories in a RuleBase.
by Michael Neale (JIRA)
Avoid WeakHashmap for tracking working memories in a RuleBase.
--------------------------------------------------------------
Key: JBRULES-541
URL: http://jira.jboss.com/jira/browse/JBRULES-541
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rule Assemply/SPI
Affects Versions: 3.0.4
Reporter: Michael Neale
Assigned To: Mark Proctor
Priority: Critical
This comes under the heading of "I knew it would happen one day and I warned people about it but they didn't listen and Michael is always right in the long run, except when he predicted that the graphical web browser would NOT take off back in 1993 and was catastrophically wrong.
Someone was having issues with concurrency (5 concurrent threads, but heavy load) and creating a newWorkingMemory - there are hangs/lock issues with the weak hashmap that points from the Single rule base to the spawned working memories. This is not surprising, blah blah blah....
Anyway, one possible solution is to have a call where users who *want* to update an existing long lived working memory changes, pass in the WM to the rulebase, with say "refresh rules" - ie the methods like removeRule() on a rule base, require a working memory to be passed in.
We can still keep the old WeakHashMap, just make it non default behaviour (it cannot scale the way it is now - with the default behaviour in my opinion).
STACK trace follows:
I'm using Java 1.5_09 on Linux. The app uses 5 simultaneous threads at
the moment. They never share WorkingMemory instances but do share the
same RuleBase.
A thread dump (see below) shows all threads being stuck in
java.util.WeakHashMap, which is called from
AbstractRuleBase.addWorkingMemory.
Has anyone seen this before? I attempted to synchronize the method
that's the entry point to newWorkingMemory(). That definitely made the
problem happen less often but didn't solve it completely. Anyone knows
any other workarounds?
Thanks,
Per
"CW4" prio=1 tid=0x1a4fd7a8 nid=0xc44 runnable [0x1a2fe000..0x1a2fefb0]
at
java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
at java.util.WeakHashMap.put(WeakHashMap.java:394)
at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
Source)
at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
Source)
at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
Source)
"CW3" prio=1 tid=0x1a4fd5f0 nid=0xc43 runnable [0x1a6fe000..0x1a6fee30]
at java.util.WeakHashMap.put(WeakHashMap.java:397)
at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
Source)
at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
Source)
at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
Source)
"CW2" prio=1 tid=0x1a4fd100 nid=0xc42 runnable [0x1a8e5000..0x1a8e5eb0]
at
java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
at java.util.WeakHashMap.put(WeakHashMap.java:394)
at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
Source)
at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
Source)
at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
Source)
"CW1" prio=1 tid=0x19afca78 nid=0xc41 runnable [0x1a966000..0x1a967130]
at
java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
at java.util.WeakHashMap.put(WeakHashMap.java:394)
at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
Source)
at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
Source)
at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
Source)
at
"CW0" prio=1 tid=0x19afc7d8 nid=0xc40 runnable [0x1aafe000..0x1aaff1b0]
at
java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
at java.util.WeakHashMap.put(WeakHashMap.java:394)
at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
Source)
at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
Source)
at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
Source)
at
--
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, 3 months