Problem
When Kafka claim-check handling is enabled, each event encoder creates its own ClaimCheck instance. An encoder group contains multiple encoders, and additional standalone encoders may also be created, so one Kafka sink can open multiple external storage clients for the same claim-check URI.
The number of storage clients grows with encoder concurrency even though all encoders belong to the same sink and use the same configuration. This wastes client-side resources and makes ownership and cleanup of the external storage instances unclear.
Expected behavior
A Kafka sink should:
- create one
ClaimCheck instance after the encoder configuration is built;
- share that instance with all encoders owned by the sink;
- keep claim-check message encoding and configuration behavior unchanged;
- close the underlying external storage when the Kafka sink is closed.
Problem
When Kafka claim-check handling is enabled, each event encoder creates its own
ClaimCheckinstance. An encoder group contains multiple encoders, and additional standalone encoders may also be created, so one Kafka sink can open multiple external storage clients for the same claim-check URI.The number of storage clients grows with encoder concurrency even though all encoders belong to the same sink and use the same configuration. This wastes client-side resources and makes ownership and cleanup of the external storage instances unclear.
Expected behavior
A Kafka sink should:
ClaimCheckinstance after the encoder configuration is built;