To enable asynchronous streaming,add the
DispatcherSynchronizationBehaviorendpoint behavior to the service
host and set itsAsynchronousSendEnabledproperty totrue. We have
also added the capability of true asynchronous streaming on the send
side. This improves scalability of the service in scenarios where it
is streaming messages to multiple clients some of which are slow in
reading possibly due to network congestion or are not reading at all.
In these scenarios we now do not block individual threads on the
service per client. This ensures that the service is able to process
many more clients thereby improving the scalability of the service.
我明白上面的意思是我补充说
<behaviors>
<endpointBehaviors>
<behavior name="AsyncStreaming">
<dispatcherSynchronization asynchronousSendEnabled="true" />
</behavior>
</endpointBehaviors>
...
到我的web.config文件并引用我的端点中的AsyncStreaming行为,但我不明白这些步骤为我完成了什么.我是否需要修改我的代码才能利用这种异步性？
同样在类似主题上(但是如果它太不同我会将它移到一个新问题),在WCF中如何使用Streams使用async / await效果？我可以执行任务< Stream> Foo()在我的服务合同中？我做了一些数据库调用,其结果我最终将包装到我将从WCF服务返回的自定义流中.能够使用像ExecuteDataReaderAsync()这样的东西非常有用,在处理流式消息而不是缓冲消息时,我仍然可以使用它吗？
我已经测试了它,我知道它“工作”使用任务但我不知道是否这样做会导致函数回退到“缓冲”模式,就像你为函数提供多个参数一样(参见第3段) “Programming Model for Streamed Transfers”在同一个MSDN页面上),我不知道如何检查是否发生了这种情况.
解决方法
RequestContext.显然,ChannelHandler.sendAsynchronously字段控制是否异步(通过RequestContext.BeginReply / EndReply APM方法)或通过RequestContext.Reply同步完成消息回复.
据我所知,所有这一切都释放了一个服务器端线程,该线程返回到池中,否则将在RequestContext.Reply中忙于将流“抽”到客户端,只要流对象在服务器上是活着的.
这似乎是完全透明的,所以我认为您可以安全地使用基于异步TAP的合同方法并返回Task< Stream>.例如,在另一个合同方法中,您可以等待Stream.WriteAsync.
当你到达那里时,请分享你的实际经验作为你自己的答案,我对细节非常感兴趣:)
