2017-02-02 2 views
0

У нас есть реализация, в которой сообщения помещаются в очередь AWS SQS и потребляются Camel AWS. Мы используем concurrentConsumers = 1. Мы регистрируем опрос очереди, как это делается org.apache.camel.component.aws.sqs.SqsConsumer.Apache Camel не получает сообщение от SQS своевременно

Тест состоит из отправки сообщения в SQS (из удаленной системы), а затем регистрации времени, в течение которого сообщение находится в очереди. На конце Camel мы регистрируем трассировку в классе SqsConsumer, и мы можем видеть, когда очередь подсчитывается, и когда сообщения расходуются.

Если мы размещаем сообщение в очереди каждые 10 секунд, большинство раз, когда Camel поднимает сообщение через 1-2 секунды. Однако есть много раз, когда требуется значительно больше времени (10+ секунд).

В основном мы видим такое поведение:

  • (Remote) Место сообщение на SQS
  • (Camel) Опрос
  • (Camel) Опрос
  • (Camel) Опрос
  • ... (для многих опросов, по умолчанию 500 миллисекунд)
  • (Camel) Получать сообщение от SQS

Мы тестировали SQS до конца без Camel, и нет проблем с пропускной способностью (1000 сообщений за несколько секунд).

Наша реализация Camel для этого теста состоит только из чтения из очереди SQS и ведения журнала - других функций нет.

Мы протестировали с изменением многих других параметров SQS Camel без каких-либо различий в поведении.

Однако, если мы протестируем с помощью concurrentConsumers = 10, то каждое сообщение будет получено из очереди почти мгновенно с минимальной задержкой.

Мой вопрос: почему единый потребитель не забирает сообщения своевременно? Если он действительно проводит опрос каждые 500 миллисекунд, как он не «видит» и не собирает сообщения?

Примечание. Мы не решаемся включить многопоточность, которая поставляется с использованием concurrentConsumers из-за функциональности нашего приложения.

+0

Вы пробовали длинный опрос? –

+0

@ketanvijayvargiya Да, но поведение кажется одинаковым. –

ответ

0

Как было предложено @ketanvijayvargiya, долгий опрос действительно является ответом. Мы посмотрели на него из-за вашего комментария. Есть несколько способов, чтобы установить значение, которое мы пытались:

  1. Via сам верблюд на SQS URI, receiveMessageWaitTimeSeconds =
  2. Установка его на самой очереди AWS SQS (на консоли, Настройка очереди -> Прием Время ожидания сообщения).

Мы проверили (2) и не видели изменения поведения (во время моего сообщения). Мы снова тестировали, используя (1), и увидели улучшения. Мы повторно протестировали (2), а также увидели улучшения, поэтому можем только предположить, что мы допустили ошибку при выполнении первого теста.

Смежные вопросы