[
https://issues.apache.org/jira/browse/KAFKA-15116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779725#comment-17779725
]
A. Sophie Blee-Goldman commented on KAFKA-15116:
------------------------------------------------
I tend to agree with Matthias here – this is definitely not a bug in Kafka
Streams, and the behavior you describe in the most recent message sounds like
it is working as intended. You can certainly disable cooperative rebalancing by
setting the UPDATE_FROM config to something 2.3 or below, but as [~mjsax]
mentioned, we plan to remove support for eager rebalancing entirely in an
upcoming release so this would only be a temporary fix at best.
I say "at best" because it sounds to me like even without cooperative
rebalancing, you're relying on implementation details that are not part of the
public contract. That's not an accusation, it just means you're putting
yourself at risk of breaking changes to your application, like cooperative
rebalancing, because the semantics around when to commit are considered
internal to Kafka Streams and can change at any time.
That said, I do agree that it would be nice if Streams had better support for
blocking operations or long-running RPCs. Unfortunately that's just not the
case at the moment, so you kind of have to take what you can get, or else
rewrite as a plain producer/consumer app. Honestly, while I'm a big believer
that almost any kind of application that follows the consume-process-produce
pattern can and should be represented as a Streams app, I think this might be
one of the few exceptions where it really does make more sense to implement
with the plain clients. It sounds like part of the application logic is already
driven by an external consumer, which together with the fact that you have
strict requirements around committing as well as a shared state with external
calls, indicates to me that Streams may not be the right tool for the job. Sort
of by definition Streams is supposed to abstract away all the client
interactions and all the offset commit logic, in addition to being shardable
such that everything you need to process a stream of records for a given
partition is local to that shard. So it's hard to imagine how to fit your
application logic into a Streams app in a completely "safe" way.
Again, this doesn't mean you can't/shouldn't try to stretch the boundaries of
Kafka Streams, but I think it makes sense to close this ticket as a bug given
that everything is working as intended. However I'd encourage you to consider
filing a "New Feature" ticket for some specific functionality that would help
with your use case. I believe there is already one for better blocking API/RPC
support, but I think the ability to pause processing in Kafka Streams would be
nice to have in general, and could be used to pause Streams during a rebalance
to solve the issue you're facing.
Hope that all makes sense! If you do want to consider rewriting this with the
plain clients, I'm happy to give some pointers. It sounds like your Streams
application is very complex already so I have to wonder if it might be more
simple to write up outside the framework of Kafka Streams
> Kafka Streams processing blocked during rebalance
> -------------------------------------------------
>
> Key: KAFKA-15116
> URL: https://issues.apache.org/jira/browse/KAFKA-15116
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 3.5.0
> Reporter: David Gammon
> Priority: Major
>
> We have a Kafka Streams application that simply takes a messages, processes
> it and then produces an event out the other side. The complexity is that
> there is a requirement that all events with the same partition key must be
> committed before the next message is processed.
> This works most of the time flawlessly but we have started to see problems
> during deployments where the first message blocks the second message during a
> rebalance because the first message isn’t committed before the second message
> is processed. This ultimately results in transactions timing out and more
> rebalancing.
> We’ve tried lots of configuration to get the behaviour we require with no
> luck. We’ve now put in a temporary fix so that Kafka Streams works with our
> framework but it feels like this might be a missing feature or potentially a
> bug.
> +Example+
> Given:
> * We have two messages (InA and InB).
> * Both messages have the same partition key.
> * A rebalance is in progress so streams is no longer able to commit.
> When:
> # Message InA -> processor -> OutA (not committed)
> # Message InB -> processor -> blocked because #1 has not been committed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
