Engine flow control support #227
Conversation
…that inteface can be paused/resumed by the engine.
|
@vijaynalawade I am thining the controller should be app-specific, can we move it as an method of app. such as: Users may don't need a controller for most cases. so can we add an env var to control it? by default, there is no controller |
app/controller.go
Outdated
| controller.triggers[id] = t | ||
| } | ||
| } | ||
| go controller.startController() |
There was a problem hiding this comment.
if you have no flow control aware triggers then why start the controller?
There was a problem hiding this comment.
@mellistibco Fixed in latest update.
| // Resume triggers | ||
| log.RootLogger().Info("Resuming Triggers...") | ||
| for _, trg := range c.triggers { | ||
| err := trg.Resume() |
There was a problem hiding this comment.
debug log to say which triggers have been resumed?
There was a problem hiding this comment.
@mellistibco Fixed in latest update.
|
agree with @lixingwang. I think in most scenarios the user will not use this... |
|
@mellistibco @lixingwang Please review latest update. |
What kind of change does this PR introduce? (check one with "x")
Fixes: #
#226
What is the current behavior?
Today, engine will simply accept as many events as possible(Direct Runner) or block trigger go-routines when worker queue is full(Pooled Runner). This could lead to a performance issue or even loss of events due to resource constrains like CPU and Memory or blocked workers(Pooled runner). This might also lead to engine crash.
What is the new behavior?
Added new interface that Trigger implementations can implement to support pause/resume. Also added a mechanism that can force pausing/resuming of triggers. The flow control policies are in not scope of this PR.