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: Frediano Ziglio <freddy77 AT gmail.com>
  • 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 21:36:42 +0000

Can you try this patch?

It decrease keepalive times to 30 seconds. Well.. where supported
(Linux for sure).

Frediano

2012/11/21 Cade Roux <cade AT roux.org>:
> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds

Attachment: more_keepalive.diff
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page