[
https://issues.apache.org/jira/browse/DERBY-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546096
]
Bryan Pendleton commented on DERBY-3230:
----------------------------------------
Stepping through the code on the server side is interesting. When the entire
dataset is fetched
via IJ, it just so happens that the last row ends up at position 32706 in the
buffer, meaning that
there is 61 bytes of space available in the buffer. But by the time
DRDAConnThread.doneData()
has finished writing the various bits and pieces of housekeeping data to the
end of the buffer,
it has gone beyond 32767 bytes and hence needs to be split. The splitQRYDTA
processing
then ends up splitting the QRYDTA block in the midst of the doneData SQLCAGRP
bytes,
rather than in the middle of some normal row data, which is how most QRYDTA
splits work.
The client code then gets into the processing of the doneData SQLCAGRP, but
does not expect
that the DRDA response block might have been split there, so instead of
requesting the
remainder of the block with a CNTQRY, the client code throws an exception.
I'm sorry, I know that the above is kind of dense and jargon-y. I think that
the bottom line is that
this problem is closely related to DERBY-614 and has to do with the fact that
this query had
the bad luck to need to split the query results at a point that was:
- after the last row of the results
- but before the end of the message
- and hence at a place where the client code didn't expect the block to have
been split.
> Selecting data from a Table raises Error XN008: Query processing has been
> terminated due to an error on the server
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3230
> URL: https://issues.apache.org/jira/browse/DERBY-3230
> Project: Derby
> Issue Type: Bug
> Components: Network Client, Network Server
> Affects Versions: 10.3.1.4
> Environment: Windows XP
> Reporter: Stefan Huber
> Priority: Critical
> Attachments: test.rar
>
>
> I got a table (PCLASS) in my database where I cannot select the data via a
> simple select statement:
> - If I execute 'select * from PCLASS': XN008: Query processing has been
> terminated due to an error on the server
> - If I execute 'select * from PCLASS order by CLASSNAME': it works
> - If I add or remove only one row to/from the table: it works
> If I use the embedded driver everything works fine. But as soon as I use the
> derby network client to access the database, this problem occurs.
> This is very odd. I spent a lot of time to do some research on this behavior
> because I could not believe that the network client produces errors depending
> on the data contained in a table. But after all it looks like I managed to
> fill the table with an exact amount of data that causes this error to arise.
> To reproduce the problem download the attached file and follow these
> instructions:
> * extract test.rar to $derby.system.home$
> * start derby network server
> * start ji utility and execute the following commands:
> ** connect to database test using client driver:
> connect 'jdbc:derby://localhost/test;user=ZOL;password=zol';
> ** select content of table PCLASS
> select * from PCLASS;
> --> Error XN008: Query processing has been terminated due to an error on the
> server
> ** disconnect from database
> disconnect;
> ** shutdown database 'test'
> connect
> 'jdbc:derby://localhost/test;user=ZOL;password=zol;shutdown=true';
> ** connect to database 'test' using embedded driver:
> connect 'jdbc:derby:test;user=ZOL;password=zol';
> ** select content of table PCLASS
> select * from PCLASS;
> --> everything o.k.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
