Mule 3.3.1直到由于线程繁忙而成功丢失消息 [英] Mule 3.3.1 until-successful losing messages due to busy threads

查看:105
本文介绍了Mule 3.3.1直到由于线程繁忙而成功丢失消息的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有2个流程. FlowA接收呼叫(htp入站)并将消息放在队列中. FlowB从此队列中提取消息并进入直到成功的循环.直到成功打出电话.

I have 2 flows. FlowA receives calls (htp-inbound) and places message on a queue. FlowB picks up messages from this queue and enters until-successful loop. Until successful makes an outbound call.

<flowA>
  <http-inbound/>
  <put message on queueA/>
</flowA>
<flowB>
  <jms:inbound queueA>
  <until-successful>
     <http-outbound/>
  </until-successful>
</flowB>

我正在Debug模式下使用此断点运行此断点,在此断点内成功进行出站呼叫.我看到每个调用都会创建一个新线程(直到成功),直到达到15.第16个调用开始,由于线程池已满,因此继续在flowB的线程中执行.我看到另外创建了16个flowB线程.之后,当flowA将消息放入队列中时,flowB对其进行提取,但我无法弄清楚下一步该如何处理:(消息丢失了!它没有尝试进行任何出站呼叫.

I am running this in Debug mode with a breakpoint where outbound call is made within untilsuccessful. I see that every call creates a new thread (until-successful) till we reach 15. The 16th call onwards, since thread pool is full, execution is continued in flowB's thread. I see 16 more flowB threads created. After that, when flowA puts a message on the queue, flowB picks it up, but I'm unable to figure out where it goes next :( The messsage is lost! It is not trying to make any outbound call.

我认为16是默认的线程池大小.

I'm thinking 16 is the default thread pool size.

阻止成功成功之前,预期的行为是什么?我希望所有线程都忙时消息会排队.

What is the expected behavior when until-successful is blocked? I expected the messages to queue up when all threads are busy.

请让我知道是否需要改写这个问题.

Please let me know if I need to rephrase the question.

我正在调试模式下运行,可能已经搞砸了...所以....请多多包涵.

I am running in debug mode and may have messed up...so....please bear with me.

推荐答案

您是对的:16是Mule中的默认线程池大小.

You're right: 16 is the default thread pool size in Mule.

消息不应丢失:消息应存储在until-successful对象存储中,一旦其中一个线程再次可用,就等待被拾取.

The message should not be lost: it should be accumulated in the until-successful object store, waiting to be picked up as soon as one of the thread becomes available again.

核心问题是until-successful使用默认工作管理器作为不可配置的线程配置文件.如果可以配置自定义线程配置文件,则可以为maxBufferSize定义一个非零值,该值将累积消息而不是触发池耗尽操作(当然,直到缓冲区已满,但这是另一个问题) ).

The core issue is that until-successful uses the default work manager which as a non-configurable threading profile. If it was possible to configure a custom threading profile, you would define a non-zero value for maxBufferSize which would then accumulate messages instead of triggering the pool exhausted action (of course, until the buffer is full, but that is another issue).

但是到目前为止,确实没有出路. until-successful用16个线程固定为如果耗尽运行"动作.

But for now, there is really no way out. until-successful is fixed with 16 threads the "if exhausted run" action.

这是一个已知问题:请在此处查看第1点 https://www.mulesoft .org/jira/browse/MULE-7035 请对此JIRA投票.

This is a known issue: see point #1 here https://www.mulesoft.org/jira/browse/MULE-7035 Please upvote this JIRA.

这篇关于Mule 3.3.1直到由于线程繁忙而成功丢失消息的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