You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally what we'd like to see is some kind of Failure Policy (call back) that provides:
a). the number of consecutive failures (thus far).
b). the amount of time those failures have occurred over.
c). the total number of failures.
d). the amount of time those failures have occurred over.
e). the amount of events currently queued.
f). the exception that occurred / caused the failure.
g). an option over what to do next, those being; "continue" to distributed events, "suspend" distribution of events, "stop" distribution of events.
Using this developers can control and intercept what should happen when failures occur.
The default FailurePolicy would be implemented much as we do now = suspend after a number of consecutive failures.
The text was updated successfully, but these errors were encountered:
This should be done in the event-distributor.
Ideally what we'd like to see is some kind of Failure Policy (call back) that provides:
a). the number of consecutive failures (thus far).
b). the amount of time those failures have occurred over.
c). the total number of failures.
d). the amount of time those failures have occurred over.
e). the amount of events currently queued.
f). the exception that occurred / caused the failure.
g). an option over what to do next, those being; "continue" to distributed events, "suspend" distribution of events, "stop" distribution of events.
Using this developers can control and intercept what should happen when failures occur.
The default FailurePolicy would be implemented much as we do now = suspend after a number of consecutive failures.
The text was updated successfully, but these errors were encountered: