This issue is fixed and released as part of 0.10.0 release. If you find an issue which seems to be related to this one, please create a new jira and link this one with new jira.

Integrated in Hive-trunk-hadoop2 #54 (See https://builds.apache.org/job/Hive-trunk-hadoop2/54/)
HIVE-3723 : Hive Driver leaks ZooKeeper connections (Gunther Hagleitner via Ashutosh Chauhan) (Revision 1414278)

Result = ABORTED
hashutosh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1414278
Files :

• /hive/trunk/ql/src/java/org/apache/hadoop/hive/ql/Driver.java

Integrated in Hive-trunk-h0.21 #1821 (See https://builds.apache.org/job/Hive-trunk-h0.21/1821/)
HIVE-3723 : Hive Driver leaks ZooKeeper connections (Gunther Hagleitner via Ashutosh Chauhan) (Revision 1414278)

Result = FAILURE
hashutosh : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1414278
Files :

• /hive/trunk/ql/src/java/org/apache/hadoop/hive/ql/Driver.java

Committed to trunk and 0.10. Thanks, Gunther!

Hmm.. make sense. +1 will commit if tests pass.

The releaseLocks call happens at various places in the run method. I think that's fine too, since calling destroy would kill the HiveLockManager which is shared between different context objects (i.e.: That should only happen when someone specifically destroys the driver.)

As a side note, compile doesn't seem to acquire any locks - the call is thus just a protection against future versions that could.

Around line 910 if compile returns non-zero value, then also we releaseLocks(List<Lock>) and then return. There also, we should call destroy() instead of releaseLocks.

The patch makes sure that calling "destroy" will always close the lock manager (and thus release the zookeeper connection.)