[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 updated WFLY-10392:
------------------------------
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.0.EO12
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-messaging-prepare/428//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=Lodh2TestCase#testLodh3kill -Dprepare.param.DATABASE=oracle12c -Dprepare.param.JDBC_STORE=true -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1526497127-wildfly-master-SNAPSHOT -DfailIfNoTests=false -Deap=7x | 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.0.EO12
groovy -DEAP_ZIP_URL=https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-messaging-prepare/428//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=Lodh2TestCase#testLodh3kill -Deap7.org.jboss.qa.hornetq.apps.clients.version=7.1526497127-wildfly-master-SNAPSHOT -DfailIfNoTests=false -Deap=7x | tee log
{code}
> 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 Erich Duda (JIRA)
Erich Duda created WFLY-10392:
---------------------------------
Summary: 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-10389) NPE during server shutdown when using scattered cache
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10389?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10389:
----------------------------------
Summary: NPE during server shutdown when using scattered cache (was: [pretesting] NPE during server shutdown when using scattered cache)
> NPE during server shutdown when using scattered cache
> -----------------------------------------------------
>
> Key: WFLY-10389
> URL: https://issues.jboss.org/browse/WFLY-10389
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> We hit NPE when running tests for RFE EAP7-867.
> EAP distribution was built from https://github.com/pferraro/wildfly/tree/scattered .
> Test description: Positive stress test (no failover), 4-node EAP cluster, clients: starting with 400 clients in the beginning, raising the number of clients to 6000 in the end of the test.
> During clean server shutdown in the end of the test, server logged NPE and got stuck:
> {code}
> [JBossINF] [0m[31m07:55:57,643 ERROR [org.infinispan.scattered.impl.ScatteredStateConsumerImpl] (thread-200,ejb,dev214) ISPN000471: Failed processing values received from remote node during rebalance.: java.lang.NullPointerException
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505)
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:56)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> [JBossINF] at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:819)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:340)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:134)
> [JBossINF] at org.jgroups.protocols.FRAG3.up(FRAG3.java:166)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> [JBossINF] at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> [JBossINF] at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> [JBossINF] at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Scattered cache was configured with bias-lifespan="0".
> Server configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> Server link:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-10390) java.net.SocketTimeoutException: Read timed out on client when using scattered cache
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-10390?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10390:
----------------------------------
Summary: java.net.SocketTimeoutException: Read timed out on client when using scattered cache (was: [pretesting] java.net.SocketTimeoutException: Read timed out on client when using scattered cache)
> java.net.SocketTimeoutException: Read timed out on client when using scattered cache
> ------------------------------------------------------------------------------------
>
> Key: WFLY-10390
> URL: https://issues.jboss.org/browse/WFLY-10390
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 13.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> When running tests for RFE EAP7-867, the client is logging sampling errors due to
> java.net.SocketTimeoutExceptions:
> {code}
> 2018/04/20 06:54:59:695 EDT [WARN ][Runner - 647] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: IO error: java.net.SocketTimeoutException: Read timed out>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: IO error: java.net.SocketTimeoutException: Read timed out
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:266)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
> at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
> at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
> at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
> at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
> at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
> at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
> at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
> at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:147)
> ... 3 more
> {code}
> We have also tried to set {{bias-lifespan="0"}}, but that did not help.
> There are two types of tests:
> 1. failover tests
> Sampling errors occur after failover.
> run with bias-lifespan="0":
> overview: 1714 sampling errors
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> client log:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> run where bias-lifespan is not set:
> overview: 620 sampling errors
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> client log:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> 2. stress tests
> Sampling errors occur regularly, in larger numbers starting from 6th iteration till the end of the test.
> run with bias-lifespan="0":
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> run where bias-lifespan is not set:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> Performance comparison (available only from VPN):
> http://download.eng.brq.redhat.com/scratch/mvinkler/reports/2018-04-23_07...
> Also, WFLY-10273 is occurring in these runs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months