Hi, I refer to the broker behaviour, for most part without SASL the brokers do respond but as soon as you put SASL into the mix it does hang whenever there is something that goes wrong, i.e the broker doesn't provide a response on the socket and the client waits reading a response that it never gets and timeout.
e.g kafka 0.9 SASL protocol is [kerberos specific interchange] <normal kafka protocol interchange> kafka 0.10 is [len][kafka protocol][kerberos specific interchange] <normal kafka protocol interchange> the kerberos specific interchange parts is where things can hang (meaning the client or broker are waiting for information from either that never arrives), and if you write [len][kafka protocol] to a SASL configured 0.9 kafka broker or vice versa the client timeout eventually not on retrying but on waiting on a response from the broker. I would file a bug but don't think this behaviour can be helped here. Regards, Gerrit On Fri, Jan 20, 2017 at 12:05 AM, Ismael Juma <ism...@juma.me.uk> wrote: > Hi Gerrit, > > I think it's important to distinguish broker and client behaviour. The > clients can hang because they keep retrying when they get certain errors. > When it comes to the broker, it should give you errors as a general rule. > If you are aware of certain scenarios where it should give an error and it > doesn't, then please file a bug with steps to reproduce. > > Ismael > > On Thu, Jan 19, 2017 at 6:48 PM, Gerrit Jansen van Vuuren < > gerrit...@gmail.com> wrote: > > > Hi, > > > > I've added kerberos support for https://github.com/gerritjvv/kafka-fast > > and > > have seen that the kafka brokers do not send any response if the SASL > > authentication is not correct or accepted, thus causing the client to > hang > > while waiting for a response from kafka. > > > > Some things that might help to debug: > > > > - kafka 0.9's SASL auth is in-compatible with 0.10 and not using the > > correct version will cause the kafka client to hang. > > - use -Dsun.security.krb5.debug=true and > > -Djava.security.debug=gssloginconfig,configfile, > configparser,logincontext > > to see debug info about what's going on. > > > > > > Some reading material can be found at: > > https://github.com/gerritjvv/kafka-fast/blob/master/kafka- > clj/Kerberos.md > > > > and if you want to see or need for testing a vagrant env with kerberos + > > kafka configured see > > https://github.com/gerritjvv/kafka-fast/blob/master/kafka- > > clj/doc/vagrant.md > > > > > > > > > > On Thu, Jan 19, 2017 at 7:37 PM, Christian <engr...@gmail.com> wrote: > > > > > I have successfully gotten SASL_PLAINTEXT configured on Kafka cluster. > We > > > implemented our own LoginModule and Server with the following caveat > > that I > > > am guessing I am doing something wrong. > > > > > > The LoginModule's login method acquires a session id from an internal > > > security system and populates the subject with the relevant > information. > > In > > > the server evaluateResponse we then validate that session. On success, > > > everything is great. However, when the evaulateResponse returns with a > > > failure (throws an exception), the producer client just hangs when > > sending > > > a message until the configured timeout occurs. Interestingly enough, we > > see > > > the evaulateResponse method is getting called about every second until > > the > > > the producer client finally times out. > > > > > > We get this same behavior when using the PlainLoginModule provided with > > > Kafka after changing the password on the client side to something > > different > > > from the server side. > > > > > > Is this expected behavior? > > > > > > Thanks, > > > Christian > > > > > >
