[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    Re: [freetds] ct_cancel  hangs
From:       "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio () vodafone ! com>
Date:       2007-07-27 12:42:24
Message-ID: F7F148C986A2A84F930FEB8C3B169EA002FBCEA1 () OPDMEXO01 ! omnitel ! it
[Download RAW message or body]

> 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

_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

[prev in list] [next in list] [prev in thread] [next in thread]