Wenn, oder wenn, zu Entsorgen HttpResponseMessage beim Aufruf ReadAsStreamAsync?

Ich bin mit dem System.Net.Http.HttpClient, um einige der client-Seite die HTTP-Kommunikation. Ich habe alle HTTP-an einem Ort, abstrahiert von dem rest des Codes. In einem Fall will ich die Antwort Lesen-Inhalte als stream an, aber der Verbraucher, der stream ist gut isoliert, von wo aus die HTTP-Kommunikation geschieht, und der stream wird geöffnet. In der Stelle, verantwortlich für die HTTP-Kommunikation ich bin die Entsorgung aller von der HttpClient Zeug.

Dieser unit-test schlägt fehl bei Assert.IsTrue(stream.CanRead):

[TestMethod]
public async Task DebugStreamedContent()
{
    Stream stream = null; //in real life the consumer of the stream is far away 
    var client = new HttpClient();        
    client.BaseAddress = new Uri("https://www.google.com/", UriKind.Absolute);

    using (var request = new HttpRequestMessage(HttpMethod.Get, "/"))
    using (var response = await client.SendAsync(request))
    {
        response.EnsureSuccessStatusCode();
        //here I would return the stream to the caller
        stream = await response.Content.ReadAsStreamAsync();
    }

    Assert.IsTrue(stream.CanRead); //FAIL if response is disposed so is the stream
}

Ich in der Regel versuchen, entsorgen Sie alles, was IDisposable zum frühest möglichen Komfort, aber in diesem Fall, entsorgen Sie die HttpResponseMessage verfügt auch über die Stream zurück von ReadAsStreamAsync.

So scheint es, wie der aufrufende code muss wissen über und den Besitz der response-Nachricht als auch als stream, oder lasse ich die response-Nachricht undisposed und lassen Sie den finalizer mit der Situation umgehen. Weder die option fühlt sich richtig an.

Diese Antwort spricht nicht über die Entsorgung der HttpClient. Wie über die HttpRequestMessage - und/oder HttpResponseMessage?

Bin ich etwas fehlt? Ich bin der Hoffnung, zu halten die Konsum-code unwissend über HTTP, sondern dass alle diese undisposed Objekte herum geht gegen Jahre der Gewohnheit!

Nur ein Tipp - Nicht alles IDisposable entsorgt werden muss
Dies scheint nicht, nichts zu tun haben mit async per se. Die Regeln sind die gleichen, so oder so: nicht entsorgen, das Objekt, bis Sie fertig ist. Das gleiche würde gelten, mit der synchronen version. Also, nutzen Sie die zurückgegebenen Stream innerhalb der using. Wenn Sie brauchen, um verwenden Sie die Stream außerhalb des Kontexts, in dem die Anforderung erstellt haben, müssen Sie zum einrichten eines anderen Mechanismus zu verfügen, die zur rechten Zeit.
Also: ich empfehle, nicht verlassen Entsorgung für den finalizer...aber ich beachten Sie, dass Sie nicht die Mühe zu entsorgen client sowieso, also, wenn Sie fühlen, nicht die Mühe mit dem anderen Zeug auch nicht. Wie für die Antwort, die Sie Referenz, beachten Sie, dass es sich auf das Szenario, wo Sie die Wiederverwendung der HttpClient Objekt; ehrlich gesagt, sollte es offensichtlich sein, dass, wenn Sie wiederverwenden möchten, müssen Sie nicht entsorgen Sie es. Die Anleitung sagt nicht, überhaupt etwas darüber, ob es legitim zu lassen das Objekt Entsorgung geschieht über die Fertigstellung (und IMHO ist es sehr schlechte form zu).

InformationsquelleAutor dkackman | 2014-12-31

.net c#dotnet-httpclient idisposable stream

11

So scheint es, wie der aufrufende code muss wissen über und nehmen
Eigentum der response-Nachricht als auch als stream, oder lasse ich
die response-Nachricht undisposed und lassen Sie den finalizer mit der Situation umgehen.
Weder die option fühlt sich richtig an.

In diesem speziellen Fall es gibt keine Finalizer. Weder HttpResponseMessage oder HttpRequestMessage einen finalizer implementieren (und das ist auch gut so!). Wenn Sie don ' T verfügen entweder von Ihnen, werden Sie von der garbage Collection eingesammelt, sobald die GC-kicks, und der Griff Ihrer zugrunde liegenden streams gesammelt werden, sobald das passiert.

Solange Sie diese Objekte verwenden, nicht entsorgen. Sobald Sie dies getan haben, entsorgen Sie. Stattdessen wickelte Sie in ein using - Anweisung können Sie immer explizit aufrufen Dispose sobald Sie fertig sind. So oder so wird die Konsum-code braucht nicht auf irgendwelche Kenntnisse zugrunde liegenden http-Anfragen.
- Ist das nicht eine gute Sache überhaupt! Verlassen un-entsorgt HttpMessageRequest & HttpMessageResponse Objekte bedeutet, dass Sie nur entsorgt werden mittels GC (wenn es Mai beschlossen, laufen) und bis dann alle Ressourcen verwendet, die für den Aufruf freigegeben werden. Dies führt zu port Erschöpfung, timeouts, wenn es ein limit für gleichzeitige HTTP-requests, etc...
- Wo in meiner Antwort habe ich gesagt, nicht zu entsorgen die Objekte? Haben Sie Lesen Sie den zweiten Absatz?
- Die GC nie Anrufe .Dispose() in seinem eigenen Recht. Es ist nur, wenn es einen finalizer aufruft .Dispose() dass die GC auslösen können entsorgen.
- vielleicht habe ich falsch gelesen, aber der Eindruck, den ich bekam, war, dass es nicht in Ordnung, entsorgen Sie diese Objekte, weil GC wird sich um Sie kümmern. In meiner Erfahrung, es ist sehr wichtig, entsorgen Sie diese explizit.
- natürlich ist der finalizer ruft die Dispose () - und nur die Objekte, die die tatsächlichen nativen Ressourcen (eine Steckdose in unserem Fall) wird der finalizer. Jedoch, es spielt keine Rolle, weil beim Aufruf von Dispose() auf die HttpResponseMessage, es wird über alle Objekte, die Referenzen einschließlich der mit dem Finalizer.
- Es ist überhaupt nicht garantiert, dass die finalizer aufruft .Dispose() - dies passiert nur, wenn der finalizer explizit geschrieben, dies zu tun.
InformationsquelleAutor Yuval Itzchakov

