IceFIX includes an administrative command-line tool named icefixadmin.
On this page:
Using icefixadmin
You can administer an IceFIX bridge using the icefixadmin tool. If you deploy a bridge as a standalone server, you must configure icefixadmin with a proxy for the bridge using the property IceFIXAdmin.Bridge. Alternatively, if you deploy a bridge using IceGrid, you must configure icefixadmin with the property Ice.Default.Locator, and each bridge must have an associated well-known object with the type id ::IceFIX::Bridge (see application.xml in demo/grid for an example).
icefixadmin supports the following command-line options:
$ icefixadmin -h Usage: icefixadmin [options] Options: -h, --help Show this message. -v, --version Display the Ice version. -e COMMANDS Execute COMMANDS. -d, --debug Print debug messages.
The tool operates in one of two modes, depending on the command-line arguments. If one or more -e options are specified, the tool executes the given commands and exits. Otherwise, the tool enters an interactive session.
In an interactive session, the help command displays the following usage information:
help
Print this message.
exit, quit
Exit this program.
activate [list]
Activate the specified bridges, or all by default.
deactivate [list]
Deactivate the specified bridges, or all by default.
status [list]
Report the status for the specified bridges, or all by default.
clean timeout [list]
Clean the database of all records older thantimeoutfor the specified bridges, or all by default.
testclean timeout [list]
Show the number of records older thantimeoutthat would be erased for the specified bridges, or for all bridges by default.
dbstat [list]
Report the status of the databases for the specified bridges, or all by default.
status [list]
Report the status for the specified bridges, or all by default.
clients [list]
Show the registered clients for the specified bridges, or all by default.
unregister [--force] [bridge] ID
Unregister the given client from the specified bridge, or all by default.
Most of the commands accept a [list] argument representing the names of one or more bridges; this argument is only relevant for an IceGrid deployment. Bridge names containing white space, or matching a command keyword, must be enclosed in single or double quotes. The bridge name is the same as the instance name in the IceGrid deployment.
Bridge life cycle
A bridge starts in an inactive state and does not connect to its configured FIX acceptor until it is activated via the activate command. Once activated, the bridge continues to relay and store messages until it is deactivated using the deactivate command. The current state of the bridge can be determined using the status command.
Administering bridge databases
A bridge maintains several databases containing routing records for FIX messages that it sends on behalf of its connected clients. These routing records, although small, must be erased administratively on a regular basis, such as bi-weekly, to prevent the database from becoming too large. You can examine the number of records in a bridge's databases using the dbstat command.
icefixadmin provides two commands for managing these routing records: clean and testclean. The clean command removes records that are older than a given timeout period, whereas testclean shows the number of records that would be erased for a given timeout period without actually removing those records. The timeout argument has the format [nd]hh[:mm[:ss]]. For example, the value 10 represents a timeout of 10 hours; 5d10 means 5 days, 10 hours; and 1d1:10:10 is a timeout of 1 day, 1 hour, 10 minutes and 10 seconds.
The timeout period must be large enough to guarantee that the bridge will not receive a FIX message in the future that correlates to an existing routing record. For example, if multi-day orders are sent with a one-week outstanding duration then choosing a timeout period of two days might unintentionally remove pending orders.
Administering bridge clients
Each IceFIX client has a unique persistent identity that a bridge uses to identify the client and route its messages. A client's identity can be assigned administratively, or the bridge can assign an identity during the client's installation. The identity can be any text string, as long as it is unique per client.
You can obtain the current set of registered client identities using the clients command. Once a client has been uninstalled, the client should also be unregistered from the bridge to ensure that the identity namespace is kept clean, and to prevent messages from accumulating for the now-uninstalled client. The unregister command removes a client's registration, but only if the client is not currently connected and does not have any queued messages. You can force the bridge to unregister a client by including the --force option.
