[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    RE: [freetds] FreeTDS (on FreeBSD) lost connection toremoteMSSQLserver
From:       "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio () vodafone ! com>
Date:       2005-06-27 15:08:15
Message-ID: F7F148C986A2A84F930FEB8C3B169EA025C78F () OPDMEXO01 ! omnitel ! it
[Download RAW message or body]

> 
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Monday, June 27, 2005 9:35 AM
> >> 
> >> Is there any way to detect server disconnection?
> >> I have FreeTDS installed from ports on FreeBSD 5.3 (version 5.0 as
> >> port says).
> >> Everything working great, but in case network problems or 
> SQL server
> >> restart tds_submit_query simply returns 0 (TDS_FAIL) with no extra
> >> information.
> >> Can I handle such kind of situation?
> >> Thank You!
> >>  
> > 
> > I remember some (old) post on this subject... it seems that FreeTDS
> > is too silent about connection closing. It close correctly 
> connection
> > and all future function should return failure condition however it
> > do not launch any message to client. James, what do you think about?
> > How do proprietary libraries behave? Do they continue informing
> > client that connection is closed?
> 
> I don't know, because I keep my clients connected?  ;-)
> 
> Looking at the code, tds_write_packet() returns TDS_SUCCEED 
> or TDS_FAIL.
> No information is stashed in the TDSSOCKET about what's 
> wrong.  I think
> that's the OP's complaint: he can't discover what's going on. 
>  (I don't
> see even a log message, let alone anything being sent to the error
> handler, btw.)  
> 
> The communication error messages, from doc/dblib_errors.txt:
> 

Mmmm...

> Bad token from the server: Datastream processing out of sync.

>From src/tds/token.c

        default:
                tds_client_msg(tds->tds_ctx, tds, 20020, 9, 0, 0,
"Unknown marker");
                if (IS_TDSDEAD(tds))
                        tds_set_state(tds, TDS_DEAD);
                else
                        tds_close_socket(tds);
                tdsdump_log(TDS_DBG_ERROR, "Unknown marker: %d(%x)!!\n",
marker, (unsigned char) marker);
                return TDS_FAIL;
        }

Perhaps proprietary error is clearer

> DB-Library capabilities not accepted by the Server.
> Unexpected capability type in CAPABILITY datastream. 392

I use very few capability

> Error in closing network connection.

?? quite strange, not handled (kernel error ??)

> Unable to connect: Adaptive Server is unavailable or does not exist.
> Unsolicited event notification received.
> Adaptive Server connection failed.
> Negotiated login attempt failed.

it would be fine if FreeTDS could distinguish these errors and report to
client...

> Error in sending out-of-band data to the server.
> Read from the server failed.

from src/tds/net.c

       if ((len = goodread(tds, header, sizeof(header))) < (int)
sizeof(header)) {
                /* GW ADDED */
                if (len < 0) {
                        tds_client_msg(tds->tds_ctx, tds, 20004, 9, 0,
0, "Read from SQL server failed.");
                        tds_close_socket(tds);
                        tds->in_len = 0;
                        tds->in_pos = 0;
                        return -1;
                }

good

        if (x < 1) {
                /*
                 * Not sure if this is the best way to do the error
handling
                 * here but this is the way it is currently being done.
                 */
                tds->in_len = 0;
                tds->in_pos = 0;
                tds->last_packet = 1;
                /* return 0 if header found but no payload */
                return len ? -1 : 0;
        }

no message... bad

> Unexpected EOF from the server.

We do not distingue this error from a read error (I don't think is a big
problem...)

> Unable to open socket.

from src/tds/net.c

       if (TDS_IS_SOCKET_INVALID(tds->s = socket(AF_INET, SOCK_STREAM,
0))) {
                tdsdump_log(TDS_DBG_ERROR, "socket creation error:
%s\n", strerror(sock_errno));
                return TDS_FAIL;
        }

no error to client

> Read attempted while out of synchronization with Adaptive Server.
> Unknown message-id in MSG datastream.
> Unable to set communications timer.
> Unrecognized TDS version received from the server.
> Write to the server failed.
> 

from src/tds/net.c

                if (retval <= 0) {
                        tdsdump_log(TDS_DBG_NETWORK, "TDS: Write failed
in tds_write_packet\nError: %d (%s)\n", sock_errno,
strerror(sock_errno));
                        tds_client_msg(tds->tds_ctx, tds, 20006, 9, 0,
0, "Write to SQL Server failed.");
                        tds->in_pos = 0;
                        tds->in_len = 0;
                        tds_close_socket(tds);
                        return -1;
                }

good

> EXCOMM is described as "Failure in communication with Server -- the
> DBPROCESS is dead."
> 
> When communication has been lost -- I'm not sure how we know when that
> is -- I think the only thing to do is to set issue the error "Write to
> the server failed" (differs by library) and set tds->state = TDS_DEAD.
> That way the client libraries would know the TDSSOCKET is no good, and
> should consistently refuse to use it.  
> 
> This is the reward for making timeouts work: now we have to tell the
> client what's wrong, instead of just retrying forever!  
> 

Correct but is what code do now.

> Of course, I'm just reasoning from the code and the documentation,
> knowing, as an application programmer, how I'd like libsybdb 
> to behave.
> I'm not set up to test this with the vendors' libraries.  If someone
> else would like to do that, I'm sure we'd learn something.  
> 
> HTH and regards, 
> 

I'll try to do some tests...

bye
  freddy77
_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

[prev in list] [next in list] [prev in thread] [next in thread]