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

Szehon Ho commented on HIVE-6050:
---------------------------------

[~ashutoshc] [~cwsteinbach] Do you guys have any thoughts/experiences on this 
issue?

It seems like we would need to change client protocol version to use another 
data type, to get this to work.  My thought was this should be ok, as 
backward-compatibility seem to be broken today anyway based on this analysis.

> JDBC backward compatibility is broken
> -------------------------------------
>
>                 Key: HIVE-6050
>                 URL: https://issues.apache.org/jira/browse/HIVE-6050
>             Project: Hive
>          Issue Type: Bug
>          Components: JDBC
>            Reporter: Szehon Ho
>
> Connect from JDBC driver of Hive 0.12 (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 
> com.cloudera.itest.hiveserver.UnmanagedHiveServer.createConnection(UnmanagedHiveServer.java:73)
>       at 
> com.cloudera.itest.AbstractTestWithStaticConfiguration.createConnection(AbstractTestWithStaticConfiguration.java:68)
>       at com.cloudera.itest.FirstTest.sanityConnectionTest(FirstTest.java:19)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>       at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>       at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>       at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>       at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>       at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>       at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>       at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>       at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
>       at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
>       at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
>       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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>       at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>       at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
>       at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
>       at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:77)
>       at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
>       at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>       at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>       at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> 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.4#6159)

Reply via email to