1

The legacy system with JMS 1.1 (TibcoJms 4.4.1) I am working on has a JMS queue (not topic) established on the server side, which is meant for PTP mode of communication. Message item will be constantly put onto the queue by the server.

What I want to achieve on the is to poll these data by multiple threads on the client side. Each thread should deal with Messages with a particular attribute value.

One way I could do this I guess is to implement a MessageListener listening on that queue which acts as a 'switch' to distribute (PUSH) the message received to each thread on the client side to process. OR I can implement a MessageListener listening on that queue on the server and put received msg on a new queue on the client and each thread will POLL against the client side queue.

Either way, I think I will need to use an extra set of data structure on the client side shared among the threads.

My question is about whether there is a more direct approach involving direct communication between the client side processor thread and that queue on the server, kind of similar to multiple subscribers to a topic (although each subscriber does not actually 'share the load' but rather gets the same load. it is acceptable for my purpose).

Is there some good common practise anyone can suggest in this situation?

4

1 回答 1

2

直接连接的概念取决于 JMS 实现的实际编码方式。pub sub 或点对点本质上都不是更直接的连接。它确实取决于实施。

添加到您选择使用的 api 中。如果您有多个线程，那么请考虑这些线程是否是中断驱动的，因此可以使用多个消息侦听器，每个侦听器都有一个选择器。或者，使用选择器再次使用同步接收。

请记住，尽管 JMS 提供者不是数据库，所以选择器的广泛用户是一个坏主意。他们只是没有所有属性的索引。如果这是一个问题，您将需要一个本地分布数据结构。

根据您所说的，不确定 pub 子模型是否有帮助。听起来只有 1 个消费者应该收到每条安装消息。

于 2014-09-21T09:47:17.670 回答