Skip to Content.
Sympa Menu

freetds - Re: [freetds] v0.95.65 Session Busy Errors After Error

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: Ken Collins <ken AT actionmoniker.com>
  • Cc: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] v0.95.65 Session Busy Errors After Error
  • Date: Sat, 7 Nov 2015 13:25:36 +0000

2015-11-07 11:47 GMT+00:00 Frediano Ziglio <freddy77 AT gmail.com>:
> 2015-11-04 21:01 GMT+00:00 Ken Collins <ken AT actionmoniker.com>:
>> 2015-11-03 1:25 GMT+00:00 Ken Collins <ken AT metaskills.net>:
>>> This is a cross post from an issue filed on GitHub. Not sure which is
>>> preferred.
>>>
>>> https://github.com/FreeTDS/freetds/issues/30
>>
>> I don't see nothing special in the log. A wrong query is sent. An
>> error is generated from the server. A cancel is sent. I cannot see
>> what happen after the cancel. Does the client process the cancel? Do
>> you have a log from 0.91 ?
>>
>> Thanks for the read thru and reply. I really did try to provide a 0.91 dump
>> file but for some reason it never generated more than two lines in the
>> file.
>>
>> From the 0.95 perspective, here are two gist links of dump output
>> immediately after the error dump previously mentioned. Both execute a
>> simple
>> `SELECT 1 AS [one]` to test the client state.
>>
>> DEBUG-0.95.65-nextquery1.log -
>> https://gist.github.com/metaskills/a07f213e14281b42695d
>>
>> DEBUG-0.95.65-nextquery2.log -
>> https://gist.github.com/metaskills/35aa3f9e0119f137c2b4
>>
>> I feel there may be an answer in these two. Gonna scan over them now and
>> think about it. Help appreciated!
>>
>
>
> Really interesting. Looks like the cancel is not sent directly but
> queued and later sent after the query. This make the query fail. Looks
> like the cancellation is not processed correctly for some reason.
> I'll have a look at what happen in the program.
>

Got it! Is not the cancel after the query but the cancel from the
message handler. In this case a cancel is set but not reset causing it
to be registered for the next query.

Not hard to fix, time to write a new test (or extend another)

Frediano




Archive powered by MHonArc 2.6.24.

Top of Page