These configuration files can be edited by hand, but you can also use the administration tool or the administration APIs to modify some of these files. See
Chapter 6, Using the EMS Administration Tool for more information about using the administration tool.
TOPIC=topic USER=
user PERM=
permissions
TOPIC=topic GROUP=
group PERM=
permissions
QUEUE=queue USER=
user PERM=
permissions
QUEUE=queue GROUP=
group PERM=
permissions
[destinationType:
destinationName] # mandatory -- include brackets
The destination-name can be any specific destination or a wildcard pattern to match multiple destinations.
This file defines the multicast channels over which messages published to multicast-enabled topics are broadcast. Each channel defined in this file has a unique name, and can have a different multicast address, multicast port, and property values.
address =
multicast-group-address:multicast-port
[maxrate =
size [KB|MB|GB]]
|
|
|
[multicast-channel-name] is the name that identifies this multicast channel.
Note that the square brackets [ ] DO NOT indicate that the multicast-channel-name is an option; they must be included around the name.
|
|
•
|
multicast-group-address is the multicast group IP address to which messages will be sent. The address must be between 224.0.0.0 and 239.255.255.255.
|
•
|
multicast-port is the multicast port destination to which messages will be sent. The multicast port must be between 1 and 65535.
|
For example, this will cause messages sent over the channel to be directed to the IP address 234.5.6.7 and multicast port 99:
|
|
Specifies the maximum number of hops that messages can make between the server and the multicast daemon.
The number of hops between the server and multicast daemon is one plus the number of routers between them. For example, if the server and multicast daemon are in the same subnet, then there is one hop between them. If the server and multicast daemon are separated by a router, then there are two hops between them. Therefore, a ttl value of 1 means that the multicast data will remain on the local subnet while a ttl value of 2 will allow the messages to travel through one router into the next subnet.
|
|
Specifies the channel's transmission priority when bandwidth is allocated. priority is given as a numerical ranking, where the highest priority is -5 and the lowest is 5.
|
|
Specifies the maximum rate at which messages can be transmitted over the channel. You can specify units of KB or MB.
|
|
Specifies the maximum length of time, in seconds, that the server will retain sent messages for retransmission. Messages are retransmitted when a multicast daemon detects a lost message and sends a negative acknowledgement to the EMS server.
Note that a long maxtime will increase the amount of memory used by the server. The maximum amount of memory used by a channel will be maxrate * maxtime. For example, specifying a maxrate of 10MB and a maxtime of 10 seconds may require the server to buffer 100 megabytes of data for retransmissions.
|
|
The IP address must be a multicast capable interface. On UNIX systems, you can determine whether an IP interface is multicast capable by running the ifconfig UNIX command.
When this parameter is not included, the default value is 0.0.0.0, which causes the EMS server to use the system’s default interface.
|
[
selector="msg-selector"]
Conflict can also arise because of wildcards. For example, if a client dynamically creates a durable subscriber for topic
foo.*, and an administrator later attempts to define a static durable for topic
foo.1, then the server detects this conflict and warns the administrator.
If the create durable command detects an existing dynamic durable subscription with the same topic and name, it promotes it to a static subscription, and writes a specification to the file
durables.conf.
[factory-name] # mandatory -- square brackets included
type = generic|xageneric|topic|queue|xatopic|xaqueue|
metric = connections | byte_rate
[connect_attempt_count|connect_attempt_delay|
connect_attempt_timeout|reconnect_attempt_count|
reconnect_attempt_delay|reconnect_attempt_timeout =
value]
|
|
|
|
[factory-name] is the name of the connection factory.
Note that the square brackets [ ] DO NOT indicate that the factory-name is optional; they must be included around the name.
|
|
•
|
generic: Generic connection (JMS 1.1)
|
•
|
topic: Topic connection (JMS 1.0.2b)
|
•
|
queue: Queue connection (JMS 1.0.2b)
|
•
|
xatopic: XA topic connection (JMS 1.0.2b)
|
•
|
xaqueue: XA queue connection (JMS 1.0.2b)
|
|
|
This example defines two servers (a and b), each of which has a fault-tolerant backup. The client program checks the load on the primary a server and the primary b server, and connects to the one that has the smaller load. If it cannot connect to one of the primary servers, the client attempts to connect to the secondary server. For example, if it cannot connect to b1, it connects to b2.
|
|
|
•
|
connections—Connect to the server with the fewest client connections.
|
•
|
byte_rate—Connect to the server with the lowest byte rate. Byte rate is a statistic that includes both inbound and outbound data.
|
|
|
The factory associates this client ID string with the connections that it creates. The client ID cannot exceed 255 characters in length.
|
|
A client program attempts to connect to its server (or in fault-tolerant configurations, it iterates through its URL list) until it establishes its first connection to an EMS server. This property determines the maximum number of iterations. When absent, the default is 2.
|
|
When attempting a first connection, the client sleeps for this interval (in milliseconds) between attempts to connect to its server (or in fault-tolerant configurations, iterations through its URL list). When absent, the default is 500 milliseconds.
|
|
When attempting to connect to the EMS server, you can set this connection timeout period to abort the connection attempt after a specified period of time (in milliseconds).
|
|
After losing its server connection, a client program configured with more than one server URL attempts to reconnect, iterating through its URL list until it re-establishes a connection with an EMS server. This property determines the maximum number of iterations. When absent, the default is 4.
|
|
When attempting to reconnect, the client sleeps for this interval (in milliseconds) between iterations through its URL list. When absent, the default is 500 milliseconds.
|
|
When attempting to reconnect to the EMS server, you can set this connection timeout period to abort the connection attempt after a specified period of time (in milliseconds).
|
|
This parameter determines the behavior of the EMS client but does not affect the multicast daemon. The multicast daemon must listen for the client on the same port that the client uses to connect. To change the TCP port that the multicast daemon listens on, use the -listen command line argument in the daemon. See Command Line Options for more information.
See Chapter 13, Using Multicast for information on multicast.
|
|
By default, a connection factory is always multicast-enabled if the EMS server to which it is connecting is enabled for multicast. If a client does not wish to receive messages over multicast from a multicast-enabled server, then this property can be set to disabled:
•
|
enabled—multicast is enabled in the factory.
|
•
|
disabled—multicast is disabled in the factory
|
See Chapter 13, Using Multicast for more information on multicast.
|
|
|
url = tcp://localhost:7222,tcp://server2:7222
clientID = "Sample Client ID"
ssl_verify_host = disabled
[jndi-name1,
jndi-name2, ...]
queue-name property1,
property2, ...
Only queues listed in this file or queues with names that match the queues listed in this file can be created by the applications (unless otherwise permitted by an entry in
acl.conf). For example, if queue
foo.* is listed in this file, queues
foo.bar and
foo.baz can be created by the application.
Properties of the queue are inherited by all static and dynamic queues with matching names. For example, if
test.* has the property
secure, then
test.1 and
test.foo are also secure. For information on properties that can be assigned to queues, see
Destination Properties.
[route-name] # mandatory -- square brackets included.
|
|
|
[route-name] is the name of the passive server (at the other end of the route); it also becomes the name of the route. Note that the square brackets [ ] DO NOT indicate that the route-name is an option; they must be included around the name.
|
|
|
|
The route belongs to the routing zone with this name. When absent, the default value is default_mhop_zone (this default yields backward compatibility with configurations from releases earlier than 4.0).
|
|
The zone type is either 1hop or mhop. When omitted, the default value is mhop.
The EMS server will refuse to start up if the zone type in the routes.conf file does not match the zone type already created in the $sys.meta file that holds the shared state for the primary and backup server.
|
|
Topic selectors (for incoming_topic and outgoing_topic parameters) control the flow of topics along the route.
|
|
|
This file defines the locations, either store files, mstore, or a database, where the EMS server will store messages or metadata (if the default
$sys.meta definition is overridden). You can configure one or many stores in the
stores.conf file.
[store_name] # mandatory -- square brackets included
file_destination_defrag=
size
[processor_id =
processor id]
[processor_id =
processor-id]
[scan_iter_interval=
time msec|sec|min|hour|day]
[scan_target_interval=
time msec|sec|min|hour|day]
|
|
|
[store_name] is the name that identifies this store file configuration.
Note that the square brackets [ ] DO NOT indicate that the store_name is an option; they must be included around the name.
|
|
•
|
file — for file-based stores.
|
|
|
The filename that will be used when creating this store file. This parameter is required for both file and mstore types. For example, mystore.db.
The location for this file can be specified using absolute or relative path names. If no path separators are present, the file will be saved in the location specified by the store parameter in the tibemsd.conf file, if any is specified there.
|
|
Do not use this parameter if the default behavior provides sufficient throughput. If no processor ID is specified for a store, the store is not bound to a specific processor.
Specify the processor-id as an integer. The processor ID is numbered starting at 0 and continuing to the number of processors available, minus 1. For example, if you have four processors, the available processor IDs are 0, 1, 2, and 3.
|
|
|
Destination defrag improves store file performance by maintaining contiguous space for new messages, while improving server read performance. When persistent pending messages begin to accumulate in a queue, messages are grouped into a batch that is re-written to disk. Messages are written close together, allowing the server to read them more efficiently when later delivering the messages to consumers.
Specify size in bytes, KB, MB or GB.
The size should be set to a size that is known to be acceptable for the disk where the store points to. For instance, if it is set to 2MB, your disk must be able to write a 2MB batch efficiently.
If file_destination_defrag is zero or absent, the destination defrag feature is disabled.
|
|
|
|
This parameter preallocates disk space for the store file. Preallocation occurs when the server first creates the store file.
You can specify units of MB or GB. Zero is a special value, which specifies no minimum preallocation. Otherwise, the value specified must be greater than 4MB.
If file_truncate is set to true, the file_minimum parameter prevents the EMS server from truncating the file below the set size.
|
|
When file_truncate is true, the store file may be truncated, but not below the size set in file_minimum.
When this parameter is absent, the default is true, and the server will periodically attempt to truncate the store file.
|
|
The mode determines whether messages will be written to the store file synchronously or asynchronously. Mode is either:
•
|
async — the server stores messages in this file using asynchronous I/O calls.
|
•
|
sync — the server stores messages in this file using synchronous I/O calls.
|
|
|
|
Determines the length of time between each interval of the store scan. The EMS server begins scanning a new section of the mstore at the time interval specified here.
Specify time in units of msec, sec, min, hour or day to describe the time value as being in milliseconds, seconds, minutes, hours, or days, respectively. For example:
scan_iter_interval=100msec
|
|
Specify time in units of msec, sec, min, hour or day to describe the time value as being in milliseconds, seconds, minutes, hours, or days, respectively. For example:
scan_target_interval=12hour
|
file = /var/local/tibems/my_sync.db
file_destination_defrag=2MB
file = /var/local/tibems/mstore1.db
scan_iter_interval=100msec
scan_target_interval=12hour
This file defines the TIBCO Rendezvous certified messaging (RVCM) listeners for use by topics that export messages to a
tibrvcm transport. The server preregisters these listeners when the server starts up so that all messages (including the first message published) sent by way of the
tibrvcm transport are guaranteed. If the server does not preregister the RVCM listeners before exporting messages, the listeners are created when the first message is published, but the first message is not guaranteed.
[jndi-name1,
jndi-name2, ...]
topic-name property1,
property2, ...
Only topics listed in this file or topics with names that match the topics listed in this file can be created by the applications (unless otherwise permitted by an entry in
acl.conf). For example, if topic
foo.* is listed in this file, topics
foo.bar and
foo.baz can be created by the application.
Properties of the topic are inherited by all static and dynamic topics with matching names. For example, if
test.* has the property
secure, then
test.1 and
test.foo are also secure. For information on properties that can be assigned to topics, see
Destination Properties.
[transport_name] # mandatory -- square brackets included
type = tibrv | tibrvcm | tibss # mandatory
[topic_import_dm = TIBEMS_PERSISTENT |
[queue_import_dm = TIBEMS_PERSISTENT |
[export_headers = true | false]
[export_properties = true | false]
transport-specific-parameters
|
|
|
The name of the transport. Note that the square brackets [ ] DO NOT indicate that the transport_name is an option; they must be included around the name.
|
|
•
|
tibrv identifies TIBCO Rendezvous transport
|
•
|
tibrvcm identifies TIBCO Rendezvous Certified Messaging transport
|
•
|
tibss identifies TIBCO SmartSockets transport
|
|
|
EMS sending clients can set the JMSDeliveryMode header field for each message. However, Rendezvous clients cannot set this header. Instead, these two parameters determine the delivery modes for all topic messages and queue messages that tibemsd imports on this transport.
|
|
When true, tibemsd includes JMS header fields in exported messages.
When false, tibemsd suppresses JMS header fields in exported messages.
|
|
When true, tibemsd includes JMS properties in exported messages.
When false, tibemsd suppresses JMS properties in exported messages.
|
|
|
If type = tibrv, the extended syntax is:
[temp_destination_timeout =
seconds]
[rv_queue_policy = [TIBRVQUEUE_DISCARD_NONE |
TIBRVQUEUE_DISCARD_FIRST |
TIBRVQUEUE_DISCARD_LAST]:
max_msgs:
qty_discard]
If type = tibrvcm, the extended syntax is:
rv_tport =
name # mandatory
[ledger_file =
file-name]
[sync_ledger = true | false]
[request_old = true | false]
[explicit_config_only = true | false]
[rv_queue_policy = [TIBRVQUEUE_DISCARD_NONE |
TIBRVQUEUE_DISCARD_FIRST |
TIBRVQUEUE_DISCARD_LAST]:
max_msgs:
qty_discard]
If type = tibss, the extended syntax is:
[server_names =
single_or_list_of_servers]
[delivery_mode = best_effort | gmd_all | gmd_some | ordered]
[lb_mode = none | round_robin | weighted | sorted]
[override_lb_mode = enable | disable]
[gmd_file_delete = enable | disable]
[
import_ss_headers = none |
type_num |
all]
[preserve_gmd = always | receivers | never]
topic_import_dm = TIBEMS_RELIABLE
queue_import_dm = TIBEMS_PERSISTENT
ledger_file = ledgerFile.store
server_names = tcp:rtHost2A:5555, ssl:rtHost2B:5571
project = mfg_process_control
override_lb_mode = enable
topic_import_dm = TIBEMS_PERSISTENT
queue_import_dm = TIBEMS_PERSISTENT
rv_queue_policy = TIBRVQUEUE_DISCARD_LAST:10000:100