|
| |
| Sun Java System Message Queue 3.5 SP1 Administration Guide | |
Appendix E
Technical NotesThis appendix contains short write-ups on the following topics:
System Clock SettingsWhen using a Message Queue system, you should be careful to synchronize system clocks and avoid setting them backward.
Synchronization Recommended
It is recommended that you synchronize the clocks on all hosts interacting with the Message Queue system. This is particularly important if you are using message expiration (TimeToLive). Failure to synchronize the hosts’ clocks may result in TimeToLive not working as expected (messages may not be delivered). You should synchronize clocks before starting any brokers.
Solaris You can issue the rdate command on a local host to synchronize with remote host. (You must be superuser--that is, root--to run this command.) For example, the following command synchronizes the local host (call it Host 2) with remote host Host1:
# rdate Host1
Linux The command is similar to Solaris, but you must provide the -s option:
# rdate -s Host1
Windows you can issue the net command with the time subcommand to synchronize your local host with a remote host. For example, the following command synchronizes the local host (call it Host 2) with remote host Host1:
net time \\Host1 /set
Avoid Setting System Clocks Backwards
You should avoid setting the system clock backwards on systems running a Message Queue broker. Message Queue uses timestamps to help identify internal objects such as transactions and durable subscriptions. If the system clock is set backwards it is theoretically possible that a duplicate internal identifier can be generated. The broker attempts to compensate for this by introducing some randomness to identifiers and by detecting clock shift when running, but if the system clock is shifted backwards by a significant amount when a broker is not running, then there is a slight risk of identifier duplication.
If you need to set the system clock backwards on a system running a broker by more than a few seconds, it is recommended that you either do it when there are no transactions or durable subscriptions, or do it when the broker is not running, then wait the amount of time you have shifted the clock before bringing the broker back up.
But the ideal approach is to synchronize clocks before starting up any brokers, and then use an appropriate technique to ensure that clocks don't drift significantly after deployment.
OS-Defined File Descriptor LimitationsOn the Solaris and Linux platforms, the shell in which the client or broker is running places a soft limit on the number of file descriptors that a client can use. In the Message Queue system, each connection a client makes, or each connection a broker accepts, uses one of these file descriptors. Each destination that has persistent messages also uses a file descriptor.
As a result, the number of connections is limited by these factors. You cannot have a broker or client running with more than 256 connections on Solaris or 1024 on Linux without changing the file descriptor limit. (The connection limit is actually lower than that due to the use of file descriptors for persistence.)
To change the file descriptor limit, see the ulimit man page. The limit needs to be changed in each shell in which a client or broker will be executing.
Securing Persistent DataThe broker uses a persistent store that can contain, among other information, message files that are being temporarily stored. Since these messages might contain proprietary information, it is recommended that the data store be secured against unauthorized access.
A broker can use either the built-in or plugged-in persistence.
Built-in Persistent Store
A broker using built-in persistence writes persistent data to a flat file data store located in a directory that depends upon the platform (see Appendix A, "Location of Message Queue Data"):
…/instances/instanceName/fs350/
where instanceName is a name identifying the broker instance.
The instanceName/filestore/ directory is created when the broker instance is started for the first time. The procedure for securing this directory depends on the operating system on which the broker is running.
Solaris and Linux The permissions on the IMQ_VARHOME/instances/instanceName/filestore/ directory depend on the umask of the user that started the broker instance. Hence, permission to start a broker instance and to read its persistent files can be restricted by appropriately setting the umask. Alternatively, an administrator (superuser) can secure persistent data by setting the permissions on the IMQ_VARHOME/instances directory to 700.
Windows The permissions on the IMQ_VARHOME/instances/instanceName/filestore/ directory can be set using the mechanisms provided by the Windows operating system that you are using. This generally involves opening a properties dialog for the directory.
Plugged-in Persistent Store
A broker using plugged-in persistence writes persistent data to a JDBC Compliant database.
For a database managed by a database server (for example, an Oracle database), it is recommended that you create a user name and password to access the Message Queue database tables (tables whose names start with “IMQ”). If the database does not allow individual tables to be protected, create a dedicated database to be used only by Message Queue brokers. See the database vendor for documentation on how to create user name/password access.
The user name and password required to open a database connection by a broker can be provided as broker configuration properties. However it is more secure to provide them as command line options when starting up the broker (see Message Queue Administration Guide, Appendix A, “Setting Up Plugged-in Persistence”).
For an embedded database that is accessed directly by the broker via the database's JDBC™ driver (for example, a Cloudscape database), security is usually provided by setting file permissions (as described in "Built-in Persistent Store," above) on the directory where the persistent data will be stored. To ensure that the database is readable and writable by both the broker and the imqdbmgr utility, however, both should be run by the same user.