This content has been marked as final. Show 8 replies
The CEP inbound adapter will commit the transaction (and acknowledge the message) when the adapter thread processing the message returns successfully to the adapter from any downstream components in the EPN. If an exception is thrown while running on the adapter thread downstream from the adapter and propagated back to the adapter the transaction will be rolled back and the message is redelivered.
The important point to note is that if there is a thread switch downstream from the adapter (e.g. there is a channel in the event flow with max-threads > 0, or there is some other mechanism that causes the event to be queued and picked up by another thread), the processing done by the new downstream thread won't normally affect the success or failure of the transaction. All that is required for the transaction to commit is for the adapter thread handling the message to return successfully.
Thanks for the helpful answer.
To complecate things a little bit:
In our appication, downstrean for the JMS inbound adapter there is a CQL that aggregates events using a time window. When the time window elapses it sends downstrean a new event (non of the original events that the time window picked).
What happens to the original events if in the middle of the time window there is an exception? Are the original events returned back (rolled back) to the JMS inbound queue?
What happens to events that are in a middle of a transaction and the CEP server fails? (complete server failure like power loss)
884793 wrote:The CQL engine does not create threads - threads are used from either the channel (if it has a threading constraint set) or the adapter (e.g through the use of RunnableBean), so thread context switches will only occur in the channel or in custom code where you are creating your own threads.
Is there some documentation or a list describing what can be considered a thread switch (what "breaks" the transaction)?
For example: Does time windows, pattern matching or putting a bean after the processor will cause the thread to switch (transaction is broken)?
Does time window also constitutes thread switch?
When I am using a time window and the CEP process fails (server is terminated unexpectedly) the events that the time window already aggregated are not returned back to the JMS queue.
I don't use any user code or max threads on the channel.
Yes, a time window can involve a thread switch. The original thread may queue the events in the window and subsequent processing of the event would be done on a timer thread. In this case it is possible for the adapter thread to return and commit the message (so the message is removed from the JMS queue) and then there can be a subsequent error or failure.
We're considering a new feature for a future release that would make it easier to detect and handle exceptions in processing the event downstream from a query with a time window - so for example you could explicitly requeue the JMS message or take some other compensating action in the case of an exception after the thread switch. As it stands today your ability to detect and handle these downstream exceptions may depend on the details of your application and EPN (e.g. do you have a Java POJO that could catch the exception downstream from the processor but upstream from the source of the exception).
You mentioned the specific case of complete server crash/failure. If you're concerned about this case you may want to consider using a CEP server cluster with the high availability feature. In this configuration, you'd also have one or more backup servers subscribing to the JMS input so if the primary server fails completely the backup would also get the message and would pick up the processing of any events that hadn't been fully processed by the primary.
To the best of my understanding (maybe I am wrong) when using a time wimdow the thread is broken in the processor. Using a POJO downstream from the processor will help catch exception but it won't be able to rollback what the processor holds. Is my understanging correct?
Do you have time estimate to the new feature you are looking to add?
Yes, there will be a thread switch in the processor when using a time window.
If you catch an exception in a downstream POJO you may or may not be able to easily recover precisely. At this point you can't rollback the actual JMS transaction that generated the input event. But you may be able to retry the processing of the event that caused the exception from the point at which you caught the exception, or take some other recovery action. This would require some custom code in the POJO and the details would be very dependent on the application and the specific cause of the exception.
I'm afraid I can't provide any commitments or details about planned features.