adikou commented on code in PR #22271: URL: https://github.com/apache/kafka/pull/22271#discussion_r3479285647
########## clients/src/main/java/org/apache/kafka/clients/consumer/internals/InternalRebalanceListener.java: ########## @@ -0,0 +1,58 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.kafka.clients.consumer.internals; + +import org.apache.kafka.common.TopicPartition; + +import java.util.Collection; + +/** + * Internal counterpart to the public rebalance listener interfaces. The consumer's runtime internals + * (subscription state, rebalance listener invoker, membership management) operates exclusively against + * this type rather than the user-facing {@link org.apache.kafka.clients.consumer.RebalanceListener}. + * + * <p>Keeping a single internal abstraction with the simple one-argument signatures means the invocation + * path can pass implementation-specific arguments and lifecycle hooks without leaking them into the public + * API. + */ +public abstract class InternalRebalanceListener { Review Comment: I'm not entirely sure I can follow `Optional<Consumer<Collection<TopicPartition>>>` signature without the help of an IDE on first glance. We already have some level of complexity with some reflection like behaviour with `ConsumerRebalanceListenerInvoker`. I wanted to trigger a notification from there without having to support the full public API RebalanceListener which supports the`RebalanceConsumer`. We'll be passing a null reference as the second param bcause I really don't want to pipe the consumer reference through the async event handler stack. Also, down the line if we ever expose a `RebalanceCause` enum like we discussed in the previous PR, I'll have to shoe-horn in a non-null implementation of `RebalanceConsumer` which only supports a rebalance cause method : also not very elegant. All of this to say, I feel it's ok supporting an internal rebalance API where we can iterate freely without u touching the public methods to do the same. At the cost of some form of duplication of course - but this cost is borne by the internals package and us (well, you) the maintainers. Thoughts? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
