为什么在使用PushStreamContent时需要此Sleep？

Question

Referring to this sample code on GitHub: https://github.com/DblV/StreamingWebApi/blob/master/StreamingService/StreamingService/Controllers/StreamingController.cs

I want to stream content stored in a database, which my query returns as a sequence of blobs (essentially one file split into "blocks"). Due to the potential size of the complete response, I want to stream it, and I am following the above example as follows:

public class FileController : ApiController
{
    [HttpGet]
    public HttpResponseMessage Get(string id, [FromUri] string contentType)
    {
        var message = new HttpResponseMessage(HttpStatusCode.OK);
        message.Content = new PushStreamContent((stream, content, context) =>
        {
            GetFileContent(stream, int.Parse(id));
            Thread.Sleep(1000);
            stream.Close();
        });
        message.Content.Headers.ContentType = new MediaTypeHeaderValue(contentType);

        return message;
    }

    private void GetFileContent(Stream stream, int id)
    {
        var result = Query(reader => reader.GetStream(0), id);

        foreach (var b in result)
        {
            b.CopyToAsync(stream);
            stream.Flush();
        }
    }

    private IEnumerable<Stream> Query(Func<DbDataReader,Stream> func, int id)
    {
        var command = // Not shown - SELECT command creating the result set

        var reader = command.ExecuteReader();
        if (reader.HasRows)
        {
            while (reader.Read())
            {
                yield return func(reader);
            }
        }

        reader.Close();
    }

Note the use and placement of Thread.Sleep . When I test this in the browser, the content downloads to a file, but without the Sleep , it hangs at the point of completion; with the Sleep , it completes properly, and the resulting download is perfect.

My question: what is the Sleep doing that averts the hang condition? My suspicion is that this is more of a work-around than a proper solution; if so, what should I be doing instead?

Answer 1

Found that it is a mistake on my part. I was incorrectly using CopyToAsync where I should be using CopyTo . Correcting this mistake, it works just fine.