Streambase - Advantages and disadvantages between EMS Acknowledge Mode Auto VS Explicit Client

[André Santos]

Hi Tibco Community,

If you have too chosse between two Acknowledge Modes Auto or Explicit Client, What would you choose, if you have for each secondmore and less 60 ems messages to display in live view amd ensure that all messages will be delivered and persistent

Any concerns about Big data transactions

Thanks a lot

Andr Santos

[Steve Barber]

Hi Andr,

 

I didn't see this question because you didn't set the product category to TIBCO Streaming. I set it for you.

 

This is, really, a question about EMS more than Streaming. 60 messages per second is not a particularly challenging message rate, assuming the messages aren't, like, gigabytes long each. So, either auto-ack or explicit client would be fine in terms of performance.

 

The difference in the ack models is more about whether a message will be re-delivered or not in case of some kind of failure during processing that message by the LiveView server. With auto-ack, the message is acknowledged back to the EMS server when it is consumed. With explicit ack, it is acknowledged, well, when it is explicitly acknowledged.

 

So, if a message is auto-acked by the EMS Consumer operator, but the LiveView server process fails before the the message is processed by the LiveView app (published to a LiveView data table), then the LiveView client will never have a chance to observe whatever changes that message caused to a LiveView table.

 

With explicit ack, you could have the message acked back to EMS after any table publications are completed. In that case, the message will be re-delivered to LiveView if LiveView fails before the ack is made, which may result in a duplicate publication to the table upon re-processing.

 

So, either way: you could have a gap or a dup, depending on the ack mode. Dups are usually better than gaps, but not always. There's a protocol for LiveView table recovery in which you can coordinate recovery with an upstream source using an embedded publisher application: there is one that you can generate for an EMS Consumer; maybe have a look at that and see if it gives you the quality of service you want in terms of gap avoidance and duplicate detection. It might be that application level sequence numbers in your EMS message stream is the only way out of this to achieve once-and-only-once processing, though that may be a more stringent requirement than you need (you only asked for delivered and persistent -- those terms are maybe more from the EMS broker's perspective, not LiveView's).