There are special cases that can occur when producer connections are refreshed:

• Connections with a ClientID for Durable Subscribers – If your Reconnect Policy field is set to None or Producer, and a JMS Connection has a Client ID specified at the time of a network/server failure, then the Connection will not be automatically refreshed. The reason for this restriction is backward compatibility, which avoids breaking existing JMS applications that try to re-create a JMS Connection with the same connection name after a failure. If implicit failover also occurs on a network failure, then the application's creation of the connection will fail due to a duplicate ClientID.

  Note:

  For information on how a consumer connection with a ClientID behaves, see Consumer Connections with a ClientID for Durable Subscriptions.

• Closed Objects Are Not Refreshed – When the application calls javax.jms.Connection.close(), javax.jms.Session.close(), etc., that object and it descendents are not refreshed. Similarly, when the JMS client is told its Connection has been administratively destroyed, it is not refreshed.

• Connection with Registered Exception Listener – If the JMS Connection has an application ExceptionListener registered on it, that ExceptionListener's onException() callback will be invoked even if the connection is implicitly refreshed. This notifies the application code of the network disconnect event. The JMS client application code might normally call connection.close() in onException; however, if it wants to take advantage of the reconnect feature, it may choose not to call connection.close(). The registered ExceptionListener is also migrated transparently to the internally refreshed connection to listen for exceptions on the refreshed connection.

• Multiple Connections – If there are multiple JMS Connections created off the same ConnectionFactory object, each connection will behave independently of the other connections as far as the reconnect feature is concerned. Each connection will have its own connection status, its own connection retry machinery, etc.

These sections discuss special cases that can occur when Sessions are reconnected.

• Transacted Sessions With Pending Commits or Rollbacks – Operations similar to non-transacted JMS Sessions, transacted JMS sessions are automatically refreshed. However, if there were send or receive operations on a session pending a commit or rollback at the time of the network disconnect, then the first commit call after the Session refresh will fail throwing a javax.jms.TransactionRolledBackException. When a JMS session transaction spans a network refresh, the commit for that transaction cannot vouch for the operations done before the refresh as part of that transaction (from an application code perspective).

  After a session refresh, operations like send() or receive() will not throw an exception; it is only the first commit after a refresh that will throw an exception. However, the first commit after a session refresh will not throw an exception if there were no pending transactional operations in that JMS session at the time of the network disconneciont. In case of Session.commit() throwing the exception, the client application code can simply retry all the operations in the transaction again with the same (implicitly refreshed) JMS objects. The stale operations before a refresh will not be committed and will not be duplicated.

• Pending Unacknowledged Messages – If a session had unacknowledged messages prior to the session refresh, then the first WLSession.acknowledge() call after a refresh throws a weblogic.jms.common.LostServerException. This indicates that the acknowledge() call may not have removed messages from the server. As a result, the refreshed session may receive duplicate messages that were also delivered before the disconnect.

It is possible that a producer can send a message at the same time that a distributed destination member becomes unavailable. If WebLogic JMS can determine that the distributed destination member is not available, or was not available when the message was sent, the system will retry sending the message to another distributed member. If there is no way to determine if the message made it through the connection all the way to the distributed member before it went down, the system will not attempt to resend the message because doing so may create a duplicate message. In that case, WebLogic JMS will throw an exception. It is up to the application to catch that exception and decide whether or not to resend the message.

Synchronous consumers use MessageConsumer.receive(), MessageConsumer.receive(timeout), and MessageConsume.receiveNoWait() methods to consume messages. The first two methods are already expected to potentially block the application code, while the third method is not expected to block the application code. To retain these semantics, the following rules describe interaction of the reconnect feature with the synchronous consumer calls:

• MessageConsumer.receive()– If there is a network disconnection during this call, this method can block for up to Reconnect Blocking Time property (described in the configuration section) for a reconnect to go through before throwing an Exception.

• MessageConsumer.receive(timeout) – This call will block for the at-most timeout in milliseconds specified by the caller. If the Reconnect Blocking Time property is less than the timeout, then the receive will still block up to the Reconnect Blocking Time setting; if the Reconnect Blocking Time value is more than the timeout, the receive will only block up to timeout.

