2009-10-09 67 views
5

我們目前正在通過JMS使用IBM MQ,但似乎正在推送比它能處理更多的消息 - 奇怪的是,問題似乎是間歇性的。WebSphere MQ低延遲消息傳遞 - 它是否具有JMS(或類似JMS)的API?

消息是價格,因此不需要保證,只需要快速發送。

由於IBM有一個Low Latency product,我想知道這是否是更好的解決方案 - 但它似乎沒有JMS api,或者至少不容易看到。

任何人都知道,如果有一個JMS API到低延遲的產品,或JMS樣,如果「獨一無二」的API它擁有的是...

或者,MQ調整指針也將不勝感激。 .. :)

回答

5

當然,低延遲消息產品會更適合您的問題,我正在研究一個項目,我們使用名爲LBM的低延遲消息傳遞產品29West做類似的事情。它沒有JMS API,我懷疑大多數低延遲空間的產品不會。有大量功能與這些類型的產品(例如持久性,選擇器等)結合使用時沒有意義。我們發現將我們自己的簡單API寫在消息傳遞產品的頂部是非常簡單的,並且使用靈活性來稍後更改產品,並將我們從JMS api的一些大量和冗長中解放出來。

要考慮的另一個選項是JGroups

29West已將JMS支持添加到其郵件產品系列。

+0

謝謝 - 我們沒有通常過量的數量或嚴格的延遲要求,我們以前的解決方案Fiorano工作得很好。不幸的是,公司標準決定IBM MQ :( – 2009-10-10 23:35:07

1

關於「針對MQ調整的指針」,在SupportPacs page上,每個平臺都有性能評估和特定的建議。向下滾動到名爲MP *的SupportPacs並查找相應的版本和平臺。大量和小型消息,持久性和非持久性,吸氣劑和推杆數量的變化等進行了測試各種情況。

1

作爲LLM產品的前開發人員,我可以說,它確實或至少做過。請參閱下面的摘錄我從公開可用的信息中心爲版本2.6採取的

這就是說,從我記得MQ的整點是保證交付。這是一個時間和地點,但它在延遲和帶寬方面需要付出代價。

LLM從根本上有不同的目的;它有可靠的交付:即如果它未能交付你只會知道它沒有交付。這些消息的可恢復性僅受限於您願意從磁盤保留多少緩存或回收的時間,以及您在多少時間內願意忍耐等待恢復的時間。在您的情況下,您可能不希望恢復。 LLM是否適合你,我無法推測。我可以說的是,作爲一名過去的開發人員以及後來的客戶,我發現兩者之間幾乎沒有任何相似之處,而且這種應用程序的LLM性能完全將MQ徹底排除在外。我也從來沒有使用過java/jms方面,並且專注於C/C++,所以請着重於一點鹽。我只知道它做到了,並且在谷歌的哪個地方看。

http://www-01.ibm.com/support/knowledgecenter/SSQPD3_2.6.0/com.ibm.wllm.doc/api/javadoc/messaging/com/ibm/llm/jms/package-summary.html

包com.ibm.llm。jms描述

爲LLM JMS客戶端實現特定於提供者的公共類。

大多數JMS使用的接口的由通用JMS 接口定義。但是,JMS規範不包括配置JMS客戶端所需的 類和接口。

有關JMS類 和方法的信息,請參閱JMS API文檔。

介紹

的LLM JMS客戶端提供Java消息服務(JMS)接口 LLM。使用JMS接口與LLM允許與其他消息傳遞提供商的通用接口,並通過 加速應用程序開發,允許開發人員使用他們熟悉的接口。使用 JMS接口最適用於使用通用 消息功能的應用程序,其中可以集中管理設置。 這包括許多傳統的客戶端應用程序。法學碩士JMS客戶 其中應用程序依賴於LLM 特定功能或需要與LLM顯著應用 相互作用並不正常工作。儘管通過使用JMS接口添加了一些延遲,但它仍然提供非常低的延遲和高吞吐量的消息傳遞。

LLM JMS客戶端支持大多數LLM客戶端功能,但不支持在一個層內運行的服務器功能,或者不支持 平衡發送器。

LLM基於做直接生產者到消費者的消息。 JMS是 通常使用消息服務器和JMS函數 要求消息服務器實現使用LLM JMS 客戶端時不可用。這包括所有的點對點消息傳遞(隊列)以及恢復功能 。 LLM JMS客戶端設計爲在JSE 環境中運行,不支持應用程序服務器擴展或XA 事務。

的LLM JMS客戶端如何實現JMS

法學碩士JMS客戶端實現每個 未暴露於外部的一個實現類的基本JMS對象。這些對象的 子類是使用相同的 實現類實現的。這意味着只有兩個被管理的對象,ConnectionFactory和Destination。一個LLM定義 的ConnectionFactory可以轉換爲TopicConnectionFactory的和 的QueueConnectionFactory和LLM定義目的地可以轉換爲 主題和隊列。 Connection,Session, MessageProducer和MessageConsumer也是如此。來自一個 供應商的目標對象必須與同一供應商的連接一起使用。但是, 可能會將由一個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編碼......