-
Notifications
You must be signed in to change notification settings - Fork 1.7k
GH-101: Rename DeDup Classes/Interfaces to Filter #104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,66 @@ | ||
/* | ||
* Copyright 2016 the original author or authors. | ||
* | ||
* Licensed under the Apache License, Version 2.0 (the "License"); | ||
* you may not use this file except in compliance with the License. | ||
* You may obtain a copy of the License at | ||
* | ||
* http://www.apache.org/licenses/LICENSE-2.0 | ||
* | ||
* Unless required by applicable law or agreed to in writing, software | ||
* distributed under the License is distributed on an "AS IS" BASIS, | ||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
* See the License for the specific language governing permissions and | ||
* limitations under the License. | ||
*/ | ||
|
||
package org.springframework.kafka.listener.adapter; | ||
|
||
import org.apache.kafka.clients.consumer.ConsumerRecord; | ||
|
||
import org.springframework.kafka.listener.AcknowledgingMessageListener; | ||
import org.springframework.kafka.support.Acknowledgment; | ||
|
||
/** | ||
* A {@link AcknowledgingMessageListener} adapter that implements filter logic | ||
* via a {@link RecordFilterStrategy}. | ||
* | ||
* @param <K> the key type. | ||
* @param <V> the value type. | ||
* | ||
* @author Gary Russell | ||
* | ||
*/ | ||
public class FilteringAcknowledgingMessageListenerAdapter<K, V> extends AbstractFilteringMessageListener<K, V> | ||
implements AcknowledgingMessageListener<K, V> { | ||
|
||
private final AcknowledgingMessageListener<K, V> delegate; | ||
|
||
private final boolean ackDiscarded; | ||
|
||
/** | ||
* Create an instance with the supplied strategy and delegate listener. | ||
* @param recordFilterStrategy the filter. | ||
* @param delegate the delegate. | ||
* @param ackDiscarded true to ack (commit offset for) discarded messages. | ||
*/ | ||
public FilteringAcknowledgingMessageListenerAdapter(RecordFilterStrategy<K, V> recordFilterStrategy, | ||
AcknowledgingMessageListener<K, V> delegate, boolean ackDiscarded) { | ||
super(recordFilterStrategy); | ||
this.delegate = delegate; | ||
this.ackDiscarded = ackDiscarded; | ||
} | ||
|
||
@Override | ||
public void onMessage(ConsumerRecord<K, V> consumerRecord, Acknowledgment acknowledgment) { | ||
if (!filter(consumerRecord)) { | ||
this.delegate.onMessage(consumerRecord, acknowledgment); | ||
} | ||
else { | ||
if (this.ackDiscarded) { | ||
acknowledgment.acknowledge(); | ||
} | ||
} | ||
} | ||
|
||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -329,7 +329,7 @@ public void listen(@Payload String foo, | |
} | ||
---- | ||
|
||
===== Handling Duplicates | ||
===== Filtering Messages | ||
|
||
In certain scenarios, such as rebalancing, a message may be redelivered that has already been processed. | ||
The framework cannot know whether such a message has been processed or not, that is an application-level | ||
|
@@ -339,15 +339,15 @@ Receiver] pattern and Spring Integration provides an | |
http://docs.spring.io/spring-integration/reference/html/messaging-endpoints-chapter.html#idempotent-receiver | ||
[implementation thereof]. | ||
|
||
|
||
The Spring for Apache Kafka project also provides some assistance by means of the `DeDuplicatingMessageListenerAdapter` | ||
The Spring for Apache Kafka project also provides some assistance by means of the `FilteringMessageListenerAdapter` | ||
classe, which can wrap your `MessageListener`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. typo: class There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The typo hasn't been fixed. Strange that my comment on the matter had gone. |
||
This class takes an implementation of `DeDuplicationStrategy` where you implement the `isDuplicate` method to signal | ||
This class takes an implementation of `RecordFilterStrategy` where you implement the `filter` method to signal | ||
that a message is a duplicate and should be discarded. | ||
|
||
Similarly, when using `@KafkaListener`, the `DeDuplicationStrategy` can be injected into the container factory. | ||
Similarly, when using `@KafkaListener`, the `RecordFilterStrategy` can be injected into the container factory. | ||
|
||
A wrapper is not provided for the `AcknowledgingMessageListener` because you might need to acknowledge the duplicated | ||
message. | ||
A `FilteringAcknowledgingMessageListenerAdapter` is also provided for wrapping an `AcknowledgingMessageListener`. | ||
This has an additional property `ackDiscarded` which indicates whether the adapter should acknowledge the discarded record. | ||
|
||
==== Serialization/Deserialization and Message Conversion | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we add this option into the
MessagingMessageListenerAdapter
as well?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I was hoping to avoid that 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to imagine a use case where not acknowledging a discarded message would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.