14-8 Programming JMS for Oracle WebLogic Server
■
MessageConsumer.receive– If there is a network disconnect 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.receivetimeout – This call will block for the at-most timeout milliseconds specified by caller. If the Reconnect Blocking Time property
is less than timeout, the receive will still block up to the Reconnect Blocking Time setting; if the Reconnect Blocking Time value is more than 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
will have no effect on this call.
If these methods eventually reach their respective timeoutwait periods, they all will throw the same Exceptions. as without reconnect. If a reconnect succeeds while these
methods are blockedcalled, 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
LostServerException. 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.
14.1.3.3.2 Asynchronous Consumers 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 Consumers registered message listeners onMessage
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
ExceptionListeners onException is invoked with a LostServerException.
14.1.3.4 Special Cases for Reconnected Consumers
These sections discuss special cases that can occur when consumers are refreshed.
14.1.3.4.1 Consumers of Distributed Destinations Previous 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.
14.1.3.4.2 Message-Driven EJBs 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.
Recovering from a Server Failure 14-9
14.1.3.4.3 Consumer Connections with a ClientID for Durable Subscriptions 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.
14.1.3.4.4 Non-Durable Subscriptions and Possible Missed Messages 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 have been published to the topic and dropped e.g., for lack of consumers while the reconnect was happening. Such missed messages can occur with either
synchronous or asynchronous non-durable subscribers.
14.1.3.4.5 Duplicate Messages 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.
14.1.3.4.6 Variations Due to Acknowledge Modes 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.
14.1.3.4.7 Reconnecting with Migrated JMS Destinations In a Cluster 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, 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.
Note: If a JMS Connection has a ClientID specified at the time of a
networkserver failure, then reconnecting that client make take significantly longer than your other clients. For example, in a cluster
the JMS server must wait for the WebLogic Server heartbeat notification that is broadcast from other members of the cluster, as
explained in Failover and Replication in a Cluster in Using Clusters for Oracle WebLogic Server.
WebLogic JMS does not support durable subscriptions on distributed topics, so there is no issue of failover to another distributed topic
member during a refresh.
14-10 Programming JMS for Oracle WebLogic Server
14.1.4 Explicitly Disabling Automatic Failover on JMS Clients
