[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:
----------------------------------------
[~eduda] Hence in the current state the version with just the property based SQL configuration isn't working on it?
> 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-10329) Have JipiJapa enable Hibernate Search backward compatibility properties
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10329?page=com.atlassian.jira.plugin... ]
Scott Marlow closed WFLY-10329.
-------------------------------
> Have JipiJapa enable Hibernate Search backward compatibility properties
> -----------------------------------------------------------------------
>
> Key: WFLY-10329
> URL: https://issues.jboss.org/browse/WFLY-10329
> Project: WildFly
> Issue Type: Task
> Reporter: Sanne Grinovero
> Assignee: Scott Marlow
> Fix For: 13.0.0.Beta1
>
>
> For Hibernate Search 5.10.x to be fully backwards compatible with the previous versions included in WildFly, we need the following property to be set by default among the Hibernate ORM configuration properties:
> {code}
> hibernate.search.index_uninverting_allowed=true
> {code}
> When set to true and the mapping actually makes use of this feature, a warning will be logged.
> We probably will want to document this as well: recommend users to set it to "false" explicitly, as relying on this feature has a performance penalty, yet no relying on it requires mapping changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10329) Have JipiJapa enable Hibernate Search backward compatibility properties
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10329?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10329:
-------------------------------------
Regarding adding a test, would that be testing that Search is properly logging a warning, to make sure that a Hibernate Search developer doesn't remove the warning? If yes, that kind of test could probably be in the Hibernate Search project? Or maybe covered by a comment in Search code, to not ever remove the warning?
For the documentation, is that covered already in Hibernate Search documentation?
I'll mark this as closed, since I can see in the WF source org.jboss.as.jpa.hibernate5.HibernatePersistenceProviderAdaptor.addProviderProperties,
{code}
// Search hint
putPropertyIfAbsent( pu, properties,"hibernate.search.index_uninverting_allowed", true);
{code}
> Have JipiJapa enable Hibernate Search backward compatibility properties
> -----------------------------------------------------------------------
>
> Key: WFLY-10329
> URL: https://issues.jboss.org/browse/WFLY-10329
> Project: WildFly
> Issue Type: Task
> Reporter: Sanne Grinovero
> Assignee: Scott Marlow
> Fix For: 13.0.0.Beta1
>
>
> For Hibernate Search 5.10.x to be fully backwards compatible with the previous versions included in WildFly, we need the following property to be set by default among the Hibernate ORM configuration properties:
> {code}
> hibernate.search.index_uninverting_allowed=true
> {code}
> When set to true and the mapping actually makes use of this feature, a warning will be logged.
> We probably will want to document this as well: recommend users to set it to "false" explicitly, as relying on this feature has a performance penalty, yet no relying on it requires mapping changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10031) Scripts throws "illegal reflective access" warning on JDK9+
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-10031?page=com.atlassian.jira.plugin... ]
Marek Kopecký updated WFLY-10031:
---------------------------------
Summary: Scripts throws "illegal reflective access" warning on JDK9+ (was: Scripts throws "illegal reflective access" warning on JDK9)
> Scripts throws "illegal reflective access" warning on JDK9+
> -----------------------------------------------------------
>
> Key: WFLY-10031
> URL: https://issues.jboss.org/browse/WFLY-10031
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Security
> Reporter: Marek Kopecký
> Assignee: James Perkins
> Priority: Blocker
>
> *Description of the issue:*
> Scripts throws "illegal reflective access" warning on JDK9/10/11.
> *How reproducible:*
> Always with JDK9, 10 and 11
> *Steps to Reproduce:*
> * ./jboss-cli.sh "echo test"
> * ./add-user.sh -u test4 -p Test123* -s
> * ./appclient.sh -v
> * ./wsconsume.sh
> * ./wsprovide.sh
> * ./domain.sh
> * ./standalone.sh
> *Actual results:*
> {noformat}
> [hudson@rhel7-large-9887 bin]$ java --version
> java 9.0.4
> Java(TM) SE Runtime Environment (build 9.0.4+11)
> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./jboss-cli.sh "echo test"
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> test
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./add-user.sh -u test4 -p Test123* -s
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [hudson@rhel7-large-9887 bin]$ cat ../standalone/configuration/mgmt-users.properties | tail -n 1
> test4=a95aa9d159b7afe0cc9d3795061551ad
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./appclient.sh -v
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> 06:11:52,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Final
> WildFly Full 13.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Final)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> *Expected results:*
> No warnings
--
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 Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10392?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10392:
-----------------------------------
I've prepared a Jenkins job \[1\] which you can use for investigation or verification of your fix. The job has pre-filled parameters. You can specify your own version of Artemis in form of ARTEMIS_REPO and ARTEMIS_VERSION parameters. ARTEMIS_VERSION can be branch name, tag or commit id.
The provided test is 100% reproducer. It fails always and on the same issue.
Wildfly which is used as base is built from Jeff's branch provided in previous comment.
\[1\] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/WFLY-10392
> 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] (SWSQE-201) Bookinfo reinstall step in pipeline
by Filip Brychta (JIRA)
[ https://issues.jboss.org/browse/SWSQE-201?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-201:
-------------------------------------
Added installation of bookinfo to Istio-Features-Bookinfo and renamed it to http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/istio-apps/job/...
Still needs to be added to Istio-and-Kiali-on-Openshift
> Bookinfo reinstall step in pipeline
> -----------------------------------
>
> Key: SWSQE-201
> URL: https://issues.jboss.org/browse/SWSQE-201
> Project: Kiali QE
> Issue Type: Task
> Reporter: Hayk Hovsepyan
> Assignee: Filip Brychta
>
> Done:
> In [Istio-and-Kiali-on-Openshift|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-and-Kiali-on-Openshift/] Pipeline in a step "Install Istio" it installs bookinfo app. But when It does not reinstall Istio, bookinfo will remain the old installed. We need clean installed Bookinfo for test purposes.
> The [Istio-Features-Bookinfo|http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/Istio-Features-Bookinfo/] job is a separate job which installs bookinfo only.
> TODO:
> Make sure that Istio-Features-Bookinfo job have an option to "Clean" and "Clean/Reinstall Bookinfo", which means that all Istio related objets are deleted from Bookinfo and Bookinfo is reinstalled.
> Make sure that the above job is included in Istio-and-Kiali-on-Openshift pipeline with optional param to activate.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10399) JSF 2.3.5
by Erick de Oliveira Leal (JIRA)
Erick de Oliveira Leal created WFLY-10399:
---------------------------------------------
Summary: JSF 2.3.5
Key: WFLY-10399
URL: https://issues.jboss.org/browse/WFLY-10399
Project: WildFly
Issue Type: Component Upgrade
Components: JSF
Affects Versions: 13.0.0.Beta1
Reporter: Erick de Oliveira Leal
Assignee: Farah Juma
JSF new version: 2.3.5
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months