Понимание надежного поведения повторных сеансов WCF - PullRequest
Новая
       18

Понимание надежного поведения повторных сеансов WCF

5 голосов
/ 07 октября 2009

У меня есть несколько вопросов о надежности сеанса WCF:

  1. Повторно ли сериализовывает WCF сообщение во время попытки повторной попытки?

    2. Если 1 правильно - это происходит после того, как параметры сообщения были удалены или нет?
    3. Если 2 правильно - есть ли способ определить, что сообщение было отправлено точно?

Я пока не могу понять это через отражатель.

UPD 1: Меня больше интересуют возвращаемые значения сервера. Что с ними происходит?

UPD 2: Когда располагаются параметры сообщения (если быть точным - ответ сервера)? Это происходит при получении соответствующих подтверждений? Вот что я имею в виду, выбрав параметры: 

at MyNamespace.MyReply.Dispose()
   at System.ServiceModel.Dispatcher.MessageRpc.DisposeParametersCore()
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessageCleanup(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
   at System.ServiceModel.Dispatcher.ChannelHandler.DispatchAndReleasePump(RequestContext request, Boolean cleanThread, OperationContext currentOperationContext)
   at System.ServiceModel.Dispatcher.ChannelHandler.HandleRequest(RequestContext request, OperationContext currentOperationContext)
   at System.ServiceModel.Dispatcher.ChannelHandler.AsyncMessagePump(IAsyncResult result)
   at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
   at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
   at System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame(IAsyncResult result)
   at System.ServiceModel.AsyncResult.Complete(Boolean completedSynchronously)
   at System.ServiceModel.Channels.InputQueue`1.AsyncQueueReader.Set(Item item)
   at System.ServiceModel.Channels.InputQueue`1.Dispatch()
   at System.ServiceModel.Channels.InputQueueChannel`1.Dispatch()
   at System.ServiceModel.Channels.ReliableReplySessionChannel.ProcessSequencedMessage(RequestContext context, String action, WsrmSequencedMessageInfo info)
...stack continues

Мне нужно использовать его для распоряжения ответом сервера (у меня есть другая ветка SOF о том, почему я пришел к этому решению).

UPD 3: Проблема, которую я пытаюсь решить, заключается в том, что кажется , что мой ответ сервера сначала удаляется, а затем приложение пытается его сериализовать. Я на 99% уверен, что я не буду использовать один и тот же объект где-либо еще. Stacktraces довольно уродливые и большие, чтобы размещать здесь.

1 Ответ

7 голосов
/ 07 октября 2009

Нет, WCF не повторно проверяет сообщение.

Что происходит, это (упрощенно): во время сеанса каждое сообщение, отправляемое от клиента, буферизируется на клиенте. По умолчанию имеется место для 32 сообщений (это можно настроить; также имеется буфер на стороне службы).

Затем сообщение отправляется на сервер, и, если оно все в порядке и отправляется, сервер отправляет подтверждение, а клиент удаляет сообщение из буфера.

Однако, если клиент отправил сообщения № 15 и № 16, а затем получил подтверждение для № 16 (но не для № 15), сообщение № 15 повторно отправляется из буфера.

Существует довольно много параметров, которые вы можете настроить, например, хотите ли вы заказать доставку, сколько раз клиент должен повторить отправку сообщения и так далее.

Проверьте эти статьи и сообщение в блоге для получения дополнительной информации:

Надеюсь, это поможет немного прояснить ситуацию

ОБНОВЛЕНИЕ ответов: взято из первой статьи (на MSDN), на которую я ссылался:

Если мы предполагаем наличие запроса / ответа шаблон общения, ответ должен быть доставлен так же надежно как запрос и, следовательно, отвечающая сторона должна внедрить механизм инициатора, который очень похоже на то, что запрашивающая сторона реализует для оригинальных запросов. Запрашивающая сторона, в свою очередь, играя роль акцептора для ответы. Если ответы теряются, они должен быть повторно отправлен отвечающей стороной и поэтому они также должны быть кэшированы (и признал). Оба конца поэтому надежный сеанс обмена сообщениями поддерживать отдельные кэши для исходящих и входящие сообщения.

Так что да, то же самое относится и к ответам - что прекрасно работает, если у нас двусторонняя связь, например, через NetTCP или HTTP - как упоминалось в статье, в случае односторонняя операция - подробности см. в статье.

Марк

...