GH-101: Rename DeDup Classes/Interfaces to Filter #104
Conversation
|
I think I'm fine with the solution. |
|
|
||
| private final AcknowledgingMessageListener<K, V> delegate; | ||
|
|
||
| private final boolean ackDiscarded; |
There was a problem hiding this comment.
Shouldn't we add this option into the MessagingMessageListenerAdapter as well?
There was a problem hiding this comment.
Yeah - I was hoping to avoid that 😄
There was a problem hiding this comment.
Trying to imagine a use case where not acknowledging a discarded message would be useful.
There was a problem hiding this comment.
They might be acking manually on some condition (special marker record perhaps and not want random acks being done on their behalf.
I guess I am just a bit uncomfortable issuing automatic acks when they have specifically requested to use manual acks.
There was a problem hiding this comment.
Ah, I see. An option gives a choice then. Should we at least make this true by default - otherwise, in the case of manual acks, they would almost never have a chance to ack those messages and there's no chance that they would ack them in the future on replay - so unless there's a message that they're interested in, this would keep redelivering messages on each restart.
|
Pushed - @artembilan - it's a bit simpler now, if the container listener factory is configured - we wrap the MMLA with a filtering adapter. |
|
The trouble with making it true by default is it really can only be used of the AckMode is set to one of the MANUAL options. |
| } | ||
| } | ||
| else { | ||
| container.setupMessageListener(messageListener); |
There was a problem hiding this comment.
We can still have this line of code without duplication in each if...else.
Minor, of course.
Will polish on merge.
|
Merged as b1dc76e |
3 participants
Resolves #101