接收/发送端口 - 排队（等待处理） [英] Receive/Send Port - Queued (Awaiting Processing)

问题描述

您好，

我有一个直接绑定接收/发送端口 接收消息，进行一些处理，然后使用直接绑定双向接收/发送形状发送响应。

I have a direct bound Receive/Send port  that receives a message, does some processing and then sends a response using a direct bound two way Receive/Send shape.

60％的时间服务完美运行并且客户端收到响应消息在3-5秒内。但是，每三个或第四个请求大约需要40-60秒。当我检查"跟踪消息事件"时log 我可以看到响应消息将被路由到状态为"Queued（Awaiting Processing）"的客户端。我已经阅读了有关此状态的所有帖子，并检查了订购的交付未开启。

60% of the time the service works perfectly and the client receives a response message within 3-5 seconds. However, every third or fourth request takes about 40-60 seconds. When I check the "Tracked Message Events" log I can see the response message that is to be  routed to the client with the status "Queued (Awaiting Processing)". I've read all the posts about this state and have checked that ordered delivery is not turned on.

业务流程始终在3-5秒范围内完成。据我所知，业务流程将响应提交给要传递的消息框，但HTTP（和WCF）隔离主机不会长时间选择消息。我在Windows Server 2008 R2上使用BizTalk 2009。我在IIS 7.5（或任何2K8R2使用的）上的单独应用程序池中有一个WCF接收位置和HTTP接收位置，并且两者的行为方式类似。

The orchestration always completes within the 3-5 second range. From what I can tell, the orchestration submits the response to the messagebox to be delivered, however the HTTP (and WCF) isolated host just doesn't pick the message up for an extended period of time. I'm using BizTalk 2009 on Windows Server 2008 R2. I have a WCF receive location and an HTTP receive location in separate application pools on IIS 7.5 (or whatever 2K8R2 uses) and both behave in a similar manner.

我运行了消息框查看器并没有什么值得注意的，事件查看器中也没有报告任何问题。我尝试使用双向直接绑定接收发送端口和两个直接绑定单向发送和接收端口，并且两者的行为方式相同。

I've run the message box viewer and there is nothing of note in there, nor is there any problem reported in the event viewer. I've tried this using a two-way direct bound receive-send port and two direct bound one-way send and receive ports and both behave in the same manner.

任何有关此问题的帮助真的很感激，因为我完全不知道为什么有些请求需要< 10秒和其他人采取> 40但是编排运行时总是3-5秒。

Any help on this would be really appreciated as I am totally baffled as to why some requests take < 10 seconds and others take > 40 yet the orchestration runtime is always 3-5 seconds.

干杯

推荐答案

我首先要仔细检查您的适配器设置中是否没有打开任何已订购的交付，以及您的业务流程的逻辑接收/发送端口。您似乎已经这样做了。

Hi, I would first double check that you don't have any ordered delivery turned on in the settings of your adapters, and also in the logical receive/send port of your orchestration. It seems you've already done so.

此外，您是否尝试将HTTP发送适配器的连接数增加到BizTalk配置文件中的特定服务器设置，在本帮助页面底部： http://msdn.microsoft.com/en-us /library/aa547969(BTS.20).aspx

Also, have you tried increasing the number of connections made by the HTTP send adapters to a particular server settings in the BizTalk config file, explained at the bottom of this help page: http://msdn.microsoft.com/en-us/library/aa547969(BTS.20).aspx

您是否在测试时尝试运行perfmon以确保没有启用biztalk主机限制？消息框查看器只会告诉您在运行时是否启用了限制，但是perfmon会在整个测试中显示值。

Have you also tried running perfmon while you test to ensure no biztalk host throttling is enabled? Message box viewer would only tell you if throttling was enabled at the time you ran it, but perfmon would show the values over the whole test.

问候，

这篇关于接收/发送端口 - 排队（等待处理）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！