Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Cade Roux <cade AT roux.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] SQL-08S01 error in FreeTDS/Azure when executing stored proc for a few minutes from Linux (but not from Windows)
  • Date: Wed, 21 Nov 2012 14:50:05 -0600

I see - that explains the problem when the flat->star-model transform
proc after the load was taking a long time (but again, that was
working from a Windows-based run of the identical script, but if there
is similar one-sided termination for some reason only Azure knows,
then that is explained).

Now that the flat->star transform is basically instant, and there
should be constant client traffic from the truncate, the inserts, the
row count and the transform, I need to break down the log from a
reproduced case adding some timings to make it easier to post here.

Thanks,

Cade
Cade Roux
cade AT roux.org
504-717-4887


On Wed, Nov 21, 2012 at 2:36 PM, James K. Lowden <jklowden AT freetds.org> wrote:
> On Wed, 21 Nov 2012 09:03:28 -0600
> Cade Roux <cade AT roux.org> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page