Why does EMS server not remove a temporary queue when the queue consumer is closed?
Article ID: KB0091789
Updated On:
| Products | Versions |
|---|---|
| TIBCO Enterprise Message Service | - |
| Not Applicable | - |
Description
Resolution:
Symptoms:
* Before EMS 4.4.0, if the requestor is gone before the reply is sent,
this will cause accumulation of temp queues in the server.
* With EMS 4.4.0, in most of the situations (except for after FT
failover, before FT_reconnect_timeout expired) - if the requestor is
gone, when the responder is trying to send the reply back, the
following exception will be thrown.
==========
javax.jms.InvalidDestinationException: Invalid temporary destination
at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:508)
at
com.tibco.tibjms.TibjmsxSessionImp._createProducer(TibjmsxSessionImp.java:906)
at
com.tibco.tibjms.TibjmsxSessionImp.createProducer(TibjmsxSessionImp.java:4249)
at tibjmsQueueReceiver.<init>(tibjmsQueueReceiver.java:82)
at tibjmsQueueReceiver.main(tibjmsQueueReceiver.java:106)
==========
Please be aware that you need to use EMS 4.4.0+ for both server and client.
* After an FT failover completes and before ft_reconnect_timeout seconds elapse, applications trying to send a message to an "invalid" temporary destinations will not receive an exception, and the server will put those into a "in doubt" state, since the connection that created the temporary destination may not have yet reconnected. After the ft_reconnect_timeout interval elapses, all temporary destinations that have not been linked to reconnected connections will be remove automatically."
Suggestions:
We normally suggest customers to use temporary topics instead of 'queues' in request/reply scenarios before EMMS 4.4.0
Using temporary queues for reply in a request/reply scenario, you may end up having lot of orphan queues accumulated on the server before EMS 4.4.0.
To overcome this situation, you may:
- Use a ttl in the request and reply message
- Use temp topics instead
- Upgrade to EMS latest version 4.4.1.
The first option will cause the reply message in the "orphan"
temporary queue to be removed (when the ttl expires) and therefore,
the temporary queue will be destroyed at regular intervals.
The second option will ensure that when the reply is sent, if the
requestor is already gone, the message will be immediately discarded
and therefore, the temporary topic will be destroyed at regular intervals.
The third option will work when both server and client are of version 4.4.0+.
Symptoms:
* Before EMS 4.4.0, if the requestor is gone before the reply is sent,
this will cause accumulation of temp queues in the server.
* With EMS 4.4.0, in most of the situations (except for after FT
failover, before FT_reconnect_timeout expired) - if the requestor is
gone, when the responder is trying to send the reply back, the
following exception will be thrown.
==========
javax.jms.InvalidDestinationException: Invalid temporary destination
at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:508)
at
com.tibco.tibjms.TibjmsxSessionImp._createProducer(TibjmsxSessionImp.java:906)
at
com.tibco.tibjms.TibjmsxSessionImp.createProducer(TibjmsxSessionImp.java:4249)
at tibjmsQueueReceiver.<init>(tibjmsQueueReceiver.java:82)
at tibjmsQueueReceiver.main(tibjmsQueueReceiver.java:106)
==========
Please be aware that you need to use EMS 4.4.0+ for both server and client.
* After an FT failover completes and before ft_reconnect_timeout seconds elapse, applications trying to send a message to an "invalid" temporary destinations will not receive an exception, and the server will put those into a "in doubt" state, since the connection that created the temporary destination may not have yet reconnected. After the ft_reconnect_timeout interval elapses, all temporary destinations that have not been linked to reconnected connections will be remove automatically."
Suggestions:
We normally suggest customers to use temporary topics instead of 'queues' in request/reply scenarios before EMMS 4.4.0
Using temporary queues for reply in a request/reply scenario, you may end up having lot of orphan queues accumulated on the server before EMS 4.4.0.
To overcome this situation, you may:
- Use a ttl in the request and reply message
- Use temp topics instead
- Upgrade to EMS latest version 4.4.1.
The first option will cause the reply message in the "orphan"
temporary queue to be removed (when the ttl expires) and therefore,
the temporary queue will be destroyed at regular intervals.
The second option will ensure that when the reply is sent, if the
requestor is already gone, the message will be immediately discarded
and therefore, the temporary topic will be destroyed at regular intervals.
The third option will work when both server and client are of version 4.4.0+.
Issue/Introduction
Why does EMS server not remove a temporary queue when the queue consumer is closed?
Feedback
Yes
No
Powered by
