[
https://issues.apache.org/jira/browse/GEODE-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006267#comment-17006267
]
ASF subversion and git services commented on GEODE-7623:
--------------------------------------------------------
Commit 36cb801582b4168a319586ebd3a9cdeee4ec2d5c in geode's branch
refs/heads/feature/GEODE-7634 from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=36cb801 ]
GEODE-7623: Preventing recursion in alert generation
After the change to send alerts in a executor, there was a possibiltiy for
sending alerts to generate new alerts, resulting an in infinite loop.
Setting the AlertingAction threadlocal in the executor thread that is sending
alerts, to prevent recursion.
Adding a test that we do not generate recursive alert messages.
> AlertingAction thread local looks like it will no longer have any effect
> ------------------------------------------------------------------------
>
> Key: GEODE-7623
> URL: https://issues.apache.org/jira/browse/GEODE-7623
> Project: Geode
> Issue Type: Bug
> Components: logging, membership
> Reporter: Dan Smith
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> From code inspection, it looks like the changes in dffcb944 have made the
> AlertingAction class effectively useless.
> The class has a thread local that is set when we start sending an alert. But
> dffcb944 changed the alert process such that shortly after the thread local
> is set, the bulk of the alerting logic happens in a *separate* thread,
> without the thread local, in ClusterAlertMessaging.sendAlert.
> Therefore, this thread local has no effect. If this behavior was previously
> useful, we need to set the thread local inside this new executor thread,
> perhaps? Or find some other way to prevent the executor from triggering new
> alerts?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
