[JBoss JIRA] Created: (JBAS-8154) 6.0.0.M3 doesn't start when using OpenJDK 7 b99
by Juergen Zimmermann (JIRA)
6.0.0.M3 doesn't start when using OpenJDK 7 b99
-----------------------------------------------
Key: JBAS-8154
URL: https://jira.jboss.org/browse/JBAS-8154
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.M3
Environment: OpenJDK 7 b99, JBossAS 6.0.0.M3, Windows VISTA
Reporter: Juergen Zimmermann
JBossAS 6.0.0.M3 cannot be started when using Open JDK 7 b99:
> run.bat
Calling C:\Software\jboss-6.0.0.M3\bin\run.conf.bat
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: C:\Software\jboss-6.0.0.M3
JAVA: C:\Software\Java\jdk\bin\java
JAVA_OPTS: -Dprogram.name=run.bat -Xms128M -Xmx512M -XX:MaxPermSize=256M -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -server
CLASSPATH: C:\Software\Java\jdk\lib\tools.jar;C:\Software\jboss-6.0.0.M3\bin\run.jar
===============================================================================
10:25:31,169 INFO [AbstractJBossASServerBase] Server Configuration:
JBOSS_HOME URL: file:/C:/Software/jboss-6.0.0.M3/
Bootstrap: $JBOSS_HOME\server/default/conf/bootstrap.xml
Common Base: $JBOSS_HOME\common/
Common Library: $JBOSS_HOME\common/lib/
Server Name: default
Server Base: $JBOSS_HOME\server/
Server Library: $JBOSS_HOME\server/default/lib/
Server Config: $JBOSS_HOME\server/default/conf/
Server Home: $JBOSS_HOME\server/default/
Server Data: $JBOSS_HOME\server/default/data
Server Log: $JBOSS_HOME\server/default/log/
Server Temp: $JBOSS_HOME\server/default/tmp
10:25:31,177 INFO [AbstractServer] Starting: JBossAS [6.0.0.20100429-M3 "Neo"]
10:25:31,972 ERROR [AbstractKernelController] Error installing to Configured: name=ClassLoaderDomain state=Instantiated: java.lang.RuntimeException: Error configuring property: useLoadClassForParent for ClassLoaderDomain
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:377) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2042) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1081) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1320) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1244) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1137) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:892) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:639) [jboss-dependency.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:92) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.mc.deployer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:193) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:310) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:257) [jboss-bootstrap-impl-mc.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381) [jboss-bootstrap-impl-as.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:717) [:1.7.0-ea]
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jboss.util.propertyeditor.PropertyEditors
at org.jboss.beans.info.plugins.BeanInfoUtil.<clinit>(BeanInfoUtil.java:54) [jboss-reflect.jar:2.2.0.Alpha4]
at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:77) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha9]
at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.Alpha9]
... 26 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8047) fail to deploy an ear file with JSF/Tomahawk implementation
by jay ZHAO (JIRA)
fail to deploy an ear file with JSF/Tomahawk implementation
-----------------------------------------------------------
Key: JBAS-8047
URL: https://jira.jboss.org/browse/JBAS-8047
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.M2, JBossAS-5.1.0.GA
Environment: RHEL
Reporter: jay ZHAO
I have an ear file with JFS/TomaHawk implementation, which has been deployed to GLassfish and Weblogic without any problem. But it fails to deploy to Jboss 5.1, here are the errors:
2010-05-26 08:21:06,295 WARN [org.apache.commons.digester.Digester] (ResourceContainer.invoker.nonDaemon-9) [ConverterRule]{faces-config/converter} Merge(null,java.math.BigDecimal)
2010-05-26 08:21:06,325 WARN [org.apache.commons.digester.Digester] (ResourceContainer.invoker.nonDaemon-9) [ConverterRule]{faces-config/converter} Merge(null,java.math.BigInteger)
2010-05-26 08:21:08,059 INFO [com.sun.faces.config.ConfigureListener] (ResourceContainer.invoker.nonDaemon-9) Application object verification completed successfully
2010-05-26 08:21:08,067 WARNING [javax.enterprise.resource.webcontainer.jsf.config] (ResourceContainer.invoker.nonDaemon-9) JSF1059: WARNING! The com.sun.faces.verifyObjects feature is to aid developers not using tools. It shouldn''t be enabled if using an IDE, or if this application is being deployed for production as it will impact application start times.
2010-05-26 08:21:08,421 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/StoreFront4025]] (ResourceContainer.invoker.nonDaemon-9) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:213)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:196)
at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
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 $Proxy38.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:286)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
at org.jboss.system.ServiceController.start(ServiceController.java:460)
at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
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:171)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.start(AbstractDeployHandler.java:263)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:177)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.start(StreamingDeploymentTarget.java:190)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.start(DeploymentProgressImpl.java:231)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:88)
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
at org.rhq.plugins.jbossas5.AbstractManagedDeploymentComponent.invokeOperation(AbstractManagedDeploymentComponent.java:181)
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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.InstantiationException: org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory
at java.lang.Class.newInstance0(Class.java:340)
at java.lang.Class.newInstance(Class.java:308)
at javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:537)
at javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:405)
at javax.faces.FactoryFinder.access$400(FactoryFinder.java:135)
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:717)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239)
at com.sun.faces.config.processor.FactoryConfigProcessor.verifyFactoriesExist(FactoryConfigProcessor.java:186)
at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:131)
at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:203)
... 78 more
any idea about it?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8831) hsqldb-ds.xml connection-url configuration for server mode results in null connection-url
by jaikiran pai (JIRA)
hsqldb-ds.xml connection-url configuration for server mode results in null connection-url
-----------------------------------------------------------------------------------------
Key: JBAS-8831
URL: https://issues.jboss.org/browse/JBAS-8831
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Reporter: jaikiran pai
Assignee: Ales Justin
The hsqldb-ds.xml has sections which need to be uncommented (and some commented) to enable server mode HSQL DB server. Additionally, a section in the bindings-jboss-beans.xml in JBOSS_HOME/server/<servername>/conf/bindingservice.beans needs to be uncommented too.
The part which fails is:
<connection-url>
<value-factory bean="ServiceBindingManager" method="getStringBinding">
<parameter>jboss:service=Hypersonic</parameter>
<parameter>jdbc:hsqldb:hsql://${host}:${port}</parameter>
</value-factory>
</connection-url>
The exception is:
Caused by: org.jboss.resource.JBossResourceException: connectionURL is null
at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createConnectionFactory(LocalManagedConnectionFactory.java:90) [:6.0.0.Final]
at org.jboss.resource.connectionmanager.ConnectionFactoryBindingService.createConnectionFactory(ConnectionFactoryBindingService.java:141) [:6.0.0.Final]
... 79 more
The root cause is that the code ends up calling the wrong method on ServiceBindingManger. Instead of calling the getStringBinding with 2 parameters, it ends up calling the getStringBinding with just the single (service name) parameter.
The code which parses the parameters, is in org.jboss.system.metadata.ServiceMetaDataParser:
private ServiceValueMetaData parseValueFactory(Element el) throws Exception
{
...
List<ServiceValueFactoryParameterMetaData> parameters = new ArrayList<ServiceValueFactoryParameterMetaData>();
attr = el.getAttributeNode("parameter");
if (attr != null)
{
parameters.add(new ServiceValueFactoryParameterMetaData(attr.getValue()));
}
else
{
NodeList children = el.getChildNodes();
for (int j = 0; j < children.getLength(); j++)
{
// skip over non-element nodes
if (children.item(j).getNodeType() != Node.ELEMENT_NODE)
continue;
Element child = (Element) children.item(j);
if ("parameter".equals(child.getTagName()))
{
parameters.add(parseValueFactoryParameter(child));
}
}
}
....
The code never enters the else part for that above xml configuration. I haven't looked into the details of that getAttributeNode API, but it appears like a bug to me in the xerces impl (i might be wrong), since "parameter" isn't really an attribute.
Assigning this to Ales for now, since that class lies within jboss-jmx-mc-int project.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8481) *nio
by Frank Langelage (JIRA)
*nio
----
Key: JBAS-8481
URL: https://jira.jboss.org/browse/JBAS-8481
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.M5
Environment: JBoss svn checkout on Solaris 10 using Sun JDK 1.6.0_21.
Reporter: Frank Langelage
22:00:07,984 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
22:01:02,245 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8626) QueuedPessimisticEJBLock released to early
by Judith Bürgstein (JIRA)
QueuedPessimisticEJBLock released to early
------------------------------------------
Key: JBAS-8626
URL: https://jira.jboss.org/browse/JBAS-8626
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA, JBossAS-3.2.7 Final
Reporter: Judith Bürgstein
Usecase:
All xx, xy, yy and xz are representing readonly entitybean-methods and are called on one EntityBean. CMT required and reentrant true.
The following methods are executed on the server in this order:
Thread1: calls entitybean.xx
Thread1: calls entitybean.xy
Thread2: calls entitybean.yy -> has to wait for the QueuedPessimisticEJBLock
Thread1: returns from entitybean.xy and frees the QueuedPessimisticEJBLock <--- BUG
Thread2: gets the QueuedPessimisticEJBLock but doesn't get the NonReentrantLock
Thread1: calls entitybean.xz -> has to wait for the QueuedPessimisticEJBLock and still holds the NonReentrantLock
Result: Undetected deadlock between QueuedPessimisticEJBLock and NonReentrantLock.
Our current workaround:
Created a subclass of QueuedPessimisticEJBLock and override problematic method "endInvocation":
public void endInvocation(Invocation P_mi)
{
Transaction F_tx = P_mi.getTransaction();
if (F_tx != null && F_tx.equals(getTransaction()))
{
EntityEnterpriseContext F_ctx = (EntityEnterpriseContext)P_mi.getEnterpriseContext();
if(F_ctx == null)
{
endTransaction(F_tx);
}
else if(F_ctx.hasTxSynchronization() == false)
{
NonReentrantLock F_mLock = F_ctx.getMethodLock();
if (F_mLock == null)
{
endTransaction(F_tx);
}
else
{
Object F_resourceHolder = F_mLock.getResourceHolder();
if (F_resourceHolder instanceof Thread
&& Thread.currentThread().equals(F_resourceHolder))
{
// don't end the transaction, because we still own the
// lock!
}
else if (F_resourceHolder instanceof Transaction
&& F_tx.equals(F_resourceHolder))
{
// don't end the transaction, because we still own the
// lock!
}
else
{
endTransaction(F_tx);
}
}
}
else
{
//hasTxSynchronization is true -> don't end the transaction
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] Created: (JBAS-8124) Memory Leak in JBossMQ with 2PC QueueSessions
by Rico Neubauer (JIRA)
Memory Leak in JBossMQ with 2PC QueueSessions
---------------------------------------------
Key: JBAS-8124
URL: https://jira.jboss.org/browse/JBAS-8124
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS (JBossMQ)
Affects Versions: JBossAS-4.2.3.GA
Reporter: Rico Neubauer
Assignee: Adrian Brock
JBossMQ has a memory leak, which has the same symptoms as reported for JBoss Messaging in https://jira.jboss.org/browse/JBMESSAGING-638 and discussed in http://community.jboss.org/thread/128250.
Problem is that when using a transacted QueueSession, when closing QueueSession#close invokes QueueSession#internalRollback to clean-up any unacknowledged messages, but also starts a new transaction, which is added to QueueConnection's SpyXAResourceProvider.
Since this transaction is never committed or rolled-back, it stays for the lifetime of the QueueConnection, which can be like forever when cacheing the QueueConnection. Also see "Steps to Reproduce"
Will attach MAT screenshot.
This occurs in JBossMQ of 4.2.3, but also 4.0.5 (and probably all 4.x)
I am aware of the EOL of JBoss 4.x, but will attach a proposed patch anyways.
Possible workarounds:
- Do not use transacted QueueSessions
- Close and nullify the QueueConnection from time to time to let GC clean-up the leaked objects
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months