MessageProducer object to send messages to a
destination. A MessageProducer object is created by passing a
Destination object to a message-producer creation method
supplied by a session.
MessageProducer is the parent interface for all message
producers.
A client also has the option of creating a message producer without supplying
a destination. In this case, a destination must be provided with every send
operation. A typical use for this kind of message producer is to send replies
to requests using the request's JMSReplyTo destination.
A client can specify a default delivery mode, priority, time to live and delivery delay for messages sent by a message producer. It can also specify the delivery mode, priority, and time to live for an individual message.
A client can specify a time-to-live value in milliseconds for each message it sends. This value defines a message expiration time that is the sum of the message's time-to-live and the GMT when it is sent (for transacted sends, this is the time the client sends the message, not the time the transaction is committed).
A JMS provider should do its best to expire messages accurately; however, the JMS API does not define the accuracy provided.
javax.jms.TopicPublisher, javax.jms.QueueSender, javax.jms.Session#createProducer
| Modifier and Type | Method and Description |
|---|---|
| public void | |
| public long | Returns: the delivery delay in milliseconds.Gets the minimum length of time in milliseconds that must elapse after a message is sent before the JMS provider may deliver the message to a consumer. |
| public int | Returns: the message delivery mode for this message producerGets the producer's default delivery mode. |
| public Destination | Returns: this producer'sDestinationGets the destination associated with this |
| public boolean | Returns: an indication of whether message IDs are disabledGets an indication of whether message IDs are disabled. |
| public boolean | Returns: an indication of whether message timestamps are disabledGets an indication of whether message timestamps are disabled. |
| public int | Returns: the message priority for this message producerGets the producer's default priority. |
| public long | Returns: the message time to live in milliseconds; zero is unlimitedGets the default length of time in milliseconds from its dispatch time that a produced message should be retained by the message system. |
| public void | |
| public void | |
| public void | send(Destination
the destination to send this message to destination, Message the message to send message)Sends a message to a destination for an unidentified message producer
using the |
| public void | send(Destination
the destination to send this message to destination, Message the message to send message, int the delivery mode to use deliveryMode, int the priority for this message priority, long the message's lifetime (in milliseconds) timeToLive)Sends a message to a destination for an unidentified message producer, specifying delivery mode, priority and time to live. |
| public void | send(Message
the message to send message, CompletionListener a completionListener)CompletionListener to be notified when the send
has completedSends a message using the |
| public void | send(Message
the message to send message, int the delivery mode to use deliveryMode, int the priority for this message priority, long the message's lifetime (in milliseconds) timeToLive, CompletionListener a completionListener)CompletionListener to be notified when the send
has completedSends a message, specifying delivery mode, priority and time to live, performing part of the work involved in sending the message in a separate thread and notifying the specified CompletionListener when the operation has completed. |
| public void | send(Destination
the destination to send this message to destination, Message the message to send message, CompletionListener a completionListener)CompletionListener to be notified when the send
has completedSends a message to a destination for an unidentified message producer,
using the |
| public void | send(Destination
the destination to send this message to destination, Message the message to send message, int the delivery mode to use deliveryMode, int the priority for this message priority, long the message's lifetime (in milliseconds) timeToLive, CompletionListener a completionListener)CompletionListener to be notified when the send
has completedSends a message to a destination for an unidentified message producer, specifying delivery mode, priority and time to live, performing part of the work involved in sending the message in a separate thread and notifying the specified CompletionListener when the operation has completed. |
| public void | setDeliveryDelay(long
the delivery delay in milliseconds. deliveryDelay)Sets the minimum length of time in milliseconds that must elapse after a message is sent before the JMS provider may deliver the message to a consumer. |
| public void | setDeliveryMode(int
the message delivery mode for this message producer; legal
values are deliveryMode)DeliveryMode.NON_PERSISTENT and
DeliveryMode.PERSISTENTSets the producer's default delivery mode. |
| public void | setDisableMessageID(boolean
indicates if message IDs may be disabled value)Specify whether message IDs may be disabled. |
| public void | setDisableMessageTimestamp(boolean
indicates whether message timestamps may be disabled value)Specify whether message timestamps may be disabled. |
| public void | setPriority(int
the message priority for this message producer; must be a
value between 0 and 9 defaultPriority)Sets the producer's default priority. |
| public void | setTimeToLive(long
the message time to live in milliseconds; zero is unlimited timeToLive)Sets the default length of time in milliseconds from its dispatch time that a produced message should be retained by the message system. |
| close | back to summary |
|---|---|
| public void close() throws JMSException Redeclares java. Closes the message producer.
Since a provider may allocate some resources on behalf of a
This method must not return until any incomplete asynchronous send operations for this MessageProducer have been completed and any CompletionListener callbacks have returned. Incomplete sends should be allowed to complete normally unless an error occurs. A CompletionListener callback method must not call close on its own MessageProducer. Doing so will cause an IllegalStateException to be thrown.
| |
| getDeliveryDelay | back to summary |
|---|---|
| public long getDeliveryDelay() throws JMSException Gets the minimum length of time in milliseconds that must elapse after a message is sent before the JMS provider may deliver the message to a consumer.
| |
| getDeliveryMode | back to summary |
|---|---|
| public int getDeliveryMode() throws JMSException Gets the producer's default delivery mode.
| |
| getDestination | back to summary |
|---|---|
| public Destination getDestination() throws JMSException Gets the destination associated with this
| |
| getDisableMessageID | back to summary |
|---|---|
| public boolean getDisableMessageID() throws JMSException Gets an indication of whether message IDs are disabled.
| |
| getDisableMessageTimestamp | back to summary |
|---|---|
| public boolean getDisableMessageTimestamp() throws JMSException Gets an indication of whether message timestamps are disabled.
| |
| getPriority | back to summary |
|---|---|
| public int getPriority() throws JMSException Gets the producer's default priority.
| |
| getTimeToLive | back to summary |
|---|---|
| public long getTimeToLive() throws JMSException Gets the default length of time in milliseconds from its dispatch time that a produced message should be retained by the message system.
| |
| send | back to summary |
|---|---|
| public void send(Message message) throws JMSException Sends a message using the
| |
| send | back to summary |
|---|---|
| public void send(Message message, int deliveryMode, int priority, long timeToLive) throws JMSException Sends a message, specifying delivery mode, priority, and time to live.
| |
| send | back to summary |
|---|---|
| public void send(Destination destination, Message message) throws JMSException Sends a message to a destination for an unidentified message producer
using the Typically, a message producer is assigned a destination at creation time; however, the JMS API also supports unidentified message producers, which require that the destination be supplied every time a message is sent.
| |
| send | back to summary |
|---|---|
| public void send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive) throws JMSException Sends a message to a destination for an unidentified message producer, specifying delivery mode, priority and time to live. Typically, a message producer is assigned a destination at creation time; however, the JMS API also supports unidentified message producers, which require that the destination be supplied every time a message is sent.
| |
| send | back to summary |
|---|---|
| public void send(Message message, CompletionListener completionListener) throws JMSException Sends a message using the When the message has been successfully sent the JMS provider invokes the callback method onCompletion on an application-specified CompletionListener object. Only when that callback has been invoked can the application be sure that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed. An application which requires this degree of confidence must therefore wait for the callback to be invoked before continuing. The following information is intended to give an indication of how an asynchronous send would typically be implemented. In some JMS providers, a normal synchronous send involves sending the message to a remote JMS server and then waiting for an acknowledgement to be received before returning. It is expected that such a provider would implement an asynchronous send by sending the message to the remote JMS server and then returning without waiting for an acknowledgement. When the acknowledgement is received, the JMS provider would notify the application by invoking the onCompletion method on the application-specified CompletionListener object. If for some reason the acknowledgement is not received the JMS provider would notify the application by invoking the CompletionListener's onException method. In those cases where the JMS specification permits a lower level of reliability, a normal synchronous send might not wait for an acknowledgement. In that case it is expected that an asynchronous send would be similar to a synchronous send: the JMS provider would send the message to the remote JMS server and then return without waiting for an acknowledgement. However the JMS provider would still notify the application that the send had completed by invoking the onCompletion method on the application-specified CompletionListener object. It is up to the JMS provider to decide exactly what is performed in the calling thread and what, if anything, is performed asynchronously, so long as it satisfies the requirements given below: Quality of service: After the send operation has completed successfully, which means that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed, the JMS provider must invoke the CompletionListener's onCompletion method. The CompletionListener must not be invoked earlier than this. Exceptions: If an exception is encountered during the call to the send method then an appropriate exception should be thrown in the thread that is calling the send method. In this case the JMS provider must not invoke the CompletionListener's onCompletion or onException method. If an exception is encountered which cannot be thrown in the thread that is calling the send method then the JMS provider must call the CompletionListener's onException method. In both cases if an exception occurs it is undefined whether or not the message was successfully sent. Message order: If the same MessageProducer is used to send multiple messages then JMS message ordering requirements must be satisfied. This applies even if a combination of synchronous and asynchronous sends has been performed. The application is not required to wait for an asynchronous send to complete before sending the next message.
Close, commit or rollback: If the close method is called
on the MessageProducer or its Session or
Connection then the JMS provider must block until any incomplete
send operations have been completed and all
A CompletionListener callback method must not call close on its own Connection, Session or MessageProducer or call commit or rollback on its own Session. Doing so will cause the close, commit or rollback to throw an IllegalStateException.
Restrictions on usage in Java EE This method must not be used in a
Java EE EJB or web container. Doing so may cause a Message headers JMS defines a number of message header fields and message properties which must be set by the "JMS provider on send". If the send is asynchronous these fields and properties may be accessed on the sending client only after the CompletionListener has been invoked. If the CompletionListener's onException method is called then the state of these message header fields and properties is undefined. Restrictions on threading: Applications that perform an asynchronous send must confirm to the threading restrictions defined in JMS. This means that the session may be used by only one thread at a time. Setting a CompletionListener does not cause the session to be dedicated to the thread of control which calls the CompletionListener. The application thread may therefore continue to use the session after performing an asynchronous send. However the CompletionListener's callback methods must not use the session if an application thread might be using the session at the same time.
Use of the CompletionListener by the JMS provider: A
session will only invoke one CompletionListener callback method
at a time. For a given MessageProducer, callbacks (both
Restrictions on the use of the Message object: Applications which perform an asynchronous send must take account of the restriction that a Message object is designed to be accessed by one logical thread of control at a time and does not support concurrent use. After the send method has returned, the application must not attempt to read the headers, properties or body of the Message object until the CompletionListener's onCompletion or onException method has been called. This is because the JMS provider may be modifying the Message object in another thread during this time. The JMS provider may throw an JMSException if the application attempts to access or modify the Message object after the send method has returned and before the CompletionListener has been invoked. If the JMS provider does not throw an exception then the behaviour is undefined.
| |
| send | back to summary |
|---|---|
| public void send(Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener) throws JMSException Sends a message, specifying delivery mode, priority and time to live, performing part of the work involved in sending the message in a separate thread and notifying the specified CompletionListener when the operation has completed. JMS refers to this as an "asynchronous send". When the message has been successfully sent the JMS provider invokes the callback method onCompletion on an application-specified CompletionListener object. Only when that callback has been invoked can the application be sure that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed. An application which requires this degree of confidence must therefore wait for the callback to be invoked before continuing. The following information is intended to give an indication of how an asynchronous send would typically be implemented. In some JMS providers, a normal synchronous send involves sending the message to a remote JMS server and then waiting for an acknowledgement to be received before returning. It is expected that such a provider would implement an asynchronous send by sending the message to the remote JMS server and then returning without waiting for an acknowledgement. When the acknowledgement is received, the JMS provider would notify the application by invoking the onCompletion method on the application-specified CompletionListener object. If for some reason the acknowledgement is not received the JMS provider would notify the application by invoking the CompletionListener's onException method. In those cases where the JMS specification permits a lower level of reliability, a normal synchronous send might not wait for an acknowledgement. In that case it is expected that an asynchronous send would be similar to a synchronous send: the JMS provider would send the message to the remote JMS server and then return without waiting for an acknowledgement. However the JMS provider would still notify the application that the send had completed by invoking the onCompletion method on the application-specified CompletionListener object. It is up to the JMS provider to decide exactly what is performed in the calling thread and what, if anything, is performed asynchronously, so long as it satisfies the requirements given below: Quality of service: After the send operation has completed successfully, which means that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed, the JMS provider must invoke the CompletionListener's onCompletion method. The CompletionListener must not be invoked earlier than this. Exceptions: If an exception is encountered during the call to the send method then an appropriate exception should be thrown in the thread that is calling the send method. In this case the JMS provider must not invoke the CompletionListener's onCompletion or onException method. If an exception is encountered which cannot be thrown in the thread that is calling the send method then the JMS provider must call the CompletionListener's onException method. In both cases if an exception occurs it is undefined whether or not the message was successfully sent. Message order: If the same MessageProducer is used to send multiple messages then JMS message ordering requirements must be satisfied. This applies even if a combination of synchronous and asynchronous sends has been performed. The application is not required to wait for an asynchronous send to complete before sending the next message.
Close, commit or rollback: If the close method is called
on the MessageProducer or its Session or
Connection then the JMS provider must block until any incomplete
send operations have been completed and all
A CompletionListener callback method must not call close on its own Connection, Session or MessageProducer or call commit or rollback on its own Session. Doing so will cause the close, commit or rollback to throw an IllegalStateException.
Restrictions on usage in Java EE This method must not be used in a
Java EE EJB or web container. Doing so may cause a Message headers JMS defines a number of message header fields and message properties which must be set by the "JMS provider on send". If the send is asynchronous these fields and properties may be accessed on the sending client only after the CompletionListener has been invoked. If the CompletionListener's onException method is called then the state of these message header fields and properties is undefined. Restrictions on threading: Applications that perform an asynchronous send must confirm to the threading restrictions defined in JMS. This means that the session may be used by only one thread at a time. Setting a CompletionListener does not cause the session to be dedicated to the thread of control which calls the CompletionListener. The application thread may therefore continue to use the session after performing an asynchronous send. However the CompletionListener's callback methods must not use the session if an application thread might be using the session at the same time.
Use of the CompletionListener by the JMS provider: A
session will only invoke one CompletionListener callback method
at a time. For a given MessageProducer, callbacks (both
Restrictions on the use of the Message object: Applications which perform an asynchronous send must take account of the restriction that a Message object is designed to be accessed by one logical thread of control at a time and does not support concurrent use. After the send method has returned, the application must not attempt to read the headers, properties or body of the Message object until the CompletionListener's onCompletion or onException method has been called. This is because the JMS provider may be modifying the Message object in another thread during this time. The JMS provider may throw an JMSException if the application attempts to access or modify the Message object after the send method has returned and before the CompletionListener has been invoked. If the JMS provider does not throw an exception then the behaviour is undefined.
| |
| send | back to summary |
|---|---|
| public void send(Destination destination, Message message, CompletionListener completionListener) throws JMSException Sends a message to a destination for an unidentified message producer,
using the Typically, a message producer is assigned a destination at creation time; however, the JMS API also supports unidentified message producers, which require that the destination be supplied every time a message is sent. When the message has been successfully sent the JMS provider invokes the callback method onCompletion on an application-specified CompletionListener object. Only when that callback has been invoked can the application be sure that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed. An application which requires this degree of confidence must therefore wait for the callback to be invoked before continuing. The following information is intended to give an indication of how an asynchronous send would typically be implemented. In some JMS providers, a normal synchronous send involves sending the message to a remote JMS server and then waiting for an acknowledgement to be received before returning. It is expected that such a provider would implement an asynchronous send by sending the message to the remote JMS server and then returning without waiting for an acknowledgement. When the acknowledgement is received, the JMS provider would notify the application by invoking the onCompletion method on the application-specified CompletionListener object. If for some reason the acknowledgement is not received the JMS provider would notify the application by invoking the CompletionListener's onException method. In those cases where the JMS specification permits a lower level of reliability, a normal synchronous send might not wait for an acknowledgement. In that case it is expected that an asynchronous send would be similar to a synchronous send: the JMS provider would send the message to the remote JMS server and then return without waiting for an acknowledgement. However the JMS provider would still notify the application that the send had completed by invoking the onCompletion method on the application-specified CompletionListener object. It is up to the JMS provider to decide exactly what is performed in the calling thread and what, if anything, is performed asynchronously, so long as it satisfies the requirements given below: Quality of service: After the send operation has completed successfully, which means that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed, the JMS provider must invoke the CompletionListener's onCompletion method. The CompletionListener must not be invoked earlier than this. Exceptions: If an exception is encountered during the call to the send method then an appropriate exception should be thrown in the thread that is calling the send method. In this case the JMS provider must not invoke the CompletionListener's onCompletion or onException method. If an exception is encountered which cannot be thrown in the thread that is calling the send method then the JMS provider must call the CompletionListener's onException method. In both cases if an exception occurs it is undefined whether or not the message was successfully sent. Message order: If the same MessageProducer is used to send multiple messages then JMS message ordering requirements must be satisfied. This applies even if a combination of synchronous and asynchronous sends has been performed. The application is not required to wait for an asynchronous send to complete before sending the next message.
Close, commit or rollback: If the close method is called
on the MessageProducer or its Session or
Connection then the JMS provider must block until any incomplete
send operations have been completed and all
A CompletionListener callback method must not call close on its own Connection, Session or MessageProducer or call commit or rollback on its own Session. Doing so will cause the close, commit or rollback to throw an IllegalStateException.
Restrictions on usage in Java EE This method must not be used in a
Java EE EJB or web container. Doing so may cause a Message headers JMS defines a number of message header fields and message properties which must be set by the "JMS provider on send". If the send is asynchronous these fields and properties may be accessed on the sending client only after the CompletionListener has been invoked. If the CompletionListener's onException method is called then the state of these message header fields and properties is undefined. Restrictions on threading: Applications that perform an asynchronous send must confirm to the threading restrictions defined in JMS. This means that the session may be used by only one thread at a time. Setting a CompletionListener does not cause the session to be dedicated to the thread of control which calls the CompletionListener. The application thread may therefore continue to use the session after performing an asynchronous send. However the CompletionListener's callback methods must not use the session if an application thread might be using the session at the same time.
Use of the CompletionListener by the JMS provider: A
session will only invoke one CompletionListener callback method
at a time. For a given MessageProducer, callbacks (both
Restrictions on the use of the Message object: Applications which perform an asynchronous send must take account of the restriction that a Message object is designed to be accessed by one logical thread of control at a time and does not support concurrent use. After the send method has returned, the application must not attempt to read the headers, properties or body of the Message object until the CompletionListener's onCompletion or onException method has been called. This is because the JMS provider may be modifying the Message object in another thread during this time. The JMS provider may throw an JMSException if the application attempts to access or modify the Message object after the send method has returned and before the CompletionListener has been invoked. If the JMS provider does not throw an exception then the behaviour is undefined.
| |
| send | back to summary |
|---|---|
| public void send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener) throws JMSException Sends a message to a destination for an unidentified message producer, specifying delivery mode, priority and time to live, performing part of the work involved in sending the message in a separate thread and notifying the specified CompletionListener when the operation has completed. JMS refers to this as an "asynchronous send". Typically, a message producer is assigned a destination at creation time; however, the JMS API also supports unidentified message producers, which require that the destination be supplied every time a message is sent. When the message has been successfully sent the JMS provider invokes the callback method onCompletion on an application-specified CompletionListener object. Only when that callback has been invoked can the application be sure that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed. An application which requires this degree of confidence must therefore wait for the callback to be invoked before continuing. The following information is intended to give an indication of how an asynchronous send would typically be implemented. In some JMS providers, a normal synchronous send involves sending the message to a remote JMS server and then waiting for an acknowledgement to be received before returning. It is expected that such a provider would implement an asynchronous send by sending the message to the remote JMS server and then returning without waiting for an acknowledgement. When the acknowledgement is received, the JMS provider would notify the application by invoking the onCompletion method on the application-specified CompletionListener object. If for some reason the acknowledgement is not received the JMS provider would notify the application by invoking the CompletionListener's onException method. In those cases where the JMS specification permits a lower level of reliability, a normal synchronous send might not wait for an acknowledgement. In that case it is expected that an asynchronous send would be similar to a synchronous send: the JMS provider would send the message to the remote JMS server and then return without waiting for an acknowledgement. However the JMS provider would still notify the application that the send had completed by invoking the onCompletion method on the application-specified CompletionListener object. It is up to the JMS provider to decide exactly what is performed in the calling thread and what, if anything, is performed asynchronously, so long as it satisfies the requirements given below: Quality of service: After the send operation has completed successfully, which means that the message has been successfully sent with the same degree of confidence as if a normal synchronous send had been performed, the JMS provider must invoke the CompletionListener's onCompletion method. The CompletionListener must not be invoked earlier than this. Exceptions: If an exception is encountered during the call to the send method then an appropriate exception should be thrown in the thread that is calling the send method. In this case the JMS provider must not invoke the CompletionListener's onCompletion or onException method. If an exception is encountered which cannot be thrown in the thread that is calling the send method then the JMS provider must call the CompletionListener's onException method. In both cases if an exception occurs it is undefined whether or not the message was successfully sent. Message order: If the same MessageProducer is used to send multiple messages then JMS message ordering requirements must be satisfied. This applies even if a combination of synchronous and asynchronous sends has been performed. The application is not required to wait for an asynchronous send to complete before sending the next message.
Close, commit or rollback: If the close method is called
on the MessageProducer or its Session or
Connection then the JMS provider must block until any incomplete
send operations have been completed and all
A CompletionListener callback method must not call close on its own Connection, Session or MessageProducer or call commit or rollback on its own Session. Doing so will cause the close, commit or rollback to throw an IllegalStateException.
Restrictions on usage in Java EE This method must not be used in a
Java EE EJB or web container. Doing so may cause a Message headers JMS defines a number of message header fields and message properties which must be set by the "JMS provider on send". If the send is asynchronous these fields and properties may be accessed on the sending client only after the CompletionListener has been invoked. If the CompletionListener's onException method is called then the state of these message header fields and properties is undefined. Restrictions on threading: Applications that perform an asynchronous send must confirm to the threading restrictions defined in JMS. This means that the session may be used by only one thread at a time. Setting a CompletionListener does not cause the session to be dedicated to the thread of control which calls the CompletionListener. The application thread may therefore continue to use the session after performing an asynchronous send. However the CompletionListener's callback methods must not use the session if an application thread might be using the session at the same time.
Use of the CompletionListener by the JMS provider: A
session will only invoke one CompletionListener callback method
at a time. For a given MessageProducer, callbacks (both
Restrictions on the use of the Message object: Applications which perform an asynchronous send must take account of the restriction that a Message object is designed to be accessed by one logical thread of control at a time and does not support concurrent use. After the send method has returned, the application must not attempt to read the headers, properties or body of the Message object until the CompletionListener's onCompletion or onException method has been called. This is because the JMS provider may be modifying the Message object in another thread during this time. The JMS provider may throw an JMSException if the application attempts to access or modify the Message object after the send method has returned and before the CompletionListener has been invoked. If the JMS provider does not throw an exception then the behaviour is undefined.
| |
| setDeliveryDelay | back to summary |
|---|---|
| public void setDeliveryDelay(long deliveryDelay) throws JMSException Sets the minimum length of time in milliseconds that must elapse after a message is sent before the JMS provider may deliver the message to a consumer. For transacted sends, this time starts when the client sends the message, not when the transaction is committed. deliveryDelay is set to zero by default.
| |
| setDeliveryMode | back to summary |
|---|---|
| public void setDeliveryMode(int deliveryMode) throws JMSException Sets the producer's default delivery mode.
Delivery mode is set to
| |
| setDisableMessageID | back to summary |
|---|---|
| public void setDisableMessageID(boolean value) throws JMSException Specify whether message IDs may be disabled.
Since message IDs take some effort to create and increase a message's
size, some JMS providers may be able to optimise message overhead if they
are given a hint that the message ID is not used by an application. By
calling this method, a JMS application enables this potential optimisation for all
messages sent using this Message IDs are enabled by default.
| |
| setDisableMessageTimestamp | back to summary |
|---|---|
| public void setDisableMessageTimestamp(boolean value) throws JMSException Specify whether message timestamps may be disabled.
Since timestamps take some effort to create and increase a message's
size, some JMS providers may be able to optimise message overhead if they
are given a hint that the timestamp is not used by an application. By
calling this method, a JMS application enables this potential optimisation for
all messages sent using this Message timestamps are enabled by default.
| |
| setPriority | back to summary |
|---|---|
| public void setPriority(int defaultPriority) throws JMSException Sets the producer's default priority. The JMS API defines ten levels of priority value, with 0 as the lowest priority and 9 as the highest. Clients should consider priorities 0-4 as gradations of normal priority and priorities 5-9 as gradations of expedited priority. Priority is set to 4 by default.
| |
| setTimeToLive | back to summary |
|---|---|
| public void setTimeToLive(long timeToLive) throws JMSException Sets the default length of time in milliseconds from its dispatch time that a produced message should be retained by the message system. Time to live is set to zero by default.
| |