CODEWITHSUNDEEP
jakarta-eejmsactivemq-classicmessagingmessagebroker
Tuomas Toivonen
Tuomas Toivonen

Reputation: 23522

JMSReplyTo, physical location of the JMS broker

I'm confused about the nature of JMSReplyTo header. It contains object of type javax.jms.Destination, typically being a logical handle to temporary queue created by the originator of the message. Here is an experimental example of temporary queue creation and setting the JMSReplyTo header.

@Component("jmsbean")
public static class JmsBean {

    @Autowired
    @Qualifier("jmscf1")
    ConnectionFactory jmsServer1;

    @Autowired
    @Qualifier("jmscf2")
    ConnectionFactory jmsServer2;

    public String testJms(@Body String body) throws JMSException {

        Connection conn = jmsServer1.createConnection();
        conn.start();
        Session session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);

        Connection conn2 = jmsServer2.createConnection();
        conn2.start();
        Session session2 = conn2.createSession(false, Session.AUTO_ACKNOWLEDGE);

        TemporaryQueue tempQueue = session2.createTemporaryQueue();

        TextMessage message = session.createTextMessage();
        message.setJMSCorrelationID("tuomas");
        message.setJMSReplyTo(tempQueue);
        message.setJMSMessageID("tuomas");
        message.setText(body);

        Queue dest = session.createQueue("dest");
        MessageProducer producer = session.createProducer(dest);
        producer.send(message);

        session.close();
        conn.close();

        MessageConsumer consumer = session2.createConsumer(tempQueue);

        TextMessage reply = (TextMessage) consumer.receive();

        session2.close();
        conn2.close();

        return reply.getText();
    }
}

Now the message consumer could just pick the JMSReplyTo header from the Message object to get a reference to the temporary queue, and should send a response to this particular queue. And finally the originator receives it from that queue.

But what actually links this Destination object to the physical location of the queue? I'm considering a special scenario, where the temporary queue resides in a remote server, in the internet, outside of the (request) consumer's domain. There has to be some sort of IP address for the consumer to access the broker in the first place. So is this mandated by the specification, or provider specific?

How could I create ConnectionFactory, Connection and Session objects against the foreign remote broker to send the reply, if the only available information about the remote broker is in the JMSReplyTo header's Destination object? Does JMS specification guarantee all the information to initiate a session is available, and if so, how?

Upvotes: 0

Views: 347

Answers (1)

Justin Bertram
Justin Bertram

Reputation: 35142

But what actually links this Destination object to the psychical location of the queue?

The JMS specification does not define any link between a Destination and a physical location. The Destination is essentially just a reference to an implementation-specific name where the message will be sent.

How could I create ConnectionFactory, Connection and Session objects against the foreign remote broker to send the reply, if the only available information about the remote broker is in the JMSReplyTo header's Destination object?

Unless the implementation you're using has extended its Destination to include such information (i.e. beyond the requirements of the JMS spec) then you won't be able to create a connection based on the the Destination. I don't know of any implementation that has such an extension, and I would be surprised if any implementation did.

Does JMS specification guarantee all the information to initiate a session is available, and if so, how?

The JMS specification makes no such guarantees.

Upvotes: 1

Related Questions