Mule VM - потеря данных / не обработка всех данных в VM

Question

Mule 3.4 создает только 16 потоков по умолчанию и не принимает конфигурации, указанные в моем коде ниже.

1. MaxActive = "100" не создается, он просто создает 16 потоков и обрабатывает их.
2. INITIALISE_ALL также не работает, у него один свободный поток, и когда данные отправляются, он создает 16 и выполняет процесс. Итак, MaxIdle=2 тоже не работает (отслеживается с помощью jvisualvm)

Почему он не переопределяет поведение по умолчанию? Я что-то пропустил?

Самая критическая проблема, с которой я сталкиваюсь сейчас, заключается в том, что, когда я отправляю около 28 идентификаторов на виртуальную машину, она обрабатывает некоторые из них, и не остается ни малейшего понятия о оставшихся, и для этого нет конкретного числа / шаблона. (Я не могу воспроизвести проблему в моем локальном ящике, это происходит в более высоких средах, таких как QA, UAT, и это работало без этой проблемы, как упоминалось выше). Пожалуйста помоги.

<flow name="Event0">
    <vm:inbound-endpoint ref="PROCESS.EVENT0" />
    <pooled-component>
        <spring-object bean="abcProcess" />
        <pooling-profile exhaustedAction="WHEN_EXHAUSTED_WAIT" initialisationPolicy="INITIALISE_ALL" maxActive="100" maxIdle="2"    maxWait="20000" />
    </pooled-component>
    <custom-exception-strategy class="org.mule.exception.DefaultMessagingExceptionStrategy">
        <commit-transaction exception-pattern="*" />
        <vm:outbound-endpoint ref="ErrorHandlerInput" />
    </custom-exception-strategy>
</flow>

Answer 1

Ты используешь DefaultMessagingExceptionStrategyи в документации сказано:

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

Поэтому вам, вероятно, следует проверить журналы и конечную точку исключения, которую вы, похоже, настроили.