|
|
||
|
The YAMI4 message broker is a separate, natively compiled program, that can be run from its directory with a simple invocation:
$ ./yami4broker
The server accepts optionally a name of configuration file as a parameter, but if none is given then the yami4broker.cfg file is used by default.
The configuration file is a text file and defines the following properties:
listener - the listener target for the message broker,warmup - the delay time for the warmup phase in milliseconds; the warmup phase is the time at the very beginning of the broker run, when the broker accepts subscriptions, but no publications - this phase is intended to help avoiding startup hazards in some reliability-focused clustered installations,max_subscriptions - the physical size of internal routing table,max_client_queue - the max length of the message queue for any given subscription; this is the max number of matching messages that were introduced to the broker by publishers, but not yet delivered to the given subscriber - when this limit is reached, the overflow policy defines the intended behaviour of the broker,overflow_policy - the intended behaviour in the case of overflow, this might be "reject_message" to reject messages that cannot be delivered, "drop_update" for silently dropping the message for the given subscriber without breaking the matching process for other subscribers and "unsubscribe" for dropping the whole overflowing subscription (note that after the subscription is dropped by the broker due to overflow, no new messages will be delivered unless the subscriber refreshes its subscription),log.main, log.subscriptions, log.messages - flags enabling the particular logging subsystems, note that log.messages is useful for precise diagnostics, but can produce lots of log entries in heavily loaded brokers.The message broker reports its activity on standard output, according to logging flags defined in the configuration file.
In addition to the configuration options described above, the broker can have an arbitrary number of forwarding channels, which to a large extent behave like permanent subscriptions with the exception that update messages sent to the forward targets have the form of regular publish messages to facilitate broker chaining.
An example forwarding can be defined as:
forward.1.target=tcp://localhost:12346 forward.1.filter=*
In this case all messages that are delivered to this broker by means of publish commands (all, because a single wildcard tag matches everything) will be forwarded to another broker running on the same host and port 12346. Any number of forwarding channels can be set up this way with indexes that form continuous range.
One of the possible uses for forwarding channels is to set up a cascading cluster for sharing load across many brokers.
Forwarding channels ignore transmission errors and are permanently active in the broker, but they are not optimized for long-term failures. It is therefore important to accompany them with the higher-level startup routine that will ensure that all involved brokers are properly running with the possible exception of some short initial period when some brokers are not yet ready while others are already operational.
Note:
It should be noted that forward channels can form an unintended circle. There is no protection against this, so some administrative care should be taken to avoid it.