[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.
If your test class only involves one test, then static usage will work, but probably not recommended.
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.
UPDATE: 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.
> If your test class only involves one test, then static usage will work, but probably not recommended.
> 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)
7 years, 1 month
[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-10280:
--------------------------------
Issue Type: Enhancement (was: Bug)
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10160) "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-10160?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-10160.
-------------------------------
Resolution: Explained
> "ISPN000476: Timed out waiting for responses for request X from node Y" immediately after node Y rejoins the cluster (failover)
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10160
> URL: https://issues.jboss.org/browse/WFLY-10160
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 12.0.0.Final, 13.0.0.Beta1, 14.0.0.Beta2
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Minor
>
> Follow-up on WFLY-9890, this time it does not affect the clients.
> Seen in SF failover tests - presumably in the most of the scenarios, for example:
> failover-http-session-jvmkill-repl-sync
> Description: In the failover test, each server is shut down and after some time it rejoins the cluster. After joining the cluster again, the load is distributed to this node. It seems that first request for some session handled by that node produces ERROR in the log of some other server, the errors keep usually occurring until the very end of the test (i.e. not only to another cluster topology change).
> Please notice in the following stacktrace (taken from perf19) - as soon as perf20 rejoins the cluster, it starts logging the TimeoutException errors. It stops only after the test is stopped.
> Nothing happens (i.e. no errror) at this time in the log of perf20.
> stacktrace:
> {code}
> [JBossINF] [0m[0m09:01:14,076 INFO [org.infinispan.CLUSTER] (thread-59,ejb,perf19) ISPN100000: Node perf20 joined the cluster
> [JBossINF] [0m[31m09:01:24,568 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p10-t1) ISPN000136: Error executing command PrepareCommand, writing keys [SessionAccessMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionCreationMetaDataKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1), SessionAttributesKey(HP8SQsg6CF1loZZb-kQ0r7qeOIl78bDk85wvRQm1)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 13116 from perf20
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:163)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:86)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:21)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Link:
> perf19: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> perf20: http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> The clients are not affected.
--
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 edited comment on WFLY-11944 at 4/4/19 3:37 PM:
--------------------------------------------------------------------
Comments in the org.jboss.as.test.clustering.ejb.RemoteEJBDirectory class:
{noformat}
NOTE:
If you hold a static reference to this class, it causes any JNDI lookups across different tests to use the same discovered node registry (DNR).
This can cause server starts and stops in one test to contaminate other tests and produce incorrect results.
It is adviseable to use one instance per test by defining a @Before and @After method to create and dispose of the instance on a per test basis
{noformat}
was (Author: rachmato):
Comments in the org.jboss.as.test.clustering.ejb.RemoteEJBDirectory class:
{noformat}
NOTE:
If you hold a static reference to this class, it causes any JNDI lookups across different tests to use the same discovered node registry (DNR). This can cause server starts and stops in one test to contaminate other tests and produce incorrect results.
It is adviseable to use one instance per test by defining a @Before and @After method to create and dispose of the instance on a per test basis
{noformat}
> 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)
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 edited comment on WFLY-11944 at 4/4/19 3:37 PM:
--------------------------------------------------------------------
Comments in the org.jboss.as.test.clustering.ejb.RemoteEJBDirectory class:
{noformat}
NOTE:
If you hold a static reference to this class, it causes any JNDI lookups across different tests to use the same discovered node registry (DNR). This can cause server starts and stops in one test to contaminate other tests and produce incorrect results.
It is adviseable to use one instance per test by defining a @Before and @After method to create and dispose of the instance on a per test basis
{noformat}
was (Author: rachmato):
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.
> 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)
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.
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)
7 years, 1 month
[JBoss JIRA] (WFLY-10073) Key requester node_X is not in current view Y; ignoring key request
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-10073?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-10073 at 4/4/19 3:34 PM:
---------------------------------------------------------------
Triage 2019-04-04: [~tommaso-borgato] Please revalidate ^ with new jgroups, this logic is changed.
was (Author: rhusar):
Triage 2019-04-04 [~tommaso-borgato] Please revalidate ^ with new jgroups, this logic is changed.
> Key requester node_X is not in current view Y; ignoring key request
> -------------------------------------------------------------------
>
> Key: WFLY-10073
> URL: https://issues.jboss.org/browse/WFLY-10073
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Daniel Cihak
> Assignee: Paul Ferraro
> Priority: Major
>
> Four errors were logged on *server* during failover scenario *eap-7x-failover-http-session-shutdown-dist-async-auth-asymEncrypt* (scenario with "AUTH" and "ASYM_ENCRYPT" protocols enabled) during new cluster view receiving:
> {code}
> 04:47:29,691 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-7,ee,perf21) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] 04:47:29,692 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) perf21: unrecognized cipher; discarding message from perf20
> [JBossINF] 04:47:29,692 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,692 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,694 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-13,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,694 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-13,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:48:37,553 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,perf21) ISPN000094: Received new cluster view for channel server: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> {code}
> WARN message was logged just before:
> {code}
> 04:47:29,692 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) perf21: unrecognized cipher; discarding message from perf20
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
> There are two WARN exceptions logged on client at the same time:
> {code}
> 04:47:28:988 EST [WARN ][Runner - 1066] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> 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:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10073) Key requester node_X is not in current view Y; ignoring key request
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-10073?page=com.atlassian.jira.plugin... ]
Radoslav Husar edited comment on WFLY-10073 at 4/4/19 3:33 PM:
---------------------------------------------------------------
Triage 2019-04-04 [~tommaso-borgato] Please revalidate ^ with new jgroups, this logic is changed.
was (Author: rhusar):
[~tommaso-borgato] Please revalidate ^ with new jgroups, this logic is changed.
> Key requester node_X is not in current view Y; ignoring key request
> -------------------------------------------------------------------
>
> Key: WFLY-10073
> URL: https://issues.jboss.org/browse/WFLY-10073
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Daniel Cihak
> Assignee: Paul Ferraro
> Priority: Major
>
> Four errors were logged on *server* during failover scenario *eap-7x-failover-http-session-shutdown-dist-async-auth-asymEncrypt* (scenario with "AUTH" and "ASYM_ENCRYPT" protocols enabled) during new cluster view receiving:
> {code}
> 04:47:29,691 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-7,ee,perf21) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] 04:47:29,692 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) perf21: unrecognized cipher; discarding message from perf20
> [JBossINF] 04:47:29,692 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,692 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,694 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-13,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:47:29,694 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-13,ee,perf21) key requester perf20 is not in current view [perf21|8] (3) [perf21, perf18, perf19]; ignoring key request
> [JBossINF] 04:48:37,553 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2,ee,perf21) ISPN000094: Received new cluster view for channel server: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> {code}
> WARN message was logged just before:
> {code}
> 04:47:29,692 WARN [org.jgroups.protocols.ASYM_ENCRYPT] (thread-1,ee,perf21) perf21: unrecognized cipher; discarding message from perf20
> {code}
> Link to server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
> There are two WARN exceptions logged on client at the same time:
> {code}
> 04:47:28:988 EST [WARN ][Runner - 1066] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: <org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: <html><head><title>Error</title></head><body>Internal Server Error</body></html>
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> 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:745)
> {code}
> Link to client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/perflab_eap-7x-failov...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month