0

ストリームとWebAPIに問題があります。

WebAPIによって消費されるストリームを返します。現在、ストリームを取得した後、ソケットをプールに入れています。しかし、これはいくつかのエラーを引き起こします。

ここで、リクエストが終了した後、ソケットをプールに入れる必要があります。（ストリームは消費され、現在は閉じられています）。

これまたは他のいくつかのベストプラクティスの代表者はいますか？

コード例：

public HttpResponseMessage Get(int fileId)
{
HttpResponseMessage response = null;
response = new HttpResponseMessage(HttpStatusCode.OK);

Stream s = GetFile(id);

response.Content = new StreamContent(fileStream);

}

GetFile(int id)
{
FSClient fs = GetFSClient();
Stream s = fs.GetFileStream(id);
AddFSToPool(fs);

return s;
}

GetFileは、自己プログラムされたFileServer-Clientを使用します。FileServer-Connectionsを再利用するオプションがあります。この接続はプールに保存されます。（プールには未使用のFileServer接続のみがあります）。次のリクエストがGetFSClient（）を呼び出すと、接続されているリクエストがプールから取得されます（そしてプールから削除されます）。

ただし、別のリクエストが着信し、プール内にあるFileServer-Connectionを使用する場合（未使用のため）、ストリームが使用されている可能性があるという問題があります。

リクエストが終了し、ストリームが完全に消費された後、「FSClintをプールに入れる」を実行したいと思います。

そのためのエントリポイントはありますか？

4

1 に答える 1

2

Stream揮発性/一時的なリソースと見なされます-実装するのも不思議ではありませんIDisposable.

また、スレッドセーフではありません。Streamこれは、最後まで読み取られた場合、最初にリセットする必要があり、2 つのスレッドがストリームを読み取っている場合、異なるチャンクを読み取る可能性が高いためです。Position

そのため、私はこの問題を解決しようとさえしません。Web サイト (本質的にマルチユーザー/マルチスレッド) でストリームを再利用することはお勧めしません。

アップデート

私が言ったように、最良の選択肢は解決策を再考することだとまだ考えていますが、リクエストの終了後に実行されるものを登録する必要がある場合は、リクエストに応じて使用RegisterForDisposeしてください:

public HttpResponseMessage Get(HttpRequestMessage req, int fileId)
{
   ....
   req.RegisterForDispose(myStream);
}
于 2013-01-28T12:12:15.763 に答える