[JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen when JBM shuts down a JGroups channel
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.... ]
Yong Hao Gao reopened JBMESSAGING-1947:
---------------------------------------
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
> Key: JBMESSAGING-1947
> URL: https://issues.jboss.org/browse/JBMESSAGING-1947
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: JMS Clustering
> Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
> Reporter: Yong Hao Gao
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
> "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
> ...
> at org.jgroups.util.Promise.getResult(Promise.java:77)
> at org.jgroups.JChannel.disconnect(JChannel.java:473)
> ...
> at org.jgroups.JChannel.close(JChannel.java:498)
> at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
> ...
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
> - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view. (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
> "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
> - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
> at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
> at org.jgroups.JChannel.up(JChannel.java:1090)
> ...
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
> - locked <0x00000000e290d740> (a org.jgroups.Membership)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
> ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
> "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
> - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
> at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
> at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
> at java.lang.Thread.run(Thread.java:662)"
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen when JBM shuts down a JGroups channel
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1947:
--------------------------------------
Issue Type: Bug (was: Feature Request)
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
> Key: JBMESSAGING-1947
> URL: https://issues.jboss.org/browse/JBMESSAGING-1947
> Project: JBoss Messaging
> Issue Type: Bug
> Components: JMS Clustering
> Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
> Reporter: Yong Hao Gao
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
> "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
> ...
> at org.jgroups.util.Promise.getResult(Promise.java:77)
> at org.jgroups.JChannel.disconnect(JChannel.java:473)
> ...
> at org.jgroups.JChannel.close(JChannel.java:498)
> at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
> ...
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
> - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view. (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
> "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
> - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
> at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
> at org.jgroups.JChannel.up(JChannel.java:1090)
> ...
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
> - locked <0x00000000e290d740> (a org.jgroups.Membership)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
> ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
> "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
> - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
> at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
> at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
> at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
> at java.lang.Thread.run(Thread.java:662)"
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1490) BridgeService should be JAAS aware
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1490?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1490:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> BridgeService should be JAAS aware
> ----------------------------------
>
> Key: JBMESSAGING-1490
> URL: https://issues.jboss.org/browse/JBMESSAGING-1490
> Project: JBoss Messaging
> Issue Type: Feature Request
> Affects Versions: 1.4.2.GA
> Environment: n/a
> Reporter: Nicholas Sayer
> Assignee: Yong Hao Gao
> Priority: Optional
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
> <application-policy name = "JmsBridgeRealm">
> <authentication>
> <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
> <module-option name = "principal">${bridge.user}</module-option>
> <module-option name = "userName">${bridge.user}</module-option>
> <module-option name = "password">${bridge.encryptedPassword}</module-option>
> <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
> <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
> </login-module>
> </authentication>
> </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
> private String sourceContext, targetContext;
> public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
> public String getSourceLoginContext() { return this.sourceContext; }
> public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
> public String getTargetLoginContext() { return this.targetContext; }
> public void start() throws Exception {
> setupSourceCredentials();
> setupTargetCredentials();
> super.start();
> }
> private void setupSourceCredentials() throws LoginException {
> PasswordCredential pc = getPasswordCredential(this.sourceContext);
> super.setSourceUsername(pc.getUserName());
> super.setSourcePassword(new String(pc.getPassword()));
> }
> private void setupTargetCredentials() throws LoginException {
> PasswordCredential pc = getPasswordCredential(this.targetContext);
> super.setTargetUsername(pc.getUserName());
> super.setTargetPassword(new String(pc.getPassword()));
> }
> private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
> LoginContext ctx = new LoginContext(contextName);
> ctx.login();
> Subject s = ctx.getSubject();
> Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
> if (creds.isEmpty())
> throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
> return creds.iterator().next(); // get 1st
> }
> }
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1478) inconsistent test suite performance
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1478?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1478:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> inconsistent test suite performance
> -----------------------------------
>
> Key: JBMESSAGING-1478
> URL: https://issues.jboss.org/browse/JBMESSAGING-1478
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Tests and Performance
> Affects Versions: 1.4.0.SP3.CP04
> Reporter: Aleksandar Kostadinov
> Assignee: Yong Hao Gao
> Labels: isolation, performance, testsuite
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit.
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1287) SOA-P test suite failures
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1287?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1287:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> SOA-P test suite failures
> -------------------------
>
> Key: JBMESSAGING-1287
> URL: https://issues.jboss.org/browse/JBMESSAGING-1287
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.0.SP3_CP01
> Reporter: Aleksandar Kostadinov
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures.
> * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
> * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
> * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
> * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73...
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue.
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1401) Unverified: Restarting a Queue will delete persistent messages in the queue.
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1401?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1401:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
> Key: JBMESSAGING-1401
> URL: https://issues.jboss.org/browse/JBMESSAGING-1401
> Project: JBoss Messaging
> Issue Type: Bug
> Components: Configuration and Management
> Affects Versions: 1.4.0.SP3
> Reporter: Jay Howell
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
>
> Restarting a queue in a running server will delete persistent messages out of the database. This bug was found while troubleshooting a case. When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone. I have yet to verify this and will verify as soon as possible. I wanted to make sure that I didn't forget to put it in. So at this point this is an unverified bug.
--
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
12 years, 1 month
[JBoss JIRA] (JBMESSAGING-1491) add support for Ingres RDBMS to JBoss Messaging
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1491?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1491:
--------------------------------------
Fix Version/s: 1.4.8.SP11
(was: 1.4.8.SP10)
> add support for Ingres RDBMS to JBoss Messaging
> -----------------------------------------------
>
> Key: JBMESSAGING-1491
> URL: https://issues.jboss.org/browse/JBMESSAGING-1491
> Project: JBoss Messaging
> Issue Type: Patch
> Affects Versions: 1.4.0.SP3.CP06, 2.0.0 Beta1, EAP/SOA-P Integration, 1.4.3.GA, Unscheduled, AS 5.0 Integration
> Environment: N/A
> Reporter: murray armfield
> Assignee: Yong Hao Gao
> Priority: Minor
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP11
>
> Attachments: ingres-persistence-service.newrev.xml, ingres-persistence-service.xml, ingres-persistence-service.xml, ingres.diff, ingresv2.diff
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> I've been working on JBoss support on Ingres.
> I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging
--
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
12 years, 1 month