Non-exhaustive.
Sources:
- The Java EE 6 Tutorial, Chapter 47
- TIBCO Enterprise Message Service User's Guide
Receiving messages can be sync (explicit call to receive
method with optional timeout) or async (register a message listener with consumer).
Able to view the messages inside a Queue that have yet to be consumed. You can browse messages and look at their headers.
(Not available for Topics, whether Durable Subscription or not.)
Like an SQL transaction, one atomic unit of work, consisting of sends/receives. Either all succeed or all fail.
Temporary queues/topics only last for as long as the connection they are created in.
If producer is asking for a reply, and creates a temporary destination and stays connected, then the consumer can send to it. The temporary destination is gone once the connection is closed.
Consumer can use a message selector, that tells the JMS provider to filter messages using the properties on the message.
Syntax is SQL-like: NewsType = 'Sports' OR NewsType = 'Opinion'
Range from 0 (low) to 9 (high), with default of 4.
JMS provider will try to deliver based on the priority, but it is not guaranteed to be exact.
Message will not be delivered after its expiry.
- AUTO_ACKNOWLEDGE = ack'ed once message is pulled (sync) or sent (async) to the consumer.
- CLIENT_ACKNOWLEDGE = consumer specifically calls
acknowledge()
on the message. However, this acknowledges all messages in the current session. - DUPS_OK_ACKNOWLEDGE = lazy ack, so if the JMS provider fails, duplicate messages may be sent to the consumer.
Whether messages will be lost if the JMS provider goes down. By default, PERSISTENT mode, so won't be lost.
You know what this is lah.
New mode: RELIABLE_DELIVERY, where server will never tell the producer what happened to the message, even if there is an exception (like due to destination not valid or access denied) that causes 0 consumers to receive the message.
Server-based way to get messages sent to one destination, sent to other destinations, regardless of type.
exclusive
: for queues, only allow one primary consumer to receive it, other consumers act as a standby to take over when the primary fails (this is compared to ordinary non-exclusive queues that do round-robin)expiration
: override expiration time on messagesflowControl
: max size of messages to be stored on server for destination, slow down producers when it is exceeded (by blocking the subsequent calls to send a message)maxbytes
: max size of messages to be stored on server for destination, reject when past that based onoverflowPolicy
(discard old or reject incoming messages)maxbytes
: max number of messages to be stored on server for destination, reject when past that based onoverflowPolicy
secure
: check user permissions (don't confuse with SSL). also, server'sauthorization
property must be enabled for this to be effective.
Enable server property authorization
, and destination property secure
where necessary.
You can create users and groups, and use them on access control lists for destinations.
Queue permissions: receive, send, browse
Topic permissions: subscribe, publish, durable, use_durable
This is available between the EMS client and server. You need to configure a certificate and primary key on the server, in the server config:
listen, ssl_server_identity, ssl_server_key
On the client, you need these jars:
tibcrypt.jar, slf4j-api-1.4.2,jar, slf4j-simple-1.4.2.jar