Are nonpersistent JMS messages redelivered to non-durable subscribers?

Question

Let's say I send a message to a non-durable subscriber, but the subscriber fails to acknowledge the message. Will the server try to redeliver the message or do redeliveries only happen for durable subscribers? Does the outcome depend on whether the message was persistent or non-persistent?

In the book "Java Message Service" by Mark Richards I have found no clear answer but two seemingly contradictory statements:

The acknowledge() method informs the JMS provider that the message has been successfully received by the consumer. This method throws an exception to the client if a provider failure occurs during the acknowledgment process. The provider failure results in the message being retained by the JMS server for redelivery.

This would suggest that the message is redelivered.

The message may be lost if the provider fails while delivering a message to a consumer with a nondurable subscription. If a durable subscriber receives a message, and a failure occurs before the acknowledgment is returned to the provider, then the JMS provider considers the message undelivered and will attempt to redeliver it.

Alright, so the message may be lost, i.e. not redelivered, but what circumstances does this depend on?

Is there even a usecase for the combination of durable subscribers and non-persistent messages?

Answer 1

Each statement you quote essentially indicates that the ultimate outcome depends on whether or not the provider encounters a "failure." The answer to your question depends on what kind of failure this is.

In the first quotation about message acknowledgement I believe the author is talking about a failure within the broker during the acknowledgement process where the broker process remains up but fails due to some internal reason.

In the second quotation about non-durable subscriptions I believe the author is talking about a failure of the broker during the process of delivering a message to a consumer where the broker process is terminated for some reason (e.g. JVM crash, hardware failure, etc.). In this case, any messages in the non-durable subscription will be lost since the subscription is, in fact, non-durable.

As a broker developer I don't really consider this message "loss," per se, because those are the expected semantics of a non-durable subscription. Since it is non-durable it is not expected to survive broker restarts (regardless of the underlying reason for the restart). I consider message loss as the unexpected removal of a message. A broker should never lose messages.