[ 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
