db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1002) Check that DRDAStatement and DRDAResultSet states are reset when they are re-used
Date Thu, 23 Feb 2006 19:02:38 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1002?page=all ]

Deepa Remesh updated DERBY-1002:
--------------------------------

    Attachment: derby1002.java

Attaching  a repro 'derby1002.java' which shows how queries can get closed on the server unexpectedly
which leads to protocol exception. To run the repro:

1. Start network server on port 2222.
2. Run the command: java derby1002
3. Output should be:

******************************************
testImplicitClose
******************************************
FAILED (no exception thrown)

******************************************
jira491Test
******************************************
JIRA-491 FAILURE:
Client sends CNTQRY and expects QRYDTA. Server sends QRYNOPRM because the query has been implicitly
closed
Caught Exception:
java.sql.SQLException: Execution failed due to a distribution protocol error that caused deallocatio
n of the conversation.  The identified cursor is not open.
        at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:285)
        at org.apache.derby.client.am.ResultSet.next(ResultSet.java:269)
        at derby1002.jira491Test(derby1002.java:123)
        at derby1002.main(derby1002.java:26)
Caused by: org.apache.derby.client.am.DisconnectException: Execution failed due to a distribution
pr
otocol error that caused deallocation of the conversation.  The identified cursor is not open.
        at org.apache.derby.client.net.NetResultSetReply.parseQRYNOPRM(NetResultSetReply.java:331)
        at org.apache.derby.client.net.NetResultSetReply.parseFetchError(NetResultSetReply.java:226)

        at org.apache.derby.client.net.NetResultSetReply.parseCNTQRYreply(NetResultSetReply.java:177
)
        at org.apache.derby.client.net.NetResultSetReply.readFetch(NetResultSetReply.java:38)
        at org.apache.derby.client.net.ResultSetReply.readFetch(ResultSetReply.java:40)
        at org.apache.derby.client.net.NetResultSet.readFetch_(NetResultSet.java:181)
        at org.apache.derby.client.am.ResultSet.flowFetch(ResultSet.java:4034)
        at org.apache.derby.client.net.NetCursor.completeSplitRow(NetCursor.java:1057)
        at org.apache.derby.client.net.NetCursor.skipFdocaBytes(NetCursor.java:537)
        at org.apache.derby.client.net.NetCursor.calculateColumnOffsetsForRow_(NetCursor.java:251)
        at org.apache.derby.client.am.Cursor.stepNext(Cursor.java:172)
        at org.apache.derby.client.am.Cursor.next(Cursor.java:185)
        at org.apache.derby.client.am.ResultSet.nextX(ResultSet.java:293)
        at org.apache.derby.client.am.ResultSet.next(ResultSet.java:260)
        ... 2 more

I have taken parts of tests for jira 821 and jira 491 from lang/procedure.java to create the
repro.

--------------------------------------------------------
Context:
--------------------------------------------------------
After Kathey suggested to separate out finalizer changes in DERBY-210, I updated my workpace
and I was running derbynetclientmats suite in a loop with my patches. I was seeing a new intermittent
failure in lang/procedure.java, which was not there last week. The failure was related to
implicit closing of result sets and hence seeing it this week. Here are the two failures I
see on repeated runs of this test with my patches. Sometimes I get either one of these failures
or none: 

1) Failure in testImplicitClose(). This tests to see that the resultsets opened by EXCSQLSTT
do not get implicitly closed. However, implicit close happens because stmt.hasdata() is evaluating
to false at the end of writeQRYDTA. And the result set's qryclsimp value is also left over
from a previous OPNQRY.

942 del
< testImplicitClose(): PASSED
942 add
> testImplicitClose(): FAILED (no exception thrown)
Test Failed.

2) In this failure also, implicit close happens because stmt.hasdata() is evaluating to false
at the end of writeQRYDTA

