[jboss-jira] [JBoss JIRA] (WFLY-11944) Some clustering test cases do not close JNDI InitialContext between tests

[Richard Achmatowicz (Jira)]

     [ https://issues.jboss.org/browse/WFLY-11944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Achmatowicz updated WFLY-11944:
---------------------------------------
    Description: 
The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans.

This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases.  The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance  which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation.

This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test.

UPDATE: This problem is present in a few other test cases, so I have updated them.

  was:
The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans.

This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases.  The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance  which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation.

This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test.

This problem is present in a few other test cases, so I have updated them.



> Some clustering test cases do not close JNDI InitialContext between tests
> -------------------------------------------------------------------------
>
>                 Key: WFLY-11944
>                 URL: https://issues.jboss.org/browse/WFLY-11944
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 17.0.0.Beta1
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>            Priority: Major
>             Fix For: 17.0.0.Final
>
>
> The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans.
> This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases.  The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance  which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation.
> This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test.
> UPDATE: This problem is present in a few other test cases, so I have updated them.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)