[JBoss JIRA] (DROOLS-4601) Escape characters added to code after editing comma separated list in guided rule editor
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-4601?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-4601:
---------------------------------
Description: In guided rules, if you create a rule with a comma separated list, quotes are automatically added to the text box when saving the rule. If you then need to edit the values, quotes are again added, which results in escape characters in the source code making the rule no longer work
> Escape characters added to code after editing comma separated list in guided rule editor
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-4601
> URL: https://issues.jboss.org/browse/DROOLS-4601
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
>
> In guided rules, if you create a rule with a comma separated list, quotes are automatically added to the text box when saving the rule. If you then need to edit the values, quotes are again added, which results in escape characters in the source code making the rule no longer work
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4574) Scenario test: UX to add an expression-based value.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4574?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4574:
-------------------------------------------
[~danielezonca] [~gabriolo] [~ibek] I posted a click-thru proposal, here are the key features:
* Any scenario cell can support an expression based value, if the user starts the value declaration with the appropriate symbol (tbd). I used # in my examples.
* A statement column may be set to accept complex expressions that reference any field in the Data Object. To set the column in this way the user needs to select the parent Data Object for that column, which will declare the property value as "expression."
- If the column is set as an expression, each cell in that column will include the symbol to set the expression by default, as this is a required format for the whole column. The symbol will be present both as hint text and will pre-populate the editable field view. If the user backs it out, the system will add it back in.
- To support List, I maintained the current interaction using the dialog. I added a radio set input selection to toggle between either Create a list using the guided experience, or to Define an expression.
I believe this current mock covers all of the Required elements, but I will be updating it to also include a minimal solution for inputting long values, as discussed with [~danielezonca]
> Scenario test: UX to add an expression-based value.
> ----------------------------------------------------
>
> Key: DROOLS-4574
> URL: https://issues.jboss.org/browse/DROOLS-4574
> Project: Drools
> Issue Type: Story
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: Screen Shot 2019-10-01 at 8.27.30 AM.png
>
>
> As a technical/advanced user (Cameron), I want to be able to input expression-based values in scenario given/expect row cells, so that I can define inputs for complex objects and logic.
> Note: Syntax highlighting and etc., are out of scope. Refer to: https://issues.jboss.org/browse/DROOLS-3514
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2389) Message from a non-member causes FD_ALL to continually suspect it
by Pedro Zapata Fernandez (Jira)
Pedro Zapata Fernandez created JGRP-2389:
--------------------------------------------
Summary: Message from a non-member causes FD_ALL to continually suspect it
Key: JGRP-2389
URL: https://issues.jboss.org/browse/JGRP-2389
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Pedro Zapata Fernandez
Assignee: Bela Ban
Fix For: 4.1.6
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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month
[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)
6 years, 1 month