This content has been marked as final. Show 4 replies
As you said,You have 2 managed servers in a cluster example 18.104.22.168:7200 and 22.214.171.124:7200
Each Managed server hosts jms server namely jms server1 and jms server2(here let jms server 1 and 2 point to migrate able targets)
So now you have created a uniform distributed queue,Target this queue to both the JMS Servers ie 1 and 2
At Coding end,It would look like below
1. I have a producer running such as java queuproducer t3::/managed_server1. I send out 4 messages. From the weblogic monitoring console I see there are 4 messages in the queu since there are no consumers to the queue yet.
2. Now I shut down managed_server1.
3. Bring up a consumer to listen on java queuconsumer t3://managed_server2. This consumer cannot consume message since the producer send all the messages to jms server1, and it is down.
4. Bring up managed server 1, start a consumer to listen to t3://managed_server1 I can get all messages.
When you shutdown managed server1, the jms server targeted to managed server 1 is not available as well (your point 3). What you can do
in this case is target the JMS Server to a migratable target and configure the migration, an example is provided here - http://middlewaremagic.com/weblogic/?p=7188
As you want to message to be processed in order, you need to do something extra here as well, for example, unit of order.
Ordered processing requires the following:
- A single consumer which processes the messages.
- Set the maximum messages per session attribute of the connection factory to 1.
- Ensure that all messaging that require ordering go to the same destination.
- Do not use custom destination ordering that change the default FIFO ordering.
- Do not set redelivery delays.
Unit-of-order is most commonly used with queues. While it can be used with topics, care must be taken when the message consumers are message-driven beans.
Message-driven beans that do not use container-managed transactions multiplex the messages from a topic subscription across multiple message-driven bean instances,
thus processing the messages in parallel. This feature is useful to speed up message processing but it does not take into account any unit-of-order. We must disable
this parallel processing to preserve the order by either using container-managed transactions or by setting max-beans-in-free-pool to 1 in the deployment override
weblogic-ejb-jar.xml. When producing unit-of-order messages to a distributed topic, we must target the distributed topic itself. Unlike other JMS messages, sending
unit-of-order messages directly to a member topic is not recommended and may cause messages to be delivered out of order. Sending the messages directly to the
distributed topic is the natural approach so this restriction should not cause any problems.
How does WebLogic know which member destination to use when multiple producers are sending messages associated with the same unit-of-order to a distributed
destination? WebLogic supports two routing mechanismsto accomplish this: path service based routing and hash-based routing.
Path service is a singleton service that runs on one server in the cluster and routes all messages associated with a particular unit-of-order to the same member destination
of the targeted distributed destination. A persistent store is used to save the state of which member destination a particular unit-of-order currently using. When a path
service receives the first message for a particular unit-of-order bound for a distributed destination, it uses the load balancing heuristics to select which member destination
will handle the unit and writes that information into the persistent store. Note that when a unit-of-order has no unconsumed messages pending, the path service entry is
removed and future messages may be sent to other member destinations.
If the path service is not configured, WebLogic uses a hash-based routing mechanism. The hash-based routing algorithm uses the unit-of-order name to determine to which
member destination the unit-of-order is associated. This means that the routing decision is made in the client based on the number of configured member destinations without
any considerations for the load balancing heuristics.
An example set-up can be found here - http://middlewaremagic.com/weblogic/?p=6334 (in the 'example' section).
Rene's information is a bit of out-of-date for all customers at 10.3.4 or later, at least with respect to the caveats about UOO and Topic MDBs, where using the new MDB "one-copy-per" modes addresses the issue. (It looks like a cut-and-paste from old documentation?) I recommend consulting the MDB Programmer's guide.
Since you have ordering requirements, yes, you very likely can make good use of unit-of-order, regardless of whether you use a distributed destination. There's a chapter on UOO in the JMS programmer's guide.
About message recovery
When a JMS server goes down, its messages will remain trapped until it's restarted (switching from a queue to a topic will not be suitable help with your use case). There are two basic options for automatically restarting a JMS server: "Whole Server Migration" and "Automatic Service Migration". The former restarts an entire WL Server either on the same machine or a different machine, and the latter restarts a JMS server on a different WL server in the same cluster. There's a white-paper on the latter here: http://www.oracle.com/technetwork/middleware/weblogic/messaging - "Automatic Service Migration (pdf)".
About full coverage of a distributed queue
A non-MDB "vanilla" consumer pins to a single distributed destination member. To ensure full coverage of consumers across a distributed destination the main options are:
(A) simply use a WebLogic MDB (highly recommended)
(B) run many consumers, and have them periodically close and reconnect
(C) setup consumers directly on each member (JNDI name will be "jms-server-name@dist-dest-jndi-name")
(D) use destination availability helper APIs to programmatically discover destination membership (advanced use case).
About WebLogic JMS in General
2 See config best practices: http://download.oracle.com/docs/cd/E17904_01/web.1111/e13738/best_practice.htm#JMSAD455
3 The book "Professional Oracle WebLogic Server" has a nice JMS chapter. It's a little out-of-date if you're on WebLogic 10.3.4 or later, particular with respect to distributed topics, but otherwise you'll probably find it to be pretty helpful. (For extensive information on topics consult both the MDB and the JMS programmer's guides.)