Fix #63 - Clarify the NONE ack policy usage #66
Conversation
| @@ -699,6 +698,10 @@ public Message<Integer> process(KafkaMessage<String, Integer> input) { | |||
| } | |||
| ---- | |||
|
|
|||
| The `NONE` acknowledgment strategy indicates that the message is not acknowledged by the method (neither implicitly nor explicitly). | |||
| However, note that all incoming messages must be acknowledged, so using `NONE` indicates that the message is acknowledged in a different location or using a different mechanism. | |||
There was a problem hiding this comment.
This could benefit from something more to differentiate it from "MANUAL:managed by the user code". Do you mean that myMessage.ack() still needs to be called but just not in this method or is it referring to Kafka layer acknowledgement must still be done for example?
There was a problem hiding this comment.
It is difficult to explain - without introducing the concept that we may be sending 1 message to more than 1 receiver (which is a concept that is not in the spec currently).
There was a problem hiding this comment.
If the difference is in effect then it might help to explain what the effect ( of having NONE versus MANUAL) is expected to be. For example.
"Specifying 'NONE' allows for this method to complete processing and return without handling acknowledgement and for this to be considered valid behaviour of the method.
However, if messages were never acknowledged this would result in
a build up of unacknowledged messages in the system as no
automatic acknowledgement will be done when 'NONE' is specified.
When 'NONE' is specified, each message object's ack() method should still be invoked
once as part of the overall processing but this is considered valid behaviour
either before, during or after this method's execution."
There was a problem hiding this comment.
"Specifying 'NONE' allows for this method to complete processing and return without handling acknowledgment and for this to be considered valid behavior of the method.
Yes.
When 'NONE' is specified, each message object's ack() method should still be invoked
once as part of the overall processing but this is considered valid behaviour
either before, during or after this method's execution."
Exactly
I'm going to update the PR with this content.
There was a problem hiding this comment.
"Specifying 'NONE' allows for this method to complete processing and return without handling acknowledgement and for this to be considered valid behaviour of the method.
However, if messages were never acknowledged the NONE policy would result in
a build up of unacknowledged messages in the system as no
automatic acknowledgement will be done when 'NONE' is specified.
When 'NONE' is specified, each message object's ack() method should still be invoked
once as part of the overall processing but this is considered valid behaviour
either before, during or after this method's execution."
| @@ -699,6 +698,10 @@ public Message<Integer> process(KafkaMessage<String, Integer> input) { | |||
| } | |||
| ---- | |||
|
|
|||
| The `NONE` acknowledgment strategy indicates that the message is not acknowledged by the method (neither implicitly nor explicitly). | |||
| However, note that all incoming messages must be acknowledged, so using `NONE` indicates that the message is acknowledged in a different location or using a different mechanism. | |||
There was a problem hiding this comment.
If the difference is in effect then it might help to explain what the effect ( of having NONE versus MANUAL) is expected to be. For example.
"Specifying 'NONE' allows for this method to complete processing and return without handling acknowledgement and for this to be considered valid behaviour of the method.
However, if messages were never acknowledged this would result in
a build up of unacknowledged messages in the system as no
automatic acknowledgement will be done when 'NONE' is specified.
When 'NONE' is specified, each message object's ack() method should still be invoked
once as part of the overall processing but this is considered valid behaviour
either before, during or after this method's execution."
Signed-off-by: Clement Escoffier <clement.escoffier@gmail.com>
cescoffier
force-pushed
the
features/clarify-ack-none
branch
from
de41f62
to
8586972
Compare
|
@hutchig I've updated the PR with your text. |
No description provided.