Siddhi allows you to manage any faults that may occur when handling streaming data in a graceful manner. This section explains the different ways in which the faults can be handled gracefully.
Handling runtime errors
To specify how errors that occur at runtime, you need to add an
@OnError annotation to a stream definition as shown below.
The on_error_action parameter specifies the action to be executed during failure scenarios. The possible action types are as follows:
LOG: This logs the event with an error, and then drops the event. If you do not specify the fault handling actionvia the
LOGis considered the default action.
STREAM: This automatically creates a fault stream for the base stream. The definition of the fault stream includes all the attributes of the base stream as well as an additional attribute named
_error. The events are inserted into the fault stream during a failure. The error identified is captured as the value for the
e.g., The following is a Siddhi application that includes the
@OnError annotation to handle failures during runtime.
Here, if an error occurs for the base stream named
StreamA, a stream named
!StreamA is automatically created. The base stream has two attributes named symbol and volume. Therefore,
!StreamA has the same two attributes, and in addition, another attribute named
The Siddhi query uses the
custom:fault() extension generates the error detected bsed on the specified condition (i.e., if the volume is less than a specified amount). If no error is detected, the output is inserted into
StreamB stream. However, if an error is detected, it is logged with the
Error Occured text. The output is inserted into a stream named
tempStream, and the error details are presented via the
_error stream attribute (which is automatically included in the
!StreamA i fault stream and then inserted into the TempStream which is the inferred output stream)..
Handling errors that occur when publishing the output
To specify the error handling methods for errors that occur at the time the output is published, you can include the on.error parameter in the sink configuration as shown below.
The action types that can be specified via the
on.error parameter when configuring a sink are as follows. If this parameter is not included in the sink configuration,
LOG is the action type by default.
LOG: Logs the event with the error, and then drops the event.
WAIT: The thread waits in the
back-off and re-tryingstate, and reconnects once the connection is re-established.
STREAM: The corresponding fault stream is populated with the failed event and the error that occured while publishing.