[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
15 years
[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
15 years
[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
15 years
[JBoss JIRA] Created: (JBAS-8039) Failed to start a JAXWS war deployment
by jay ZHAO (JIRA)
Failed to start a JAXWS war deployment
---------------------------------------
Key: JBAS-8039
URL: https://jira.jboss.org/browse/JBAS-8039
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
We have a JAXWS war file which has been successfully deployed to GlassFish, WebSphere and WebLogic, but cannot be deployed to JBoss AS 5.1 and 6.0.0.M2. Here are the errors:
2010-05-19 10:32:09,746 ERROR [org.rhq.plugins.jbossas5.deploy.LocalDeployer] (ResourceContainer.invoker.nonDaemon-5) Error deploying application for request [CreateResourceReport: ResourceType=[ResourceType[id=0, category=Service, name=Web Application (WAR), plugin=JBossAS5]], ResourceKey=[null]].: java.lang.Exception: Failed to start deployment [vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/] during deployment of 'JAXWSDiscoveryService.war' - cause: java.lang.RuntimeException:org.jboss.deployers.spi.DeploymentException: Deployment context not found: vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/ -> : vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/
at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:146)
at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110)
at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:473)
at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295)
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:525)
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)
We are not sure what deployment context means here and what Jboss is expected. We don't have jboss-web.xml file in war file. We could not find a clear instruction on whether we need jboss-web.xml or not. Some of our war files without jboss-web.xml still can be deployed successfully, but some not. We also could not find a good instruction on how to create one if we need.
--
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
15 years
[JBoss JIRA] Created: (JBAS-8806) JBoss 6: NotSerializableException org.jboss.resource.work.JBossWorkManager
by Petr H (JIRA)
JBoss 6: NotSerializableException org.jboss.resource.work.JBossWorkManager
--------------------------------------------------------------------------
Key: JBAS-8806
URL: https://issues.jboss.org/browse/JBAS-8806
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: 6.0.0.Final
Reporter: Petr H
Assignee: Jesper Pedersen
Use of JBoss JCA WorkManager via JNDI throws java.io.NotSerializableException: org.jboss.resource.work.JBossWorkManager at JBossAS 6.0.0
Sample code (and known workaround) in the referenced forum thread.
The currently known workaround is to use more direct approach but this introduces a direct dependency on the JBoss code. As this issue affects for example Spring Framework I'm affraid such workaround isn't sufficient here.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8387) support injection for a servlet that is registered programmatically
by Marcel Kolsteren (JIRA)
support injection for a servlet that is registered programmatically
-------------------------------------------------------------------
Key: JBAS-8387
URL: https://jira.jboss.org/browse/JBAS-8387
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Weld/CDI
Affects Versions: 6.0.0.M4
Reporter: Marcel Kolsteren
Assignee: Marius Bogoevici
Injection of a CDI Managed Bean into a servlet works for servlets that are registered using web.xml, but fails for servlets that are registered using the addServlet() method of the servlet context. Supporting injection in both cases would be more consistent and more convenient for developers.
In order to demonstrate this issue, I created an Arquillian test for a managed JBoss M4 application server. The test deploys a war-file that contains two servlets. Both servlets refer to the same servlet class. The servlet class is very simple: it has a field into which a request scoped bean is injected, and it reports to the client whether or not this field contains a null value. The first servlet is defined in the web.xml file, the second servlet is registered programmatically by calling ServletContext.addServlet. The test cases show that the first servlet works as expected. However, the second servlet detects a null value in the field that should contain an injected instance of the request scoped bean. Steps for reproduction:
unpack the attached zip file
export JAVA_HOME = <home of your JDK>
export JBOSS_HOME = <root directory of your JBoss 6 M4 server>
mvn test
--
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
15 years