Multiple application messaging servers

In a standard mode, when dealing within messaging, one domain is configured as followed, and most of the time it is enough :

However, if you have to deal with a high number of messages, to process a maximum number of messages, you may want to create multiple domains to handle those messages.
Let’s create a new one as below : 

Then, coming back on the domain status’ page, we see that new domain :

We have to activate it to make this new domain processing messages. Change the status, and click “update” button : 


Here we go. An error is raised, we cannot have more than one master domain. And being master is set by default for a given domain.

What is that ?
A master domain can be used to balance ingoing/outgoing messages between master and slave(s) domains. Particularly useful when dealing a very high number of messages in a short time.

We can handle it in two ways.

1. Static slave
In the configuration file appsrv.cfg, we can change a parameter value – Domain Slave Mode – from 0 to 1 to make the domain a slave domain.
Change from default value

To 

Reload the application server domain, and coming back to the domain status’ page to make it active :

 
After updating the status, we can see the domain APPDOM2 activated and also that’s a slave domain. It is fixed, there’s no way to change but modify the configuration file manually and reload again the domain.
Without any failover set, it is probably the easiest way to achieve the goal : handle a high number of messages, you could make multiple slaves domains all managed by one and only master domain.
Using multiple slaves domains can also be useful, you could set a load balance in between all of them (click on “Master/Slave LoadBalance”) to configure all the priorities, such as following :


2. Dynamic slave
An other way for handling a high number of messages and multiple domains would be to make slave domain dynamic. It is maybe a little bit more tricky, but also probably more reliable and scalable.
A dynamic slave domain can become a master domain in case of failure of the current master domain. Really nice features if the messages have to be processed asap or with a minimum of down-time.
So, we return back to the original domain status’ page, the second domain APPDOM2 is inactive (it is not set as static slave in the configuration file):

Click on “SetUp Failover”, then check “enable Failover”, define a failover time (when the slave domain has to become master after original master failure, here 5 minutes) and most importantly check “Dynamic Slave Option”. Finally set a failover priority (1, 2, 3…) and save :

It makes that second domain defined as dynamic slave as shown above in the failover setting as well as below in the domain status page :

From now, we have two domains which proceed with the messages, given the fact that if the first one fails, the second will become the master.
Just to show it, here I stopped the first domain APPDOM, once the failover time is off (as shown earlier, 5 minutes), we can see the second domain APPDOM2 becoming master (it is not “dynamic slave” anymore), and the first obviously becoming inactive :
 
When the first domain APPDOM is restarted, it becomes the slave domain whereas the second domain APPDOM2 remains the master.



Making choice between static and dynamic slave domain may not be an easy task, it depends of your all architecture and requirements you have in messages processing. The first might be useful on not so big environment whereas the second is more than recommended on big environments (you don’t want to make dynamic domain on non-messages dedicated domain).

Enjoy,

Nicolas.

Find out more on OTN hosted Peoplebooks : http://download.oracle.com/docs/cd/E24150_01/pt851h2/eng/psbooks/tiba/book.htm?File=tiba/htm/tiba13.htm