在 Web 应用程序中使用 NServiceBus
关于 Using NServiceBus with Asp.Net MVC 2 线程的另一个问题。 Udi回复说,如果我们确实想这样做,可以使用以下方法。
var sync = Bus.Send<SomeMessage>(/*data*/)
.Register((AsyncCallback)delegate(IAsyncResult ar)
{
var result = ar.AsyncState as CompletionResult;
// do something with result.Messages
},
null
);
sync.AsyncWaitHandle.WaitOne( /*timeout*/);
这在 Windows 应用程序中可以完美地工作,因为只有一个用户。
我想知道这在网络应用程序中是如何工作的;因为有多个线程(对于多个用户会话)调用 Bus.Send 并等待回调。将只有一个回复队列(如果我的理解是正确的)。
NServiceBus 是否根据从队列收到的响应消息知道要恢复哪个线程?
如果我的理解是正确的,那么不建议在此类场景中使用消息传递(从 Web 应用程序向服务发送请求消息,服务处理消息并回复响应消息)
“例如,如果您想执行像 GetCustomersByRegionRequest 和 CustomersByRegionResponse 这样的查询不应使用消息传递来实现。” - http://docs.preferrer.net/
Another question on the Using NServiceBus with Asp.Net MVC 2 thread. Udi has replied saying following method can be used if we really want to do it.
var sync = Bus.Send<SomeMessage>(/*data*/)
.Register((AsyncCallback)delegate(IAsyncResult ar)
{
var result = ar.AsyncState as CompletionResult;
// do something with result.Messages
},
null
);
sync.AsyncWaitHandle.WaitOne( /*timeout*/);
This will work perfectly in a windows application, because there is only one user.
I wonder how this will work in a web application; since there are multiple threads (for multiple user sessions) call Bus.Send and waiting for the callback. There will be only one reply queue (if my understanding is correct).
Does NServiceBus know which thread to resume based on the response message it received from queue?
If my understanding is correct, it's not recommended to use messaging for these kind of scenarios (send a request message from a web Application to a Service, which handle the message and reply with a response message)
"For example, if you want to perform queries like GetCustomersByRegionRequest and CustomersByRegionResponse, that should not be implemented using messaging."
- http://docs.particular.net/
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在内部,NSB 通过维护回调及其相关消息的字典来将所有这些保持在一起。这些消息具有用于执行查找的相关 ID。您是对的,在请求/响应场景中使用消息确实违背了消息传递的目的。主要目的是不阻塞,其中请求/响应本质上是阻塞模式。请参阅上面帖子中 Andreas 的回复,它有很好的解释。
Internally NSB keeps this all together by maintaining a dictionary of the callbacks and their associated messages. The messages have a correlation id that is used to do the lookup. You are correct, using message in a Request/Response scenario really defeats the purpose of messaging. The main purpose is to not block, wherein Request/Response inherently is a blocking pattern. See the response from Andreas in the post above, it has a good explanation.