Question

У меня есть конфигурация для чтения данных из БД с использованием jdbc:inbound-channel-adapter. Конфигурация:

<int-jdbc:inbound-channel-adapter query="SELECT * FROM requests WHERE processed_status = '' OR processed_status IS NULL LIMIT 5" channel="requestsJdbcChannel" 
    data-source="dataSource" update="UPDATE requests SET processed_status = 'INPROGRESS', date_processed = NOW() WHERE id IN (:id)" > 
      <int:poller fixed-rate="30000" /> 
    </int-jdbc:inbound-channel-adapter> 

    <int:splitter input-channel="requestsJdbcChannel" output-channel="requestsQueueChannel"/> 

    <int:channel id="requestsQueueChannel"> 
      <int:queue capacity="1000"/> 
    </int:channel> 

    <int:chain id="requestsChain" input-channel="requestsQueueChannel" output-channel="requestsApiChannel"> 
      <int:poller max-messages-per-poll="1" fixed-rate="1000" /> 
    . 
    . 
    </int:chain> 

В описанной выше конфигурации, я определил Poller с JDBC fixed-rate в 30 секунд. Когда есть прямой канал вместо requestsQueueChannel, запрос выбора получает только 5 строк (так как я использую ограничение строк в select query) и ждет еще 30 секунд для следующего опроса.

Но после того, как я представил requestsQueueChannel с очередью и добавил poller внутри requestsChain, jdbc-inbound не работает должным образом. Он не ждет еще 30 секунд для следующего опроса. Иногда он дважды проверяет БД в строке (в течение секунды), как если бы выполнялось 2 потока и получалось два набора строк из БД. Однако нет асинхронной передачи обслуживания, кроме указанных выше.

Мое понимание состоит в том, что даже если есть requestsQueueChannel, то после выполнения запроса выбора он должен подождать еще 30 секунд для опроса БД. Есть что-то, чего я не вижу? Я просто хочу понять поведение этой конфигурации.

Answer 1

Вопрос о Весенних интеграции пуллеров активации два раза, как если бы они 2 нитки, это в основном та же проблема, я наткнулся здесь, с файловой системой пуллеров:

How to prevent duplicate Spring Integration service activations when polling directory

Видимо это относительно общая неправильная конфигурация, где контексты Spring и сервлета загружают конфигурацию Spring Integration. В результате этого действительно есть две нити, и, как видно, активисты активируются дважды в течение периода опроса. Обычно в течение нескольких секунд друг от друга, поскольку каждый из них запускается, когда загружается его контекст.

Мой подход к обеспечению конфигурации Spring Integration был загружен только в одном контексте, чтобы структурировать пакеты проектов для обеспечения разделения.

Сначала определите веб-конфигурацию, которая только подбирает классы под «веб-пакетом».

@Configuration 
@ComponentScan(basePackages = { "com.myapp.web" }) 
@EnableWebMvc 
public class WebConfig extends WebMvcConfigurerAdapter { 
    @Override 
    public void configureDefaultServletHandling(
      DefaultServletHandlerConfigurer configurer) { 
     configurer.enable(); 
    } 
} 

Создание отдельных классов конфигурации корневой для загрузки зерна, таких как услуги и хранилища, которые не принадлежат в контексте сервлета. Один из них должен загрузить конфигурацию Spring Integration. т.е .:

@Configuration 
@ComponentScan(basePackages = { "com.myapp.eip" }) 
@ImportResource(value = { "classpath:META-INF/spring/integration-context.xml"  }) 
public class EipConfig { 
} 

Дополнительный фактор в конфигурации, которые имели некоторое время, чтобы работать, что мои сервлет фильтры и конфигурация веб-безопасность необходимы, чтобы быть в корневом контексте, а не в контексте сервлета.

Answer 2

При использовании DirectChannel следующий опрос не считается до конца текущего.

При использовании QueueChannel (или исполнителя задачи), полеллер может снова запустить его снова.

Входящие адаптеры имеют значение max-messages-per-poll по умолчанию, поэтому ваш конфигуратор должен работать должным образом. Можете ли вы разместить журнал DEBUG где-нибудь?