4

Can anyone clearly explain what is durable and non-durable in JMS Topic?

I have server and client model till now server will send the request to client to finish the request sent from server and the client accepts the request ant send back the response to server.

I have one scenario, instead of server initiate the request send to my client, my client have to look into server for particular request and send the response for that to server back.

Can I apply JMS Topic to solve this ? If anyone clearly explained would be appreciated. Thanks in advance.

Bhuvanesh Waran
  • 593
  • 12
  • 28

2 Answers2

6

There is no concept of a topic being durable or a non durable. It is the subscription for a topic that can be durable or non durable.

A non durable subscription means that publication will be delivered to the subscriber application as long as it is up and running. Once the application terminates, the broker will remove the subscription and no more publications will be delivered to that subscriber.

On the other hand, for a durable subscription, publications will be delivered to the subscription even if the subscriber application is not running. Broker will hold such publications (in a queue) when the application is down. Once the application comes up, those publications will be delivered.

Shashi
  • 14,980
  • 2
  • 33
  • 52
0

Once a client registers to receive messages for a topic, a durable topic keeps messages for that client when the client is disconnected. So if the client is not or cannot always be connected, the messages may be there waiting at a later time (depends, some JMS providers allow durable messages to expire, so if the client isn't connected for a long time the messages just don't sit there forever).

A non-durable topic means that the client only gets messages for the topic when actively connected.

In your use case, the only way the client can "look for a particular request" is that the topic is durable, the client has at least once connected for messages from the topic, the provider supports durable topics, and the messages were sent to the topic since the last time the client connected.

If you are looking for every message ever sent to the topic to be there (which is one way I interpreted your requirement), such that the client can search through looking for a specific request at any arbitrary time in the past, JMS does not sound like the solution.

Scott Sosna
  • 1,443
  • 1
  • 8
  • 8