Верблюд ApacheMQ -> AHC поведение (блокировка?)

Question

Я только начал использовать Apache Camel, и меня интересует кажущееся нелогичным поведение по умолчанию асинхронного http-клиента (AHC). Принимая сообщения от ActiveMQ, я не могу заставить его работать неблокирующим образом.

Мой маршрут выглядит так:

@Component
public class Broadcaster extends RouteBuilder {

  @Override
  public void configure() throws Exception {
    errorHandler(deadLetterChannel("activemq:failed.messages"));

    from("activemq:outbound.messages")
    .setExchangePattern(ExchangePattern.InOnly)
    .recipientList(simple("ahc:${in.header[PublishDestination]}"))
    .end();
  }
}

Я поставил в очередь несколько сообщений, половину из которых я отправил на задержанный веб-сервер, а другую - на нормальное. Я ожидал увидеть все обычные сообщения, потребляемые быстрым сервером, и медленные сообщения постепенно со временем. Однако такое поведение наблюдается на быстром веб-сервере:

00:24:02.585, <hello>World</hello>
00:24:03.622, <hello>World</hello>
00:24:04.640, <hello>World</hello>
00:24:05.658, <hello>World</hello>

Как видите, между каждым зарегистрированным запросом ровно одна секунда, что соответствует искусственной задержке в 1 секунду на медленном сервере. Исходя из времени маршрутизации, похоже, что потребитель JMS ожидает завершения AHC, прежде чем он получит следующее сообщение из очереди:

Processor                                 Elapsed (ms)
[activemq://outbound.messages           ] [      1020]
[setExchangePattern[InOnly]             ] [         0]
[ahc:${in.header[PublishDestination]}}  ] [      1018]

Я должен явно использовать асинхронные производители и писать обработчики обратного вызова в этих случаях, или я что-то упускаю? Спасибо!

Answer 1

Ну, в случае RTFM, я думаю, хотя моя страница ActiveMQ оставляет желать лучшего с точки зрения свойств, доступных для конфигурации конечной точки. Вероятно, должна быть заметка о том, что большинство (всех?) Опций конфигурации JMS также доступны для компонента ActiveMQ. В любом случае решение состоит в том, чтобы определить потребителя следующим образом:

from("activemq:outbound.messages?asyncConsumer=true")