You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/01/01 00:18:00 UTC

[jira] [Commented] (GEODE-7623) AlertingAction thread local looks like it will no longer have any effect

    [ 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)