Re: SQL-08S01 error in FreeTDS/Azure when executing stored proc for a few minutes from Linux (but not from Windows)

On Wed, 21 Nov 2012 09:03:28 -0600
Cade Roux <[email protected]> wrote:

> I'm thinking that Azure "pauses" the connection at
> some point and the inserts fail and then the connection starts working
> again (I reuse the same connection for all the files).  Why this
> happens only on the start of a file is a bit of a mystery, although
> obviously there is a small time gap between files for the count to be
> take, the file to be close, the new file to be opened, and the table
> to be truncated before the next set of inserts.  

Looking back at your first message, I see this error in your log:

    net.c:1257:GNUTLS: level 4:
      REC[0x9a833c8]: Sent Packet[6] Application Data(23) with length:
101 
    token.c:540:tds_process_tokens(0x9a574b8, 0xbfcb9ca8, 0xbfcb9cac,
0x6914) 
    util.c:156:Changed query state from PENDING to READING
    net.c:1199:in tds_pull_func
    util.c:331:tdserror(0x9a54e80, 0x9a574b8, 20004, 104)
    odbc.c:2270:msgno 20004 20003
    util.c:361:tdserror: client library returned TDS_INT_CANCEL(2)
    util.c:384:tdserror: returning TDS_INT_CANCEL(2)
    util.c:156:Changed query state from READING to DEAD
    net.c:1257:GNUTLS: level 7:
      READ: -1 returned from 0x9a574b8, errno=104 gerrno=0

tds_pull_func reads encrypted data.  From the log messages, it would
appear it called tds_goodread, which eventually called read(2), which
failed with errno 104.  Unfortunately the error processing doesn't
write the error message associated with 104 for your system.  However,
it seems that the server drops the connection, and SQLExecute then fails
with "Read from SQL Server failed".  

The server closed the connection.  Why?  It doesn't say.  Searching
Google for "azure timeout", I found

http://blogs.msdn.com/b/avkashchauhan/archive/2011/11/12/windows-azure-load-balancer-timeout-details.aspx

which suggests that Azure will close the connection after some
time, depending on load.  Hard to tell exactly what's going on between
all the HTTP and .Net frou-frou.  

There is of course no need to silently terminate the connection.  The
client is patiently waiting for the server to send data.  If the server
wishes to close the connection for any reason, it's still free to issue
an error message first, allowing the client to notify the user. 

--jkl