Hi Alessandro,
Thanks for the help. It looks like the issue is on our side: KDC hasn’t been
properly setup for Zookeeper: required principals don’t exist.
I just wonder why the error message cannot be more descriptive and if we could
improve it by properly logging the original exception.
Hello Enrico,
yes, a custom made client, that was updated and now is stopped again...
The difference is that in new version only this is the output:
Oct 25 10:56:23 zookeeper_node_1: 2019-10-24 21:56:23,119 [myid:1] -
WARN [NIOWorkerThread-6:NIOServerCnxn@370] - Exception causing close of
Hi Andor,
Enrico's collegue here.
If I remember correctly the issue in our case was related to the
ticket_lifetime and renew_lifetime options.
These two krb.conf options didn't matter before Java 9 (see
https://bugs.openjdk.java.net/browse/JDK-8044500 and
In my 3 node cluster if I stop one of the followers Zookeeper service
everything is fine, connections migrate and there's no interruption of
service.
If I stop the leader's Zookeeper service a lot of things *appear* fine, if
I run
echo "status" | nc localhost 2181
The output looks normal: a new
Andor
did you try with a smaller file ?
Enrico
Il giorno mar 29 ott 2019 alle ore 11:09 Enrico Olivelli - Diennea <
enrico.olive...@diennea.com> ha scritto:
> I would try to shrink the file to the minimum and add one line at a time.
>
> With JDK8 we also had problems with Unlimited Strength
I would try to shrink the file to the minimum and add one line at a time.
With JDK8 we also had problems with Unlimited Strength policy stuff
Hope that helps
Enrico Olivelli
MagNews Platform Development Manager @ Diennea – MagNews
Tel.: (+39) 0546 066100 - Int. 125
Viale G.Marconi 30/14 - 48018
Thanks Enrico for the quick help.
Here’s my krb5.conf:
[libdefaults]
default_realm = STREAMANALYTICS
dns_lookup_kdc = false
dns_lookup_realm = false
ticket_lifetime = 86400
renew_lifetime = 604800
forwardable = true
default_tgs_enctypes = aes256-cts aes128-cts des3-hmac-sha1 arcfour-hmac
Andor,
this is a minimal krb5.conf file that is working from jdk8 to jdk13 and
ZooKeeper
maybe you can compare to your one and start dropping configuration lines that
are not needed.
Java is adding more and more capabilities to GSSAPI support and this sometimes
leads to behavior changes
Il mar 29 ott 2019, 00:52 Sebastian Schmitz <
sebastian.schm...@propellerhead.co.nz> ha scritto:
> Hello again,
>
> just as a final update on this. We had a weird consumer which
> someone updated without informing me...
Can you please define 'weird'? A custom made client?
Turning it off
Hi Sylvain,
That should not be the case. Txns are not going to be created from read
requests and not hit SyncRequestProcessor which is responsible for maintaining
txn and snap logs.
The error handling you see in processTxn() is for ignoring failures during log
replaying inside processTxn()
10 matches
Mail list logo