사실 저는 JMS를 청취하는 것이 응용 프로그램 서버의 가장 좋은 이유라고 말하고 싶습니다. 독립 실행 형 메시지 브로커는 여전히 메시지를 수신하는 구성 요소가 필요하기 때문에 문제를 해결하지 못합니다. 이를 수행하는 가장 좋은 방법은 MDB를 사용하는 것입니다. 이론적으로 Spring MessageListenerContainer를 사용할 수 있습니다. 그러나 이것은 JMS가 블로킹 읽기만을 지원하고 스프링이 자신의 쓰레드를 스핀 업 시켜서 (Tomcat에서도) 완전히 지원되지 않고 트랜잭션, 보안, 네이밍 (JNDI)과 클래스 로딩을 깨뜨릴 수 있다는 단점이있다. 원격). JCA 리소스 어댑터는 WorkManager를 통해 스레드를 회전시키는 것을 포함하여 원하는대로 자유롭게 수행 할 수 있습니다. JMS (또는 다른 대상) 외에도 XA 트랜잭션과 JTA, 즉 응용 프로그램 서버가 필요한 시점에서 데이터베이스가 사용되는 것 같습니다. 예, 이것을 서블릿 컨테이너로 패치 할 수 있지만,이 시점에서 애플리케이션 서버와 구별 할 수 없게됩니다.
IMHO 애플리케이션 서버에 대한 가장 큰 이유는 서버가 사양을 구현하고 최악의 버그를 해결할 때까지 사양이 게시 된 후 수년이 걸리는 것입니다. 지금은 EE 7이 공개되기 직전에 EE 6 서버가 나타나기 시작했습니다. 버그가 완전히 잡히지는 않았습니다. 일부 벤더가 EE 6 라인에서 버그를 수정하지 않는 것은 코믹 해집니다. 이미 다가오는 EE 7 라인으로 인해 바쁘기 때문입니다.
편집 마지막 단락의
긴 설명 :
자바 EE 많은 장소에서 문맥 정보라고 무엇에 의존한다. 서버/컨테이너에서 응용 프로그램으로 명시 적으로 인수로 전달되지 않지만 암시 적으로 "거기에있는"정보입니다. 예를 들어 보안 검사를위한 현재 사용자. 현재 트랜잭션 또는 연결입니다. 객체를 지연 적으로로드하거나 코드를 지연시키기 위해 클래스를 찾는 현재 응용 프로그램입니다. 또는 JNDI 조회를 수행하기위한 현재 구성 요소 (servlet, EJB, ...). 이 모든 정보는 서버/컨테이너가 컴포넌트 (서블릿, EJB, ...)를 호출하기 전에 설정하는 스레드 로컬에 있습니다. 자신 만의 스레드를 만들면 서버/컨테이너가 해당 스레드에 대해 알지 못하므로이 정보를 사용하는 모든 기능이 더 이상 작동하지 않습니다. 당신은 당신이 산란하는 쓰레드에서 그러한 기능을 사용하지 않음으로써이 문제를 해결할 수 있습니다.우리는 서블릿 3.0 사양을 선택하면
일부 링크
http://www.oracle.com/technetwork/java/restrictions-142267.html#threads http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4
우리가 찾을 :
2.3.3.3 비동기 처리
자바 엔터프라이즈 에디션은 15.2 절과 같은 기능 .2, 15-174 페이지의 "웹 어플리케이션 환경"및 15.3.1 절. "Secu 전파 15-176 페이지의 "EJBTM 호출의 rity Identity"는 초기 요청을 실행하는 스레드 또는 요청이 AsyncContext.dispatch 메소드를 통해 컨테이너에 전달되는 경우에만 사용할 수 있습니다. Java Enterprise Edition 기능은 AsyncContext.start (Runnable) 메소드를 통해 응답 객체에서 직접 작동하는 다른 스레드에서 사용할 수 있습니다.
이것은 비동기 처리에 관한 내용이지만 사용자 정의 스레드에도 동일한 제한 사항이 적용됩니다.
public void start (Runnable r) -이 메소드는 컨테이너가 관리되는 스레드 풀에서 스레드를 보내 지정된 Runnable을 실행하게합니다. 컨테이너는 적절한 컨텍스트 정보를 Runnable에 전파 할 수 있습니다.
다시 비동기 처리이지만 동일한 제한이 사용자 정의 스레드에 적용됩니다.
15.2.2 웹 응용 프로그램 환경
개발자가 만든 스레드에서 수행하지만, 가 현재 너무을 할 필요가 없습니다 때이 동작을 지원한다 서블릿 컨테이너의이 유형. 이러한 요구 사항은이 규격의 차기 버전에서 추가 될 것이다. 개발자는 응용 프로그램에서 만든 스레드에 대한이 기능에 따라 휴대용이 아니므로 권장하지 않는다는 점에주의해야합니다.
비 휴대용이란 하나의 서버에는있을 수 있지만 다른 서버에는있을 수 없다는 것을 의미합니다. 당신이 MDB 당신이 javax.jms.MessageConsumer에 네 가지 방법을 사용할 수 밖에 JMS와 메시지를 수신 할 싶을 때
:
#receiveNoWait() 당신이 할 수있는을이에 컨테이너 스레드에서, 그것을 차단하지 않습니다, 그러나 그것은 엿 같아 . 메시지가 없으면 null을 반환합니다. 이것은 메시지 청취에 적합하지 않습니다.#receive(long) 컨테이너 스레드에서이 작업을 수행 할 수 있습니다. 일반적으로 컨테이너 스레드에서 차단 대기를 수행하지 않습니다. 다시는 메시지 청취에 적합하지 않습니다.#receive(),이 블록은 무제한적일 수 있습니다. 다시는 메시지 청취에 적합하지 않습니다.#setMessageListener() 원하는대로 메시지가 도착하면 콜백을받습니다. 그러나 라이브러리가 응용 프로그램 서버에 연결할 수 없으면 컨테이너 스레드가 아닙니다. 응용 프로그램 서버에 대한 후크는 JCA를 통해 자원 어댑터에만 사용할 수 있습니다.
그래, 작동 할 수도 있지만 보장 할 수 없으며 많은 문제가 발생할 수 있습니다. 우리는 JNDI 데이터 소스 바람둥이를 통해 제이보스를 사용하고 풀링
는'그러나 이것은 몇 가지 단점이있다 네이밍 (JNDI) 및 클래스 로딩 (이는 다시 리모팅을 깨뜨릴 수 있습니다). 당신이 이것을 발견 한 곳을 보여줄 수 있습니까? 나는 몇몇 사람들이 App Server없이 독립적 인 메시지 브로커를 사용하여 Spring을 사용할 것이라고 확신한다. 누군가가 어디서나이 문제를 제기했는지 찾아 내려는 시도. 당신이 틀렸다는 것을 말하는 것은 아닙니다! :-) 더 많은 통찰력을 얻으려고. –