[Mono-dev] SQL Server question

[Neale Ferguson]

After fixing bug 609109, we're encountering an interesting situation. It
appears that the performance improvement is working "too well". Running an
internal test suite, we're finding that things work well but then suddenly
we get the server side closing the connection (a RST packet is being sent)
which results in us shutting down the connection and reflecting an IO
exception to the mono code:

14112 13:24:44.554091 sendto(8, ..., 126, 0, NULL, 0) = 126 <0.000029>
14112 13:24:44.554166 recvfrom(8, ..., 8, 0, NULL, NULL) = 8 <0.000575>
14112 13:24:44.554790 recvfrom(8, ..., 18, 0, NULL, NULL) = 18 <0.000010>
14112 13:24:44.558550 sendto(8, ..., 7999, 0, NULL, 0) = 7999 <0.000039>
14112 13:24:44.558712 sendto(8, ..., 489, 0, NULL, 0) = 489 <0.000008>
14112 13:24:44.558766 poll([{fd=8, events=POLLIN}], 1, 300000) = 1 ([{fd=8,
revents=POLLERR|POLLHUP}]) <0.000974>
14112 13:24:44.559794 recvfrom(8, 0x7f1f7642b138, 8, 0, 0, 0) = -1
ECONNRESET (Connection reset by peer) <0.000013>
14112 13:24:44.560381 shutdown(8, 0 /* receive */) = -1 ENOTCONN (Transport
endpoint is not connected) <0.000008>
14112 13:24:44.560422 close(8)          = 0 <0.000020>

19549 19.576639   129.2.10.148          129.2.10.36           TCP      60
ms-sql-s > 58955 [RST, ACK] Seq=3201427 Ack=16493 Win=0 Len=0

Worried that something in my fix had broken something we started
instrumenting the code. We found that when code to display what was being
appended to the output buffer the problem went away. When that code was
replaced by a simple 1 ms sleep the problem also disappeared.

This has led me to wonder if it is possible to hammer a SQL Server too hard
and have it simply shut up the client by closing its connection. Maybe this
is outside of SQL Server and something that Windows itself is doing. I am
not an expert in either of these components but I've seen references when
searching on these symptoms to indicate I may not be mad. Does anyone have
any experiences or opinions?

Neale