Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Mon, 6 Jan 2014 21:25:52 +0000 (UTC)
From: "Thejas M Nair (JIRA)" <jira@apache.org>
To: hive-dev@hadoop.apache.org
Message-ID: <JIRA.12685264.1387318989793.49743.1389043552849@arcas>
In-Reply-To: <JIRA.12685264.1387318989793@arcas>
References: <JIRA.12685264.1387318989793@arcas>
Subject: [jira] [Commented] (HIVE-6050) JDBC backward compatibility is
 broken
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HIVE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863439#comment-13863439 ] 

Thejas M Nair commented on HIVE-6050:
-------------------------------------

bq. Do you guys have any thoughts on which would be a more common scenario to support: new jdbc driver compatible with old server version or old jdbc driver compatible with a newer server version?
I think it is very important that one version of jdbc driver be able to talk to different versions of HS2. If the older version of driver is able to talk to newer versions of HS2, that would be the ideal case.


> JDBC backward compatibility is broken
> -------------------------------------
>
>                 Key: HIVE-6050
>                 URL: https://issues.apache.org/jira/browse/HIVE-6050
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2, JDBC
>            Reporter: Szehon Ho
>            Assignee: Carl Steinbach
>            Priority: Blocker
>
> 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(HiveConnection.java:336)
> 	at org.apache.hive.jdbc.HiveConnection.<init>(HiveConnection.java:158)
> 	at org.apache.hive.jdbc.HiveDriver.connect(HiveDriver.java:105)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:571)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:187)
> 	at org.apache.hive.jdbc.MyTestJdbcDriver2.getConnection(MyTestJdbcDriver2.java:73)
> 	at org.apache.hive.jdbc.MyTestJdbcDriver2.&lt;init&gt;(MyTestJdbcDriver2.java:49)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> 	at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:187)
> 	at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:236)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:233)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
> 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:523)
> 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1063)
> 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:914)
> Caused by: org.apache.thrift.TApplicationException: Required field 'client_protocol' is unset! Struct:TOpenSessionReq(client_protocol:null)
> 	at org.apache.thrift.TApplicationException.read(TApplicationException.java:108)
> 	at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:71)
> 	at org.apache.hive.service.cli.thrift.TCLIService$Client.recv_OpenSession(TCLIService.java:160)
> 	at org.apache.hive.service.cli.thrift.TCLIService$Client.OpenSession(TCLIService.java:147)
> 	at org.apache.hive.jdbc.HiveConnection.openSession(HiveConnection.java:327)
> 	... 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 'TOpenSessionReq.java', method TOpenSessionReqStandardScheme.read():
> 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
(v6.1.5#6160)