[JBoss JIRA] (JBLOGGING-94) JBoss Logging does not detect log4j 2.0
by Henry Clout (JIRA)
Henry Clout created JBLOGGING-94:
------------------------------------
Summary: JBoss Logging does not detect log4j 2.0
Key: JBLOGGING-94
URL: https://issues.jboss.org/browse/JBLOGGING-94
Project: JBoss Logging
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jboss-logging-log4j
Affects Versions: 3.1.2.GA
Environment: Hibernate
Reporter: Henry Clout
Assignee: David Lloyd
The class org.jboss.logging.LoggerProviders checkes for the presence of log4j using the code:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.Hierarchy", true, cl);
return new Log4jLoggerProvider();
}
However, despite having the log4j-1.2-api-2.0.jar bridge included, this fails as the class org.apache.log4j.Hierarchy is not present in log4j 2.0.
I worked around this by forcing JBoss logging to use slf4j (which is then proxied to log4j) by setting the -Dorg.jboss.logging.provider=slf4j option.
As a proper fix, however, how about checking for a class that is included in log4j 1.2, 2.0 but not slf4j? org.apache.log4j.config.PropertySetter seems to tick the box.
I tested changing the afore mentioned method to:
private static LoggerProvider tryLog4j(final ClassLoader cl) throws ClassNotFoundException {
Class.forName("org.apache.log4j.LogManager", true, cl);
// JBLOGGING-65 - slf4j can disguise itself as log4j. Test for a class that slf4j doesn't provide.
Class.forName("org.apache.log4j.config.PropertySetter", true, cl);
return new Log4jLoggerProvider();
}
And indeed I started receiving logging messages from Hibernate (via JBoss logging.)
--
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-1609) Poor performance of TCP/TCPGOSSIP when a node fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1609?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1609.
----------------------------
Resolution: Done
Closing the issue. Feel free to reopen if the solution doesn't work for you. Since I'll release 3.3. by May 8, if you reopen it I might push it into 3.4.
> Poor performance of TCP/TCPGOSSIP when a node fails
> ---------------------------------------------------
>
> Key: JGRP-1609
> URL: https://issues.jboss.org/browse/JGRP-1609
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1, 3.3
> Environment: Linux
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> I have TCP transport with TCPGOSSIP for discovery. The exact config is same as tcp.xml but has TCPGOSSIP instead of TCPPING and MERGE3 instead of MERGE2.
> When I run Mperf with this stack on nodes A,B,C and in the middle of the test, shutdown the network interface of a node, say C, C is removed from the view after FD interval but the subsequent performance is very poor, in tens of KB rather than tens to hundrend MB.
> What I observed is that the TrasnferQueueBundler in the TP keeps trying to connect to node C for every multicast and times out.
> When I disable bundling with 3.1, the Mperf sender thread gets into the same condition for every multicast.
> Logically, once the view has changed, we want the nodes A and B to continue to perform at the same rate they were doing before the network interface for C is shutdown.
> The following stack trace shows where it is doing the connect to node C with bundling enabled.
> "TransferQueueBundler,mperf,lnx1-60691" prio=10 tid=0x00002aaab4024000 nid=0x6f77 runnable [0x00000000420f7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> - locked <0x00000000f223f0f0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at org.jgroups.util.Util.connect(Util.java:354)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(TCPConnectionMap.java:408)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:775)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:184)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:99)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1611)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:94)
> at org.jgroups.protocols.TP.doSend(TP.java:1560)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2329)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2261)
> at org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2246)
> at java.lang.Thread.run(Thread.java:662)
> The netstat also shows it keeps trying to connect to that node C (192.20.20.33)
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:53070 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:36345 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 113287 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:35389 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> With bundling disabled (had to use 3.1 version), the following stack trace shows where sender thread keeps trying to connect to node C.
> "sender-0" prio=10 tid=0x000000004cc1e800 nid=0x429 runnable [0x00002afe67973000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> - locked <0x00000000ec6046a0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jgroups.util.Util.connect(Util.java:305)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:388)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:785)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:174)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:86)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1348)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:81)
> at org.jgroups.protocols.TP.doSend(TP.java:1296)
> at org.jgroups.protocols.TP.send(TP.java:1285)
> at org.jgroups.protocols.TP.down(TP.java:1143)
> at org.jgroups.protocols.Discovery.down(Discovery.java:573)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:242)
> at org.jgroups.protocols.FD.down(FD.java:308)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:80)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:667)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:678)
> at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:459)
> at org.jgroups.protocols.UNICAST2.down(UNICAST2.java:531)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:328)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:968)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:351)
> at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:116)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:341)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:147)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:729)
> at org.jgroups.JChannel.send(JChannel.java:445)
> at org.jgroups.tests.perf.MPerf$Sender.run(MPerf.java:564)
--
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-1609) Poor performance of TCP/TCPGOSSIP when a node fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1609?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1609:
--------------------------------
I tried this, didn't use ifdown but kill -suspend or kill -3/9, and it worked. A few things though to make it work:
# Do *not* enable TCPGOSSIP.return_entire_cache
# FD's timeout will be needed to exclude C
# GossipRouter must be started with -expiry <millisecs to expiry>
You can dump the GossipRouters cache with JMX, or with "java org.jgroups.tests.RouterStubGet -cluster mperf". After expiry ms max, C's entry should be removed.
After FD kicks in (or FD_SOCK, if you CTRL-C the process), there should be a view change excluding C. After this, there should no connections be made to C any longer.
MERGE3 does contact the GossipRouter to see if there are partitions, but if -expiry is *not* defined, the entry for C will never get removed and therefore we'll tyr forever to contact C.
Let me know if this works.
> Poor performance of TCP/TCPGOSSIP when a node fails
> ---------------------------------------------------
>
> Key: JGRP-1609
> URL: https://issues.jboss.org/browse/JGRP-1609
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.1, 3.3
> Environment: Linux
> Reporter: Ramky Kandula
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> I have TCP transport with TCPGOSSIP for discovery. The exact config is same as tcp.xml but has TCPGOSSIP instead of TCPPING and MERGE3 instead of MERGE2.
> When I run Mperf with this stack on nodes A,B,C and in the middle of the test, shutdown the network interface of a node, say C, C is removed from the view after FD interval but the subsequent performance is very poor, in tens of KB rather than tens to hundrend MB.
> What I observed is that the TrasnferQueueBundler in the TP keeps trying to connect to node C for every multicast and times out.
> When I disable bundling with 3.1, the Mperf sender thread gets into the same condition for every multicast.
> Logically, once the view has changed, we want the nodes A and B to continue to perform at the same rate they were doing before the network interface for C is shutdown.
> The following stack trace shows where it is doing the connect to node C with bundling enabled.
> "TransferQueueBundler,mperf,lnx1-60691" prio=10 tid=0x00002aaab4024000 nid=0x6f77 runnable [0x00000000420f7000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> - locked <0x00000000f223f0f0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at org.jgroups.util.Util.connect(Util.java:354)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(TCPConnectionMap.java:408)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:775)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:184)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:99)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1611)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:94)
> at org.jgroups.protocols.TP.doSend(TP.java:1560)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendBundledMessages(TP.java:2329)
> at org.jgroups.protocols.TP$TransferQueueBundler.sendMessages(TP.java:2261)
> at org.jgroups.protocols.TP$TransferQueueBundler.run(TP.java:2246)
> at java.lang.Thread.run(Thread.java:662)
> The netstat also shows it keeps trying to connect to that node C (192.20.20.33)
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:53070 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:36345 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 113287 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:51724 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> [root@lnx1 ~]# netstat -an| grep 7800
> tcp 0 0 192.20.20.233:7800 0.0.0.0:* LISTEN
> tcp 0 1 192.20.20.233:35389 192.20.20.33:7800 SYN_SENT
> tcp 0 0 192.20.20.233:34237 192.20.20.133:7800 ESTABLISHED
> With bundling disabled (had to use 3.1 version), the following stack trace shows where sender thread keeps trying to connect to node C.
> "sender-0" prio=10 tid=0x000000004cc1e800 nid=0x429 runnable [0x00002afe67973000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(Unknown Source)
> - locked <0x00000000ec6046a0> (a java.net.SocksSocketImpl)
> at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
> at java.net.PlainSocketImpl.connect(Unknown Source)
> at java.net.SocksSocketImpl.connect(Unknown Source)
> at java.net.Socket.connect(Unknown Source)
> at org.jgroups.util.Util.connect(Util.java:305)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:388)
> at org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(TCPConnectionMap.java:785)
> at org.jgroups.blocks.TCPConnectionMap.send(TCPConnectionMap.java:174)
> at org.jgroups.protocols.TCP.send(TCP.java:56)
> at org.jgroups.protocols.BasicTCP.sendUnicast(BasicTCP.java:86)
> at org.jgroups.protocols.TP.sendToAllPhysicalAddresses(TP.java:1348)
> at org.jgroups.protocols.BasicTCP.sendMulticast(BasicTCP.java:81)
> at org.jgroups.protocols.TP.doSend(TP.java:1296)
> at org.jgroups.protocols.TP.send(TP.java:1285)
> at org.jgroups.protocols.TP.down(TP.java:1143)
> at org.jgroups.protocols.Discovery.down(Discovery.java:573)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:242)
> at org.jgroups.protocols.FD.down(FD.java:308)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:80)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:667)
> at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:678)
> at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:459)
> at org.jgroups.protocols.UNICAST2.down(UNICAST2.java:531)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:328)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:968)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:351)
> at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:116)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:341)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:147)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:729)
> at org.jgroups.JChannel.send(JChannel.java:445)
> at org.jgroups.tests.perf.MPerf$Sender.run(MPerf.java:564)
--
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)
[ https://issues.jboss.org/browse/JBCLUSTER-306?page=com.atlassian.jira.plu... ]
Mahesh H edited comment on JBCLUSTER-306 at 4/30/13 7:08 AM:
-------------------------------------------------------------
when a node processes requests in some cases locks
the session and never unlock it, preventing other node from processing requests
for that session. The affected node never regain the locked session and keep
throwing the following exception for all subsequent requests
May be Multi Threading Issue in Cluster
was (Author: softmahi):
when a node processes requests in some cases locks
the session and never unlock it, preventing other node from processing requests
for that session. The affected node never regain the locked session and keep
throwing the following exception for all subsequent requests
Multi Threading Issue in Cluster
> 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: Bug
> Security Level: Public(Everyone can see)
> Environment: Jboss AS 7.2.0 Final (Alpha)
> 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] (JBCLUSTER-306) Runtime Exception on jboss AS 7.2.0 Final Cluster in domain Mode
by Mahesh H (JIRA)
[ https://issues.jboss.org/browse/JBCLUSTER-306?page=com.atlassian.jira.plu... ]
Mahesh H updated JBCLUSTER-306:
-------------------------------
Issue Type: Bug (was: Feature Request)
Environment: Jboss AS 7.2.0 Final (Alfa) (was: Jboss AS 7.2.0 Final )
Forum Reference: https://issues.jboss.org/browse/AS7-4260?_sscc=t, https://bugzilla.redhat.com/show_bug.cgi?id=900204
when a node processes requests in some cases locks
the session and never unlock it, preventing other node from processing requests
for that session. The affected node never regain the locked session and keep
throwing the following exception for all subsequent requests
Multi Threading Issue in Cluster
> 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: Bug
> Security Level: Public(Everyone can see)
> Environment: Jboss AS 7.2.0 Final (Alfa)
> 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] (JBCLUSTER-306) Runtime Exception on jboss AS 7.2.0 Final Cluster in domain Mode
by Mahesh H (JIRA)
[ https://issues.jboss.org/browse/JBCLUSTER-306?page=com.atlassian.jira.plu... ]
Mahesh H updated JBCLUSTER-306:
-------------------------------
Environment: Jboss AS 7.2.0 Final (Alpha) (was: Jboss AS 7.2.0 Final (Alfa))
> 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: Bug
> Security Level: Public(Everyone can see)
> Environment: Jboss AS 7.2.0 Final (Alpha)
> 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] (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 resolved JGRP-1610.
----------------------------
Resolution: Done
> 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