Утешение - медленная интеграция Spring
Мы используем утешение как шину сообщений между модулями и подсистемами. Наше приложение построено на интеграции Spring Boot и Spring (адаптер канала, управляемый сообщениями, DefaultMessageListenerContainer, CachingConnectionFactory).
Мы наблюдаем случайную медлительность с интервалом 10-15 минут, происходящую раз в несколько дней. В некоторых случаях на основе журналов есть только отправитель от модуля-1 к получателю из модуля-2, занимает 15 минут, и между ними также нет активатора службы.
У кого-нибудь была подобная проблема? Есть какие-нибудь советы по устранению этой проблемы?
Спасибо, Артем, за хорошее предложение, я включу журналы отладки для конкретных пакетов jms. Что касается размера памяти, я убедился, что он намного ниже максимального предела. Я также проверил нагрузку в течение этого периода времени, которая незначительна.
В нашем коде мы используем динамическое масштабирование с помощью CachingConnectionFactory. Это может быть потенциальной проблемой, как описано в этом потоке ссылка на сайт
Журналы также подтверждают то же поведение. Скажем, Listener-4 используется в 12:01 и снова используется в 12:17, в промежутках между ними он не используется. Похоже, Listener-4 принял сообщение, но на самом деле не передал его адаптеру канала из-за кэширования в CachingConnectionFactory.
Ответы 1
Это действительно хороший вопрос, который помог мне понять некоторые аспекты SI и JMS. Я пишу этот ответ в надежде, что кто-то, у кого есть подобная проблема, получит некоторую информацию. В нашем сценарии было несколько проблем. Ниже приведены основные моменты.
- Удаление фабрики кэширующих подключений для DMLC в значительной степени решило проблему.
- Мы используем блокировку потока от DMLC до завершения потока. При определенном сценарии активатор нашего сервиса завис во время персистентности.
- Наш брокер сообщений настроен на предварительную выборку 18, что позволяет доставить до 18 сообщений потребителю без подтверждения. В нашем случае одно сообщение застряло в активаторе службы, поток заблокирован, но потребитель jms продолжает получать до 18 сообщений, не передавая их брокеру DMLC. Мы уменьшили упреждающую выборку до 1, это помогло сократить количество зависших сообщений до одного.
- Мы подозревали, не разрывается ли соединение mysql при определенном сценарии бездействия, как описано в этом потоке База данных MySQL разрывает соединение через 8 часов. Как это предотвратить?. Мы добавили настройку сохранения активности источника данных, добавив запрос проверки. Это помогло нам свести количество зависших сообщений к нулю.
Я бы посоветовал включить уровень ведения журнала
DEBUGдля категорииorg.springframework.integration. Таким образом, вы увидите многоpreSendиpostSend, а также некоторые другие полезные журналы Spring Integration. Это должно дать вам некоторые подсказки, где ваша система застряла. Также убедитесь, что с памятью и GC все хорошо. Используйте Visual VM по этому поводу.