August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-86) [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-86?page=com.atlassian.jira.plugin.s... ] Miroslav Novak updated WFWIP-86: -------------------------------- Steps to Reproduce: {code} git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout eap7.2.x-artemis2.x-ha-jdbc groovy -DEAP_ZIP_URL=https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-tooling/job/early-testing-messaging-prepare/155/artifact/jboss-eap.zip -DEAP_ZIP_URL_OLD=http://download.eng.brq.redhat.com/devel/candidates/JBEAP/to_be_deleted/JBEAP-7.1.0/jboss-eap-7.1.0.zip PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=JMSBridgeTestCase#testStartStopJMSBridge -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1531748885-SNAPSHOT | tee log {code} was: {code} git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git cd eap-tests-hornetq/scripts/ git checkout eap7.2.x-artemis2.x-ha-jdbc groovy -DEAP_ZIP_URL=https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP-tooling/job/early-testing-messaging-prepare/155/artifact/jboss-eap.zip -DEAP_ZIP_URL_OLD=http://download.eng.brq.redhat.com/devel/candidates/JBEAP/to_be_deleted/JBEAP-7.1.0/jboss-eap-7.1.0.zip PrepareServers7.groovy export WORKSPACE=$PWD export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap cd ../jboss-hornetq-testsuite/ mvn clean test -Dtest=ResourceAdapterCompatibilityTestCase#newJmsOldMdbWithJGroupsUdpDiscovery -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1531748885-SNAPSHOT | tee log {code} > [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge > -------------------------------------------------------------------------------- > > Key: WFWIP-86 > URL: https://issues.jboss.org/browse/WFWIP-86 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There are duplicated messages in scenario where JMS bridge is stopped and started. > Test Scenario: > * Start 2 servers and configure JMS from node-1 to node-3 > * Start sending messages to queue InQueue to node-1 > * Stop JMS bridge using management operation (CLI) > * Wait for 5 sec > * Start JMS bridge using management operation > * Start receiving mesage from node-3 from OutQueue > Expected results: > There are no lost/duplicated mesages. > Actual Result: > Receiver got duplicated messages. > Link to failed Jenkins run: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2853) Make DMN Verifier use the experimental tag

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2853?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2853: -------------------------------- Tester: Jozef Marko > Make DMN Verifier use the experimental tag > ------------------------------------------ > > Key: DROOLS-2853 > URL: https://issues.jboss.org/browse/DROOLS-2853 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor, verifier > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Labels: drools-tools > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2853) Make DMN Verifier use the experimental tag

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2853?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2853: -------------------------------- Labels: drools-tools (was: ) > Make DMN Verifier use the experimental tag > ------------------------------------------ > > Key: DROOLS-2853 > URL: https://issues.jboss.org/browse/DROOLS-2853 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor, verifier > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Labels: drools-tools > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-86) [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge

by Justin Bertram (JIRA)

