2015-03-18 2 views
1

Мне нравится, как SI позволяет создавать прозрачные прокси-каналы для каналов с использованием @Gateway и @ServiceActivator.Gateway + ServiceActivator without poller

Я смотрел http://docs.spring.io/spring-integration/reference/html/messaging-channels-section.html#channel-interfaces-subscribablechannel. Есть два типа каналов:

  • Pollable (Queue, Priority, Rendezvous)
  • Subscribable (Direct, исполнитель, PublishSubscribe)

Глядя на них, он смотрит на меня, что все эти сделаны таким образом, что один из ниже верно:

  • приемные опросы
  • отправителя, блоки
  • Сообщения могут быть обработаны несколькими нитями сразу

Есть ли способ настроить/использование SI таким образом, что:

  • Отправитель посылает в очередь и не блокирует (если не очевидно, очередь заполнена)
  • приемник принимает из очереди, но не опрашивать

Довольно много, как put/take от BlockingQueue из самой Java.

Могу ли я игнорировать некоторые ограничения здесь? Кроме того, если есть веские альтернативы для того, что я пытаюсь сделать (в основном асинхронная шина событий) с аналогичным интерфейсом (т. Е. Не нужно вручную отправлять сообщения, но с прозрачным способом с использованием интерфейсов), я бы будем рады услышать о них.

ответ

1

Если вы используете QueueChannel и установить Poller-х receiveTimeout -1, то структура будет делать то, что угодно - голосующий поток блокируется на ожидании сообщения (с отрицательным таймаута, он использует take() под одеялом).

По умолчанию (для потребителя опроса) max-messages-per-poll также равно -1 (бесконечность), что означает, что никакого «опроса» вообще не будет (после первого триггера), просто блокирования.

Если в очереди есть предел, отправитель будет блокироваться до тех пор, пока не будет свободное место (он использует put(), когда используется таймаут отправки -1 - по умолчанию).

+0

Отлично, спасибо Гэри! –

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