All docs This doc
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.

@OnError(action='on_error_action') define stream <stream name> (<attribute name> <attribute type>, <attribute name> <attribute type>, ... );

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 @OnError annotation, LOG is 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 _error attribute.

e.g.,  The following is a Siddhi application that includes the @OnError annotation to handle failures during runtime.

@OnError(name='STREAM') define stream StreamA (symbol string, volume long); from StreamA[custom:fault() > volume] insert into StreamB; from !StreamA#log("Error Occured") select symbol, volume long, _error insert into tempStream;

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 _error.


Handling errors that occur when publishing the output

To specify the error handling methiods 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.

@sink(type='sink_type', on.error='on.error.action') define stream <stream name> (<attribute name> <attribute type>, <attribute name> <attribute type>, ... );

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-trying state, 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.
  • No labels