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] Resolved: (DERBY-35) DRDA Chaining in Network Server is incorrect
Date Fri, 05 Nov 2004 16:20:37 GMT
     [ http://nagoya.apache.org/jira/browse/DERBY-35?page=history ]
     
A B resolved DERBY-35:
----------------------

     Resolution: Fixed
    Fix Version: 10.0.2.0

Fixed with svn rev 55942.  See email "Re: Regarding DERBY-35..." for a detailed description
of what all was done with this fix.

> DRDA Chaining in Network Server is incorrect
> --------------------------------------------
>
>          Key: DERBY-35
>          URL: http://nagoya.apache.org/jira/browse/DERBY-35
>      Project: Derby
>         Type: Bug
>   Components: Network Server
>     Versions: 10.0.2.0
>  Environment: Network drivers/clients other than the IBM DB2 JDBC Universal driver, when
run against Network Server.
>     Reporter: A B
>     Assignee: A B
>      Fix For: 10.0.2.0

>
> I have come across several instances where Network Server can break DRDA chaining protocol
and can thus cause (typically intermittent) connection/communication failures for non-IBM-JDBC-Universal
clients (in particular, the problems have been seen with DB2's CLI client and with the .NET
ODBC provider).
> The problems don't appear to surface when using the IBM DB2 JDBC Universal driver (i.e.
the Java driver that is most typically used with Network Server)--I don't know the specifics
of why not, but it seems to be the case that the universal driver isn't as strict about enforcing
DRDA chaining protocol as other clients.
> [ NOTE: "DSS" here is a DRDA term.  It stands for "Data Stream Structure" and is, in
layman's terms, a structured message that is passed between the client and the server. ]
> Some background:
> I -- The DDMReader recognizes chaining on requests from the client through use of the
reader.isChainedWith<Same/Diff>ID() method, which indicates whether or not the current
DSS being read is chained to the _FOLLOWING_ DSS (the one to be read next).
> II -- The DDMWriter enforces chaining on replies through use of a "chain bit" in the
header of the reply DSS.  If two replies AR and BR are chained, then the reply Header of AR
has to indicate whether is it chained to BR, and if so, it has to indicate whether BR will
have the SAME correlation id or a DIFFERENT correlation id.  The chain bit must be set according
to the chaining of the request DSSes (as determined from the reader.isChainedWith<...>ID()
methods) to which we're responding.  DDM Writer currently sets the chaining bit based on a
"reuseCorrId" flag that it receives from DRDAConnThread at the time of the write.  That flag
indicates whether or not the the current DSS (the one being written) should have the same
correlation id as the _PRECEDING_ DSS (the one we most recently wrote). 
> That said, the intermittent connection/communication failures that are showing up with
non-IBM-Universal drivers are caused by two factors:
> 1) There are several places in the DRDAConnThread code where the "reuseCorrId" flag that
is passed to DDMWriter is incorrect (it doesn't take chaining of the requests into account).
 This leads to incorrect chaining of the reply DSSes, which can then lead to problems for
the client when the client tries to process the reply (the client expects the replies to be
chained in a specific way, and if Network Server doesn't do it, the client can choke).
> 2) Currently, DDMWriter doesn't set the chaining bits for a reply DSS until the NEXT
reply DSS has begun (see "createDss<...>" methods in the DDMWriter class, for example).
 At the same time, there are a handful of calls to "send()" in the DRDAConnThread class, and
those calls tell DDMWriter to flush everything it has written to the client.  This is a problem:
if, for example, DDMWriter has written some reply DSS AR, the chaining bits for AR won't get
set until the next DSS is created--so if we up and call "send()", we'll end up sending AR
across the wire with it's chaining bits UNSET.  This isn't a problem if AR is NOT supposed
to be chained to anything after it--because the default chaining is "none".  However, if DRDAConnThread
calls "send()" in the middle of a chain, the last reply written is going to have incorrect
chaining info, and that can cause problems on the client.
> Whether or not the client actually chokes on the incorrect chaining bits is intermittent:
the reason is that this all depends on how the network packets are buffered and on the relative
speed of the CPU's of the client and server.  That said, the problem is typically more reproducible
across machines (i.e. if the client and server are two different machines).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message