Утешение - медлительность весенней интеграции

Question

Мы используем утешение в качестве шины сообщений между модулями и подсистемами. Наше приложение построено на интеграциях Spring Boot и Spring (адаптер-управляемый сообщениями канал, DefaultMessageListenerContainer, CachingConnectionFactory).

Мы наблюдаем случайную медлительность с интервалом 10-15 минут, которая происходит один раз в несколько дней. В некоторых случаях, основываясь на журналах, отправитель от модуля-1 до получателя от модуля-2 занимает только 15 минут, а между ними также нет активатора службы.

У кого-нибудь была похожая проблема? Любой совет по устранению неполадок в этом вопросе?

Answer 1

Это действительно хороший вопрос, который помог мне понять несколько аспектов СИ и JMS. Я пишу этот ответ, надеясь, что кто-то, имеющий подобную проблему, получит некоторую информацию. В нашем сценарии было более одной проблемы. Ниже приведены основные моменты:

• Удаление фабрики кеширующих соединений для DMLC в значительной степени решило проблему.
• Мы используем блокировку потока от DMLC до завершения потока. По определенному сценарию наш активатор службы застрял во время сохранения.
• Наш брокер сообщений настроен на предварительную выборку 18, что позволяет доставлять до 18 сообщений потребителю без подтверждения. В нашем случае одно сообщение застревает в нашем активаторе сервиса, поток блокируется, но потребитель jms продолжает получать до 18 сообщений, не передавая их в DMLC-брокер. Мы сократили предварительную выборку до 1, это помогло уменьшить количество застрявших сообщений до одного.
• Мы подозревали, прерывается ли соединение mysql при определенном сценарии неактивности, как объяснено в этом потоке База данных MySQL обрывает соединение через 8 часов. Как это предотвратить? . Мы добавили параметр поддержания источника данных путем добавления запроса проверки. Это помогло нам уменьшить количество застрявших сообщений до нуля.