Hi

Can any body list down what are the advantages of
having muliple brokers on a single server.

-Rajesh

There are a couple of reasons why you might want to do this.

• Partitioning and segregating different processes.

It is often quite useful to give each department or business unit its own broker. In this way, each broker can be managed and updated independently of the other brokers. A failure in one broker doesn’t impact the others. The downside is that this inhibits reuse.

• Facilitating development.

Giving each developer their own broker to work on gives them a sandbox to play in where they won’t clobber other people’s work. Team development on a single broker requires some coordination to avoid losing work. Having multiple brokers avoids the need to coordinate activities on the broker (e.g. if two people are editing the same event type at the same time, the last to save will win). The trade-off is the time and effort needed to combine the work of several developers from several brokers into a single broker for production.

Anyone have any other thoughts?

To follow up on Rob’s points –

Because each broker runs as a separate program, each instance of a broker server drags on your hosting machine. In a production environment, an Enterprise Server hosting multiple “heavy loaded” broker servers must be carefully architected to protect system resources and bandwidth.

Similarly, if the design calls for 4-5 “light load” broker servers (each operating as a thread), you may find your network architecture strained as well.

There really is no best solution except to build your infrastructure while leaving yourself with plenty of room to grow. If building territories and/or gateways will help reduce the server load, then they should be built.

That said, in development environments, multiple brokers is a great way to give developers autonomy in building adapters and documents.

The disadvantages are:

1. multiple brokers will fight to write to the same datastore and
   datastore may get corrupted.
2. each broker is lot of disk io bound so performance (of system
   and of integration) may get slower

Let’s be clear about terminology:

Broker server: an instance of a broker process listening on a port. More than one broker server can be running on a single host if they listen on different ports. Broker servers do not share datastores, directories, etc. and indeed it is relatively straight-forward to do this. Each Broker Server on a box is independent.

Broker: an entity running within a broker server. More than one broker can run within a broker server. This is a common configuration. There is no danger of datastore corruption (other than the usual things that dork files–power outages, disk failures, etc.). Brokers in a broker server share the data storage. Disk IO constraints depend greatly on client queue configuration (volatile, guaranteed).

Multiple brokers is what I was referring to. Running multiple broker servers on a single host has its own set of configuration techniques and pros and cons. I know of at least one company that runs several broker servers, each with several brokers, on a single Solaris box with no problem. The bog down, IMO, is that they run all the adapters on the same box and there literally hundreds of them.

The biggest performance gain I’ve seen in the past is to move adapters off of the broker server host and onto their own box.

Of course your mileage may vary…