272.9. 고급 주제

Camel exchange를 외부 서브스크립션 가입자에게 라우팅할 때 백압은 이를 전달하기 전에 교환 캐시의 내부 버퍼에 의해 처리됩니다. 구독자가 교환 속도보다 느리면 버퍼가 너무 커질 수 있습니다. 많은 경우에 이것은 피해야 합니다.

다음 경로를 고려하십시오.

from("jms:queue")
.to("reactive-streams:flow");

JMS 큐에 많은 메시지가 포함되어 있고 흐름 스트림과 연결된 구독자가 너무 느리면 메시지가 JMS에서 큐에 추가되고 버퍼에 추가되므로 "메모리 부족" 오류가 발생할 수 있습니다. 이러한 문제를 방지하려면 경로에 ThrottlingInflightRoutePolicy 를 설정할 수 있습니다.

ThrottlingInflightRoutePolicy policy = new ThrottlingInflightRoutePolicy();
policy.setMaxInflightExchanges(10);

from("jms:queue")
.routePolicy(policy)
.to("reactive-streams:flow");

정책은 활성 교환의 최대 수(및 버퍼의 최대 크기만큼)를 제한하고 임계값(예:10 )보다 낮게 유지합니다. 10 개 이상의 메시지가 비행 중일 때 경로가 일시 중지되어 구독자가 처리할 때까지 기다립니다.

이 메커니즘을 통해 구독자는 백압을 통해 경로 일시 중지/재시작을 자동으로 제어합니다. 여러 구독자가 동일한 스트림에서 항목을 사용하는 경우 가장 느린 사용자가 경로 상태를 자동으로 제어합니다.

다른 상황에서는 http 소비자를 사용하는 경우 route suspension을 사용하면 http 서비스를 사용할 수 없으므로 기본 구성(정책, 바인딩되지 않은 버퍼 없음)을 사용하는 것이 좋습니다. 사용자는 http 서비스에 대한 요청 수를 제한하여 메모리 문제를 방지해야 합니다(예: 확장).

특정 양의 데이터 손실이 허용 가능한 상황에서 BUFFER 이외의 역압 전략을 설정하는 것이 빠른 소스를 처리하기 위한 해결책이 될 수 있습니다.

from("direct:thermostat")
.to("reactive-streams:flow?backpressureStrategy=LATEST");

LATEST backpressure 전략을 사용하면 경로에서 수신한 마지막 교환만 게시자에 의해 유지되지만 이전 데이터는 삭제됩니다(다른 옵션을 사용할 수 있음).