Java EE에 대한 저지 클라이언트 요청 문제

Question

Weblogic 12.2.1 및 내장 Jersey 클라이언트 2.21.1을 사용하여 2 시간마다 원격 시스템에 https 요청을 배치합니다.
이 경우 나는 특정 시간에 Weblogic에 의해 실행되는 @Scheduled 메소드를 가진 @Singleton 빈을 가지고있다. 그래서 @Scheduled 메소드를 실행할 때마다 여러 개의 https를 차례로 호출합니다. 모든 요청은 동기식입니다.

문제는 몇 가지 이유 때문에 다음 요청이 이전 요청보다 1 분 지연되어 전송된다는 것입니다 (Wireshark 출력에 따라). Jersey의 호출 호출이 차단 중입니다. 응답은 즉시 온다. 원격 시스템에는 문제가 없습니다.

JUnit 테스트 (일반 Java)에서 실행될 때 요청을 보내는 동일한 코드는 지연이 없습니다. 모든 요청이 즉시 전달됩니다. 어쩌면 Weblogic 컨테이너에서 뭔가있을 수 있습니다.
비슷한 문제가있는 사람은 누구입니까?

Answer 1

사실 ApacheConnectorProvider으로 클라이언트의 기본값 HttpUrlConnectorProvider을 변경하면 요청간에 더 이상 지연이 없었습니다. 실제로 어떤이에 대한 저지 문서 상태 것은 :

... 일부 풀링 연결이 응용 프로그램도 부트 스트랩 전에있을 수 있습니다 (예 : 응용 프로그램 서버와 같은) 복잡한 환경에서,이 방법은 우리가 100 % 신뢰할 수 없습니다 및 Apache Connector와 같은 다른 클라이언트 전송 커넥터를 사용하는 것이 좋습니다.

그러나 클라이언트의 멀티 파트 기능을 사용하려는 경우에도 또 다른 문제가 발생합니다. 이에 워드 프로세서 말 :

이

은 기본 커넥터 구현 이외의 사용에주의 경고. WriterInterceptor 또는 MessageBodyWriter에 HTTP 헤더를 처리하는 데 문제가 있습니다. 헤더 필드를 변경해야하는 경우 ApacheConnectorProvider 또는 GrizzlyConnectorProvider를 사용하지 말고 JettyConnectorProvider를 사용하지 마십시오. 예를 들어 HTTP 헤더를 수정하는 Jersey Multipart 기능에이 문제가 적용됩니다.

마침내 필자는 multipart를 가진 multipart 또는 slow 요청없이 ApacheConnector (빠른 요청)를 선택해야하는 상황에 처했다. 웃기지 않니?

Java EE 환경에서 실제로 작업하고있는 다른 편안한 클라이언트를 연구하는 데 더 많은 시간을 할애해야한다고 생각합니다.