[ https://issues.jboss.org/browse/WFWIP-86?page=com.atlassian.jira.plugin.s... ] Justin Bertram commented on WFWIP-86: ------------------------------------- I don't believe this is actually a regression. The failure was only happening intermittently between EAP and Wildfly so I changed to test to run EAP & EAP and it failed eventually as well. It obviously needs to be fixed, but probably shouldn't be a blocker for upgrade. > [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge > -------------------------------------------------------------------------------- > > Key: WFWIP-86 > URL: https://issues.jboss.org/browse/WFWIP-86 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There are duplicated messages in scenario where JMS bridge is stopped and started. > Test Scenario: > * Start 2 servers and configure JMS from node-1 to node-3 > * Start sending messages to queue InQueue to node-1 > * Stop JMS bridge using management operation (CLI) > * Wait for 5 sec > * Start JMS bridge using management operation > * Start receiving mesage from node-3 from OutQueue > Expected results: > There are no lost/duplicated mesages. > Actual Result: > Receiver got duplicated messages. > Link to failed Jenkins run: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-86) [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge

by Justin Bertram (JIRA)

[ https://issues.jboss.org/browse/WFWIP-86?page=com.atlassian.jira.plugin.s... ] Justin Bertram commented on WFWIP-86: ------------------------------------- The "Steps to Reproduce" refer to {{ResourceAdapterCompatibilityTestCase#newJmsOldMdbWithJGroupsUdpDiscovery}}. However, this doesn't appear to be the right test for this issue. It seems to me the test should be {{JMSBridgeTestCase#testStartStopJMSBridge}}. Can anyone confirm? > [Artemis 2.x upgrade] Duplicated messages in scenario with stop/start JMS bridge > -------------------------------------------------------------------------------- > > Key: WFWIP-86 > URL: https://issues.jboss.org/browse/WFWIP-86 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There are duplicated messages in scenario where JMS bridge is stopped and started. > Test Scenario: > * Start 2 servers and configure JMS from node-1 to node-3 > * Start sending messages to queue InQueue to node-1 > * Stop JMS bridge using management operation (CLI) > * Wait for 5 sec > * Start JMS bridge using management operation > * Start receiving mesage from node-3 from OutQueue > Expected results: > There are no lost/duplicated mesages. > Actual Result: > Receiver got duplicated messages. > Link to failed Jenkins run: > https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eap-7.x-messag... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10160) "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10160?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-10160: --------------------------------------- Since this doesn't affect clients, this is mostly just log noise. Lowering priority. > "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover) > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10160 > URL: https://issues.jboss.org/browse/WFLY-10160 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final, 13.0.0.Beta1, 14.0.0.CR1 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Minor > > Follow-up on WFLY-9890, this time it does not affect the clients. > Seen in SF failover tests - presumably in the most of the scenarios, for example: > failover-http-session-jvmkill-repl-sync > Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server, the errors keep usually occurring until the very end of the test (i.e. not only to another cluster topology change). > Please notice in the following stacktrace (taken from perf19) - as soon as perf20 rejoins the cluster, it starts logging the TimeoutException errors. It stops only after the test is stopped. > Nothing happens (i.e. no errror) at this time in the log of perf20. > stacktrace: > {code} > [JBossINF] [0m[0m09:01:14,076 INFO [org.infinispan.CLUSTER] (thread-59,ejb,perf19) ISPN100000: Node perf20 joined the cluster > [JBossINF] [0m[31m09:01:24,568 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p10-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionAccessMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionCreationMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionAttributesKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 13116 from perf20 > [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163) > [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86) > [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21) > [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [JBossINF] at java.lang.Thread.run(Thread.java:748) > [JBossINF] > {code} > Link: > perf19: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... > perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... > The clients are not affected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10160) "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10160?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10160: ---------------------------------- Priority: Minor (was: Major) > "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover) > ------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-10160 > URL: https://issues.jboss.org/browse/WFLY-10160 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 12.0.0.Final, 13.0.0.Beta1, 14.0.0.CR1 > Reporter: Michal Vinkler > Assignee: Paul Ferraro > Priority: Minor > > Follow-up on WFLY-9890, this time it does not affect the clients. > Seen in SF failover tests - presumably in the most of the scenarios, for example: > failover-http-session-jvmkill-repl-sync > Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server, the errors keep usually occurring until the very end of the test (i.e. not only to another cluster topology change). > Please notice in the following stacktrace (taken from perf19) - as soon as perf20 rejoins the cluster, it starts logging the TimeoutException errors. It stops only after the test is stopped. > Nothing happens (i.e. no errror) at this time in the log of perf20. > stacktrace: > {code} > [JBossINF] [0m[0m09:01:14,076 INFO [org.infinispan.CLUSTER] (thread-59,ejb,perf19) ISPN100000: Node perf20 joined the cluster > [JBossINF] [0m[31m09:01:24,568 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p10-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionAccessMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionCreationMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionAttributesKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 13116 from perf20 > [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163) > [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86) > [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21) > [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [JBossINF] at java.lang.Thread.run(Thread.java:748) > [JBossINF] > {code} > Link: > perf19: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... > perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa... > The clients are not affected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10808) Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected

by Joshua Swett (JIRA)

Joshua Swett created WFLY-10808: ----------------------------------- Summary: Default Value of local-receiver-pass-by-value in jboss-ejb-client Descriptor is Not Respected Key: WFLY-10808 URL: https://issues.jboss.org/browse/WFLY-10808 Project: WildFly Issue Type: Bug Components: EE, EJB Affects Versions: 13.0.0.Final, 12.0.0.Final, 11.0.0.Final Reporter: Joshua Swett Priority: Minor Attachments: TestWAR.war The jboss-ejb-client.xml deployment descriptor file can be used to configure the pass semantics of the local EJB receiver using the local-receiver-pass-by-value attribute. As per the EJB spec, the default behaviour should be to pass by value, and this is appropriately reflected in the jboss-ejb-client XSD. As of Wildfly 11, the *omission* of the local-receiver-pass-by-value attribute in a jboss-ejb-client deployment descriptor actually results in remote EJB parameters and the return value being passed by reference as opposed to the documented default of being passed by value. It appears that this bug is a result of changes made for WFLY-5403. The root cause is that the EJBClientDescriptorMetaDataProcessor.java class only uses the pass-by-value receiver if the local-receiver-pass-by-value attribute is Boolean.TRUE (line 177 in 13.0.0.Final), but EJBClientDescriptor10Parser.java defaults the value to null if it is not included in the jboss-ejb-client.xml (line 132 in 13.0.0.Final). The old and working behaviour was to fallback to the value configured at the ejb subsystem level if the jboss-ejb-client.xml excluded the attribute. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10807) mod_cluster simple-load-provider validator is missing a maximum value

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10807?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10807: ---------------------------------- Summary: mod_cluster simple-load-provider validator is missing a maximum value (was: mod_cluster simple-load-provider validator is missing a ceiling) > mod_cluster simple-load-provider validator is missing a maximum value > --------------------------------------------------------------------- > > Key: WFLY-10807 > URL: https://issues.jboss.org/browse/WFLY-10807 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 8.0.0.Final, 9.0.0.Final, 10.0.0.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=simple-load-provider,value=9999 > should fail. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10807) mod_cluster simple-load-provider valitator is missing a ceiling

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-10807: ------------------------------------- Summary: mod_cluster simple-load-provider valitator is missing a ceiling Key: WFLY-10807 URL: https://issues.jboss.org/browse/WFLY-10807 Project: WildFly Issue Type: Bug Components: mod_cluster Affects Versions: 13.0.0.Final, 12.0.0.Final, 11.0.0.Final, 10.1.0.Final, 10.0.0.Final, 9.0.0.Final, 8.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Minor /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=simple-load-provider,value=9999 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2018