[JBoss JIRA] Created: (JBREM-1297) Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners
by Artur Karpinski (JIRA)
Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners
-----------------------------------------------------------------------------------
Key: JBREM-1297
URL: https://issues.jboss.org/browse/JBREM-1297
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.5.4.SP2
Reporter: Artur Karpinski
Priority: Critical
Deadlock is probably caused by changes introduced in this fix: JBREM-1242.
Thread A:
1. MicroRemoteClientInvoker.terminateLease, locks clientLeaseLock
2. Client.notifyListeners, locks connectionValidatorLock
Thread B:
1. Client.setupClientLease, locks connectionValidatorLock
2. MicroRemoteClientInvoker.establishLease, locks connectionValidatorLock
Please check stacktraces when this deadlock occurred:
{code}
"Timer-16" - Thread t@486453
java.lang.Thread.State: BLOCKED
at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
- waiting to lock <747c39d3> (a java.lang.Object) owned by "WorkManager(2)-241" t@6121
at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
- locked <751714e> (a java.lang.Object)
at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
{code}
and
{code}
"WorkManager(2)-241" - Thread t@6121
java.lang.Thread.State: BLOCKED
at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
- waiting to lock <751714e> (a java.lang.Object) owned by "Timer-16" t@486453
at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
- locked <747c39d3> (a java.lang.Object)
at org.jboss.remoting.Client.connect(Client.java:1918)
at org.jboss.remoting.Client.connect(Client.java:737)
{code}
One way to fix this would be to add lock on connectionValidatorLock in MicroRemoteClientInvoker.terminateLease. I'm trying to analyse code to check if this fix will not introduce another deadlock problem.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (AS7-3175) NPE when using xa datasource with recovery
by Stuart Douglas (Created) (JIRA)
NPE when using xa datasource with recovery
------------------------------------------
Key: AS7-3175
URL: https://issues.jboss.org/browse/AS7-3175
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.0.CR1b
Reporter: Stuart Douglas
Assignee: Jesper Pedersen
Fix For: 7.1.0.Final
IF you add the <recovery> tag to an XA datasource server startup will fail with an NPE:
{code}
07:34:29,840 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-10) Error during the deployment of java:jboss/datasources/H2XADS: java.lang.NullPointerException
at org.jboss.jca.deployers.common.AbstractDsDeployer.deployXADataSource(AbstractDsDeployer.java:739)
at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:339)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:271)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:111)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_29]
{code}
The line in question has:
{code}
if (recoveryMD == null || !recoveryMD.getNoRecovery())
{code}
The issue is recoveryMD.getNoRecovery() is returning null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (AS7-3170) JMS configuration disappears from configuration xml after being rewritten by JBoss
by Alex Krasov (Created) (JIRA)
JMS configuration disappears from configuration xml after being rewritten by JBoss
----------------------------------------------------------------------------------
Key: AS7-3170
URL: https://issues.jboss.org/browse/AS7-3170
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.0.CR1b
Environment: Windows7 x64, JBoss AS 7.1.0CR1b
Reporter: Alex Krasov
Assignee: Clebert Suconic
I have 2 JMS queues defined at standalone-full.xml. JBoss recognized them on first run and everything seems to be ok, but it rewrites standalone.xml without queues definition, i.e. completely ommiting the <jms-destinations> element, so after jboss restart queues don't exist anymore.
This happens on the first standalone-full.xml rewrite (i.e. after something have been deployed, etc.)
This bug is a regression, beta1 and earlier worked just fine.
Please see forum thread for detailed discussion, more users' reports and example standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
by Stuart Douglas (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas commented on AS7-3162:
-------------------------------------
I don't think this is a valid deployment. According to the spec:
{code}
• If an Application subclass is present that is not being handled by an existing servlet then the servlet added by the ContainerInitializer MUST be named with the fully qualified name of the Application subclass. If the Application subclass is annotated with @ApplicationPath and no servlet-mapping exists for the added servlet then a new servlet mapping is added with the value of the @ApplicationPath annotation with ”/*” appended otherwise the existing mapping is used. If the Application subclass is not annotated with @ApplicationPath then the application MUST be packaged with a web.xml that specifies a servlet mapping for the added servlet. It is an error for more than one application to be deployed at the same effective servlet mapping
{code}
Basically the presence of an Application class on the CP changes the way that the deployment is handled. I think that we should probably just provide a more meaningful error message in this case.
> RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3162
> URL: https://issues.jboss.org/browse/AS7-3162
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> I've deployment like this:
> {code}
> @Deployment
> public static Archive<?> deploy() {
> WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war");
> war.addPackage(HttpRequest.class.getPackage());
> war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class);
> war.addAsWebInfResource(
> WebXml.get("<servlet-mapping>\n"
> + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n"
> + " <url-pattern>/myjaxrs/*</url-pattern>\n"
> + "</servlet-mapping>\n" + "\n"), "web.xml");
> return war;
> }
> {code}
> This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application"
> ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like:
> {code}
> public class ApplicationInvalid1 extends Application {
> private Set<Class<?>> classes = new HashSet<Class<?>>();
> public ApplicationInvalid1() {
> }
> @Override
> public Set<Class<?>> getClasses() {
> return classes;
> }
> }
> {code}
> There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (AS7-3007) Incorrect parsing of complex resource-adapters subsystem configuration
by Vladimir Rastseluev (Created) (JIRA)
Incorrect parsing of complex resource-adapters subsystem configuration
----------------------------------------------------------------------
Key: AS7-3007
URL: https://issues.jboss.org/browse/AS7-3007
Project: Application Server 7
Issue Type: Bug
Reporter: Vladimir Rastseluev
Assignee: Stefano Maestri
Fix For: 7.1.0.Final
There are many errors in parsing complex XML configuration of resource-adapters subsystem:
1)elements <bean-validation-groups> and <recovery> not proceeded at all (with all the sub-elements) - IllegalArgumentException is thrown
2)elements <prefill>,<is-same-rm-override>,<no-tx-separate-pools>,<interleaving>,<pad-xid>,<wrap-xa-resource>,<bootstrap-context>,<application> don't pass to the model - error in description
3)after parsing there is an <use-try-lock> element in model, which is not in XSD schema.
Properties are tested here:
https://github.com/vratsel/jboss-as/commit/17f8344a6966b9a49dd327e7118f23...
To reproduce this issue, try to uncomment any line in ra.xml file or in ComplexResourceAdaptersSubsystemTestCase.java
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (AS7-3018) NotSerializableException org.jboss.as.clustering.SimpleMarshalledValue expected to be marshallable on injecting @Clustered @Local @Stateful bean
by Radoslav Husar (Created) (JIRA)
NotSerializableException org.jboss.as.clustering.SimpleMarshalledValue expected to be marshallable on injecting @Clustered @Local @Stateful bean
------------------------------------------------------------------------------------------------------------------------------------------------
Key: AS7-3018
URL: https://issues.jboss.org/browse/AS7-3018
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld, Clustering
Affects Versions: No Release
Environment: d9e236d24eebe271373feb607e634eea6182b74e
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Priority: Blocker
Fix For: 7.1.0.CR1
Hi Paul, this one slipped in after the SFSB EJB3 pull request overnight:
{noformat}
[JBossINF] 07:50:09,331 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/clusterbench].[LocalEjbServlet]] (ajp-perf20-10.16.90.58-8009-121) Servlet.service() for servlet LocalEjbServlet threw exception: org.jboss.weld.exceptions.CreationException: WELD-000079 Could not find the EJB in JNDI: class org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$Proxy$
[JBossINF] at org.jboss.weld.bean.SessionBean.create(SessionBean.java:305) [weld-core-1.1.4.Final.jar:]
[JBossINF] at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107) [weld-core-1.1.4.Final.jar:]
[JBossINF] at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90) [weld-core-1.1.4.Final.jar:]
[JBossINF] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79) [weld-core-1.1.4.Final.jar:]
[JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(LocalStatefulSB$Proxy$_$$_WeldClientProxy.java) [clusterbench-ee6-ejb.jar:]
[JBossINF] at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:22) [classes:]
[JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:]
[JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:]
[JBossINF] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:]
[JBossINF] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
[JBossINF] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:123) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.CR1-SNAPSHOT.jar:]
[JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:445) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.5.Final.jar:]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
[JBossINF] Caused by: org.infinispan.marshall.NotSerializableException: Object of type class org.jboss.as.clustering.SimpleMarshalledValue expected to be marshallable
{noformat}
https://github.com/rhusar/clusterbench/blob/master/clusterbench-ee6-ejb/s...
https://github.com/rhusar/clusterbench/blob/master/clusterbench-ee6-web/s...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months