[jira] Commented: (DERBY-5) Network Server Protocol error when select fails and "order by" is specified

["A B (JIRA)" <de...@db.apache.org>]

     [ http://issues.apache.org/jira/browse/DERBY-5?page=comments#action_54810 ]
     
A B commented on DERBY-5:
-------------------------

With svn rev 55942 (which was the fix for Derby-35), it turns out that this bug (Derby-5) is now much more likely to occur.  The reason is because the chaining fixes for Derby-5 will keep everything belonging to the same chain within an outgoing buffer until the chain ends or the buffer is full (which is the _correct_ behavior), at which point the buffer's contents will be transmitted.

As a result, whenever we hit the error block of code mentioned in the bug description for _this_ bug, we are more likely to have data stored in the buffer, and that means that the incorrect call to "writer.clearBuffer" is more likely to do the wrong thing.

So that said, I guess this will be the next bug I work on...

> Network Server Protocol error when select fails and "order by" is specified
> ---------------------------------------------------------------------------
>
>          Key: DERBY-5
>          URL: http://issues.apache.org/jira/browse/DERBY-5
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Versions: 10.0.2.0
>     Reporter: Tulika Agrawal

>
> Reporting for Army, filed on derby-dev list.
> If, when using the Network Server, one tries to execute a select 
> statement that fails because of an SQL exception (ex. divide-by-zero), 
> and if an "order by" clause is specified as part of the select, the 
> server will throw a distributed protocol exception, instead of the 
> appropriate error.
> Repro (using the "ij" utility)
> ij> connect 'jdbc:derby:net://localhost:1527/myDB:user=u;password=p;';
> ij> create table t1 (i int, j int);
> 0 rows inserted/updated/deleted
> ij> insert into t1 values (2,0);
> 1 row inserted/updated/deleted
> -- Without an "order by" it's fine...
> -- (22012 ==> "Attempt to divide by zero.", which is fine)
> ij> select {fn mod(i,j)} from t1;
> 1
> -----------
> ERROR 22012: DB2 SQL error: SQLCODE: -1, SQLSTATE: 22012, SQLERRMC: 22012
> -- With an order by, it dies...
> ij> select {fn mod(i,j)} from t1 order by 1;
> ERROR 58009: Execution failed due to a distribution protocol error that 
> caused deallocation of the conversation. A DRDA Data Stream Syntax Error 
> was detected. Reason: 0x13
> NOTES:
> The problem is in the DRDAConnThread.java file, "processCommands(...)" 
> method, in the "case CodePoint.OPNQRY" block of code. In the case of an 
> SQL exception, there's a call to "writer.clearBuffer()" that is used to 
> ensure that _only_ an OPNQFLRM is sent back to the client, not the 
> OPNQRYRM and/or QRYDSC that may have been written to buffer before the 
> OPNQFLRM. That call to "clearBuffer" has to be replaced with something 
> smarter, so that instead of doing a full clear (which causes the problem 
> shown above), it only backs out the buffer writes that it has made since 
> beginning the "case CodePoint.OPNQRY" block...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira