[
https://issues.jboss.org/browse/WFLY-5437?page=com.atlassian.jira.plugin....
]
Michal Vinkler commented on WFLY-5437:
--------------------------------------
Our tests seem to be working as expected.
In ER6, this issue was observed only in one async scenario, 55 occurrences.
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
In ER5, there were some occurrences in 3 async scenarios, and also 1 occurrence in sync
scenario (it happened 30 seconds after perf19 was killed, so it doesn't seem to be
tied directly to the failover):
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
It was not observed at all in ER4.
To summarize: the issue happens intermittently in async scenarios, very rarely in sync
scenarios. The issue doesn't seem to be tied directly to the failover.
Occassional stale data with remote EJB invocations and sync cache
-----------------------------------------------------------------
Key: WFLY-5437
URL:
https://issues.jboss.org/browse/WFLY-5437
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR1
Reporter: Richard JanÃk
Assignee: Paul Ferraro
Hi,
we're occasionally getting stale data on remote EJB invocations (number counter
returns number 1 lower than expected, see example). -This is usually preceded (~6 seconds
before that) by cluster wide rebalance after a node is brought back from dead.-
- 2000 clients, stale data is uncommon
- requests from a single client are separated by a 4 second window.
An example of stale data:
{code}
2015/08/28 13:01:35:442 EDT [WARN ][Runner - 640] HOST
perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data:
<org.jboss.smartfrog.loaddriver.RequestProcessingException: Response serial does
not match. Expected: 86, received: 85, runner: 640.>
{code}
And a link to our jobs if you're interested:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...
This behavior has so far been observed with jvmkill and undeploy scenario, on REPL-SYNC
and DIST-SYNC caches.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)