[JBoss JIRA] (JBWEB-293) NPE if method getClassLoader() returns null to represent the bootstrap class loader
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.... ]
Chao Wang updated JBWEB-293:
----------------------------
Attachment: (was: JBWEB-293.patch)
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
> Key: JBWEB-293
> URL: https://issues.jboss.org/browse/JBWEB-293
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-2.1.14.GA
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
> Iterator<Class<?>> iter = cache.keySet().iterator();
> while (iter.hasNext()) {
> Class<?> key = iter.next();
> BeanProperties bp = cache.get(key);
> if(bp.getType().getClassLoader().equals(classloader)){
> iter.remove();
> }
> }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties@36d4423d,
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties@2948ceea,
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties@6b0879d2,
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties@797600e3,
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties@32347561,
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties@12064d07,
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties@5bab0fcf,
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties@3b9b0e0d,
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties@40b7960d,
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties@54dc50ac,
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties@4c3477ba,
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties@8a07b6c,
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties@6006f3e0,
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties@68752860}
> {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
10 years, 10 months
[JBoss JIRA] (JBWEB-293) NPE if method getClassLoader() returns null to represent the bootstrap class loader
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/JBWEB-293?page=com.atlassian.jira.plugin.... ]
Chao Wang updated JBWEB-293:
----------------------------
Attachment: JBWEB-293.patch
> NPE if method getClassLoader() returns null to represent the bootstrap class loader
> -----------------------------------------------------------------------------------
>
> Key: JBWEB-293
> URL: https://issues.jboss.org/browse/JBWEB-293
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-2.1.14.GA
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: JBWEB-293.patch
>
>
> from the scenario in [JBPAPP-11027|https://issues.jboss.org/browse/JBPAPP-11027] , and java code in java/javax/el/BeanELResolver.java :
> {code:title=BeanELResolver.java|borderStyle=solid}
> Iterator<Class<?>> iter = cache.keySet().iterator();
> while (iter.hasNext()) {
> Class<?> key = iter.next();
> BeanProperties bp = cache.get(key);
> if(bp.getType().getClassLoader().equals(classloader)){
> iter.remove();
> }
> }
> {code}
> Here, when key is "class java.lang.Class" and bp's type is "class java.lang.Class", method getClassLoader() returns null to represent the bootstrap class loader, then NPE as described is threw during stopping service jboss.web
> {noformat}
> cache content:
> class org.jboss.on.embedded.bean.ResourceListItem=javax.el.BeanELResolver$BeanProperties@36d4423d,
> class org.jboss.on.embedded.ui.NavigationAction_$$_javassist_seam_9=javax.el.BeanELResolver$BeanProperties@2948ceea,
> class org.jboss.on.embedded.ui.ResourceAction_$$_javassist_seam_12=javax.el.BeanELResolver$BeanProperties@6b0879d2,
> class org.jboss.on.embedded.ui.nav.SubCategoryTreeNode=javax.el.BeanELResolver$BeanProperties@797600e3,
> class org.jboss.on.embedded.ui.nav.PlatformResourceTreeNode=javax.el.BeanELResolver$BeanProperties@32347561,
> class java.lang.Class=javax.el.BeanELResolver$BeanProperties@12064d07,
> class org.jboss.on.embedded.ui.nav.SingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties@5bab0fcf,
> class org.jboss.on.embedded.ui.nav.ResourceTreeNode=javax.el.BeanELResolver$BeanProperties@3b9b0e0d,
> class org.jboss.on.embedded.ui.nav.NonSingletonResourceTypeTreeNode=javax.el.BeanELResolver$BeanProperties@40b7960d,
> class org.rhq.core.domain.measurement.MeasurementDefinition=javax.el.BeanELResolver$BeanProperties@54dc50ac,
> class org.rhq.core.domain.resource.Resource=javax.el.BeanELResolver$BeanProperties@4c3477ba,
> class org.rhq.core.domain.measurement.MeasurementDataTrait=javax.el.BeanELResolver$BeanProperties@8a07b6c,
> class org.jboss.seam.security.Identity=javax.el.BeanELResolver$BeanProperties@6006f3e0,
> class org.jboss.on.embedded.bean.MeasurementDisplay=javax.el.BeanELResolver$BeanProperties@68752860}
> {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
10 years, 10 months
[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 closed JBMESSAGING-1947.
-------------------------------------
Resolution: Done
> 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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months