*** Start: procedure jdk1.5.0_02 DerbyNetClient 2006-02-21 23:36:42 ***
940 del
< JIRA-491 Successful.
941 del
< JIRA-492 successful -- no hang!
942 del
< testImplicitClose(): PASSED
942 add
> JIRA-491 FAILURE: Caught Exception:
> java.sql.SQLException: Execution failed due to a distribution protocol error that caused
deallocation of the conversation.  The identified cursor is not open.
> Caused by: org.apache.derby.client.am.DisconnectException: Execution failed due to a
distribution protocol error that caused deallocation of the conversation.  The identified
cursor is not open.
> 	... 3 more
> JIRA-492: FAILURE in data setup:
> java.sql.SQLException: Invalid operation: statement closed
> Caused by: org.apache.derby.client.am.SqlException: Invalid operation: statement closed
> 	... 3 more
> JIRA-492: FAILURE in procedure creation:
> java.sql.SQLException: Invalid operation: statement closed
> Caused by: org.apache.derby.client.am.SqlException: Invalid operation: statement closed
> 	... 3 more
> ERROR (no SQLState): invalid operation: connection closed
> java.sql.SQLException: invalid operation: connection closed
> Caused by: org.apache.derby.client.am.SqlException: invalid operation: connection closed
> 	... 3 more
Test Failed.

On looking at these, I found there could still be problems in the network server code where
DRDAStatement and DRDAResultSet get re-used. Also, it seemed to me these failures are not
related to my patch and should happen without my patch. I was able to create a repro using
parts of the procedure test and creating/closing statements at right time to provoke this
bug without my patch. 

--------------------------------------------------------
Details of what repro does:
--------------------------------------------------------
1) Run a select statement so that OPNQRY will be sent to server and qryclsimp will be set
to CodePoint.QRYCLSIMP_YES
2) Close the above statement so that network server will re-use its DRDAStatement for the
next statement.
3) Create a callabale statement and execute a procedure and get all data so that hasdata for
the DRDAResultSet will be false.
4) Close the above statement so that network server will re-use its DRDAStatement for the
next statement.
5a) Run testImplicitClose() from procedure test. This test checks that result sets do not
get implicitly closed when using EXCSQLSTT. But this will fail since the DRDAResultSet has
wrong states and the 'writeQRYDTA' method used by OPNQRYRM and EXCSQLSTT commands is the same.
5b) Run the test for jira 491. The QRYDTA will be split and hence hasdata must be true at
the time of sending first QRYDTA. However, hasdata evaluates to false and hence server closes
the result set. Client sends CNTQRY to get the next QRYDTA. Since server has closed the query,
it sends back QRYNOPRM which causes a protocol exception.

--------------------------------------------------------
Summary:
--------------------------------------------------------
Network server code should be changed and reviewed thoroughly to see that the re-use of objects
happens correctly. 

> Check that DRDAStatement and DRDAResultSet states are reset when they are re-used
> ---------------------------------------------------------------------------------
>
>          Key: DERBY-1002
>          URL: http://issues.apache.org/jira/browse/DERBY-1002
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Reporter: Deepa Remesh
>     Assignee: Deepa Remesh
>      Fix For: 10.2.0.0
>  Attachments: derby1002.java
>
> Network server re-uses DRDAStatement and DRDAResultSet objects when client sends a request
with same section number. When re-using DRDAStatement, it's close() method is called which
inturn calls close() method of DRDAResultSet. For re-use to work properly, we have to ensure
the states of these objects are reset. This is not a bug but it is an area for possible improvements
like:
> * The reset of all states are not in the close() methods. The states get re-initialized
at different places in the code. Fo example, in case of DRDAResultSet, they get initialized
in some other DRDAStatement methods - like addResultSet, setRsDefaultOptions, setOPNQRYOptions,
setQueryOptions etc. It will be good to have all resets in one method.
> * The method name "close" is confusing since it is also called when objects get re-used.
For clarity, it may be good to have a method named reset(). And then have the close method
call reset.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message