Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Update Interval in NSRule #253

Closed
mrutid opened this issue Jul 31, 2017 · 4 comments
Closed

[BUG] Update Interval in NSRule #253

mrutid opened this issue Jul 31, 2017 · 4 comments
Labels
Milestone

Comments

@mrutid
Copy link
Member

mrutid commented Jul 31, 2017

No description provided.

@fgalan fgalan added the bug label Jul 31, 2017
@fgalan
Copy link
Member

fgalan commented Aug 2, 2017

I have done the following test on a Perse-FE 1.3.1 version (IoTP Partners envioronment) using the configuration portal (VR interface):

  • 9:52: create a rule with two cards: entity type "test" + no signal with 60s and 11 min as checking interval, sending an email as result.
  • 10:46: rule update to 17 min interval, all the other parameters the same
  • 11:40: rule update to 19 min interval, all the other parameters the same
  • 13:00: deleting the rule

The result is the following:

imagen

It seems that each time the rule is updated a new timer is added instead of modifying the existing timer. At the end, after creation plus two updates, the rule has 3 timers at the same time (probably updating a third time before deleting will end in a fourth timer... although I haven't actually tested).

Deleting the rule seems to remove all timers (although I'm not sure if this a "complete clenaup" or the internal timer structure stills being dirty after deleting with some stale data).

Another (minor) fact in this test is the initial notification a 10:02. This is out of sync of the first time (the only one just after creating the rule), maybe it is a kind of creation-time glitch...

@fgalan
Copy link
Member

fgalan commented Aug 2, 2017

A comparison of 1.3.1 vs 1.5.0 code and internal logic make us think that this could has been fixed in 1.5.0. Thus, the procedure above should be reproduced in 1.5.0 in order to see what's happen.

@mrutid
Copy link
Member Author

mrutid commented Aug 3, 2017

What if...?
Maybe the problem, as Fermin said, is related with HA. Explore scenario with CEP A and CEP B, both sync via noSignal.refreshAllRules() (where rules are read from Mongo, then Added, and last Removed if they were not in mongo).

In our case POST /rule could be processed by CEP A, PUT /rule could be processed by CEP B. Then when A syncs it reads and adds the modified Rule, with the new period. But never remove the timer because the rule is in both sets:

_// remove old rules not in the new set
    deleteNSRuleIf(function(srv, subsrv, nm) { 
      return !ruleSet.includes(srv, subsrv, nm);
 });`_

Remarks:

DeleteNSRule is the only one in charge of remove timers. 
Usual PUT/Modify performs always a DeleteRule prior to the AddRule.
It could be simulated by inserting a modified Rule directly in mongo.

@fgalan
Copy link
Member

fgalan commented Aug 4, 2017

Fixed by PR #255

@fgalan fgalan added this to the 1.6.0 milestone Aug 4, 2017
@fgalan fgalan closed this as completed Aug 4, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants