使用 JMS 临时队列进行同步使用是一个好习惯吗? [英] Is it a good practice to use JMS Temporary Queue for synchronous use?

问题描述

如果我们使用使用临时队列"的 JMS 请求/回复机制，该代码是否具有可扩展性?

If we use JMS request/reply mechanism using "Temporary Queue", will that code be scalable?

截至目前，我们不知道我们是支持每秒 100 个请求，还是每秒 1000 个请求.

As of now, we don't know if we will supporting 100 requests per second, or 1000s of requests per second.

下面的代码是我想实现的.它以同步"方式使用 JMS.关键部分是创建消费者"以指向为此会话创建的临时队列"的地方.我只是不知道使用这样的临时队列是否是一种可扩展的设计.

The code below is what I am thinking of implementing. It makes use of JMS in a 'Synchronous' fashion. The key parts are where the 'Consumer' gets created to point a 'Temporary Queue' that was created for this session. I just can't figure out whether using such Temporary Queues is a scalable design.

  destination = session.createQueue("queue:///Q1");
  producer = session.createProducer(destination);
  tempDestination = session.createTemporaryQueue();
  consumer = session.createConsumer(tempDestination);

  long uniqueNumber = System.currentTimeMillis() % 1000;
  TextMessage message = session
      .createTextMessage("SimpleRequestor: Your lucky number today is " + uniqueNumber);

  // Set the JMSReplyTo
  message.setJMSReplyTo(tempDestination);

  // Start the connection
  connection.start();

  // And, send the request
  producer.send(message);
  System.out.println("Sent message:\n" + message);

  // Now, receive the reply
  Message receivedMessage = consumer.receive(15000); // in ms or 15 seconds
  System.out.println("\nReceived message:\n" + receivedMessage);

更新:

我遇到了另一种模式，参见这篇博客这个想法是为发送和接收使用常规"队列.但是，对于同步"调用，为了获得所需的响应(即匹配请求)，您可以创建一个使用选择器"侦听接收队列的消费者.

I came across another pattern, see this blog The idea is to use 'regular' Queues for both Send and Receive. However for 'Synchronous' calls, in order to get the desired Response (i.e. matching the request), you create a Consumer that listens to the Receive queue using a 'Selector'.

步骤:

    // 1. Create Send and Receive Queue.
    // 2. Create a msg with a specific ID
 final String correlationId = UUID.randomUUID().toString();
 final TextMessage textMessage = session.createTextMessage( msg );
 textMessage.setJMSCorrelationID( correlationId );

    // 3. Start a consumer that receives using a 'Selector'.
           consumer = session.createConsumer( replyQueue, "JMSCorrelationID = '" + correlationId + "'" );

所以这种模式的不同之处在于我们不会为每个新请求创建一个新的临时队列.相反，所有响应都只进入一个队列，但使用选择器"来确保每个请求线程接收唯一关心的响应.

So the difference in this pattern is that we don't create a new temp Queue for each new request. Instead all responses come to only one queue, but use a 'selector' to make sure each request-thread receives the only the response that is cares about.

我认为这里的缺点是您必须使用选择器".我还不知道这比前面提到的模式更不受欢迎还是更受欢迎.想法?

I think the downside here is that you have to use a 'selector'. I don't know yet if that is less preferred or more preferred than earlier mentioned pattern. Thoughts?

推荐答案

关于帖子中的更新 - 如果在消息标题上执行，选择器将非常有效，就像您对关联 ID 所做的那样.Spring Integration 也在内部为 实现 JMS 出站网关.

Regarding the update in your post - selectors are very efficient if performed on the message headers, like you are doing with the Correlation ID. Spring Integration also internally does this for implementing a JMS Outbound gateway.

这篇关于使用 JMS 临时队列进行同步使用是一个好习惯吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！