[JBoss JIRA] (SWSQE-73) Automation UI - Services Page
by Jeeva Kandasamy (JIRA)
Jeeva Kandasamy created SWSQE-73:
------------------------------------
Summary: Automation UI - Services Page
Key: SWSQE-73
URL: https://issues.jboss.org/browse/SWSQE-73
Project: Swift Sunshine QE
Issue Type: Task
Reporter: Jeeva Kandasamy
Assignee: Jeeva Kandasamy
Automate Kiali "Services Page".
- Get all available service list
- Test filters, Service Name, and Namespace
- Test sort options
- Test pagination
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10060) wsconsume script is not working on JDK9+
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-10060?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-10060:
------------------------------------
I see there is already {{org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.JBossModulesAwareCompiler}} so I think this work was probably already done at some point, or at least started.
> wsconsume script is not working on JDK9+
> ----------------------------------------
>
> Key: WFLY-10060
> URL: https://issues.jboss.org/browse/WFLY-10060
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Affects Versions: 12.0.0.Final
> Reporter: Jan Blizňák
> Assignee: R Searls
> Attachments: mywsdl2java
>
>
> wsconsume script is not working on JDK9/10/11
> {code:java}
> [jbliznak@rh wildfly-13.0.0.Alpha1-SNAPSHOT]$ java -version
> java version "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)
> [jbliznak@rh wildfly-13.0.0.Alpha1-SNAPSHOT]$ bin/wsconsume.sh https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by com.sun.xml.bind.v2.runtime.reflect.opt.Injector (jar:file:/tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/com/sun/xml/bind/main/jaxb-runtime-2.3.0.jar!/) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
> WARNING: Please consider reporting this to the maintainers of com.sun.xml.bind.v2.runtime.reflect.opt.Injector
> 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
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -compile -exsh false -d /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430 -verbose -classdir /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output -allowElementReferences https://raw.githubusercontent.com/jbossws/jbossws-cxf/master/modules/test...
> wsdl2java - Apache CXF 3.2.2
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:6: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebEndpoint;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:7: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebServiceClient;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:8: error: package javax.xml.ws is not visible
> import javax.xml.ws.WebServiceFeature;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:9: error: package javax.xml.ws is not visible
> import javax.xml.ws.Service;
> ^
> (package javax.xml.ws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:3: error: package javax.jws is not visible
> import javax.jws.WebMethod;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:4: error: package javax.jws is not visible
> import javax.jws.WebParam;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:5: error: package javax.jws is not visible
> import javax.jws.WebResult;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:6: error: package javax.jws is not visible
> import javax.jws.WebService;
> ^
> (package javax.jws is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/EndpointInterface.java:7: error: package javax.jws.soap is not visible
> import javax.jws.soap.SOAPBinding;
> ^
> (package javax.jws.soap is declared in module java.xml.ws, which is not in the module graph)
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:72: error: cannot find symbol
> return super.getPort(EndpointInterfacePort, EndpointInterface.class);
> ^
> symbol: variable super
> location: class org.openuri._2004._04.helloworld.TestService
> /tmp/wildfly/dist/target/wildfly-13.0.0.Alpha1-SNAPSHOT/output/tmp854430/org/openuri/_2004/_04/helloworld/TestService.java:84: error: cannot find symbol
> return super.getPort(EndpointInterfacePort, EndpointInterface.class, features);
> ^
> symbol: variable super
> location: class org.openuri._2004._04.helloworld.TestService
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: Failed to compile generated code
> at org.apache.cxf.impl//org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:125)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:303)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> at org.apache.cxf.impl//org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.impl//org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> at org.jboss.ws.jaxws-client//org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> at org.jboss.ws.tools.common//org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10075:
----------------------------------
Steps to Reproduce:
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 f3de9baf1f8b39b810bf3d55d45f4341e3b2aa87
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-messaging-prepare/258/artifact/jboss-eap.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=ClusterTestCase#testStopStartCluster -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1521544306-SNAPSHOT -DfailIfNoTests=false | tee log
{code}
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10075:
----------------------------------
Summary: [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster (was: [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restartin nodes in cluster)
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restarting nodes in cluster
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-2409) Memory Leak in sliding window
by Mike Baranski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2409?page=com.atlassian.jira.plugi... ]
Mike Baranski edited comment on DROOLS-2409 at 3/22/18 9:23 AM:
----------------------------------------------------------------
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
{code:java}
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(100l);
}
}
{code}
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
{code:java}
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
{code}
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
was (Author: mbaranski):
Agreed on the fact that this is not *really* a great real-world example. Perhaps better is a "batch" like example where we add maybe 200 records at a time and sleep in between:
bq. for (i = 0; i < 10000000; i++) {
bq. averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
bq. if (i % 100000 == 0) {
bq. System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
bq. Thread.sleep(500l);
bq. }
bq. if (i % 200 == 0) {
bq. Thread.sleep(100l);
bq. }
bq. }
bq.
bq.
This sleeps 100 ms each 200 events, which drools seems to be able to handle OK for the first few million at least.
This starts to really degrade the performance:
```
for (i = 0; i < 10000000; i++) {
averageMeasurementService.addMeasurement(new Measurement(random.nextInt(100)));
if (i % 100000 == 0) {
System.out.println(i + " inserted into list of " + averageMeasurementService.getFactCount());
Thread.sleep(500l);
}
if (i % 200 == 0) {
Thread.sleep(10l);
}
}
```
In fact, with the above, it looks like maybe the event counter is overflowing:
{quote}
6200000 inserted into list of -1170
zzZZzz: 49.609819277108436
zzZZzz: 49.63111764705882
zzZZzz: 49.31702380952381
zzZZzz: 49.355625
6300000 inserted into list of 20459
zzZZzz: 49.52712348322627
zzZZzz: 49.58170454545454
6400000 inserted into list of 70065
{quote}
> Memory Leak in sliding window
> -----------------------------
>
> Key: DROOLS-2409
> URL: https://issues.jboss.org/browse/DROOLS-2409
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Affects Versions: 7.6.0.Final
> Environment: Mac with Java 1.8 using Spring Boot (see attached demo project)
> Reporter: Mike Baranski
> Assignee: Mario Fusco
> Priority: Critical
> Attachments: complete.tar.gz
>
>
> See attached project.
> `gradle test` causes an out of memory exception on my machine after ~2.6 million events. Events should be released for GC after 1 second, but that does not appear to be happening.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restartin nodes in cluster
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-10075?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10075:
----------------------------------
Attachment: journal-node-2.txt
> [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restartin nodes in cluster
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10075
> URL: https://issues.jboss.org/browse/WFLY-10075
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: journal-node-2.txt
>
>
> There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
> Test Scenario:
> * start two servers in cluster (JGroups used for discovery)
> * send messages to testQueue0 on node-1 and node-2
> * wait until consumers on both nodes receive 300 messages
> * cleanly shut down 1st and then 2nd server
> * leave servers shut down for one minute
> * start both servers
> * wait until both consumers receive 500 messages
> * stop sending messages and receive all remaining messages
> Pass Criteria: All send messages are received by consumer
> Actual Result: There are lost messages.
> Investigation:
> There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
> I'm attaching trace logs from client and servers and content of journal from 2nd server.
> This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10067) Failover does not work with HTTP conncetors/acceptors
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10067?page=com.atlassian.jira.plugin... ]
Erich Duda updated WFLY-10067:
------------------------------
Steps to Reproduce:
At first the test must be unignored by removing the Ignore annotation.
{code}
export DISABLE_TRACE_LOGS=false
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-messaging-prepare/258//artifact/jboss-eap.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=CleanUpOldReplicasTestCase#testMaxReplicatedJournalSize0 -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1521544306-SNAPSHOT -DfailIfNoTests=false -Deap=7x | tee log
{code}
If you want to run the test with netty connectors/acceptors, add this parameter {{-Dprepare.param.CONNECTOR_TYPE=NETTY_NIO}}
was:
{code}
export DISABLE_TRACE_LOGS=false
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-messaging-prepare/258//artifact/jboss-eap.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=CleanUpOldReplicasTestCase#testMaxReplicatedJournalSize0 -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1521544306-SNAPSHOT -DfailIfNoTests=false -Deap=7x | tee log
{code}
If you want to run the test with netty connectors/acceptors, add this parameter {{-Dprepare.param.CONNECTOR_TYPE=NETTY_NIO}}
> Failover does not work with HTTP conncetors/acceptors
> -----------------------------------------------------
>
> Key: WFLY-10067
> URL: https://issues.jboss.org/browse/WFLY-10067
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: clients.log, server1.log, server2.log, test.log
>
>
> Failover does not work with HTTP connectors/acceptors.
> *Scenario:*
> # There are two Wildfly servers configured as Live-Backup pair
> # There is one JMS producer and one JMS receiver which sends/receives messages
> # Live server is several times killed and restarted.
> *Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
> *Reality*: Sometimes happens that clients don't do failover.
> *Users impact:* One of basics feature of HA, failover, does not work properly.
> *Blocker* priority was set because this is regression against previous releases of Wildfly.
> *Detail description of issue*
> In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
> {code:title=Backup log}
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
> 07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
> 07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
> 07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
> 07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
> {code}
> {code:title=Clients log}
> 07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
> 07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
> 07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
> 07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
> GET HTTP/1.1
> host: localhost
> upgrade: activemq-remoting
> connection: upgrade
> activemqServerName: default
> httpUpgradeEndpoint: acceptor
> Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
> Content-Length: 2426
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Thu, 22 Mar 2018 06:52:49 GMT
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
> 07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10075) [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restartin nodes in cluster
by Miroslav Novak (JIRA)
Miroslav Novak created WFLY-10075:
-------------------------------------
Summary: [Artemis 2.x upgrade] Stuck messages in artemis.internal.sf.my-cluster... queue after restartin nodes in cluster
Key: WFLY-10075
URL: https://issues.jboss.org/browse/WFLY-10075
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
Priority: Blocker
There are lost messages in scenario where nodes in cluster are cleanly stopped and started again. This issue was hit with Artemis 2.5.0.Final and WF Jeff's integration branch WFLY-9407_upgrade_artemis_2.4.0_with_prefix.
Test Scenario:
* start two servers in cluster (JGroups used for discovery)
* send messages to testQueue0 on node-1 and node-2
* wait until consumers on both nodes receive 300 messages
* cleanly shut down 1st and then 2nd server
* leave servers shut down for one minute
* start both servers
* wait until both consumers receive 500 messages
* stop sending messages and receive all remaining messages
Pass Criteria: All send messages are received by consumer
Actual Result: There are lost messages.
Investigation:
There are lost messages which were sent to 2nd node. However they got stuck in queue {{.artemis.internal.sf.my-cluster.8a7e9e98-2c36-11e8-9737-fa163ea20b26}} during load balancing to 1st server.
I'm attaching trace logs from client and servers and content of journal from 2nd server.
This is regression against Artemis 1.5.5 thus setting blocker priority.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month