Basic Server Configuration

The JMS server is configured using a property file, which is normalled called msgsvc.properties. This file has several properties, which must be specified prior to starting the server:

msgsvc.name - This is the name of the JMS server. The name serves as a prefix to all database tables used by the server. If multiple servers share the same database, the name must be different to avoid corrupting the database.
msgsvc.factory.topic - A comma separated list of additional topic connection factories. The format of each item is:
```
   name:clientID:username:password
```
The clientID, username and password entries are all optional. The topic connection factories will be bound into the topic context of the JMS server's name space.
msgsvc.xa.factory.topic - A comma separated list of additional XA topic connection factories. The format is the same as shown above. The XA topic connection factories will be bound into the topic context of the JMS server's name space.
msgsvc.factory.queue - A comma separated list of additional queue connection factories. The format is the same as shown above. The XA queue connection factories will be bound into the queue context of the JMS server's name space.
msgsvc.xa.factory.queue - A comma separated list of additional XA queue connection factories. The format is the same as shown above. The XA queue connection factories will be bound into the queue context of the JMS server's name space.
msgsvc.memory - The maximum amount of memory available for messages. When this amount of memory is exceeded, the JMS server will start to page out messages. Note that this value should be balanced against the maximum memory sizes set on destinations. Please read below for more details.
msgsvc.port - This is the TCP/IP port where the JMS server will listen for incoming IIOP requests. Only one server can use a port of each machine.
msgsvc.logdir - The log directory where the JMS server writes status and error information.
msgsvc.maxthreads - The maximum number of threads the server is allowed to allocate. If this property is not specified, the JMS server will not limit the number of threads, but instead allocated threads a needed.
msgsvc.store - The store name indicates which database to use. The JMS server supports the following names:
- "Cloudscape" for Cloudscape 3.6
- "Oracle" for Oracle 8.1.x
- "ASAnywhere" for Sybase Adaptive Server Anywhere 6.0
- "SQLServer" for Microsoft SQL Server 2000
- "DB2" for IBM DB2 Universal Database Version 7
- "Informix" for IBM Informix Dynamic Server 9
- "MySQL" for MySQL
- "File" for a file based store
- "memory" for a memory store.
Note that the JMS server does not maintain any persistent state when using a memory store.
msgsvc.jdbc.driver - This is the JDBC driver to use for accessing the persistent store.
msgsvc.jdbc.url - The URL for connecting to a database.
msgsvc.jdbc.user - The database user name. As described below, this user is also automatically a JMS administrator if security is enabled.
msgsvc.jdbc.password - The password for the database user.
msgsvc.jdbc.minpoolsize - The minimum connection pool size to use for database access. When the JMS server starts, it will allocate this number of database connections.
msgsvc.jdbc.maxpoolsize - The maximum connection pool size. Depending on the hardware on which the JMS server is running, this number has a direct effect on the performance during high volumes of persistent messages.
msgsvc.jdbc.maxmsgsize - The maximum message size that can be stored in the database. Note that this property is only used with the Sybase database to set the textsize of binary data. This property is ignored for all other databases.
msgsvc.security.enable - Whether or not to enable security. The default value is false, i.e. run without security. A secure server requires username and password to connect, and will apply access control to it destinations, as described here.

Once the msgsvc.properties file has been edited according to the environment, the tables used by JMS server must be created. This is only required the first time, or after each time the tables have been destroyed. The database is initialized using the dbinit command. The JMS server is started and shutdown using the jmqserv command.

Memory Management

The JMS server can be configured to limit the amount of memory used for messages using the msgsvc.memory. This will indirectly limit the total amount of memory used by the server process. When the maximum allowed memory has been exhausted the server will start to page out messages to the database.

While preventing the JMS server from exhausting the memory available to the Java Virtual Machine is a good goal, it is important to match the value of msgsvc.memory to the nature of the application. As an example, if an application fans out from few topic publishers to many topic subscribers, it is better to limit memory using destination properties.

Furthermore, if destinations are limited using the destination.maxUnconsumedMsgNum or destination.maxUnconsumedMsgBytes properties, the value of msgsvc.memory should typically be set to accommodate that amount of memory. This is particularly true if flow control is applied during normal operation.

If an application sends messages in large bursts, or if some destinations have message consumers that are inactive for extensive periods of time, the msgsvc.memory property can be a used to ensure that only messages that are actually in use by the server will reside in memory.