우리는 현재 JMS를 통해 IBM MQ를 사용하고 있지만 처리 할 수있는 것보다 많은 메시지를 보내고있는 것처럼 보입니다 - 이상하게도 문제는 간헐적 인 것 같습니다.WebSphere MQ Low Latency Messaging - JMS (또는 JMS와 유사한) API를 가지고 있습니까?
메시지는 가격이므로 보장 할 필요가 없으며 빨리 보내야합니다.
IBM이 Low Latency product을 가지고 있기 때문에 이것이 더 나은 해결책 일지 궁금해졌습니다.하지만 JMS API가 없거나 쉽게 볼 수없는 것 같습니다. 또는 그것을 가지고 않는다 "독특한"API 인 경우 JMS와 같은 낮은 대기 시간 제품으로 JMS API를이 있다면
사람은
가 또는 MQ 튜닝에 대한 포인터도 감상 할 수 ... 알고있다. .. :)분명히 낮은 대기 시간의 메시징 제품이 문제에 더 적합 할 것이므로 29West에서 LBM이라고하는 대기 시간이 짧은 메시징 제품을 사용하여 매우 유사한 작업을 수행하는 프로젝트를 진행하고 있습니다. 그것은 JMS API를 가지고 있지 않으며 대기 시간이 짧은 공간에서 대부분의 제품이 그렇지 않을 것이라고 생각합니다. 이러한 유형의 제품 (예 : 지속성, 선택자 등)과 함께 사용할 수없는 많은 기능이 있습니다. 우리는 메시징 제품 상단에 간단한 API를 작성하는 것이 매우 쉽다는 것을 알았고 나중에 제품을 변경할 수있는 유연성을 제공하고 JMS API의 대량 및 자세한 정보에서 자유 로워졌습니다.
고려할 또 다른 옵션은 JGroups입니다.
29West는 메시징 제품 라인에 JMS 지원을 추가했습니다.
"MQ 튜닝 용 포인터"와 관련하여 SupportPacs page에는 특정 권장 사항이있는 플랫폼마다 성능 평가가 있습니다. MP *라는 SupportPac으로 스크롤하여 해당 버전 및 플랫폼을 찾으십시오. 크고 작은 메시지, 지속성 및 비 지속성, 게터 및 퍼터 수에 대한 변형 등으로 다양한 시나리오가 테스트됩니다.
LLM 제품의 이전 개발자로서, . 아래 버전 2.6에 공개 된 정보 센터에서 발췌 한 내용을 참조하십시오.
그런데 MQ의 전체 요점은입니다. 시간과 장소가 있지만 대기 시간과 대역폭면에서 비용이 많이 든다.
LLM은 근본적으로 다른 목적을 가지고 있습니다. 그것은 신뢰할 수있는 배달을 가지고 있습니다 : 그것이 전달하지 못하면 당신은 단순히 전달하지 못했다는 것을 알게 될 것입니다. 이러한 메시지의 복구 가능성은 디스크에서 캐시 또는 리콜 할 의사가있는 정도와 프로세스를 보류하는 동안 복구를 기다릴 용의가있는 시간에 의해서만 제한됩니다. 경우에 따라 복구에 신경을 쓰지 않아도됩니다. LLM이 당신에게 옳은 것인지 아닌지는 추측 할 수 없습니다. 제가 말할 수있는 것은 과거의 개발자로서 나중에 클라이언트로서의 관점에서이 둘 사이의 유사성은 거의 없으며 LLM의 성능은 MQ를 완전히 물 밖으로 날려 버렸습니다. 나는 또한 자바/jms 측을 사용하지 않았고 C/C++에 초점을 맞추었기 때문에 이것을 소금 한알로 가져 가라. 나는 그것이 그것을했고 그것을 구글에서 볼 것을 알았다.
패키지 com.ibm.llm.jms 설명
LLM JMS 클라이언트에 대한 공급자 관련 공용 클래스를 구현합니다.
JMS에서 사용되는 대부분의 인터페이스는 일반적인 JMS 인터페이스에 의해 정의됩니다. 그러나 JMS 사양에는 클래스와 JMS 클라이언트 구성에 필요한 인터페이스가 포함되어 있지 않습니다.
JMS 클래스 및 메소드에 대한 자세한 내용은 JMS API 설명서를 참조하십시오.
소개
LLM JMS 클라이언트는 LLM에 자바 메시지 서비스 (JMS) 인터페이스를 제공합니다. LLM에 JMS 인터페이스를 사용하면 다른 메시징 프로 바이더와 공통된 인터페이스가 가능하며 개발자는 익숙한 인터페이스를 개발자가 사용할 수 있도록 애플리케이션 개발 속도를 까지 가속화 할 수 있습니다. 을 사용하면 JMS 인터페이스는 설정을 중앙에서 관리 할 수있는 일반 메시징 기능을 사용하는 응용 프로그램에 가장 적합합니다. 여기에는 많은 전통적인 클라이언트 응용 프로그램이 포함됩니다. LLM JMS 클라이언트 은 응용 프로그램이 LLM 특정 기능에 의존하거나 중요한 응용 프로그램을 필요로하는 곳에서 작동하지 않습니다. LLM과 상호 작용합니다. JMS 인터페이스를 사용하여 대기 시간이 추가되지만 대기 시간이 매우 짧고 처리량이 많은 메시징을 제공합니다.
LLM JMS 클라이언트는 대부분의 LLM 클라이언트 기능을 지원하지만 계층 내에서 실행되는 서버 기능 또는 균형 전송기 인 을 지원하지 않습니다.
LLM은 직접 제작자 대 소비자 메시징을 기반으로합니다. JMS는 클라이언트를 사용할 때 에 메시지 서버가 필요한 메시지 서버 및 JMS 기능을 사용하여 일반적으로 구현되는 입니다. 여기에는 모든 지점 간 메시징 (대기열)과 복구 기능인 이 포함됩니다. LLM JMS 클라이언트는 JSE 환경에서 실행되도록 설계되었으며 응용 프로그램 서버 확장 또는 XA 트랜잭션을 지원하지 않습니다. LLM JMS 클라이언트가 LLM JMS 클라이언트가 외부에 노출되지 않는 구현 클래스와 기본 JMS 객체의 각을 구현 JMS
를 구현하는 방법
. 이러한 객체의 서브 클래스는 구현 클래스를 사용하여 구현됩니다. 즉, 객체, ConnectionFactory 및 Destination이 두 개만 관리됩니다. 으로 정의 된 LLM은 TopicConnectionFactory 및 QueueConnectionFactory로 캐스팅 될 수 있으며 LLM 정의 대상은 주제 및 대기열로 캐스트 될 수 있습니다. Connection, Session, MessageProducer 및 MessageConsumer도 마찬가지입니다. 한 공급자의 대상 개체는 동일한 공급자가 Connection과 함께 사용해야합니다. 그러나 한 JMS 공급자가 생성 한 메시지를 다른 JMS 공급자에게 보낼 수 있습니다. 다른 JMS 공급자가 만든 메시지를 보내는 것이 LLM JMS 클라이언트에서 만든 메시지를 보내는 것만 큼 효과적이지는 않지만이 기능은 응용 프로그램이 한 공급자에서 다른 공급자로 쉽게 연결될 수 있도록하기 위해 제공됩니다.
LLM JMS 클라이언트는 지점 간 메시징 모델 (대기열)을 구현하지 않지만 모든 JMS 객체를 작성할 수 있습니다.
LLM JMS 클라이언트의 JVM을 필요로 적어도 자바 5
LLM JMS 클라이언트가 여섯 메시지 유형 객체 (메시지, BytesMessage의, MapMessage, ObjectMessage에, StreamMessage 오브젝트 및 끝난 TextMessage)를 정의합니다. JMS에서 JMS로 메시지를 보낼 때 JMS 헤더 은 메시지 유형을 나타냅니다. JMS 헤더가 누락 된 경우 (JMS가 아닌 프로듀서로부터 메시지를 보낼 때 이 공통 임) LLM JMS 클라이언트는 내용에서 메시지 유형을 추론합니다. 일반적으로 메시지는 BytesMessage로 표시되지만 메시지 이 UTF-8 BOM으로 시작하거나 XML 인 것으로 보이는 경우 TextMessage로 해석됩니다. TextMessages는 UTF-8로 코딩되어 있다고 가정합니다. ......
감사합니다. 일반적으로 과도한 볼륨이나 엄격한 대기 시간 요구 사항이 없으며 이전 솔루션 인 Fiorano가 정상적으로 작동했습니다. 불행히도 회사 표준은 IBM MQ를 지시합니다. –