db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-614) Execution failed because of a Distributed Protocol Error
Date Thu, 16 Feb 2006 18:35:10 GMT
     [ http://issues.apache.org/jira/browse/DERBY-614?page=all ]

Bryan Pendleton updated DERBY-614:

    Attachment: d614_a.diff

Welcome back, JIRA! Attached is d614_a.diff, which contains the patch that Deepa found as
well as a new regression test which demonstrates the problem. To verify this fix, run the
regression test without the patch and you will get a StringOutOfBoundsException in the client-side
parsing, then apply the one-line change to DRDAResultSet.java and the test will pass. To run
the test by itself:

  java -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest derbynet/prepStmt.java

Thank you very much to Deepa for finding the problem and describing it so clearly. For everybody
else, here's the quick summary:

  DRDAStatement objects on the server side can get re-used after they have been closed.
  After a statement has been closed, the client may re-use the Section Number when
  sending a new request for a new statement. The server then discovers that there was
  a statement object in memory, and it automatically closes that statement and re-uses
  it. With my first patch to this bug, I introduced a problem in this processing; the
  splitQRYDTA field was not cleared when the statement was closed. This meant that
  if that splitQRYDTA field just happened to have some pending query data from the
  previous statement at the point where it was re-used, the pending query data would
  erroneously stick around and be returned as the first result for the new statement.

  Thus, the conditions that lead up to this bug are:
  - a statement is created, and results are fetched, and a QRYDTA block has to be split.
  - instead of sending a CNTQRY to fetch the split data, the client instead closes the
 - then, the client creates a new statement with the same Section Number (it is free to
   do so, since the previous statement has been closed), and sends a new query
   request over.
 - at that point, the server responds to the new query with the leftover split QRYDATA.

The regression test simply forces the server down this code path.

If somebody could please take a look at this patch, I would be very grateful.

> Execution failed because of a Distributed Protocol Error
> --------------------------------------------------------
>          Key: DERBY-614
>          URL: http://issues.apache.org/jira/browse/DERBY-614
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Versions:
>  Environment: Linux 2.4, Sun JDK 1.4.2_07, full SYSINFO will be attached.
>     Reporter: Bryan Pendleton
>     Assignee: Bryan Pendleton
>      Fix For:
>  Attachments: clientSideTrace.txt, clientStack.txt, d614_a.diff, derby-614.zip, derbynetclientmats_report.txt,
query.txt, reset_drda_rs.diff, serverSideTrace.txt, spec.html, svn-diff-2005-12-04.txt, svn-status-2005-12-04.txt,
> I am intermittently receiving Distributed Protocol Error exceptions in my client code.
> my derby.log is recording Distributed Protocol Error exceptions on the server side.
> I cannot reliably reproduce this problem. 
> However, the problem always occurs in the same section of my application, so I can at
> describe that section of my application. (I'll do so in an attachment).
> Here is the error I receive on the server side. Sometimes, the CODPNT is 2116 and the
> Error Code Value is 1d, rather than 2114 and e.
> 2005-10-05 02:10:23.663 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = BuildFar
> m), (DRDAID = GA0A0026.P7E6-4182154075488704215{136532}), Execution failed becau
> se of a Distributed Protocol Error:  DRDA_Proto_SYNTAXRM; CODPNT arg  = 2114; Er
> ror Code Value = e
> Execution failed because of a Distributed Protocol Error:  DRDA_Proto_SYNTAXRM;
> CODPNT arg  = 2114; Error Code Value = e
> 2005-10-05 02:10:23.663 GMT Thread[DRDAConnThread_2,5,main] (DATABASE = BuildFar
> m), (DRDAID = GA0A0026.P7E6-4182154075488704215{136532}), null
> null
> org.apache.derby.impl.drda.DRDAProtocolException
>         at org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(Unknown Sourc
> e)
>         at org.apache.derby.impl.drda.DRDAConnThread.missingCodePoint(Unknown So
> urce)
>         at org.apache.derby.impl.drda.DRDAConnThread.parseCNTQRY(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.splitQRYDTA(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(Unknown Source)
>         at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Sou
> rce)
>         at org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source)

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message