Skip to Content.
Sympa Menu

freetds - Re: [freetds] Getting DB error = 20017 - Unexpected EOF from the server

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Getting DB error = 20017 - Unexpected EOF from the server
  • Date: Fri, 13 Mar 2009 23:41:25 -0400

Frediano Ziglio wrote:
> http://h71000.www7.hp.com/doc/82final/6529/6529pro_030.html

(nice resource!)

http://www.opengroup.org/onlinepubs/000095399/functions/send.html
http://www.opengroup.org/onlinepubs/000095399/functions/write.html

"[For] a socket, write() shall be equivalent to send() with no flags set."

> The problem is that in some situations
> tds_select can return even if data are not pending (or not possible to
> write) and catching these errors keep looping.

What situations?

I can't see a *standard* way for the code to fail in the way it did.

http://h71000.www7.hp.com/doc/82final/6529/6529pro_020.html#r_send

But then there are always nonstandard, undocumented ways. Sigh.

I agree with your analysis, but not DEC's implementation! EINPROGRESS is
not just a nonstandard return from write(2), it's nonsensical. We already
already know select(2) gave us the green light. EAGAIN or EWOULDBLOCK
will nevertheless tell us if *nothing* can be written. *Partial* success
is not an error, whether or not O_NONBLOCK is set. Who needs yet another
alias for "can't write to nonblocking socket"?

That said, the list of error conditions is quite long and the code a bit
simplistic. I wonder why we haven't bumped into this before. Here's the
union of possible error conditions and how I think they should be treated:


Error:
erc vendors description
------------ ------------ ----------------------------------------
EACCES posix The calling process does not have the ap
EBADF posix vms The socket argument is not a valid file
ECONNRESET posix vms A connection was forcibly closed by a pe
EDESTADDRREQ posix vms The socket is not connection-mode and no
EFAULT vms The message argument is not in a readab
EIO posix An I/O error occurred while reading from
EMSGSIZE posix vms The message is too large to be sent all
ENOBUFS posix vms Insufficient resources were available in
ENOTCONN posix vms The socket is not connected or otherwise
ENOTSOCK posix vms The socket argument does not refer to a
EOPNOTSUPP posix vms The socket argument is associated with a
EPIPE posix The socket is shut down for writing, or
Retry:
EAGAIN posix The socket's file descriptor is marked O
EINPROGRESS vms (undocumented)
EINTR posix vms A signal interrupted send() before any d
ENETDOWN posix vms The local network interface used to reac
ENETUNREACH posix vms No route to the network is present.
EWOULDBLOCK posix vms The socket's file descriptor is marked O

Yes, generic network failures should be subject to timeouts, not
automatically fail. No reason not to wait for a router to reboot.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page