According to the JMS spec, "PERSISTENT delivery mode instructs the JMS
provider to take extra care to insure that the message is not lost in
transit due to a JMS provider failure".
In other words, PERSISTENT message must be delivered "once and only
once", while NON_PERSISTENT message may be delivered "at most once".
In JMQ, this translates to following extra overheads -
1. The 'irouter' saves every PERSISTENT message on the disk.
2. Additional handshaking is required to remove these messages from
the disk when the subscriber acknowledges the message delivery.
This obviously has a huge impact on performance.
Here are some pros and cons of using PERSISTENT delivery mode -
1. The NON_PERSISTENT "at most once" delivery mode does NOT mean that
JMQ will occasionally drop such messages. It also does NOT mean
that these messages will have lower priority in any sense. All it
means is that, if for some reason irouter process is restarted
(e.g. after a crash), the PERSISTENT messages can be redelivered.
2. Note that the message redelivery after irouter restart is subject
to the subscription contract. For example, if the application uses
non-durable Topic subscription there is no point in using
PERSISTENT delivery. (because by definition non-durable topic
subscriptions get only the messages sent after the subscription is
created, and provider failure always causes all subscribers to
reconnect and start from scratch...)
3. So in other words - PERSISTENT delivery mode is useful only if you
are using either point-to-point (Queue) model, or durable Topic
subscriptions.
4. Even in case of point-to-point model, if occasional message loss
due to a provider failure is acceptable for a specific
application, it is better to use NON_PERSISTENT mode.
5. Finally PERSISTENT delivery mode is usually used in conjunction
with either CLIENT_ACKNOWLEDGE or transacted sessions (on the
receiver side) to insure that the message gets removed
from the disk only after the subscriber has processed it...