• MessageConsumer.receiveNoWait() – This call will not block if the JMS Connection is in the process of reconnecting. The Reconnect Blocking Time value has no effect on this call.

If these methods eventually reach their respective timeout/wait periods, they all will throw the same Exceptions. as they would reconnect. If a reconnect succeeds while these methods are blocked/called, then these methods will continue returning messages, but with a potentially lowered quality-of-service and with generally similar semantics of receiving messages (like Redelivered messages), as after a recover. The application is notified of this possibility by a Connection ExceptionListener callback with theLostServerException. In addition, for non-AUTO_ACK acknowledge modes, the first acknowledge call after a refresh will throw a LostServerException to notify the application of this possibility.

In the context of a reconnect, the behavior for asynchronous consumers will be governed by the setting on the Total Reconnect Period property. The JMS consumer's registered message listener's onMessage()method will continue to be invoked if the reconnect framework is able to successfully re-establish a connection within the Total Reconnect Period setting after a connection failure. If the user explicitly calls a close() on the JMS Connection (or on the JMS Session corresponding to the asynchronous Consumer), then the reconnect framework will not invoke any further onMessages for that Consumer. The onMessage() should expect post recover behavior (like redelivered messages) if the Connection ExceptionListener's onException is invoked with a LostServerException.

Before to WebLogic Server 9.2, consumers of distributed destinations (DDs) were pinned to a particular destination member of the DD for the life of the pinned consumer. This applies to queue consumers of distributed queues, and non-durable subscribers of distributed topics (durable subscribers are not supported distributed topics).

With MessageConsumer reconnect, DD consumers are also refreshed; however, the refreshed consumer is almost never on the same destination member as the stale consumer. Therefore, even though the application is using the same DD consumer across a refresh, it is effectively not pinned to the same destination member across a refresh.

Message-driven EJBs (MDBs) are a special sub case of asynchronous consumers that have their own behavior requirements and their own refresh framework. As such, MDBs are not expected to participate in MessageConsumer refreshes, and are not expected to be affected in any other way by the JMS client reconnect framework.

Durable subscriptions on standalone topics will not notice any difference due to the client reconnect feature if the topic is still available across a disconnect. The JMS client reconnect framework implicitly refreshes the durable subscriber on that topic and continue from where it was interrupted. Note that if your Reconnect Policy is set to All, JMS Connections with a ClientID will also refresh automatically, thus allowing durable subscriptions (which are scoped by ClientID) to refresh automatically. Connections with a ClientID set will not reconnect for any other Reconnect Policy setting.

For consumers that are non-durable subscribers of topics, though the consumption apparently continues successfully across a refresh from an application perspective, it is possible for messages to be published to the topic and dropped (e.g., for lack of consumers) while the reconnect was happening. Missed messages can occur with either synchronous or asynchronous non durable subscribers.

Due to the nature of the consumer refresh feature, there is a possibility of redelivered messages without the client application code calling recover explicitly because a consumer refresh effectively does an implicit equivalent of a recover upon a refresh. This is the main reason why implicit Consumer refresh is not on by default. The semantics of never redelivering a successfully acknowledged message still hold true.

There is also an unlikely case when non-durable subscribers of distributed topics can receive duplicate messages that are not marked redelivered (e.g., when failover happens faster than messages are discarded in topics). This is a consequence of a non-durable subscriber refresh for the distributed topic not being pinned to a topic member across a refresh.

There will be no difference in the reconnect behaviors of Consumers due to different acknowledge modes. However, the first acknowledge call after a refresh for non-AUTO_ACK modes will throw a LostServerException as described earlier to notify user of potential lowered quality of service.

Consumers will not always reconnect after a JMS server (and its destinations) is migrated to another server in a cluster. If consumers do not get migrated with the destinations, then either an exception is thrown or onException will occur to inform the application that the consumer is no longer valid. As a workaround, an application can refresh the consumer either in the exception handler or through onException.