[JBoss JIRA] (AS7-4882) CLONE - Remote EJB clients hanging after EJBClient.createSession when using DIST
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4882:
-----------------------------------
Summary: CLONE - Remote EJB clients hanging after EJBClient.createSession when using DIST
Key: AS7-4882
URL: https://issues.jboss.org/browse/AS7-4882
Project: Application Server 7
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 7.1.2.Final (EAP)
Reporter: Radoslav Husar
Assignee: jaikiran pai
Priority: Critical
Fix For: 7.1.3.Final (EAP)
We are seeing that in stress tests (positive test, no failures), the clients hang when using DIST mode; both SYNC and ASYNC.
The clients hang in method [1]; there is nothing suspicious on the server side. [2]
The client has no knowledge about repl/dist topology, thus this should be a server-side issue.
As of filing, we are investigating the issue.
Job
https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Performance-Cluste...
Client code
https://svn.devel.redhat.com/repos/jboss-qa/load-testing/sf-components/pr...
App code
https://github.com/rhusar/clusterbench
[1]
{noformat}
"Runner - 1279" daemon prio=10 tid=0x00007f4388950000 nid=0x73df in Object.wait() [0x00007f423ed29000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at org.xnio.AbstractIoFuture.awaitInterruptibly(AbstractIoFuture.java:123)
- locked <0x00000006c0285ad0> (a java.lang.Object)
at org.jboss.ejb.client.remoting.IoFutureHelper$1.get(IoFutureHelper.java:57)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.openSession(RemotingConnectionEJBReceiver.java:236)
at org.jboss.ejb.client.EJBClient.createSession(EJBClient.java:163)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:135)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.initSession(StatefulSBProcessorFactoryImpl.java:148)
at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:58)
at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:51)
at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
at java.lang.Thread.run(Thread.java:662)
{noformat}
[1]
{noformat}
"EJB default - 10" prio=10 tid=0x00007fefcc059000 nid=0x308b waiting on condition [0x00007fefa7a33000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000006bfe65cc8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4721) CLONE - Jms client can't authenticate to messaging subsystem
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/AS7-4721?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak closed AS7-4721.
-------------------------------
Brilliant! Authentication is ok and works as expected.
> CLONE - Jms client can't authenticate to messaging subsystem
> ------------------------------------------------------------
>
> Key: AS7-4721
> URL: https://issues.jboss.org/browse/AS7-4721
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS, Security
> Affects Versions: 7.1.1.Final
> Reporter: Miroslav Novak
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 7.1.2.Final (EAP)
>
>
> Jms client can't authenticate to messaging subsystem. I've prepared reproducer for EAP 6 ER6 but this issue is also in AS7 master.
> Exception:
> {code}
> Exception in thread "main" javax.jms.JMSSecurityException: Unable to validate user: admin
> at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:312)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:781)
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:280)
> at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:601)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:684)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:119)
> at testjndi.SecurityClient.getConnection(SecurityClient.java:308)
> at testjndi.SecurityClient.initializeClient(SecurityClient.java:83)
> at testjndi.SecurityClient.main(SecurityClient.java:363)
> Caused by: HornetQException[errorCode=105 message=Unable to validate user: admin]
> ... 9 more
> {code}
> Steps to reproduce:
> 1. Download and unzip EAP 6 ER6 - http://download.devel.redhat.com/devel/candidates/JBEAP/JBEAP-6.0.0-ER6/j...
> 2. Using add-user.sh create user to application realm - for example with username: admin, password:adminadmin, role:guest
> 3. Unzip attached reproducer.zip and copy standalone-full-ha.xml to $JBOSS_HOME/stanalone/configuration
> 4. Start server
> 5. Start jms client in reproducer - sh start-client.sh 127.0.0.1 jms/queue/testQueue0 admin adminadmin (parameters are hostname queueJndiName username password)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4309) EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4309:
-----------------------------------
Summary: EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='node-1', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='127.0.0.1', destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from the same machine as the server. As a result the "silent auth" mechanism as explained "Local clients" section of this doc [1] comes into picture. The EJB client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto connection to a node in the cluster is because the EJB client API implementation is missing this piece of configuration which enables "silent auth" for cluster nodes. We need to fix that to make it consistent with how we handle non-cluster node connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4185) Impossible to use "reload" MDR operation in testsuite run
by Vladimir Rastseluev (JIRA)
Vladimir Rastseluev created AS7-4185:
----------------------------------------
Summary: Impossible to use "reload" MDR operation in testsuite run
Key: AS7-4185
URL: https://issues.jboss.org/browse/AS7-4185
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: Vladimir Rastseluev
Fix For: 7.1.2.Final
Writing test, using Arquillian, that needs server reloading (e.g.for changing server configuration).
Test successfully pass, when runs alone.
If it runs in testsuite, it can pass or not, but tests,next to it, fail with this exception:
org.jboss.remoting3.NotOpenException: Writes closed
at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
at org.jboss.remotingjmx.protocol.v1.Common.write(Common.java:177)
at org.jboss.remotingjmx.protocol.v1.ClientConnection$TheConnection.addNotificationListener(ClientConnection.java:1298)
at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:65)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:57)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JBCLUSTER-299) New node cannot enter the cluster during a failover.
by Terrence Cowhey (JIRA)
Terrence Cowhey created JBCLUSTER-299:
-----------------------------------------
Summary: New node cannot enter the cluster during a failover.
Key: JBCLUSTER-299
URL: https://issues.jboss.org/browse/JBCLUSTER-299
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Terrence Cowhey
Assignee: Paul Ferraro
The setup is a cluster of 4 nodes, arranged into 2 'sites':
Primary Site: site2blade1, site2blade2
Secondary Site: site2blade3, site2blade4
After restarting the nodes of the secondary site many times, one of them fails to come up, with a deployment failure in JMS - the PostOffice fails with an IllegalStateException.
The previous restarts were induced by either 'kill -KILL' on the app server, or a graceful shutdown. The final (failed) restart was on site2blade4, and was induced by a graceful shutdown of the app server.
The IllegalStateException is being thrown during a failover while a new node is starting to join the cluster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month