[JBoss JIRA] (JGRP-1617) Sync dispatcher castMessage does not awake blocked thread on ACK
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1617?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1617:
---------------------------
Fix Version/s: 3.2.9
> Sync dispatcher castMessage does not awake blocked thread on ACK
> ----------------------------------------------------------------
>
> Key: JGRP-1617
> URL: https://issues.jboss.org/browse/JGRP-1617
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Fix For: 3.2.9, 3.3
>
> Attachments: bla.java, filtered.log.bz2
>
>
> On version 3.3.0.CR1 we observed that the following code:
> {code}final RequestOptions options = RequestOptions.SYNC();
> dispatcher.castMessage( null, message, options );
> {code}
> will always block until the timeout defined in _RequestOptions_, even if the remote operation is very quick in responding.
> We could workaround the issue by setting a custom _RspFilter_, but this filter is otherwise not needed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JGRP-1610) LockingService and rpc on the same cluster, tryLock() hangs
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1610?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1610:
--------------------------------
- The attached test was added to the testsuite
- Lock granting and denying response messages are now send as OOBs
- The locking around the server lock table has been tightened
> LockingService and rpc on the same cluster, tryLock() hangs
> -----------------------------------------------------------
>
> Key: JGRP-1610
> URL: https://issues.jboss.org/browse/JGRP-1610
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
> Attachments: RpcLockingTest.java
>
>
> Hi,
> Yes, the sequence diagram only depicted the second part of my description.
> Anyway, I've attached a test file that reproduce the problem.
> It contains two test cases, one where the coordinator of the lock is the one who
> sends the message first, and a second case where the non-coordinator sends
> the message first.
> In the first case the receiver, non-coordinator, will hang in tryLock. In the second
> case though, everything works fine.
> Regards,
> Daniel Olausson
> On 25 March 2013 16:15, Bela Ban <belaban(a)yahoo.com> wrote:
> Hi Daniel,
> the sequence diagram differs from your description, can you submit a
> test case (e.g. copy MessageDispatcherRSVPTest and modify it), so I can
> take a look ?
> I assume your RPCs are blocking (sync) and non-OOB ? Could be a
> recursive invocation, where FIFO order (default) leads to a distributed
> deadlock.
> A test case would clarify what you want to do, and if I can reproduce
> the problem, I can fix it.
> On 3/25/13 1:54 PM, Daniel Olausson wrote:
> > Hi,
> >
> > We trying to use the same channel for our lockingService and
> > rpcDispatcher. But we are noticing some weird behavior.
> >
> > The end result is that lock.tryLock(lockName) never returns, which it
> > should always do.
> >
> > This happens when we do the following:
> >
> > On computer A, we lock the lock.
> > Do a rpc to a function on computer B, this function tries to take the
> > lock(lock.tryLock(lockName)), but it can't because the lock is locked.
> > This is correct behavior.
> > Computer A unlocks the lock.
> >
> > On computer B we now do the same procedure, we lock the lock and do a
> > rpc to computer A, but here is when the strange thing happens. Computer
> > A tries to take the lock by executing tryLock, but it never returns.
> >
> > Here is a sequence diagram:
> > http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQXV0aGVudGljY...
> >
> >
> > In this example we use the standard udp.xml with <CENTRAL_LOCK/> added
> > on the top of the stack. Everything works if we use PEER_LOCK but then
> > we need the messages to arrive in the same order everywhere, e.g. atomic
> > broadcast.
> >
> > It also works if we use different clusters for locking and rpc, but it
> > would be convenient if we could use the same cluster.
> >
> >
> > Is it recommended to use the same channel for different services?
> >
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JGRP-1619) Fix the OSGi manifest entries
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1619?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1619:
---------------------------
Fix Version/s: 3.4
(was: 3.3)
Pushed into 3.4. If I receive a patch by May 6 2013, I'll move this issue back to 3.3.
> Fix the OSGi manifest entries
> -----------------------------
>
> Key: JGRP-1619
> URL: https://issues.jboss.org/browse/JGRP-1619
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Markus Wolf
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> Currently the headers import the packages org.apache.log4j and org.apache.logging.log4j not optionally.
> But in the documentation it is stated, that the log framework could be chosen by the implementor.
> This is currently not the case when deploy to an osgi runtime.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBCLUSTER-306) Runtime Exception on jboss AS 7.2.0 Final Cluster in domain Mode
by Mahesh H (JIRA)
Mahesh H created JBCLUSTER-306:
----------------------------------
Summary: Runtime Exception on jboss AS 7.2.0 Final Cluster in domain Mode
Key: JBCLUSTER-306
URL: https://issues.jboss.org/browse/JBCLUSTER-306
Project: JBoss Clustering
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Environment: Jboss AS 7.2.0 Final
Reporter: Mahesh H
Assignee: Paul Ferraro
Hi,
i am running load test on domain cluster . There are two nodes on which i am running load test faceing Runtime Exception ... Below is the stacktrace.
[Server:server-three] 23:23:38,944 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-2) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
[Server:server-three] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010213: Cannot acquire lock default-host/onebill/Ph-o7voM40LQY7VPJZCZBvEe from cluster
[Server:server-three] at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
[Server:server-three] at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:392)
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:523) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:495) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] ... 11 more
[Server:server-three]
[Server:server-three] 23:24:08,952 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-1) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
[Server:server-three] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010213: Cannot acquire lock default-host/onebill/Ph-o7voM40LQY7VPJZCZBvEe from cluster
[Server:server-three] at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
[Server:server-three] at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:392)
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:523) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:495) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] ... 11 more
[Server:server-three]
[Server:server-three] 23:24:38,967 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-2) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
[Server:server-three] at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
[Server:server-three] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from POST to MODIFIED
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years