Kbase 22011: InvalidDestinationException w/NON_PERSISTENT in SonicMQ 4.x
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/3/2002 |
|
SUMMARY:
This Solution applies to SonicMQ Versions 3.0, 3.5 and 4.0 and the SonicMQ C Client version 3.0. It explains the change in the behavior of the NON_PERSISTENT delivery mode for queue senders in SonicMQ 4.0 and how this can bring about an InvalidDestinationException when using temporary queues.
EXPLANATION:
When SonicMQ Version 3.x Java, C, and C++ queue senders set the
delivery mode to NON_PERSISTENT, the broker security setting
determines the behavior of the client with respect to acknowledgements
from the broker on each call to send().
When the broker is not security enabled, the behavior with
NON_PERSISTENT delivery mode is the same as that with
progress.message.jclient.DeliveryMode.NON_PERSISTENT_ASYNC. When
using this asynchronous delivery mode, the producer does not wait for
an acknowledgment from the broker after sending a message.
When the broker is security enabled, NON_PERSISTENT delivery mode is
synchronous: the sender waits for an acknowledgment from the broker
after sending each message. If a destination queue becomes unwriteable, an InvalidDestinationException is thrown on the client.
With SonicMQ Version 4.0 clients, NON_PERSISTENT delivery mode
retains the JMS specified synchronous behavior for queue senders,
whether or not security is enabled on the broker. This means that the
behavior of SonicMQ client code may be different when running with
SonicMQ Version 4.0 than when running with previous versions.
Under SonicMQ 3.0, a QueueSender using NON_PERSISTENT delivery mode
with a broker on which security is not enabled, does not throw an
exception if the destination queue is unwriteable. In this scenario,
the same code running as a SonicMQ 4.0 client throws an
InvalidDestinationException.
This difference in behavior is most apparent in applications in which
a receiver sets up a temporary queue and later closes its session
(thereby deleting the temporary queue) without alerting a
NON_PERSISTENT_ASYNC sender to that queue. With SonicMQ 4.0, the
sender in this scenario throws an exception for every message it
attempts to send after the temporary queue is gone.
SOLUTION:
Version 4.0 queue senders must explicitly specify the delivery mode as
progress.message.jclient.DeliveryMode.NON_PERSISTENT_ASYNC to get
asynchronous behavior with NON_PERSISTENT delivery mode.
Note that the behavior of topic publishers using NON_PERSISTENT
delivery mode is the same in SonicMQ Versions 3.0, 3.5, and 4.0.
References to Written Documentation:
SonicMQ Programming Guide, Versions 3.0, 3.5, and 4.0
Java Message Service (JMS) Specification
SonicMQ API Reference