db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-614) Execution failed because of a Distributed Protocol Error
Date Mon, 17 Oct 2005 15:41:45 GMT
    [ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12332240 ] 

A B commented on DERBY-614:
---------------------------

It looks to me like the problem is that, in the "splitQRYDTA" method that Kathey mentioned,
the server reads a codepoint and _assumes_ it's a CNTQRY without explicitly checking for it:

	// read CNTQRY - not sure why JCC sends this
	correlationID = reader.readDssHeader();
	int codePoint = reader.readLengthAndCodePoint();
	DRDAStatement contstmt = parseCNTQRY();

The server reads the codePoint and then assumes that a CNTQRY follows--but it looks like that's
not a valid assumption.  In this case, the app wants to stop reading the data early, so instead
of sending a CNTQRY the client ends up sending a CLSQRY.  The CLSQRY codepoint is read, but
then parseCNTQRY() is called, so the server is looking for CNTQRY data (which expects a BLKSZ)
and instead gets CLSQRY data (which has no BLKSZ), hence the missingCodePoint exception.

I looked at the DDM Manual and found the following statements:

[ LMTBLKPRC ]: A query is terminated any time the CLSQRY command suspends it.

[ EXCSQLSTT ]: After the EXCSQLSTT or each subsequent CNTQRY command, each result set is suspended
unless some condition terminates the result set (see CNTQRY (on page 234)). The CNTQRY
command can continue a suspended result set so that the next portion of the answer set data
is
returned. A result set is terminated anytime the CLSQRY command is received and processed.

[ LMTBLKPROC ]: The following examples show some of the valid responses to the CLSQRY command:
  • If the query is suspended under normal conditions, then an SQLCARD object is returned.

I'm assuming that in this case "the query is suspended under normal conditions" (at least,
I don't see anything in the traces to indicate otherwise), so based on the above lines from
the DDM manual, it seems like the server should be allowing for a CLSQRY to be received in
the middle of splitQRYDTA and, if it receives one, should perform normal CLSQRY processing
(ultimately returning a SQLCARD).

That said, though, I spent a good chunk of time trying to force this situation to occur, and
I wasn't able to do so.  That doesn't mean it's not possible, just that I didn't have any
luck reproducing the problem on my own.

> 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: 10.1.1.0
>  Environment: Linux 2.4, Sun JDK 1.4.2_07, full SYSINFO will be attached.
>     Reporter: Bryan Pendleton
>  Attachments: clientSideTrace.txt, clientStack.txt, derbyTrace.txt, query.txt, serverSideTrace.txt,
sysinfo.derby
>
> I am intermittently receiving Distributed Protocol Error exceptions in my client code.
Simultaneously,
> 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
least
> 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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message