[JBoss JIRA] (WFLY-12635) Http requests failed with ISPN000299 after redirect and session invalidation
by Ricardo Martin Camarero (Jira)
[ https://issues.jboss.org/browse/WFLY-12635?page=com.atlassian.jira.plugin... ]
Ricardo Martin Camarero moved JBEAP-17726 to WFLY-12635:
--------------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-12635 (was: JBEAP-17726)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Web (Undertow))
Affects Version/s: 18.0.0.Beta1
(was: 7.2.4.GA)
> Http requests failed with ISPN000299 after redirect and session invalidation
> ----------------------------------------------------------------------------
>
> Key: WFLY-12635
> URL: https://issues.jboss.org/browse/WFLY-12635
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Major
>
> ISPN000299 occurred when invoking redirect and session invalidation on a servlet. After that happens, requests with same session id failed with the ISPN000299 continously. This issue can be occurred with a single EAP node.
> Full stacktrace is in the logs.zip.
> {code}
> 2019-10-01 20:22:42,655 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (async-thread--p22-t1) ISPN000136: Error executing command RemoveCommand, writing keys [SessionCreationMetaDataKey(Mvpa7i8iMTyGTgWLPVIr32P7fYzsUWAUQ2ZJIxkl)]: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey(Mvpa7i8iMTyGTgWLPVIr32P7fYzsUWAUQ2ZJIxkl) and requestor GlobalTx:jboss_node1:17. Lock is held by GlobalTx:jboss_node1:16
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:288)
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:218)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.checkState(InfinispanLock.java:436)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lambda$toInvocationStage$3(InfinispanLock.java:412)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:442)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> at java.lang.Thread.run(Thread.java:748)
> 2019-10-01 20:22:42,660 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /hello/redirect: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey(Mvpa7i8iMTyGTgWLPVIr32P7fYzsUWAUQ2ZJIxkl) and requestor GlobalTx:jboss_node1:17. Lock is held by GlobalTx:jboss_node1:16
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> at org.infinispan.cache.impl.CacheImpl.executeCommandWithInjectedTx(CacheImpl.java:1729)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1707)
> at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:632)
> at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:549)
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:363)
> at org.infinispan.cache.impl.EncoderCache.remove(EncoderCache.java:683)
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:363)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:131)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:119)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:43)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:87)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:37)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:388)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:208)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at com.example.RedirectServlet.doGet(RedirectServlet.java:28)
> ...
> Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key SessionCreationMetaDataKey(Mvpa7i8iMTyGTgWLPVIr32P7fYzsUWAUQ2ZJIxkl) and requestor GlobalTx:jboss_node1:17. Lock is held by GlobalTx:jboss_node1:16
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:288)
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:218)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.checkState(InfinispanLock.java:436)
> at org.infinispan.util.concurrent.locks.impl.InfinispanLock$LockPlaceHolder.lambda$toInvocationStage$3(InfinispanLock.java:412)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:442)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> ... 1 more
> Suppressed: org.infinispan.util.logging.TraceException
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:41)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:250)
> at org.infinispan.cache.impl.CacheImpl.executeCommandWithInjectedTx(CacheImpl.java:1729)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1707)
> at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:632)
> at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:549)
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:363)
> at org.infinispan.cache.impl.EncoderCache.remove(EncoderCache.java:683)
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:363)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:131)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:119)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove(InfinispanSessionMetaDataFactory.java:43)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:87)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(InfinispanSessionFactory.java:37)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:61)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:388)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:208)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at com.example.RedirectServlet.doGet(RedirectServlet.java:28)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> ... 1 more
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Dennis Reed (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2387:
-----------------------------------
> Workaround to make the warnings go away:
This would apply to the "no physical address" logs, but not the FD_ALL warnings (which only existed in a few versions).
The FD_ALL log was increased to WARN in
commit da67b146b55964cf168c73625d77cbdc66390d06
Author: Bela Ban <belaban(a)yahoo.com>
Date: Mon Jan 30 14:18:55 2017 +0100
FD_ALL / FD_SOCK: changed suspected peer log stmt from DEBUG -> WARN
But was overwritten by a later merge:
commit 89b5ea49a46946a08f9f4642641b2726683e5218
Date: Fri Aug 4 17:42:52 2017 +0200
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2387:
--------------------------------
OK, {{Test}} creates a cluster of 2 and a cluster of 1, and then has one of the non-members send to a member. This is clear; as the logical address cache will *not* contain the non-member's address, we will see the warning. However, it should disappear after conn_close_timeout ms.
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Dennis Reed (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Dennis Reed edited comment on JGRP-2387 at 10/3/19 11:40 AM:
-------------------------------------------------------------
> I'm wondering why the logical address cache in the transport would not have the address: unless the
> member to which we're trying to send the message has never been a member
Checking the logs from the original event, the FD_ALL warnings began just after the member left, with the "no physical address" warnings starting about 2 minutes (logical_addr_cache_expiration) later.
was (Author: dereed):
> I'm wondering why the logical address cache in the transport would not have the address: unless the
> member to which we're trying to send the message has never been a member
TP.java:handleDownEvent, case VIEW_CHANGE:
// fix for https://jira.jboss.org/jira/browse/JGRP-918
logical_addr_cache.retainAll(members);
So I had assumed this was expected. But now I see that's not a real map, and doesn't actually remove them.
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2387:
--------------------------------
Yes, retainAll() only _marks_ elements as REMOVABLE, but doesn't remove then until
* {{logical_addr_cache_max_size}} has been exceeded and
* {{logical_addr_cache_expiration}} has been exceeded
I've got a simple test case here and am experimenting with this now (attached).
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2387:
---------------------------
Attachment: bla6.java
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2387:
--------------------------------
Oops, just saw you already had a test attached, looking at it now...
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java, bla6.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Dennis Reed (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Dennis Reed edited comment on JGRP-2387 at 10/3/19 11:34 AM:
-------------------------------------------------------------
> I'm wondering why the logical address cache in the transport would not have the address: unless the
> member to which we're trying to send the message has never been a member
TP.java:handleDownEvent, case VIEW_CHANGE:
// fix for https://jira.jboss.org/jira/browse/JGRP-918
logical_addr_cache.retainAll(members);
So I had assumed this was expected. But now I see that's not a real map, and doesn't actually remove them.
was (Author: dereed):
> I'm wondering why the logical address cache in the transport would not have the address: unless the
> member to which we're trying to send the message has never been a member
TP.java:handleDownEvent, case VIEW_CHANGE:
// fix for https://jira.jboss.org/jira/browse/JGRP-918
logical_addr_cache.retainAll(members);
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Dennis Reed (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Dennis Reed commented on JGRP-2387:
-----------------------------------
> I'm wondering why the logical address cache in the transport would not have the address: unless the
> member to which we're trying to send the message has never been a member
TP.java:handleDownEvent, case VIEW_CHANGE:
// fix for https://jira.jboss.org/jira/browse/JGRP-918
logical_addr_cache.retainAll(members);
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.6
>
> Attachments: Test.java
>
>
> If an FD_ALL control message from a non-member is seen by FD_ALL, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years