AndrewJSchofield commented on PR #19715: URL: https://github.com/apache/kafka/pull/19715#issuecomment-2879257695
> > @apoorvmittal10 , In KafkaApis, I think you're referring to this [check](https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/server/KafkaApis.scala#L3995) `config.shareGroupConfig.isShareGroupEnabled || shareVersion().supportsShareGroups`. The second condition like you said can deny share fetch calls, however for now since we have `config.shareGroupConfig.isShareGroupEnabled` and if you use `group.share.enable=true` in your `server.properties` and then toggle the share.version feature to disable share groups, then share fetch won't be denied. Hence, I think we need the attribute `supportsShareGroups` in `ShareSessionCache` > > So are we saying that though `group.share.enable=true` is enabled in config but then again we want to deny the feature if toggled using feature flag? If we want that behaviour then it should be consistent across KafkaApis and other places. Shoulnd't be that KafkaApis have `OR` check and ShareSessionCache just rely on feature flag. Also my understanding is that `group.share.enable=true` is an internal config which is currently being used for tests and actual servers should not set it. Anyways I think we have to be consistent. It should be possible to enable share groups using either of the `share.version=1` feature version or setting `group.share.enable=true` config. Both switches are functional and if either is turned on, share groups are enabled. -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
