Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

Hey Ron and Rajini, Here are my thoughts: Regarding separators in SaslExtensions - Agreed, that was a bad move. Should definitely not be a concern of CallbackHandler and LoginModule implementors. SaslExtensions interface - Wouldn't implementing it as an interface mean that users will have to make

Build failed in Jenkins: kafka-trunk-jdk8 #2833

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk8 #2832

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk8 #2831

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk8 #2830

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

Hi again, Rajini and Stanislav. I wonder if making SaslExtensions an interface rather than a class might be a good solution. For example: public interface SaslExtensions { /** * @return an immutable map view of the SASL extensions */ Map map(); } This solves the issue of lack of

Build failed in Jenkins: kafka-trunk-jdk8 #2829

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Processor API StateStore and Recovery with State Machines question.

Hi Folks I have a quick question about a scenario that I would appreciate some insight on. This is related to a KIP I am working on, but I wanted to break this out into its own scenario to reach a wider audience. In this scenario, I am using builder.internalTopologyBuilder to create the following

Build failed in Jenkins: kafka-trunk-jdk8 #2828

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-2.0-jdk8 #86

See Changes: [ismael] MINOR: Close ZooKeeperClient if waitUntilConnected fails during -- [...truncated 2.52 MB...] org.apache.kafka.streams.StreamsConfigTest >

[jira] [Created] (KAFKA-7191) Add sensors for NumOfflineThread, FetchRequestRate and FetchRequestLocalTime in the follower broker

Dong Lin created KAFKA-7191: --- Summary: Add sensors for NumOfflineThread, FetchRequestRate and FetchRequestLocalTime in the follower broker Key: KAFKA-7191 URL: https://issues.apache.org/jira/browse/KAFKA-7191

Build failed in Jenkins: kafka-trunk-jdk8 #2827

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk8 #2826

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk8 #2825

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Re: [Discuss] KIP-321: Add method to get TopicNameExtractor in TopologyDescription

Works for me. On 7/22/18 9:48 AM, Guozhang Wang wrote: > I think I can be convinced with deprecating topics() to keep API minimal. > > About renaming the others with `XXNames()`: well, to me it feels still not > very worthy since although it is not a big burden, it seems also not a big >

Build failed in Jenkins: kafka-trunk-jdk8 #2824

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Jenkins build is back to normal : kafka-trunk-jdk10 #308

See

Build failed in Jenkins: kafka-trunk-jdk8 #2823

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-2.0-jdk8 #85

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H34 (ubuntu xenial) in workspace >

Build failed in Jenkins: kafka-trunk-jdk8 #2822

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-2.0-jdk8 #84

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H34 (ubuntu xenial) in workspace >

Re: Discussion: New components in JIRA?

Hello Ray, Thanks for brining this up. I'm generally +1 on the first two, while for the last category, personally I felt leaving them as part of `tools` is fine, but I'm also open for other opinions. A more general question though, is that today we do not have any guidelines to ask JIRA

Build failed in Jenkins: kafka-trunk-jdk8 #2821

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H32 (ubuntu xenial) in workspace

Build failed in Jenkins: kafka-trunk-jdk10 #307

See -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H23 (ubuntu xenial) in workspace

Re: [Discuss] KIP-321: Add method to get TopicNameExtractor in TopologyDescription

I think I can be convinced with deprecating topics() to keep API minimal. About renaming the others with `XXNames()`: well, to me it feels still not very worthy since although it is not a big burden, it seems also not a big "return" if we name the newly added function `topicSet()`. Guozhang

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

Hi Rajini. The SaslServer is going to have to validate the extensions, too, but I’m okay with keeping the validation logic elsewhere as long as it can be reused in both the client and the secret. I strongly prefer exposing a map() method as opposed to extensionNames() and

Re: [DISCUSS] KIP-342 Add Customizable SASL extensions to OAuthBearer authentication

Hmm I think we need a much simpler SaslExtensions class if we are making it part of the public API. 1. I don't see the point of including separator anywhere in SaslExtensions. Extensions provide a map and we propagate the map from client to server using the protocol associated with the

Re: [DISCUSS] KIP-291: Have separate queues for control requests and data requests

Hi Jun, The usage of correlation ID might still be useful to address the cases that the controller epoch and leader epoch check are not sufficient to guarantee correct behavior. For example, if the controller sends a LeaderAndIsrRequest followed by a StopReplicaRequest, and the broker

Jenkins build is back to normal : kafka-trunk-jdk8 #2820

See