web server - Borland Technical Publications

Error Recovery
Error Recovery
That said, it is possible to deploy MDBs in more than one Partition with the Messaging
Server pushing messages to only one, switching to the other in case of failure. Most
JMS products allow queues to behave in load-balancing or fault-tolerant modes. That
is, MDB replicas can register to the same queue and the messages are distributed to
them using a load-balancing algorithm. Alternately, messages may all go to one
consumer until it fails, at which point delivery shifts to another. The connection
established to the JMS service provider from the MDB can also provide a loadbalancing
and/or fault-tolerant node. JMS service providers may provide fault-tolerance
features. For specific information on clustering and fault tolerance features, refer to
JMS Provider Pluggability.
Keep in mind that only one MDB instance in a container that subscribes to a topic will
consume any given message. This means that, for all parallel instances of an MDB to
concurrently process messages, only one of the instances will actually receive any
particular message. This frees up the other instances to process other messages that
have been sent to the topic. Note that each container that binds to a particular topic will
consume a message sent to that topic. The JMS subsystem will treat each messagedriven
bean in separate containers as a separate subscriber to that message! This
means that if the same MDB is deployed to many containers in a cluster, then each
deployment of the bean will consume a message from the topic to which it subscribes.
If this is not the behavior you desire, and you require exactly one consumption of a
message, then you should consider deploying a queue rather than a topic.
The following section deals with JMS server connection failures and setting connection
rebind attempt properties. It also covers the redelivery of messages to the JMS service
when an MDB fails to consume a message. The section on redelivery covers setting
the redeliver attempt property as well as two properties for delivering messages to a
dead queue.
Rebinding
A connection failure usually occurs after you deploy your bean, causing a need for
rebind attempt. You also receive an error if you are trying to deploy your bean and a
connection to the JMS server was never established. Whether a failure occurs post
deployment or no connection was found during deployment, the container will
transparently attempt to rebind the JMS service provider connection when you set the
rebind attempt properties. This ensures even greater fault-tolerance from an MDB
instance.
The two bean-level properties that control the number of rebind attempts made and the
time interval between attempts are:
■
■
ejb.mdb.rebindAttemptCount: this is the number of times the EJB Container tries to
re-establish a failed JMS connection for this MDB. The default value is 5 (five).
To make the container attempt to rebind infinitely you need to explicitly specify
ejb.mdb.rebindAttemptCount=0.
ejb.mdb.rebindAttemptInterval: the time in seconds between successive retry
attempts. The default value is 60.
Chapter 20: Message-Driven Beans and JMS 187