Ok that makes sense. But still, I don't understand how the "Can't
release lock we don't hold" exception can happen, knowing for sure that
neither the Zookeeper process or the MCF agent process have been down
and/or restarted. Not sure that increasing the session lifetime would
solve that
What this code is doing is interpreting exceptions back from Zookeeper.
There are some kinds of exceptions it interprets as "session has expired",
so it rebuilds the session.
The code is written in such a way that the locks are presumed to persist
beyond the session. In fact, if they do not
Karl,
I tried to understand the Zookeeper lock logic in the code, and the only
thing I don't understand is the 'handleEphemeralNodeKeeperException'
method that is called in the catch(KeeperException e) of every
obtain/release lock method of the ZookeeperConnection class.
This method sets
Yes, I will then try the patch and see if it is working
Regards,
Julien
Le 07/12/2021 à 14:28, Karl Wright a écrit :
Yes, this is plausible. But I'm not sure what the solution is. If a
zookeeper session disappears, according to the documentation everything
associated with that session
Yes, this is plausible. But I'm not sure what the solution is. If a
zookeeper session disappears, according to the documentation everything
associated with that session should also disappear.
So I guess we could catch this error and just ignore it, assuming that the
session must be gone anyway?
Hi,
the Zookeeper lock error mentioned in the before last comment of this
issue https://issues.apache.org/jira/browse/CONNECTORS-1447:
FATAL 2017-08-04 09:28:25,855 (Agents idle cleanup thread) - Error tossed:
Can't release lock we don't hold
java.lang.IllegalStateException: Can't release lock
