Advanced Configurations Guide

Callback Brokers

Mirror Brokers


Callback Brokers

When an OpenMOM client runs on the same machine as the OpenMOM broker(s) it is connected to, it's easy to notify it of message arrivals (a simple message filter plugged in the broker forwards window manager events or other alerts). When the OpenMOM broker is remote, it becomes more difficult to avoid message polling (start a local message broker and enable routes between it and the relevant brokers).

To skip route creation and to make things transparent, special OpenMOM brokers can be started on client machines to avoid polling through the network. Such a broker is called a callback broker. Message arrivals on remote brokers trigger the push of notification messages (called callback messages) on the callback broker.
When such a notification arrives on a callback broker, standard callback reflexes are triggered to alert client applications.
However, even if the client application doesn't handle callbacks (it polls), a callback broker is useful. The client won't have to poll for pending messages through the network, but only poll on the local callback broker. Receipt of a callback message involves getting the originator message through the network, which is done transparently.

Starting a callback broker :

A callback broker must run with fixed properties:

Name : REcallback
Role : -2
Protocol : TCP/IP
Configuration file : REcallback.cnf

The callback broker must be started before any client applications.

It can be started manually (using RE_ServerWin.exe or, for a console version, RE_Server.exe)
Example : <install dir>\xiomom\bin\RE_ServerWin.exe -s REcallback -r -2 -p ncacn_ip_tcp -c <install dir>\xiomom\files\REcallback.cnf

It can be started automatically by setting an environment variable:
set REAUTOCB=1
A console version of the broker is then started at the same time as the first client application; It has to be stopped manually when required (Shutdown operation from an OpenMOM explorer or Ctrl-C within the broker's console).

To enable communications between message brokers and callback brokers:

If a callback broker runs on a client host, every implied remote message broker has to run with a particular registration reflex (function REenableCallbacks in RE_LocalService.dll), and has to be started with the TCP/IP protocol (or with a set of protocols including it). The REenableCallbacks reflex can be added to any broker, even if its clients don't use callback brokers.

The broker configuration file %REROOT%\xiomom\files\CBdefault.cnf declares such a reflex.

Example : <install dir>\xiomom\bin\RE_ServerWin.exe -s <server name> -r <server role> -p ncacn_ip_tcp -c <install dir>\xiomom\files\CBdefault.cnf

 

 


Mirror Brokers

Mirror brokers can be used for fault-tolerance purposes.
Your own mirroring facilities can be used by way of OpenMOM message broker reflexes (for example one can plug a message filter which sends copies of incoming messages to another message broker and a message delivery filter, which deletes these copies when needed. By configuring client hosts' servers list, client applications automatically reconnect to the mirror broker when the master fails).

OpenMOM is shipped with predefined mirroring facilities. This mirroring is based upon shared log files and so involves only persistent messages.
Mirror brokers must be started after the main message broker(s) (otherwise client applications connect them directly and they are used as "normal" message brokers). When the main message broker fails clients automatically reconnect to the mirror broker. Persistent messages are recovered from the log file(s) with no downtime for end-users.
The message broker and its mirror(s) must share (at least) one log file. The mirror broker role must be set to -1 and it must then be run with a particular registration reflex (function RE_LPconnectSvcToBkupLog dans RE_LogService.dll). This reflex is constructed to deny service connections while the main broker is active.

 

 

Mirror brokers can be mirrored too, the same way.

 

Example

In this example there are a main message broker running on Machine1 and its mirror broker running on Machine2.
The RElog2.log log file is shared by both brokers while the RElog.log file is managed only by the main one
(this implies that the log file which is not shared has to be replaced by the most recent one before restarting the
main broker).

Main Broker Configuration

Name : Broker1
Role : 1

Mirror Broker Configuration

Name : Broker1
Role : -1


Services which connect to Broker1 must use a Servers List like the following one to make sure that all services
involved reconnect to the same mirror broker :

 


Copyright © 1999 4 Tier Software