Skip to Content.
Sympa Menu

freetds - Re: [freetds] ct_cancel hangs

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ct_cancel hangs
  • Date: Fri, 27 Jul 2007 14:42:24 +0200

> ZIGLIO, Frediano, VF-IT a écrit :
> >> ZIGLIO, Frediano, VF-IT wrote:
> >>>>> net.c:542:Received packet
> >>>>> 0000 fd 30 00 02 00 d1 04 00-00
> >> |.0...... .|
> >>>>> token.c:1920:processing row. column size is 253
> >>>> That "fd 30 00" means "end of result set (fd), "results
> >>>> cancelled (30)".
> >>>>
> >>> Mumble mumble... it seems that client part is still
> >> expecting row data
> >>> while server send cancel acknowledge... it would be helpful to see
> >>> previous packet header. Perhaps server stop sending row
> informations
> >>> just sending an empty packet with last flag set to 1 ??
> >> Well, it's a mistake for the client to expect row data after
> >> the server
> >> sends that cancel acknowledgement.
> >>
> >> Cancel -->
> >> <-- data
> >> <-- data
> >> <-- data
> >> <-- End of Results, results cancelled
> >> [state == idle]
> >>
> >
> > yes, but how does the client know that the server is
> sending acknowledge
> > and not just data cause it have still to receive our cancel? Client
> > correctly send cancel and start parsing data normally (but
> discarding
> > rows and similar). When it receive cancel acknowledge it
> pass status to
> > idle and reset TDSSOCKET cancel flag. From dump we saw a
> packet which
> > contains only the acknowledge but it seems that client is
> still handling
> > row data so it parses the acknowledge as a normal column
> data. Perhaps
> > for long resultset server stops sending row data setting last_packet
> > flags in header and than send the aknowledge in a different packet??
> > This is why I asked to see previous packet...
> >
>
> here is a larger part of the logfile around the ct_cancel command.
> Is this more useful?
> (I've removed some nominative lines)
>
>
> (...)
> read.c:179:tds_get_string: reading 15 from wire to give 15 to client.
> token.c:1526:processing result. type = 39(varchar), varint_size 1
> token.c:1547:processing result. column_size 2
> read.c:179:tds_get_string: reading 12 from wire to give 12 to client.
> token.c:1526:processing result. type = 111(datetime-null),
> varint_size 1
> token.c:1547:processing result. column_size 8
> read.c:179:tds_get_string: reading 10 from wire to give 10 to client.
> token.c:1526:processing result. type = 39(varchar), varint_size 1
> token.c:1547:processing result. column_size 10
> read.c:179:tds_get_string: reading 15 from wire to give 15 to client.
> token.c:1526:processing result. type = 39(varchar), varint_size 1
> token.c:1547:processing result. column_size 2
> read.c:179:tds_get_string: reading 10 from wire to give 10 to client.
> token.c:1526:processing result. type = 38(integer-null), varint_size 1
> token.c:1547:processing result. column_size 4
> read.c:179:tds_get_string: reading 17 from wire to give 17 to client.
> token.c:1526:processing result. type = 39(varchar), varint_size 1
> token.c:1547:processing result. column_size 2
> read.c:179:tds_get_string: reading 6 from wire to give 6 to client.
> token.c:1526:processing result. type = 38(integer-null), varint_size 1
> token.c:1547:processing result. column_size 4
> read.c:179:tds_get_string: reading 13 from wire to give 13 to client.
> token.c:1526:processing result. type = 39(varchar), varint_size 1
> token.c:1547:processing result. column_size 2
> read.c:179:tds_get_string: reading 16 from wire to give 16 to client.
> token.c:1526:processing result. type = 38(integer-null), varint_size 1
> token.c:1547:processing result. column_size 2
> read.c:179:tds_get_string: reading 7 from wire to give 7 to client.
> net.c:446:Received header
> 0000 04 00 01 fc 00 00 00 00- |........|
>
....

I'm unable to reproduce on my system :(
I need packets from cancel to the end...

Try with this query (better on master or tempdb databases)

select a.*, b.*, c.* from sysobjects a, sysobjects b, sysobjects c

this should produce a lot of long rows (and doesn't contain sensible data).

freddy77





Archive powered by MHonArc 2.6.24.

Top of Page