db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-614) Execution failed because of a Distributed Protocol Error
Date Mon, 14 Nov 2005 21:13:28 GMT
    [ http://issues.apache.org/jira/browse/DERBY-614?page=comments#action_12357630 ] 

Francois Orsini commented on DERBY-614:
---------------------------------------

I have done a bit of reading on the subject (which was a great learning exercise btw) and
I find Brian's approach with 1) and 2) to be appropriate. We'll need to ensure the remainder
data attached to the resultset is released/freed if the CLSQRY DDM command is sent by the
requester or due to some unexpected error condition (as part of ENDQRYRM) returned from the
server - but that should happen as part of resultset deallocation logic.. 

As far as handling MAXBLKEXT in 3) - I'd say that we obviously need to take it into account
since a client (requester) could set a value different than zero (i.e. other DRDA clients
out there).

Interestingly enough, the DDM specifications mention the following for MAXBLKEXT:

"A value of zero indicates that the requester is not capable of receiving extra query blocks
of answer set data. "

which is the default we have right now, hence the server should not be returning extra query
blocks of QRYDTA...would that also be why the client sent CLSQRY in the first place...I mean,
if the client set a MAXBLKEXT of zero, then it will not expect reading further data from the
server after the initial reply (just some thoughts).

Now, the specs also say the following about MAXBLKEXT:

"A value of minus one indicates that the requester is capable of receiving the entire result
set."  (am reading this as the requester will be able to receive the entire resultset without
any particular limit on the number of blocks of answer set data returned by the server) -
this is not very clear from the specs so not completely sure about this. 

Hence, should not we set '-1' as the default value of MAXBLKEXT for the Derby DRDA networkclient
driver instead of zero? Since and IMHO, the (derby) server should by default try to return
the entire resultset (in chunks/clocks as appropriate) to the derby networkclient which has
control as far as reading more data or not (via CLSQRY) anyway.

Now, in case of MAXBLKEXT limit being reached (or in MAXBLKEXT  value being zero) then the
server should probably terminate the query via a ENDQRYRM reply and some error condition (Severity
Code).


> 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, derby-614.zip, 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