[MonetDB-users] java.lang.AssertionError: block 0 should have been fetched by now
Hi, I get an error message when I retrieve a MAL plan over JDBC after the 250th call to ResultSet.next(). The relevant part of the stack trace is: java.lang.AssertionError: block 0 should have been fetched by now :( at nl.cwi.monetdb.jdbc.MonetConnection$ResultSetResponse.getLine(MonetConnection.java:1585) at nl.cwi.monetdb.jdbc.MonetResultSet.absolute(MonetResultSet.java:194) at nl.cwi.monetdb.jdbc.MonetResultSet.relative(MonetResultSet.java:2149) at nl.cwi.monetdb.jdbc.MonetResultSet.next(MonetResultSet.java:2116) The call to EXPLAIN works in mclient and returns a MAL plan that is 402 lines long. I can reproduce the error when I try to create the plan via jdbcclient, except that it says that block 1 should have been fetched and the exporter stops after line 160 or so. However, other SQL queries that also produce more than 250 results work over JDBC. Not sure what the difference is, but these queries only return column of integers. I'm using the Aug2011-SP3 release on OS X 10.6.8. Please let me know if I should provide other information like the SQL query or the MAL plan. Cheers, Viktor
On 30-11-2011 10:00:29 +0100, Viktor Rosenfeld wrote:
Hi,
I get an error message when I retrieve a MAL plan over JDBC after the 250th call to ResultSet.next(). The relevant part of the stack trace is:
java.lang.AssertionError: block 0 should have been fetched by now :( at nl.cwi.monetdb.jdbc.MonetConnection$ResultSetResponse.getLine(MonetConnection.java:1585) at nl.cwi.monetdb.jdbc.MonetResultSet.absolute(MonetResultSet.java:194) at nl.cwi.monetdb.jdbc.MonetResultSet.relative(MonetResultSet.java:2149) at nl.cwi.monetdb.jdbc.MonetResultSet.next(MonetResultSet.java:2116)
The call to EXPLAIN works in mclient and returns a MAL plan that is 402 lines long. I can reproduce the error when I try to create the plan via jdbcclient, except that it says that block 1 should have been fetched and the exporter stops after line 160 or so.
However, other SQL queries that also produce more than 250 results work over JDBC. Not sure what the difference is, but these queries only return column of integers.
They are "real" SQL results. The PLAN, EXPLAIN and TRACE results are "fake", and they cause JDBC to choke when the results get large. It's simply because the server doesn't behave as the client asked it to behave (because these are "fake" results). Short answer: this is why these are not supported through JDBC.
Fabian Groffen wrote:
On 30-11-2011 10:00:29 +0100, Viktor Rosenfeld wrote:
Hi,
I get an error message when I retrieve a MAL plan over JDBC after the 250th call to ResultSet.next(). The relevant part of the stack trace is:
java.lang.AssertionError: block 0 should have been fetched by now :( at nl.cwi.monetdb.jdbc.MonetConnection$ResultSetResponse.getLine(MonetConnection.java:1585) at nl.cwi.monetdb.jdbc.MonetResultSet.absolute(MonetResultSet.java:194) at nl.cwi.monetdb.jdbc.MonetResultSet.relative(MonetResultSet.java:2149) at nl.cwi.monetdb.jdbc.MonetResultSet.next(MonetResultSet.java:2116)
The call to EXPLAIN works in mclient and returns a MAL plan that is 402 lines long. I can reproduce the error when I try to create the plan via jdbcclient, except that it says that block 1 should have been fetched and the exporter stops after line 160 or so.
However, other SQL queries that also produce more than 250 results work over JDBC. Not sure what the difference is, but these queries only return column of integers.
They are "real" SQL results. The PLAN, EXPLAIN and TRACE results are "fake", and they cause JDBC to choke when the results get large. It's simply because the server doesn't behave as the client asked it to behave (because these are "fake" results).
Short answer: this is why these are not supported through JDBC.
OK, thanks. Cheers, Viktor
On 30-11-2011 13:08:40 +0100, Viktor Rosenfeld wrote:
I get an error message when I retrieve a MAL plan over JDBC after the 250th call to ResultSet.next(). The relevant part of the stack trace is:
java.lang.AssertionError: block 0 should have been fetched by now :( at nl.cwi.monetdb.jdbc.MonetConnection$ResultSetResponse.getLine(MonetConnection.java:1585)
They are "real" SQL results. The PLAN, EXPLAIN and TRACE results are "fake", and they cause JDBC to choke when the results get large. It's simply because the server doesn't behave as the client asked it to behave (because these are "fake" results).
Short answer: this is why these are not supported through JDBC.
OK, thanks.
I came across this once again, and found that with some goodwill this was actually easy to fix. Next release "Dec2011" will have the fix for this. So TRACE and EXPLAIN will work over JDBC. It may just blowup a bit in case of lots of output, since the blockwise pagination of the results is absent.
participants (2)
-
Fabian Groffen -
Viktor Rosenfeld