Hello,
KIP-418 (>=2.8) improved the branching return type from KStream<>[] to HashMap.
This changes the output binding when using multiple branches in the Kafka
Streams binder of Spring Cloud Stream - the bindings are possibly wrong because
the map storing the KStream branches is unordered.
Before KIP-418, if I have multiple branches, my function could look like this:
public Function<KStream<String, String>, KStream<String, String>[]> process() {
Predicate<String, String> isHappy = (k, v) -> v.contains(":D");
Predicate<String, String> isSad = (k, v) -> v.contains(":(");
Predicate<String, String> isOwo = (k, v) -> v.toLowerCase().contains("owo");
return input.branch(isHappy, isSad, isOwo);
}
There is an output binding for each branch. Since the return type is a
KStream[] where the order of branches matches the supplied order, the
corresponding output bindings are process-out-0 (isHappy), process-out-1
(isSad), process-out-2 (isOwo).
This changes when using the new branching impl:
public Function<KStream<String, String>, KStream<String, String>[]> process() {
return input -> {
final Map<String,KStream<String, String>> streamMap = input
.split()
.branch(isHappy)
.branch(isSad)
.branch(isOwo)
.noDefaultBranch();
return streamMap.values().toArray(new KStream[0]);
}
}
The call to HashMap<>.values() doesn't necessarily return the KStreams in
supplied/insertion order. For example, if the order of KStreams in the return
corresponds to isSad, isOwo, isHappy, the output bindings would become
process-out-0 (isSad), process-out-1 (isOwo), process-out-2 (isHappy) -
different from expected. If the map was ordered like a LinkedHashMap, the
return order and thus the bindings would be correct.
Is this intended behaviour with KIP-418? If so, will the deprecated branching
methods be kept indefinitely for multiple output bindings to bind correctly?
