You have a durable subscriber, and the subscriber is down or not reachable when the message is produced. Which two options regarding the expiry of these messages are true? 

Answer options:

A. after the subscriber is unavailable for 10 minutes
B. when the subscriber is available
C. after the subscriber is unavailable for after an hour
D. are available until the specified time elapses
E. are expired instantly

BD

By default, JMS messages never expire. When applications send messages to queues or topics with durable subscribers, WebLogic must retain the message until it is consumed. This is fine in most point-to-point messaging applications because consumers are constantly consuming messages. Any message sent to a queue will typically be consumed in a relatively short period of time. If the consumers get disconnected, they will usually reconnect as soon as possible and start processing any messages that might have built up in the queue. D: For durable subscribers to a topic, this is not necessarily true. The messaging system is forced to retain any message that has not been consumed by a durable subscriber, regardless of whether that durable subscriber will ever return. In this case, WebLogic is at the mercy of the durable subscriber to unsubscribe when it no longer wishes to receive the messages. If the durable subscriber logic is flawed in such a way that the subscribers do not unsubscribe properly, the messaging system will start to fill up with messages that may never be delivered. This calls for real caution in using durable subscribers. Fortunately, there is another way to help deal with this problem. Message expiration can be set at the connection factory level. Using a connection factorys default time-to-live attribute, we can specify the number of milliseconds that WebLogic should retain an undelivered message after it is sent.