Kbase 33204: NON_PERSISTENT_ASYNC temporary queues and InvalidDestinationException (NON_PERSISTENT delivery mode)
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Solution ID: P3204
GOAL:
NON_PERSISTENT_ASYNC for temporary queues and NON_PERSISTENT delivery mode for queue senders
GOAL:
How does the behavior of SonicMQ client code differ when running with SonicMQ Version 4.0 versus previous versions?
GOAL:
How did the behavior change for the NON_PERSISTENT delivery mode in SonicMQ4.0?
GOAL:
What happens to NON_PERSISTENT delivery mode when the broker is not security enabled?
GOAL:
How might the behavior change of NON_PERSISTENT delivery mode for queue senders about throwing an InvalidDestinationException when using temporary queues?
GOAL:
What happens when 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?
FACT(s) (Environment):
SonicMQ
FIX:
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.
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.