[JBoss JIRA] (WFLY-8713) ISPN000136: Error executing command PutKeyValueCommand, writing keys
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-8713?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-8713.
--------------------------------
Resolution: Out of Date
> ISPN000136: Error executing command PutKeyValueCommand, writing keys
> --------------------------------------------------------------------
>
> Key: WFLY-8713
> URL: https://issues.jboss.org/browse/WFLY-8713
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Environment: Linux
> Reporter: Divey Gupta
> Assignee: Paul Ferraro
> Priority: Major
>
> We have a cluster of 6 wildfly all running 10.0.0. There was a network blip for few minutes so the connectivity between the members of the cluster got affected.
> After that one of the members started throwing the following error on login.
> {noformat}
> ERROR [InvocationContextInterceptor] (default task-51) ISPN000136: Error executing command PutKeyValueCommand, writing keys [SessionCreationMetaDataKey(k1XmyfLfE8KInACteyuTXQLCki9jq-HKL2-Ayo6G)]: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 27
> at org.infinispan.statetransfer.StateTransferLockImpl.reportErrorAfterWait(StateTransferLockImpl.java:159) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:98) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:366) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:281) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:107) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:43) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:78) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1672) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.putIfAbsentInternal(CacheImpl.java:1163) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.CacheImpl.putIfAbsent(CacheImpl.java:1151) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.DecoratedCache.putIfAbsent(DecoratedCache.java:508) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at org.infinispan.cache.impl.AbstractDelegatingCache.putIfAbsent(AbstractDelegatingCache.java:246) [infinispan-core-8.2.4.Final.jar:8.2.4.Final]
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:325) [rt.jar:1.8.0_72]
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:53)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.createValue(InfinispanSessionMetaDataFactory.java:36)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:52)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.createValue(InfinispanSessionFactory.java:38)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.createSession(InfinispanSessionManager.java:257)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.createSession(DistributableSessionManager.java:110)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:787) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:802) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:131) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:88) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:80) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.FormAuthenticationMechanism.runFormAuth(FormAuthenticationMechanism.java:126) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.FormAuthenticationMechanism.authenticate(FormAuthenticationMechanism.java:96) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:263) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) [undertow-servlet-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805) [undertow-core-1.4.0.Final.jar:1.4.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-8014) Remote store cannot be added to a cache via CLI
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-8014?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-8014.
------------------------------
Resolution: Explained
> Remote store cannot be added to a cache via CLI
> -----------------------------------------------
>
> Key: WFLY-8014
> URL: https://issues.jboss.org/browse/WFLY-8014
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Michal Petrov
> Assignee: Paul Ferraro
> Priority: Major
>
> It is not possible to add remote store to a new cache:
> {quote}
> /subsystem=infinispan/cache-container=web/local-cache=myCache/store=remote:add(remote-servers=\[mail-smtp\])
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache-configuration.web.myCache.store is already registered",
> "rolled-back" => true
> }
> {quote}
> However it is possible to add a file store:
> {{/subsystem=infinispan/cache-container=web/local-cache=myCache/store=file:add}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11944) Some clustering test cases do not close JNDI InitialContext between tests
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11944?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11944:
--------------------------------------------
See comments in the org.jboss.as.test.clustering.ejb.RemoteEJBDirectory class.
> 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.
> 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)
7 years, 1 month
[JBoss JIRA] (WFLY-7332) Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-7332?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-7332.
--------------------------------
Resolution: Out of Date
Triage 2019-04-04: already fixed.
> Infinispan transformation tests fail on 'backups' resource for EAP 7.0.0
> ------------------------------------------------------------------------
>
> Key: WFLY-7332
> URL: https://issues.jboss.org/browse/WFLY-7332
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> {noformat}
> Failed tests:
> TransformersTestCase.testTransformerEAP700:162->testTransformation:191->AbstractSubsystemTest.checkSubsystemModelTransformation:292 cache-container/maximal/distributed-cache/dist/component/: {
> "expiration" => {
> "interval" => 10000L,
> "lifespan" => 10L,
> "max-idle" => 10L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "enabled" => undefined,
> "timeout" => 60000L
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000,
> "isolation" => "READ_COMMITTED",
> "striping" => true
> },
> "backups" => {},
> "transaction" => {
> "locking" => "OPTIMISTIC",
> "mode" => "FULL_XA",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> }
> {
> "expiration" => {
> "max-idle" => 10L,
> "lifespan" => 10L,
> "interval" => 10000L
> },
> "state-transfer" => {
> "chunk-size" => 10000,
> "timeout" => 60000L,
> "enabled" => undefined
> },
> "eviction" => {
> "max-entries" => 20000L,
> "strategy" => "UNORDERED"
> },
> "locking" => {
> "striping" => true,
> "isolation" => "READ_COMMITTED",
> "acquire-timeout" => 30000L,
> "concurrency-level" => 2000
> },
> "backups" => undefined,
> "transaction" => {
> "mode" => "FULL_XA",
> "locking" => "OPTIMISTIC",
> "stop-timeout" => 60000L
> },
> "backup-for" => {},
> "partition-handling" => {}
> } expected:<[backup-for, [backups, ]eviction, expiration...> but was:<[backup-for, []eviction, expiration...>
> Tests run: 108, Failures: 1, Errors: 0, Skipped: 19
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11944) Some clustering test cases do not close JNDI InitialContext between tests
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11944?page=com.atlassian.jira.plugin... ]
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.
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.
> 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.
> 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)
7 years, 1 month
[JBoss JIRA] (WFLY-11944) Some clustering test cases do not close JNDI InitialContext between tests
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11944?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz updated WFLY-11944:
---------------------------------------
Summary: Some clustering test cases do not close JNDI InitialContext between tests (was: RemoteStatelessFailoverTestCase does not close JNDI InitialContext between test cases)
> 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.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month