Thanks, Boyang,

I maintain a framework (Spring for Apache Kafka) that sits on top of the
clients, and I would like to be able to support all broker versions. I
don't have control over what brokers my users are using.

You guys have done a great job since 0.10.2.0 (I think) of supporting older
brokers from newer clients but this one's a blocker for me.

My framework will enforce the proper semantics for EOS, depending on the
broker version, but I need to know which model to use at runtime.

As I said, I can have a property that the user can set to tell the
framework that the broker is >= 2.5 but it would be cleaner if I could stay
away from that.

Something like KafkaAdminClient.brokerApi() (or add the lowest API/broker
version to describeCluster()), would be helpful.

Worst case, I'll add a configuration option.

Thanks.

On Thu, Apr 2, 2020 at 4:45 PM Boyang Chen <reluctanthero...@gmail.com>
wrote:

> Thanks for the question Gary. The reasoning for crash the new
> sendTxnOffsets API is because we don't want users to unconsciously violate
> the EOS guarantee. In your case, using this API with 2.4.1 is not supported
> anyway, so the upgrade path has to start from broker first to 2.5, and then
> client binaries. Is there any further concern that blocks you from getting
> the broker side upgrade first before using the new API?
>
> Boyang
>
> On Thu, Apr 2, 2020 at 1:37 PM Gary Russell <gruss...@pivotal.io> wrote:
>
> > Is there any way to determine the broker version in the kafka-clients?
> >
> > I need to determine whether I can use the new  sendOffsetsToTransaction
> > with ConsumerGroupMetadata or use the old one.
> >
> > If I use the new API with a 2.4.1 broker, I get
> >
> > UpsupportedVersionException: Attempted to write a non-default
> generationId
> > at version 2
> >
> > Alternatively, couldn't the client simply extract the groupId from the
> > ConsumerGroupMetadata and use the old struct if the broker is too old?
> >
> > I'd rather not have a user property in my framework to tell us which API
> to
> > use.
> >
> > Thanks in advance.
> >
>

Reply via email to