Re-usable Destination Objects Reconnected Connection Objects

Recovering from a Server Failure 14-3

14.1.2.1 Sample Producer Code

In the event of a network failure, the WebLogic JMS client code for message production will attempt to reconnect to an available server during Steps 3-8 shown in Example 14–1 . Example 14–1 Sample JMS Client Code for Message Production set exception listener 1. public void onExceptionjavax.jms.JMSException jsme { connection.setExceptionListener handle the exception, which may require checking for duplicates or sending the message again } 2. Context ctx = create WebLogic JNDI context with credentials etc. 3. ConnectionFactory cf = ctx.lookupJNDI name of connection factory 4. Destination dest = ctx.lookupJNDI name of destination the following operations recover from network failures 5. Connection con = cf.createConnection 6. Session sess = con.createSessionno transactions, ack mode 7. MessageProducer prod = sess.createProducerdest 8. Loop over: 9. Message msg = sess.createMessage try block to handle destination availablitiy scenarios 10. try { prod.sendmsg} catch Some Destination Availability Exception e { handle the exception, in most cases, the destination or member is not yet available, so the code should try to resend } end loop done sending messages 11. con.close; ctx.close; The JMS producer will transparently failover to another server instance, if one is available. This keeps the client code as simple as listed above and eliminates the need for client code for retrying across network failures. The WebLogic JMS does not reconnect MessageConsumers by default. For this to automatically occur programmatically, your client application code must call the WebLogic WLConnection extension, with the setReconnectPolicy set to all, as explained in Section 14.1.3, Configuring Automatic Failover for JMS Consumers.

14.1.2.2 Re-usable ConnectionFactory Objects

A ConnectionFactory object looked up via JNDI see Step 1 in Example 14–1 and Example 14–2 is re-usable after a server or network failure without requiring a re-lookup. A network failure could be between the JMS client JVM and the remote WebLogic Server instance it is connected to as part of the JNDI lookup, or between the JMS client JVM and any remote WebLogic Server instance in the same cluster where the JMS client subsequently connects.

14.1.2.3 Re-usable Destination Objects

A Destination object queue or topic looked up via JNDI see Step 2 in Example 14–1 and Example 14–2 is re-usable after a server or network failure without requiring another lookup. The same principle applies to producers that send to a distributed 14-4 Programming JMS for Oracle WebLogic Server destinations, since the client looks up the distributed destination in JNDI, and not the unavailable distributed member. A network failure could be between the client JVM and the WebLogic Server instance it is connected to, or between that WebLogic Server instance and the WebLogic Server instance that actually hosts the destination. The Destination object will also be robust after restarting the WebLogic Server instance hosting the destination.

14.1.2.4 Reconnected Connection Objects

The JMS Connection object is used to map one-to-one to a physical network connection between the client JVM and a remote WebLogic Server instance. With the JMS client reconnect feature, the JMS Connection object that the client gets from the ConnectionFactory.createConnection method see Step 3 in Example 14–1 and Example 14–2 maps in a one-to-one-at-a-time fashion to the physical network connection. One consequence is that while the JMS client continues to use the same Connection object, it could be actually communicating with a different WebLogic Server instance after an implicit failover. If there is a network disconnect and a subsequent implicit refresh of the connection, all objects derived from the connection such as javax.jms.Session and javax.jms.MessageProducer objects are also implicitly refreshed. During the refresh, any synchronous operation on the connection or its derived objects that go to the server such as producer.send or connection.createSession, may block for a period of time before giving up on the connection refresh. This time is configured using the Administration Console or the setReconnectBlockingMillislong API in the weblogic.jms.extension.WLConnection interface. The reconnect feature keeps trying to reconnect to the WebLogic Server instances ConnectionFactory object in the background until the application calls connection.close. The ReconnectBlockingMillis parameter is the time-out for a synchronous caller trying to use the connection when the connection in being retried in the background. If a synchronous call does time out without seeing a refreshed connection, it then behaves in exactly the same way that is, throws the same Exceptions as without the implicit reconnect that is, it will behave as if it was called on a stale connection without the reconnect feature. The caller can then decide to simply retry the synchronous call with a potentially lower quality of service, like duplicate messages, or decide to call connection.close, which will terminate the background retries for that connection.

14.1.2.4.1 Special Cases for Reconnected Connections 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 networkserver 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 Note: For information on how consumers of distributed destinations behave with automatic JMS client reconnect, see Section 14.1.3.4.1, Consumers of Distributed Destinations. Recovering from a Server Failure 14-5 failure, then the applications creation of the connection will fail due to a duplicate ClientID. ■ 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 ExceptionListeners 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.

14.1.2.5 Reconnected Session Objects