Können Sie auch Streams als input-parameter, also der Anrufer hat die vollständige Kontrolle über den Typ des Streams sowie es zur Verfügung. Und jetzt können Sie auch entsorgen httpResponse bevor die Steuerung verlässt die Methode.

Unten ist die extension Methode für HttpClient

    public static async Task HttpDownloadStreamAsync(this HttpClient httpClient, string url, Stream output)
    {
        using (var httpResponse = await httpClient.GetAsync(url).ConfigureAwait(false))
        {
            //Ensures OK status
            response.EnsureSuccessStatusCode();

            //Get response stream
            var result = await httpResponse.Content.ReadAsStreamAsync().ConfigureAwait(false);

            await result.CopyToAsync(output).ConfigureAwait(false);
            output.Seek(0L, SeekOrigin.Begin);                
        }
    }

InformationsquelleAutor LP13

4

Umgang mit Verfügt in .NET ist sowohl in einfach, und schwer. Für Sie sicher.

Streams ziehen diese gleichen Unsinn... Tut Entsorgung der Puffer auch dann automatisch entsorgen Stream gewickelt? Sollte es? Als Verbraucher sollte ich noch wissen, ob es funktioniert?

Wenn ich viel mit diesem Zeug, ich gehe durch einige Regeln:
1. Dass, wenn ich denke, es sind nicht-native Ressourcen im Spiel (wie, eine Netzwerk-Verbindung!) Ich lassen Sie nicht immer die GC "komme". Ressourcen-Erschöpfung ist real, und guten code beschäftigt.
2. Wenn eine Einweg-nimmt eine Einweg-als parameter, es gibt nie Schaden abdeckt, meinem Hintern und macht sicher, dass mein code verfügt über jeden Gegenstand, den er macht. Wenn mein code nicht, ich kann es ignorieren.
3. GCs call ~Abschließen, aber nichts garantiert, dass Finalize (d.h. Ihre benutzerdefinierten Destruktor) aufgerufen Entsorgen. Es gibt keine Magie, entgegen der Meinungen oben, so dass Sie für Sie verantwortlich zu sein.
So, du hast ein HttpClient, ein HttpRequestMessage, und ein HttpResponseMessage. Das Leben eines jeden von Ihnen, und jede Einweg, die Sie machen, müssen respektiert werden. Also, Ihr Stream sollte nie erwarten, um zu überleben außerhalb des Dispoable Lebensdauer HttpResponseMessage, weil Sie nicht instanziieren der Stream.

In deinem obigen Szenario, mein Muster wäre, zu behaupten, dass zu bekommen, der Stream war wirklich nur in einer Statischen.DoGet(uri) - Methode, und den Stream, den du wieder zurückkehren würde, HABEN zu unserer eigenen machen. Das bedeutet, dass ein zweiter Stream, mit der HttpResponseMessage stream .CopyTo würde meine neue Stream (routing durch ein FileStream-oder ein MemoryStream-oder was auch immer am besten zu Ihrer situation passt)... oder etwas ähnliches. Denn:
- Sie haben kein Recht, die Lebenszeit HttpResponseMessage Stream. Das ist seine, nicht deine. 🙂
- Hält die Lebensdauer von Einweg-wie HttpClient, während Sie Knirschen der Inhalt der zurückgegebenen stream, ist eine verrückte blocker. Das wäre wie mit auf eine SqlConnection, während Sie analysieren eine DataTable (sich vorstellen, wie schnell würden wir verhungern Sie einen Verbindungspool wenn DataTables haben große)
- Freilegung der wie zu bekommen, die Reaktion kann Arbeit gegen FESTE... Sie hatte einen Stream, das ist Einweg, aber es kam aus einer HttpResponseMessage, was ist Einweg, aber das passiert nur, weil wir verwendet HttpClient und HttpRequestMessage, die Einweg - ... und alles, was Sie wollte, war ein stream von einer URI. Wie verwirrend diese Verantwortung fühlen?
- Netzwerke sind immer noch die langsamste Spuren in Computersystemen. Halten Sie für eine "Optimierung" noch in den Wahnsinn. Es gibt immer bessere Möglichkeiten zur Bewältigung der langsamsten Komponenten.
So verwenden Sie Einwegprodukte wie catch-and-release... machen Sie, Haken Sie die Ergebnisse für sich selbst, lassen Sie Sie so schnell wie möglich. Und nicht zu verwechseln mit der Optimierung für die Richtigkeit, insbesondere aus den Klassen, die Sie nicht selbst Autor.

InformationsquelleAutor Craig Brunetti

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.