Support Questions

Find answers, ask questions, and share your expertise

Impala Prepared Statement Exception when statement executed second time

avatar
Explorer

Using the Impala JDBC driver, I'm getting an exception when trying to use a prepared statement more than once. The first execute works, and the second doesn't. Here's my code snippet:

 

PreparedStatement stmt = null;
try {
stmt = conn.prepareStatement("select * from hbase_vm_customer where cas_id=?");
} catch (SQLException e) {
e.printStackTrace();
}

try {
stmt.setString( 1, "155304611");
ResultSet rs = stmt.executeQuery();
if( !rs.next() ) {
System.out.println( "missing row" );
}
else {
System.out.println( rs.getString(1) );
}
rs.close();
} catch (SQLException e) {
e.printStackTrace();
}

try {
stmt.setString( 1, "155304612");
ResultSet rs = stmt.executeQuery();
if( !rs.next() ) {
System.out.println( "missing row for " );
}
else {
System.out.println( rs.getString(1) );
}
} catch (SQLException e) {
e.printStackTrace();
}

 

Here's the stack trace:

 

155304611
java.sql.SQLException: [JDBC Driver]Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at com.cloudera.impala.jdbc.common.SPreparedStatement.getInputParameterValues(SPreparedStatement.java:3313)
at com.cloudera.impala.jdbc.common.SPreparedStatement.getInputParameterValues(SPreparedStatement.java:3268)
at com.cloudera.impala.jdbc.common.SPreparedStatement.executeQuery(SPreparedStatement.java:1070)
at imptest.ImpExample.main(ImpExample.java:50)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
... 6 more

 

 

This is a query against an Hbase table, and

I'm using Cloudera_ImpalaJDBC4_2.5.5.1007 jdbc driver.

Any suggestions would be appreciated.

1 ACCEPTED SOLUTION

avatar
Explorer

I was able to switch to the Impala JDBC4 2.5.32 version of the driver and the prepared statement behavior is what I expect with that one.

View solution in original post

1 REPLY 1

avatar
Explorer

I was able to switch to the Impala JDBC4 2.5.32 version of the driver and the prepared statement behavior is what I expect with that one.