스프링 통합 폴러 대 디스패처

Question

스프링 통합을 사용하여 간단한 응용 프로그램을 설정하려고합니다. 목표는 단순히 파일 인 Y 운드 채널 어댑터를 사용하여 새 파일에 대한 디렉토리를 모니터하고 파일이 추가 될 때 파일을 처리하는 것입니다. 단순화를 위해 현재 파일을 처리하는 것은 단순히 일부 출력 (처리중인 파일의 이름)을 로깅하는 것입니다. 그러나 다중 스레드 방식으로 파일을 처리하려고합니다. 따라서 10 개의 파일이 선택되었고 병렬로 처리되어야하며 일단 완료되면 다음 10 개의 파일로 넘어갑니다.

두 가지 접근 방식을 시도했는데 둘 다 비슷하게 작동하는 것처럼 보였습니다. 폴러 또는 디스패처를 이와 비슷한 방식으로 사용하는 것의 차이점을 알고 싶었습니다.

접근법 # 1 - 사용 폴러 그래서 여기 내가 이해 생각

<int-file:inbound-channel-adapter id="filesIn" directory="in"> 
     <int:poller fixed-rate="1" task-executor="executor" /> 
</int-file:inbound-channel-adapter> 

<int:service-activator ref="moveToStage" method="move" input-channel="filesIn" /> 

<task:executor id="executor" pool-size="5" queue-capacity="0" rejection-policy="DISCARD" /> 

우리가 즉시 파일이 수신 될 때 지속적으로 디렉토리 폴링하고 있다는 것입니다 그 filesIn 채널로 전송 풀 제한이 될 때까지 도달했습니다. 그런 다음 풀이 가득 찰 때까지 폴링이 여전히 백그라운드에서 계속된다고 가정하더라도 추가 파일은 보내지지 않습니다. 이것은 작동하는 것처럼 보이지만 폴링 당 최대 메시지를 사용하면 여기 폴링 빈도를 줄이는 데 도움이되는지 확실하지 않습니다. 폴링 당 최대 메시지를 풀 크기에 가깝게 설정합니다.

접근법 # 2 - 나는 순차적 인 방식으로는 폴링을 가정하고 있으므로 폴러 실행 프로그램을 사용하지 않는, 그래서 여기 괜찮

<int-file:inbound-channel-adapter id="filesIn" directory="in"> 
    <int:poller fixed-rate="5000" max-messages-per-poll="3" /> 
</int-file:inbound-channel-adapter> 

<int:bridge input-channel="filesIn" output-channel="filesReady" /> 

<int:channel id="filesReady"> 
    <int:dispatcher task-executor="executor"/> 
</int:channel> 

<int:service-activator ref="moveToStage" method="move" input-channel="filesInReady" /> 

<task:executor id="executor" pool-size="5" queue-capacity="0" rejection-policy="CALLER_RUNS" /> 

디스패처

사용. 모든 설문 조사 3 파일을 선택하여 filesReady 채널로 보내야합니다. 그러면 파일을 디스패처를 사용하여 서비스 활성기로 전달하고 디스패처 용 실행기를 사용하므로 즉시 제어를 반환하고 filesIn 채널에서 더 많은 파일을 보낼 수 있습니다.

나는 나의 질문이 내가 양쪽 접근법을 올바르게 이해하고 있고, 하나가 다른 것보다 낫다 고 생각한다.

감사합니다.

Answer 1

예. 이해했습니다.

일반적으로 모든 밀리 초 폴링 (및 큐가 꽉 찼을 때 폴링 삭제)은 자원 낭비 (CPU 및 I/O)라고 말합니다.

또한 첫 번째 경우 폴링 당 최대 메시지를 늘리면 실행자 스레드에서 폴링이 수행되므로 스케줄러가 실행자에게 폴을 넘겨주고 해당 스레드는 mmpp을 처리하므로 도움이되지 않습니다.

두 번째 경우에는 폴링 중에 폴링 중에 스케줄러 스레드가 손을 뻗기 때문에 (mmpp) 예상대로 작동합니다.

따라서 일반적으로 두 번째 구현이 가장 좋습니다 (새로운 파일이 도착할 때 평균 2.5 초 지연으로 살 수있는 한).