Hello, dear friends. In this video, we will examine the reliability mechanisms. Let's begin. You've seen how to connect to a provider, create different types of messages, send them to queues or topics and receive them. But what if you rely heavily on JMS and need to ensure reliability or other advanced features?

JMS defines several levels of reliability to ensure your message is delivered even if the provider crashes is under load or if destinations are filled with messages that should have expired. You can use six methods to achieve reliable message delivery. These are; filtering messages, setting message time to live, specifying message persistence, controlling acknowledgement, creating durable subscribers, setting priorities. Let's examine them one by one. First, filtering messages. Some messaging applications need to filter the messages they receive. When a message is broadcast to many clients it becomes useful to set criteria, so that it is only consumed by certain receivers. This eliminates both time and bandwidth the provider would waste transporting messages to clients that don't need them.

You've seen that messages are composed of three parts; header, properties, and body. The header contains a fixed number of fields and the properties are a set of custom name value pairs that the application can use to set any values. Selection can be done in those two areas. Producers set one or several property values or header fields and the consumer specifies message selection criteria using selector expressions. Only messages that match the selector are delivered. Message selectors assign the work of filtering messages to the JMS provider rather than to the application. A message selector is a string that contains an expression. The syntax of the expression is based on a subset of the SQL 92 conditional expression syntax and looks like this. As I previously stated, we will create the JMS project and carry out the majority of these operations. For the time being, we will examine them using code snippets. Let's look at this code. With the first one, we will receive messages with a JMS priority value of less than six. In the second line, we will receive messages with the JMS priority value of less than six and an order amount value of less than 200.

And with the last line, we will receive messages with order amount values between 1000 and 2000. In the proceeding code, a consumer is created with the JMSContext.CreateConsumer method, parsing a selector string. This string can use header field, JMS priority six, or custom properties order amount 200. The producer sets these properties into the message like this. Selector expressions can use; logical operators; not, and, or, comparison operators; =, <, <=, >, >=, <>, arithmetic operators +, -, *, / and so on. The other method is setting message time to live. Under heavy load, a time to live can be set on messages to ensure that the provider will remove them from the destination when they become obsolete  either by using the JMS Producer API or setting the JMS Expiration header field. The JMS Producer has a set time to live method that takes a number of milliseconds. As you can see in this code, we can adjust the time by a second. The other one is specifying message persistence.

JMS supports two modes of message delivery; persistent and non-persistent. Persistent delivery ensures that a message is delivered only once to a consumer, whereas non-persistent delivery requires a message to be delivered once at most. Persistent delivery, which is the default, is more reliable, but at a performance cost, as it prevents losing a message if a provider failure occurs. The delivery mode can be specified by using the set delivery mode method of the JMS Producer interface. In this code, you can see the usage of the set delivery mode method. With deliverymode., you can use persistent or non persistent. Let's continue with controlling acknowledgement. So far, the scenarios we've explored have assumed that a message is sent and received without any acknowledgement. But sometimes you'll need to acknowledge that the message has been received. An acknowledgement phase can be initiated either by the JMS Provider or by the client depending on the acknowledgement mode. In transactional sessions, acknowledgement happens automatically when a transaction is committed. If a transaction is rolled back, all consumed messages are re-delivered. But in non-transactional sessions, an acknowledgement mode must be specified.

There are three types of acknowledgement modes. These are; auto-acknowledge, client acknowledge, dupes okay acknowledge. In auto-acknowledge mode, the session automatically acknowledges the receipt of a message. In client acknowledge mode, a client acknowledges a message by explicitly calling the message acknowledge method. Dups_Ok_acknowledge option instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS Provider fails, so it should be used only by consumers that can tolerate duplicate messages. If the message is re-delivered, the provider sets the value of the JMS re-delivered header field to true. This code uses the JMS session mode annotation to send the acknowledgement mode to the JMS Context on the producer. The consumer explicitly acknowledge the message by calling the acknowledge method. The other one is creating durable consumers. The disadvantage of using the pub-sub model is that a message consumer must be running when the messages are sent to the topic. Otherwise, it will not receive them. By using durable consumers, the JMS API provides a way to keep messages in the topic until all subscribed consumers receive them.

With a durable subscription, the consumer can be offline for some time, but when it reconnects it receives the messages that arrived during its disconnection. To achieve this, the client creates a durable consumer using the JMS Context. At this point, the client program starts the connection and receives messages. The name Java EE 7 durable subscription is used as an identifier of the durable subscription. Each durable consumer must have a unique ID resulting in the declaration of a unique connection factory for each potential durable consumer. I think this method is clear now. The last method is setting priorities. You can use message priority levels to instruct the JMS Provider to deliver urgent messages first. JMS defines 10 priority values, with zero as the lowest and nine as the highest. You can specify the priority value by using the set priority method of the JMS Producer. Most of these methods return the JMS Producer to allow method calls to be chained together, allowing a fluid programming style. For example, with this code, we can set priority, time to live and delivery mode together. That's all for now. In this video, we learned the six methods of reliability mechanisms. Actually, we need to discuss Message-Driven Beans. However, we have already covered MDB in the EJB topic. So, I won't go over MDB again. In the following video, we will create a project with JMS, where we will apply what we have learned. See you in the next video.