FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Jeff.Goodwin AT fairchildsemi.com wrote:
> freetds-bounces AT lists.ibiblio.org wrote on 03/15/2009 06:13:21 PM:
> > 
> http://h71000.www7.hp.com/doc/82final/6529/6529pro_030.html#app_error_codes
> > 
> > 54 ECONNRESET    SS$_CONNECFAIL    Connection reset by peer
> 
> When the program failed again today with a EINPROGRESS, I felt 
> something was amiss.  I realized that although I had rebuilt all my 
> executables, I neglected to rebuild my intermediate object file that
> links  with main ADA program to provide the Sybase calls.  The
> ECONNRESET was not  the result of the changes that Freddy had suggested
> as I was still running  the same code.  

You have an interesting problem, Jeff.  I wanted to include a URL to a TCP
reference, so we could all review the same text.  Sadly, and not for the
first time, I didn't find one.  I had to return to Richard Stevens's UNIX
Network Programming Vol 1, 3rd ed.  

If you've found a FreeTDS problem, I want to know about it.  OTOH the
evidence so far all points the other way.  So you have my attention, for
what that's worth.  

> This mean that the ECONNRESET is an additional issue that we have only 
> seen this one time.  

That's information.  

> As you can see below, the stop times and elapsed 
> times are all over the place:

I shortened and sorted your rows to clarify: 

errno date & time        Elapsed time  nRecords
----- ------------------ ------------- --------
   36 21-FEB 15:24:24.21 1 00:31:41.19     2876
   36 24-FEB 09:25:44.82 1 00:25:51.75     5254 
   36  3-MAR 08:40:02.18 1 00:12:44.24    26091
   36  4-MAR 17:09:46.15 1 00:57:54.58      996
   36 11-MAR 16:16:12.36 1 00:08:52.41    22292
   36 13-MAR 11:46:47.78 0 04:22:57.17     5834
   54 15-MAR 02:54:58.96 1 00:23:09.64     9036
   36 16-MAR 11:13:36.99 1 00:02:23.50     1411
   
Except for 13 March, everything is between 24 and 25 hours.  Hmm....

Keep in mind errno is bogus if read/write returns 0.  For reading, 0
indicates the peer closed the connection, which is not an error as far as
the local TCP is concerned.  For writing, 0 is the smallest non-error
value.  

Stated another way: if zero bytes are read, it's a TDSESEOF error.  If
zero are written, retry.  That's what needs to happen.  

> I also have monitored the process quotas and it doesn't 
> seem to be a resource exhaustion issue on the client process side.

I don't think it's client resource exhaustion.  IMO the server is closing
the connection.  I was offering as a possible explanation exhaustion of a
server resource.  

> This program is being ported from the OpenVMS VAX architecture using the
> 
> commercial Sybase client to the OpenVMS Itanium architecture using 
> FreeTDS.  The program is still in test mode.  That is why there is not a
> 
> failure every day.

Is the server implementation changing, too, or just the client?  

> The client and server are on the same LAN and there are no firewalls 
> between them.  

Noted.  

> I had entertained the idea of putting the server on the 
> exact same physical network card to eliminate any 'in between' network 
> hardware issues.  After your comments, I'll think we'll proceed with
> that  plan.  

Worth trying.  I don't know whether to root for that one or not.  

> We had also considered there was something on the server that might be 
> shutting the processes down.  We hadn't found anything, but after
> looking  at the above data again, it still seems to be a probable cause.

If the server logs indicate nothing amiss, then the server thinks the
*client* terminated.  If the server and the client both think the other
guy did it, that points to the network, firewall or no.  :-(

Keep posting the tail end of the TDSDUMP logs, though, especially the last
packet sent.  I can't help thinking we're overlooking something, a bit set
or reset, that constitutes a protocol violation and is cause for
termination, as it were.  But my leading suspect is either an intermediary
closing the connection, or something (perhaps even something about the
client TCP implementation) causing the server's TCP to close the
connection.  None of which seems likely to me, either.  

> I've implemented the changes from the diff file you supplied as well as 
> the strerror() change you suggested.

Excellent.  Next time you post, please include a universal diff if it's
not too much trouble (against the unmodified tarball).  Or even just net.c
 Just to make sure what you did is what I think you did, and all that.  

Regarding tcpdump(8).  Remember you don't need to run it on the client or
the server.  You just need a machine attached to the same network and that
can see both sides.  (Sorry if that was obvious.)  

HTH.  

--jkl