[JBoss JIRA] (WFWIP-12) [Artemis upgrade] Output of CLI operations in messaging subsystem's server changed from 7.1
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-12?page=com.atlassian.jira.plugin.s... ]
Erich Duda commented on WFWIP-12:
---------------------------------
CC [~ehugonnet] Can you please take care of integration part?
> [Artemis upgrade] Output of CLI operations in messaging subsystem's server changed from 7.1
> -------------------------------------------------------------------------------------------
>
> Key: WFWIP-12
> URL: https://issues.jboss.org/browse/WFWIP-12
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Original Estimate: 2 hours
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Output of CLI operations in messaging subsystem's server element changed and it is is missing some attributes it used to display in EAP 7.1.
> _Affected operations_
> *list-all-consumers-as-json* and *list-consumers-as-json*
> Missing attributes
> * destinationName
> * destinationType
> * durable
> {noformat:title="7.1.0.GA"}
> Result list-all-consumers-as-json{"outcome" => "success","result" => "[{\"consumerID\":0,\"connectionID\":\"-733935378\",\"sessionID\":\"fede1b60-04e9-11e8-9641-cc3d825a3be2\",\"queueName\":\"testSubscriberClientId-hornetqCliOperations.testSubscriber-hqServerCliOperations\",\"browseOnly\":false,\"creationTime\":1517226368495,\"destinationName\":\"testTopic\",\"destinationType\":\"topic\",\"durable\":true}]"}
> {noformat}
> {noformat:title="Wildfly latest with artemis 2.x"}
> Result list-all-consumers-as-json{"outcome" => "success","result" => "[{\"consumerID\":0,\"connectionID\":\"784f1287\",\"sessionID\":\"f146b48e-04e3-11e8-bb50-cc3d825a3be2\",\"queueName\":\"jms.queue.testQueue\",\"browseOnly\":false,\"creationTime\":1517223768695,\"deliveringCount\":8}]"}
> {noformat}
> *list-connections-as-json*
> Missing attributes
> * clientID
> {noformat:title="7.1.0.GA"}
> "result" => "[{\"connectionID\":\"1343044951\",\"clientAddress\":\"/127.0.0.1:57038\",\"creationTime\":1517303830995,\"clientID\":\"testSubscriberClientId-hornetqCliOperations\"},{\"connectionID\":\"2052915500\",\"clientAddress\":\"/127.0.0.1:57040\",\"creationTime\":1517303831216},{\"connectionID\":\"668896556\",\"clientAddress\":\"/127.0.0.1:57042\",\"creationTime\":1517303831210},{\"connectionID\":\"2096792561\",\"clientAddress\":\"/127.0.0.1:57044\",\"creationTime\":1517303831223,\"clientID\":\"testPublisherClientId\"}]"
> {noformat}
> {noformat:title="Wildfly latest with artemis 2.x"}
> "result" => "[{\"connectionID\":\"a8842f44\",\"clientAddress\":\"/127.0.0.1:55938\",\"creationTime\":1517298838294,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"c515bc06\",\"clientAddress\":\"/127.0.0.1:55936\",\"creationTime\":1517298837454,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":0},{\"connectionID\":\"b9a9153f-0592-11e8-80ff-54ee7547c83e\",\"clientAddress\":\"invm:0\",\"creationTime\":1517298837312,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":0},{\"connectionID\":\"fe42578a\",\"clientAddress\":\"/127.0.0.1:55944\",\"creationTime\":1517298838495,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"cde89186\",\"clientAddress\":\"/127.0.0.1:55940\",\"creationTime\":1517298838493,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2},{\"connectionID\":\"480099e7\",\"clientAddress\":\"/127.0.0.1:55942\",\"creationTime\":1517298838495,\"implementation\":\"RemotingConnectionImpl\",\"sessionCount\":2}]"
> {noformat}
> This is compatibility issue, as some scripts may depend on missing attributes. Customer's tooling which used to work with 7.1 may not work now.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1646) FIPS PKCS11 breaks after migrating from client scheme 1.0 to 1.1
by Martin Choma (JIRA)
Martin Choma created ELY-1646:
---------------------------------
Summary: FIPS PKCS11 breaks after migrating from client scheme 1.0 to 1.1
Key: ELY-1646
URL: https://issues.jboss.org/browse/ELY-1646
Project: WildFly Elytron
Issue Type: Bug
Components: Authentication Client
Affects Versions: 1.5.5.Final
Reporter: Martin Choma
Priority: Blocker
I have working configuration
{code}
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<key-stores>
<key-store name="truststore" type="PKCS11">
<key-store-clear-password password="${password}" />
</key-store>
</key-stores>
<ssl-contexts>
<ssl-context name="client-cli-context">
<trust-store key-store-name="truststore" />
<cipher-suite selector="${cipher.suite.filter}" />
<protocol names="${protocol}" />
</ssl-context>
</ssl-contexts>
<ssl-context-rules>
<rule use-ssl-context="client-cli-context" />
</ssl-context-rules>
</authentication-client>
</configuration>
{code}
After migrating to urn:elytron:1.1 error occurs.
{code}
10:44:07,823 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
at org.jboss.modules.Module.run(Module.java:352)
at org.jboss.modules.Module.run(Module.java:320)
at org.jboss.modules.Main.main(Main.java:593)
Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
... 5 more
Caused by: java.io.IOException: Failed to obtain SSLContext
at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
... 8 more
Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used
at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:115)
at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:78)
at javax.net.ssl.SSLContext.init(SSLContext.java:282)
at org.jboss.as.cli.impl.CommandContextImpl.createSslContext(CommandContextImpl.java:715)
at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
... 10 more
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-83) [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFWIP-83?page=com.atlassian.jira.plugin.s... ]
Erich Duda closed WFWIP-83.
---------------------------
Resolution: Done
I confirm that this one is fixed. Closing.
> [Artemis 2.x upgrade] javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-83
> URL: https://issues.jboss.org/browse/WFWIP-83
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is regression TCK 7 when running WF/EAP with Artemis 2.x resource adapter against AMQ 7.2.0.GA. WF/EAP with Artemis 2.x is last build from [2018-08-06]:
> https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-...
> There are approximately 200 failures with exception:
> {code}
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) 08-03-2018 09:55:10: SVR-ERROR: javax.jms.InvalidClientIDException: clientID=cts was already set into another connection
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.validateClientID(ActiveMQConnection.java:266)
> [javatest.batch] ESC[0mESC[0m09:55:10,602 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnection.authorize(ActiveMQConnection.java:681)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:849)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createXATopicConnection(ActiveMQConnectionFactory.java:387)
> [javatest.batch] ESC[0mESC[0m09:55:10,603 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.setup(ActiveMQRAManagedConnection.java:745)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.<init>(ActiveMQRAManagedConnection.java:161)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAManagedConnectionFactory.createManagedConnection(ActiveMQRAManagedConnectionFactory.java:151)
> [javatest.batch] ESC[0mESC[0m09:55:10,604 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(Semaphor
> eConcurrentLinkedDequeManagedConnectionPool.java:1326)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinke
> dDequeManagedConnectionPool.java:499)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:632)
> [javatest.batch] ESC[0mESC[0m09:55:10,605 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:604)
> [javatest.batch] ESC[0mESC[0m09:55:10,606 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> [javatest.batch] ESC[0mESC[0m09:55:10,610 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:746)
> [javatest.batch] ESC[0mESC[0m09:55:10,611 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:751)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.validateUser(ActiveMQRAConnectionFactoryImpl.java:475)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at org.apache.activemq.artemis.ra.ActiveMQRAConnectionFactoryImpl.createTopicConnection(ActiveMQRAConnectionFactoryImpl.java:217)
> [javatest.batch] ESC[0mESC[0m09:55:10,612 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.testInitForT(TransactionTests.java:354)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test06(TransactionTests.java:634)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [javatest.batch] ESC[0mESC[0m09:55:10,613 INFO [stdout] (Thread-68) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at java.lang.reflect.Method.invoke(Method.java:498)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.EETest.run(EETest.java:550)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.lib.harness.ServiceEETest.run(ServiceEETest.java:113)
> [javatest.batch] ESC[0mESC[0m09:55:10,614 INFO [stdout] (Thread-68) at com.sun.ts.tests.common.vehicle.ejb.EJBVehicle.runTest(EJBVehicle.java:70)
> {code}
> Note that TCK 7 is passing when trying with current Wildfly master (Artemis 1.5.5.012).
> Link to TCK 7 job:
> https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-third-...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak reopened WFWIP-65:
---------------------------------
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10847) Multiple service modules in single EAR use same tracer instance
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/WFLY-10847?page=com.atlassian.jira.plugin... ]
Gary Brown commented on WFLY-10847:
-----------------------------------
[~juraci.costa] Based on the examples above, if we go for one tracer per EAR then all tracing is reported against the same "service" - which might be ok, but doesn't necessarily provide the clarity about what activity occurred in the individual components.
If however we take the other route, and a tracer per component in the EAR, then I assume this would also mean that each EJB Jar would also have its own tracer? Not necessarily a bad thing if being used by multiple WAR files in the same EAR, but may be over the top of the EAR contains many individual EJB Jars.
Two questions:
1) Is it possible to provide a configuration option that would enable switching between either mode - so it becomes a user decision?
2) If a tracer is created per component in the EAR, can the "service name" be composed of the EAR and deployment name?
> Multiple service modules in single EAR use same tracer instance
> ---------------------------------------------------------------
>
> Key: WFLY-10847
> URL: https://issues.jboss.org/browse/WFLY-10847
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Reporter: Michal Jurc
> Assignee: Juraci Paixão Kröhling
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> When deploying an EAR with two stand-alone JAX-RS services in stand-alone WAR modules, both of the services use the same {{Tracer}} instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-65) [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-65?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-65:
-------------------------------------
[~clebert.suconic] [~martyn-taylor] I can see this issue in latest build:
https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
There are 2 servers in colocated topology. 1st one is killed and colocated backup 2nd server starts. However clients do not failover, in trace logs from client there is:
{code}
18:06:46,042 Thread-46 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1118] Backup is not active, trying original connection configuration now.
18:06:46,042 Thread-46 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1301] Neither backup or live were active, will just give up now
{code}
> [Artemis 2.x upgrade] Artemis RA connections disconnected after failover
> -------------------------------------------------------------------------
>
> Key: WFWIP-65
> URL: https://issues.jboss.org/browse/WFWIP-65
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Clebert Suconic
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: DedicatedFailoverTestCaseWithMdb.testShutdownWithFailback.zip
>
>
> There is regression againt Artemis 1.5.5.0012 in scenario with failover of Artemis RA from live to backup (shared store, dedicated topology). After backup activates after failover, connections of RA does not failover to backup (or are disconnected from backup just after failover)
> Test scenario:
> * There are three servers. Live server (Node 1) and backupserver (Node 2) are in dedicated HA topology.
> * InQueue and OutQueue are deployed on live and backup. Send messages to InQueue on live server.
> * When all messages are sent, deploy message driven bean on Node 3.
> * MDB sends messages form InQueue to OutQueue.
> * Shutdown live server. Wait for backup server to alive, then start live server again and stop backup.
> * Receive messages from OutQueue from live server.
> Results:
> After live server is stopped and backup activates, no messages are processed by MDB. Looking at trace logs it seems that MDB does reconnect to backup but it's then disconnected. Then I don't see connector to backup server between tried connectors during reconnection.
> Attaching reproduce and logs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-15) [Artemis 2.x upgrade] Broken managed connections after suspending remote broker
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-15?page=com.atlassian.jira.plugin.s... ]
Miroslav Novak commented on WFWIP-15:
-------------------------------------
Artemis 2.x run: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view/EAP...
WF master(Artemis 1.5.5) run: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag...
> [Artemis 2.x upgrade] Broken managed connections after suspending remote broker
> -------------------------------------------------------------------------------
>
> Key: WFWIP-15
> URL: https://issues.jboss.org/browse/WFWIP-15
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Test Scenario:
> * Start 2 servers in cluster with deployed InQueue and OutQueue (jms cluster)
> * Send 50000 messages (10KB) to InQueue
> * Start 2 other servers (mdb nodes) which have configured remote JCA to connect to jms cluster
> * Deploy MDB to each mdb node
> ** MDB consumes messages from InQueue and resend to OutQueue
> * Suspend one of JMS servers (node-3) for 5 minutes when MDBs are processing messages
> * Resume JMS servers and wait for MDBs to process all messages
> Pass Criteria: All messages sent to InQueue well get to OutQueue
> Actual Result:
> There are errors on one of the MDB servers node-4 after node-3 is resumed:
> {code}
> 21:35:05,813 ERROR [org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueWithOutQueueLookups] (Thread-168 (ActiveMQ-client-global-threads)) Could not create a session: IJ000453: Unable to get managed connection fo
> r java:/JmsXA: javax.jms.JMSException: Could not create a session: IJ000453: Unable to get managed connection for java:/JmsXA
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:909)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:531)
> at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueWithOutQueueLookups.onMessage(MdbWithRemoteOutQueueWithOutQueueLookups.java:89) [lodhLikemdb1.jar:]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.8.0_162]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_162]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_162]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:253) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:238) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPS
> HOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:243) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNA
> PSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:243) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNA
> PSHOT]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) [wildfly-elytron-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueWithOutQueueLookups$$$view1.onMessage(Unknown Source) [lodhLikemdb1.jar:]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) [:1.8.0_162]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_162]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_162]
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73) [wildfly-ejb3-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.jboss.qa.hornetq.apps.mdb.MdbWithRemoteOutQueueWithOutQueueLookups$$$endpoint1.onMessage(Unknown Source) [lodhLikemdb1.jar:]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:302)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1002) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1125) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0.jar:2.5.0]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_162]
> Caused by: javax.resource.ResourceException: IJ000453: Unable to get managed connection for java:/JmsXA
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:690)
> at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:789)
> at org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:872)
> ... 69 more
> Caused by: javax.resource.ResourceException: IJ000655: No managed connections available within configured blocking timeout (30000 [ms])
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:570)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:714)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:613)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:624)
> ... 72 more
> {code}
> later on there are errors:
> {code}
> 21:35:52,119 WARN [org.apache.activemq.artemis.core.client] (Thread-218 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,120 WARN [org.apache.activemq.artemis.core.client] (Thread-208 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,122 WARN [org.apache.activemq.artemis.core.client] (Thread-161 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,123 WARN [org.apache.activemq.artemis.core.client] (Thread-172 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,124 WARN [org.apache.activemq.artemis.core.client] (Thread-167 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,124 WARN [org.apache.activemq.artemis.core.client] (Thread-174 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,124 WARN [org.apache.activemq.artemis.core.client] (Thread-176 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,124 WARN [org.apache.activemq.artemis.core.client] (Thread-196 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:52,124 WARN [org.apache.activemq.artemis.core.client] (Thread-157 (ActiveMQ-client-global-threads)) AMQ212009: resetting session after failure
> 21:35:53,087 WARN [org.apache.activemq.artemis.core.client] (Thread-163 (ActiveMQ-client-global-threads)) AMQ212052: Packet PACKET(SessionXAResponseMessage)[type=55, channelID=10, packetObject=SessionXAResponse
> Message, error=false, message=null, responseCode=0] was answered out of sequence due to a previous server timeout and it's being ignored: java.lang.Exception: trace
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:395) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:319) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sessionStop(ActiveMQSessionContext.java:399) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:1019) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.stop(ClientSessionImpl.java:1008) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:912) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.rollback(ClientSessionImpl.java:895) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.resetIfNeeded(ClientSessionImpl.java:985) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:371)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1002) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:50) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1125) [artemis-core-client-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0.jar:2.5.0]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_162]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_162]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0.jar:2.5.0]
> {code}
> However mdb server never recovers from this situation. It seems that all managed connections are left in broken state.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months