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
The question is how do we verify message acknowledgement in the TCK? It's a reasonably fundamental feature of the spec, so important to verify, but there are a number of challenges:
Some messaging providers may only acknowledge every n messages, assuming idempotent messaging.
Some messaging providers may not retry on failure, rather they might send failed messages to a dead letter queue.
I think the second point there is actually not an issue. The messaging spec is a spec for handling messages as a stream. When handling messages as a stream, messages don't fail, the stream does. Any failure that comes from the stream may or may not be related to a particular message, but the stream doesn't and can't tell you that. When a failure occurs, all you have is an exception, and zero or more unacknowledged messages. And I'm pretty sure all queues that support acknowledgement can at least be run in a mode where messages are retried if the message is neither acked nor nacked.
As for message providers that only acknowledge every n messages, we could potentially require that the configuration for the TCK is n == 1, even if that's not the default.
The text was updated successfully, but these errors were encountered:
The question is how do we verify message acknowledgement in the TCK? It's a reasonably fundamental feature of the spec, so important to verify, but there are a number of challenges:
I think the second point there is actually not an issue. The messaging spec is a spec for handling messages as a stream. When handling messages as a stream, messages don't fail, the stream does. Any failure that comes from the stream may or may not be related to a particular message, but the stream doesn't and can't tell you that. When a failure occurs, all you have is an exception, and zero or more unacknowledged messages. And I'm pretty sure all queues that support acknowledgement can at least be run in a mode where messages are retried if the message is neither acked nor nacked.
As for message providers that only acknowledge every n messages, we could potentially require that the configuration for the TCK is n == 1, even if that's not the default.
The text was updated successfully, but these errors were encountered: