hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Furcy Pin (JIRA)" <>
Subject [jira] [Commented] (HIVE-6050) Newer versions of JDBC driver does not work with older HiveServer2
Date Thu, 01 Dec 2016 10:44:58 GMT


Furcy Pin commented on HIVE-6050:


I ran into the same problem, and found a workaround for my setup, so I wanted to share it.

I have an application that uses hive-cli 1.2.0 (because of Spark) and that sends queries to
our cluster via hive-jdbc.
Our cluster is still stuck in 1.1.0 (thank you Cloudera) and I ran into this issue when talking
with the v1.2.0 jdbc client to the v1.1.0 jdbc server.

I managed to make everything work with the following dependency setup (sbt syntax):

libraryDependencies += "org.apache.hive" % "hive-service" % "1.1.0"

libraryDependencies += "org.apache.hive" % "hive-jdbc" % "1.1.0"

libraryDependencies += "org.apache.hive" % "hive-cli" % "1.2.0" exclude("org.apache.hive",

The trick was that the {{client_protocol}} is not defined in {{hive-jdbc}} but in {{hive-service}},
so you must make sure that your client has the same version of {{hive-service}} than your

I didn't run into any other compatibility problem so far, but I don't guarantee that nothing
will break when mixing two hive versions together...

> Newer versions of JDBC driver does not work with older HiveServer2
> ------------------------------------------------------------------
>                 Key: HIVE-6050
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2, JDBC
>    Affects Versions: 0.13.0
>            Reporter: Szehon Ho
>            Priority: Blocker
> HiveServer2 instance has to be upgraded before the JDBC drivers used by applications
are upgraded. If jdbc drivers are updated before HiveServer2 is upgraded it will not be functional.
> Connect from JDBC driver of Hive 0.13 (TProtocolVersion=v4) to HiveServer2 of Hive 0.10
(TProtocolVersion=v1), will return the following exception:
> {noformat}
> java.sql.SQLException: Could not establish connection to jdbc:hive2://localhost:10000/default:
Required field 'client_protocol' is unset! Struct:TOpenSessionReq(client_protocol:null)
> 	at org.apache.hive.jdbc.HiveConnection.openSession(
> 	at org.apache.hive.jdbc.HiveConnection.<init>(
> 	at org.apache.hive.jdbc.HiveDriver.connect(
> 	at java.sql.DriverManager.getConnection(
> 	at java.sql.DriverManager.getConnection(
> 	at org.apache.hive.jdbc.MyTestJdbcDriver2.getConnection(
> 	at org.apache.hive.jdbc.MyTestJdbcDriver2.&lt;init&gt;(
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> 	at java.lang.reflect.Constructor.newInstance(
> 	at org.junit.runners.BlockJUnit4ClassRunner.createTest(
> 	at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(
> 	at
> 	at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> 	at org.junit.runners.ParentRunner$
> 	at org.junit.runners.ParentRunner$1.schedule(
> 	at org.junit.runners.ParentRunner.runChildren(
> 	at org.junit.runners.ParentRunner.access$000(
> 	at org.junit.runners.ParentRunner$2.evaluate(
> 	at
> 	at
> 	at
> 	at
> 	at
> Caused by: org.apache.thrift.TApplicationException: Required field 'client_protocol'
is unset! Struct:TOpenSessionReq(client_protocol:null)
> 	at
> 	at org.apache.thrift.TServiceClient.receiveBase(
> 	at org.apache.hive.service.cli.thrift.TCLIService$Client.recv_OpenSession(
> 	at org.apache.hive.service.cli.thrift.TCLIService$Client.OpenSession(
> 	at org.apache.hive.jdbc.HiveConnection.openSession(
> 	... 37 more
> {noformat}
> On code analysis, it looks like the 'client_protocol' scheme is a ThriftEnum, which doesn't
seem to be backward-compatible.  Look at the code path in the generated file '',
> 1. The method will call 'TProtocolVersion.findValue()' on the thrift protocol's byte
stream, which returns null if the client is sending an enum value unknown to the server. 
(v4 is unknown to server)
> 2. The method will then call struct.validate(), which will throw the above exception
because of null version.  
> So doesn't look like the current backward-compatibility scheme will work.

This message was sent by Atlassian JIRA

View raw message