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
Resolves#731
- Auto detect reply topic/partition
- Improve docs to explain how to use a shared reply topic
- Add boolean to reduce log level for unexpected responses
* Polishing - PR Comments
return new ReplyingKafkaTemplate<>(pf, replyContainer);
388
388
}
389
389
390
390
@Bean
391
391
public KafkaMessageListenerContainer<String, String> replyContainer(
392
392
ConsumerFactory<String, String> cf) {
393
+
393
394
ContainerProperties containerProperties = new ContainerProperties("kReplies");
394
395
return new KafkaMessageListenerContainer<>(cf, containerProperties);
395
396
}
@@ -407,7 +408,7 @@ public class KRequestingApplication {
407
408
}
408
409
----
409
410
410
-
In addition to the reply topic header set by user code, the template sets a header `KafkaHeaders.CORRELATION_ID` which must be echoed back by the server side.
411
+
The template sets a header `KafkaHeaders.CORRELATION_ID` which must be echoed back by the server side.
411
412
412
413
In this case, simple `@KafkaListener` application responds:
413
414
@@ -444,9 +445,23 @@ public class KReplyingApplication {
444
445
445
446
The `@KafkaListener` infrastructure echoes the correlation id and determines the reply topic.
446
447
447
-
See <<annotation-send-to>> for more information about sending replies; in this case we use the default header `KafKaHeaders.REPLY_TOPIC` to indicate which topic the reply goes to.
448
+
See <<annotation-send-to>> for more information about sending replies; the template uses the default header `KafKaHeaders.REPLY_TOPIC` to indicate which topic the reply goes to.
449
+
450
+
Starting with version 2.2, the template will attempt to detect the reply topic/partition from the configured reply container.
451
+
If the container is configured to listen to a single topic or a single `TopicPartitionInitialOffset`, it will be used to set the reply headers.
452
+
If the container is configured otherwise, the user must set up the reply header(s); in this case, an INFO log is written during initialization.
When configuring with a single reply `TopicPartitionInitialOffset`, you can use the same reply topic for multiple templates, as long as each instance listens on a different partition.
460
+
When configuring with a single reply topic, each instance must use a different `group.id` - in this case, all instances will receive each reply, but only the instance that sent the request will find the correlation id.
461
+
This may be useful for auto-scaling, but with the overhead of additional network traffic and the small cost of discarding each unwanted reply.
462
+
When using this setting, it is recommended that you set the template's `sharedReplyTopic` to true, which will reduce the logging level of unexpected replies to DEBUG instead of the default ERROR.
448
463
449
-
IMPORTANT: If you have multiple client instances, each will need a dedicated reply topic for each instance.
464
+
IMPORTANT: If you have multiple client instances, and you don't configure them as discussed in the paragraphe above, each instance will need a dedicated reply topic.
450
465
An alternative is to set the `KafkaHeaders.REPLY_PARTITION` and use a dedicated partition for each instance; the `Header` contains a 4 byte int (Big-endian).
451
466
The server must use this header to route the reply to the correct topic (`@KafkaListener` does this).
452
467
In this case, though, the reply container must not use Kafka's group management feature and must be configured to listen on a fixed partition (using a `TopicPartitionInitialOffset` in its `ContainerProperties` constructor).
0 commit comments