]
Richard Achmatowicz commented on WFLY-4853:
-------------------------------------------
Modified the test case so that we run two separate tests:
- testConcurrentFailoverOverWithoutTransactions(): the test case without transactions
enabled on the ejb-forwarder bean's methods
- testConcurrentFailoverOverWithTransactions: the test case with transactions enabled on
the ejb-forwarder bean's methods
This allows better test scenario coverage, as well as allowing me to get the test merged
and ignore the transactional case while it is being fixed.
Provide two cluster test case for EJBClient
-------------------------------------------
Key: WFLY-4853
URL:
https://issues.jboss.org/browse/WFLY-4853
Project: WildFly
Issue Type: Feature Request
Components: Test Suite
Affects Versions: 10.0.0.Alpha4
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
The Wildfly test suite is missing a test case for testing EJBClient interactions over two
clusters, which does exist in the EAP test cycle. This test case aims to duplicate that
multi-node SmartFrog test in the Wildfly testsuite so that errors are identified early.
The test setup:
- two clusters
{noformat}
ejb-forwarder = {node0, node1}
ejb={node3, node4}
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to
cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10
ms
The test execution:
- once the servers and deployments have been deployed, each server is shut down and then
restarted in turn, at which time the test ends.
The expected behaviour:
- at least 90% of client invocations will complete without exception
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice
versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa
depending on which node of cluster ejb is down)
The invocation transaction attribute set up:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context, which uncovered a
number of issues...