0

追加のソースから HTTP メッセージを受信できるようにするためのカスタム バインディングを作成しました。ただし、まだバグがないわけではありません。

私のサービスは、最初のリクエストが処理されるとすぐに CPU 使用率を最大 100% に押し上げ、より多くのリクエストが入ってくるほどサービスが遅くなるのを観察しました。バインディングの機能。

最初のリクエストが入る前までは、すべて正常に動作します:

ChannelListener: OnBeginAcceptChannel
ChannelListener: OnAcceptChannel

次に、最初のメッセージの処理が行われます。

Channel: static constructor
Channel: constructor
ChannelListener: OnEndAcceptChannel (completes)
ChannelListener: Uri get
ChannelListener: OnBeginAcceptChannel
ChannelListener: OnAcceptChannel
Channel: OnOpen
Channel: BeginTryReceiveRequest
Channel: TryReceiveRequest
Channel: WaitForRequest
Channel: ReceiveRequest
Context: constructor
Channel: EndTryReceiveRequest (completes)
Context: RequestMessage get
`Channel: BeginTryReceiveRequest`
Context: Reply noTimeout
Context: Reply
Context: Close noTimeout
`Channel: TryReceiveRequest`
`Channel: WaitForRequest`
`Channel: ReceiveRequest (hangs)`
`Channel: EndTryReceiveRequest (doesn't complete since receive hangs)`
`Channel: BeginTryReceiveRequest`
`and so on...`

チャネルは IReplyChannel インターフェイスを実装しているため、要求を取得して応答し、チャネルを閉じることしかできないはずです。チャネルを閉じるだけでなく、ServiceModel は、過去に使用されていたチャネルに関係なく、既に使用されているチャネルで TryReceiveRequest をスパムし続けます。

これを適切に修正する方法はありますか?応答コンテキストを閉じた後に ServiceModel がチャネルを閉じないのはなぜですか?

4

1 に答える 1