[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro commented on WFLY-10392:
----------------------------------------
[~jmesnil][~eduda] I have build a "special" version of artemis that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 8:26 AM:
-----------------------------------------------------------------
[~jmesnil][~eduda] I have built a "special" version of artemis that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
was (Author: fnigro):
[~jmesnil][~eduda] I have build a "special" version of artemis that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 8:26 AM:
-----------------------------------------------------------------
[~jmesnil][~eduda] I have built a "special" version of 1.5.5 that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
was (Author: fnigro):
[~jmesnil][~eduda] I have built a "special" version of artemis that contains just the Peroperties-based-SQLProvider commit + a fix on a JDBC connection leaks: https://github.com/franz1981/activemq-artemis/tree/WFLY-10392_NO_JDBC_HA (ie no JDBC HA at all).
Testing it has resulted in a failure: https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392/3/
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 6:33 AM:
-----------------------------------------------------------------
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it will solve the regression.
[~jmesnil] I can't test it on CI because I need it to be changed on the EAP zip as well, wdyt? makes sense?
was (Author: fnigro):
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it will solve the regression.
[~jmesnil] I can't test it on CI because I need it to be changed on teh EAP zip as well, wdyt? makes sense?
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 6:33 AM:
-----------------------------------------------------------------
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it will solve the regression.
[~jmesnil] I can't test it on CI because I need it to be changed on teh EAP zip as well, wdyt? makes sense?
was (Author: fnigro):
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it will solve the regression.
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 6:11 AM:
-----------------------------------------------------------------
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it will solve the regression.
was (Author: fnigro):
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it is the cause of the regression.
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 6:00 AM:
-----------------------------------------------------------------
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
I have spotted an important difference from 2.x master on Oracle SQL statements:
1.5.5-x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19) GENERATED BY DEFAULT ON NULL AS IDENTITY,recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
upstream 2.x:
{code:sql}
create-journal-table.oracle=CREATE TABLE %s(id NUMBER(19),recordType NUMBER(5),compactCount NUMBER(5),txId NUMBER(19),userRecordType NUMBER(5),variableSize NUMBER(10),record BLOB,txDataSize NUMBER(10),txData BLOB,txCheckNoRecords NUMBER(10),seq NUMBER(19))
{code}
This change was introduced by [ARTEMIS-1660 create-journal-table.oracle does create identity for column id|https://github.com/apache/activemq-artemis/commit/722ef6aa6c09eaf344d5...] and it is not ported on the JDBC HA commits yet: I will manually porting it to check if it is the cause of the regression.
was (Author: fnigro):
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFCORE-3851) Make wildfly-component-matrix-plugin defined in pluginManagement section, preferably in jboss-parent
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3851?page=com.atlassian.jira.plugi... ]
Kabir Khan resolved WFCORE-3851.
--------------------------------
Fix Version/s: 5.0.0.Beta4
Resolution: Done
> Make wildfly-component-matrix-plugin defined in pluginManagement section, preferably in jboss-parent
> -----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3851
> URL: https://issues.jboss.org/browse/WFCORE-3851
> Project: WildFly Core
> Issue Type: Task
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Fix For: 5.0.0.Beta4
>
>
> Make wildfly-component-matrix-plugin defined in pluginManagement section, preferably in jboss-parent
> Follow-up of https://issues.jboss.org/browse/WFLY-10365 work
> Goal is to incorporate comments added to https://github.com/wildfly/wildfly/pull/11218
> * wildfly-component-matrix-plugin defined in pluginManagement section
> * avoid dual jboss-parent version definition
> * move plugin definition into jboss-parent if possible
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-9892:
----------------------------------
[~pcraveiro] Can you please help Sande with the above questions?
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0
[JBoss JIRA] (WFLY-10392) Regression in Remote JCA scenario with JDBC store after Artemis upgrade
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Francesco Nigro edited comment on WFLY-10392 at 5/19/18 4:31 AM:
-----------------------------------------------------------------
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
was (Author: fnigro):
[~eduda] [~jmesnil] I have manually checked the SQL statements related to Oracle before and after the introduction of the property based configuration:
!image-2018-05-19-10-26-05-662.png|thumbnail!
I can't spot meaningful differences TBH, [~jmesnil] wdyt?
So, given that:
* the SQL doesn't seem to have been changed
* I have reverted any bits of JDBC HA that could impact the original behaviour (on tables creation and specific SQL statements)
There are very few options left:
# the issue could be related to any other remaining commits that seems unrelated
# the env where the tests are running has something wrong
I'm checking if there is anything related to the former, would be great to do the same for the latter.
> Regression in Remote JCA scenario with JDBC store after Artemis upgrade
> -----------------------------------------------------------------------
>
> Key: WFLY-10392
> URL: https://issues.jboss.org/browse/WFLY-10392
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Attachments: image-2018-05-19-10-26-05-662.png, sql-diff.png
>
>
> After Artemis upgrade to 1.5.5.jbossorg-011 (WFLY-10139) I can see a regression in Remote JCA test case when JDBC persistent store is used. This issue is not present if Artemis file based journal is used.
> When I removed commits related to JDBC HA from Artemis upgrade, the test passed with both JDBC and file based store.
> *Remote JCA scenario:*
> * There are 4 Wildfly servers
> * Servers 1 and 3 are used as messaging brokers - they are called JMS servers
> * Servers 2 and 4 have MDBs and RA configured to connect to JMS servers. These servers are called MDB servers.
> * External standalone producer sends messages to server 1 to InQueue
> * MDBs on MBD severs receive messages from InQueue and send them to OutQueue
> * External standalone receiver receives messages from server 3 from OutQueue
> * During this scenario server 1 is several times killed and restarted.
> *Expectation:* All messages sent by the standalone producer are received by the standalone receiver. There are no lost or duplicated messages.
> *Reality:* After some kills of server 1, message flow coming from the standalone producer is broken and the receiver does not receive any messages in specified timeout.
> *Critical* priority was chosen because the regression has been detected only in this particular test case so far. We ran only nightly testing scope. After that we run full testing, we will know more about impact of this issue.
> *Technical details:*
> At some point following log messages start to occur in the test log. It seems that they are related to malfunction of communication among Artemis brokers what causes that message flow is broken.
> {code}
> 21:55:51,724 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-client-global-threads)) AMQ222139: MessageFlowRecordImpl [nodeID=e53da514-5953-11e8-910a-fa163e48a89a, connector=TransportConfigur
> ation(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=10080&host=rhel7-la
> rge-58597, queueName=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, queue=QueueImpl[name=sf.my-cluster.e53da514-5953-11e8-910a-fa163e48a89a, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=
> d80bf5bd-5953-11e8-ac10-fa163e48a89a]]@756a727a, isClosed=false, reset=true]::Remote queue binding jms.queue.DLQe53da514-5953-11e8-910a-fa163e48a89a has already been bound in the post office. Most likely cause f
> or this is you have a loop in your cluster due to cluster max-hops being too large or you have multiple cluster connections to the same nodes using overlapping addresses
> {code}
> {code}
> 21:55:53,078 ERROR [org.apache.activemq.artemis.core.server] (Thread-6 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.InQueuee53da514-5953-11e8-910a-fa163e48a89a on ClusterConnectionImpl@14989488[nodeUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a, connector=TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=8080&host=rhel7-large-58597, address=jms, server=ActiveMQServerImpl::serverUUID=d80bf5bd-5953-11e8-ac10-fa163e48a89a]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004) [artemis-server-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124) [artemis-core-client-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
- 1
- 0