[JBoss JIRA] (WFCORE-3832) [GSS](7.2) Support hex encoding in jdbc-realm for elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3832?page=com.atlassian.jira.plugi... ]
Jan Kalina commented on WFCORE-3832:
------------------------------------
[~mchoma] fixed (after confirming from PRODMGT-1878)
> [GSS](7.2) Support hex encoding in jdbc-realm for elytron
> ---------------------------------------------------------
>
> Key: WFCORE-3832
> URL: https://issues.jboss.org/browse/WFCORE-3832
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 5.0.0.Alpha7
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: elytron
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3832) [GSS](7.2) Support hex encoding in jdbc-realm for elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3832?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-3832:
-------------------------------
Summary: [GSS](7.2) Support hex encoding in jdbc-realm for elytron (was: [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron)
> [GSS](7.2) Support hex encoding in jdbc-realm for elytron
> ---------------------------------------------------------
>
> Key: WFCORE-3832
> URL: https://issues.jboss.org/browse/WFCORE-3832
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 5.0.0.Alpha7
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: elytron
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1582) [GSS](7.2) Support hex encoding in jdbc-realm for elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1582?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1582:
----------------------------
Summary: [GSS](7.2) Support hex encoding in jdbc-realm for elytron (was: [GSS](7.1.z) Support hex encoding in jdbc-realm for elytron)
> [GSS](7.2) Support hex encoding in jdbc-realm for elytron
> ---------------------------------------------------------
>
> Key: ELY-1582
> URL: https://issues.jboss.org/browse/ELY-1582
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Affects Versions: 1.3.2.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: elytron
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10385) TransactionInflowTestCase does not function correctly under security manager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-10385?page=com.atlassian.jira.plugin... ]
Kabir Khan resolved WFLY-10385.
-------------------------------
Fix Version/s: 13.0.0.Beta1
Resolution: Done
> TransactionInflowTestCase does not function correctly under security manager
> ----------------------------------------------------------------------------
>
> Key: WFLY-10385
> URL: https://issues.jboss.org/browse/WFLY-10385
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: David Lloyd
> Assignee: Ondra Chaloupka
> Fix For: 13.0.0.Beta1
>
>
> Proactively assigning to [~ochaloup] as he is the original test author; feel free to adjust as necessary.
> {{org.jboss.as.test.integration.transaction.inflow.TransactionInflowTestCase}} does not function correctly under a security manager. The stack trace is like this:
> {noformat}
> Breakpoint reached
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
> at java.lang.SecurityManager.checkConnect(SecurityManager.java:1048)
> at org.wildfly.security.manager.WildFlySecurityManager.checkConnect(WildFlySecurityManager.java:390)
> at java.net.InetAddress.getLocalHost(InetAddress.java:1477)
> at org.jboss.as.test.integration.transaction.inflow.TransactionInflowXid.getXid(TransactionInflowXid.java:128)
> at org.jboss.as.test.integration.transaction.inflow.TransactionInflowXid.getUniqueXid(TransactionInflowXid.java:102)
> at org.jboss.as.test.integration.transaction.inflow.TransactionInflowResourceAdapter.endpointActivation(TransactionInflowResourceAdapter.java:65)
> at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:194)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.activate(MessageDrivenComponent.java:277)
> at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:235)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Perm = ("java.net.SocketPermission" "behemoth.local" "resolve"), CS = (vfs:/content/inflow-txn-ra.rar/inflow-txn-inside.jar <no signer certificates>), CL = ModuleClassLoader for Module "deployment.inflow-txn-ra.rar" from Service Module Loader, ID = 824b419
> {noformat}
> The cause is that {{org.jboss.as.test.integration.transaction.inflow.TransactionInflowXid#getXid}} calls {{java.net.InetAddress#getLocalHost}} which requires a security manager permission. If the permission is denied (which it always is when running under a security manager), then it falls back through a {{catch (Exception ex)}} to a bogus IP address of "1.2.3.4".
> For correct operation, the test archives which use this method should have the {{"*"}} {{"resolve"}} {{SocketPermission}} granted to them.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[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/17/18 11:32 AM:
------------------------------------------------------------------
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...] as well.
It seems to appear while stopping the SQL driver:
{code:java}
AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager: java.sql.SQLException: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8@78acabf3
at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:169)
at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:783)
at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.stop(AbstractJDBCDriver.java:98) [artemis-jdbc-store-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
{code}
I'm not sure this last one is the real reason of the regression TBH.
was (Author: fnigro):
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...] as well.
It seems to appear while stopping the SQL driver:
{{AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager: java.sql.SQLException: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8@78acabf3
at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:169)
at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:783)
at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.stop(AbstractJDBCDriver.java:98) [artemis-jdbc-store-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
}}
I'm not sure this last one is the real reason of the regression TBH.
> 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
>
> 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
[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/17/18 11:32 AM:
------------------------------------------------------------------
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...] as well.
It seems to appear while stopping the SQL driver:
{{AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager: java.sql.SQLException: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8@78acabf3
at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:169)
at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:783)
at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.stop(AbstractJDBCDriver.java:98) [artemis-jdbc-store-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
}}
I'm not sure this last one is the real reason of the regression TBH.
was (Author: fnigro):
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...] as well.
It seems to appear while stopping the SQL driver: AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager: java.sql.SQLException: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8@78acabf3
at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:169)
at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:783)
at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.stop(AbstractJDBCDriver.java:98) [artemis-jdbc-store-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
I'm not sure this last one is the real reason of the regression TBH.
> 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
>
> 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
[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/17/18 11:31 AM:
------------------------------------------------------------------
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...] as well.
It seems to appear while stopping the SQL driver: AMQ224068: Unable to stop component: org.apache.activemq.artemis.core.persistence.impl.journal.JDBCJournalStorageManager: java.sql.SQLException: IJ031040: Connection is not associated with a managed connection: org.jboss.jca.adapters.jdbc.jdk8.WrappedConnectionJDK8@78acabf3
at org.jboss.jca.adapters.jdbc.WrappedConnection.lock(WrappedConnection.java:169)
at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:783)
at org.apache.activemq.artemis.jdbc.store.drivers.AbstractJDBCDriver.stop(AbstractJDBCDriver.java:98) [artemis-jdbc-store-1.5.5.jbossorg-011.jar:1.5.5.jbossorg-011]
I'm not sure this last one is the real reason of the regression TBH.
was (Author: fnigro):
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted other 2 commits:
# a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...]
# a [change|https://github.com/franz1981/activemq-artemis/commit/3ee566c07a532...] on ActiveMQScheduledComponent::initialDelay
The first seems to appear while stopping the SQL driver while the second one could affect the JDBCJournal periodic sync process that would start before having the tables created.
> 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
>
> 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
[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/17/18 11:23 AM:
------------------------------------------------------------------
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
Looking at the logs I have spotted other 2 commits:
# a change done on [ARTEMIS-1757 Improve DB2 compatibility|https://github.com/franz1981/activemq-artemis/commit/17502f...]
# a [change|https://github.com/franz1981/activemq-artemis/commit/3ee566c07a532...] on ActiveMQScheduledComponent::initialDelay
The first seems to compare while stopping the SQL driver while the second one could affect the JDBCJournal periodic sync process that would start before having the tables created.
was (Author: fnigro):
[~eduda] I will take a look to the logs too! Yes already done (now): you can use the same branch I've posted above (y)
Please could you share here the commit of the version that is working (without the JDBC HA porting)?
> 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
>
> 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