Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 7 Using the Configuration Files : Using Other Configuration Files

Using Other Configuration Files
In addition to the main configuration file, there are several other configuration files used for various purposes:
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.
The following sections describe the configuration files.
acl.conf
This file defines all permissions on topics and queues for all users and groups. The format of the file is:
TOPIC=topic USER=user PERM=permissions
TOPIC=topic GROUP=group PERM=permissions
QUEUE=queue USER=user PERM=permissions
QUEUE=queue GROUP=group PERM=permissions
ADMIN USER=user PERM=permissions
ADMIN GROUP=group PERM=permissions
 
Table 34 ACL Parameters
Name of the group to which you wish to add permissions. The designation all specifies a predefined group that contains all users.
The permissions which can be assigned to queues are send, receive and browse. The permissions which can be assigned to topics are publish, subscribe and durable and use_durable. The designation all specifies all possible permissions. For information about these permissions, refer to When Permissions Are Checked and Inheritance of Permissions.
Example
ADMIN USER=sys-admins PERM=all
TOPIC=foo USER=user2 PERM=publish,subscribe
TOPIC=foo GROUP=group1 PERM=subscribe
bridges.conf
This file defines bridges between destinations. See Destination Bridges for more information about destination bridges.
The format of the file is:
[destinationType:destinationName] # mandatory -- include brackets
destinationType=destinationToBridgeTo1 [selector="msg-selector"]
destinationType=destinationToBridgeTo2 [selector="msg-selector"]
...
The destination-name can be any specific destination or a wildcard pattern to match multiple destinations.
 
For detailed information about message selector syntax, see theMessage Selectors’ section in description for the Message class in TIBCO Enterprise Message Service Java API Reference.
Example
[topic:myTopic1]
topic=myTopic2
queue=myQueue1
durables.conf
This file defines static durable subscribers.
The file consists of lines with either of these formats:
topic-name durable-name
  [route]
  [clientid=id]
  [nolocal]
  [selector="msg-selector"]
 
When present, the subscriber is another server, and the durable-name is the name of that server.
selector="string"
For detailed information about message selector syntax, see theMessage Selectors’ section in description for the Message class in TIBCO Enterprise Message Service Java API Reference.
Example
topic1 dName1
topic2 dName2 clientid=myId,nolocal
topic3 dName3 selector="urgency in (’high’,’medium’)"
topic4 Paris route
Conflicting Specifications
When the server detects an conflict between durable subscribers, it maintains the earliest specification, and outputs a warning. Consider these examples:
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.
Configuration
To configure durable subscriptions in this file, we recommend using the create durable command in the tibemsadmin tool; see create durable on page 132.
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.
factories.conf
This file defines the connection factories for the internal JNDI names.
The file consists of factory definitions with this format:
[factory-name] # mandatory -- square brackets included
  type = generic|xageneric|topic|queue|xatopic|xaqueue|
  url = url-string
  metric = connections | byte_rate
  clientID = client-id
  [connect_attempt_count|connect_attempt_delay|
  connect_attempt_timeout|reconnect_attempt_count|
  reconnect_attempt_delay|reconnect_attempt_timeout = value]
  [ssl-prop = value]*
 
[factory-name]
[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
xageneric: Generic XA connection
topic: Topic connection
queue: Queue connection
xatopic: XA topic connection
xaqueue: XA queue connection
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.
Example
[north_america]
  type = topic
  url = tcp://localhost:7222,tcp://server2:7222
  clientID = "Sample Client ID"
  ssl_verify_host = disabled
Configuration
To configure connection factories in this file, we recommend using the tibemsadmin tool; see create factory on page 133.
Load Balancing
 
groups.conf
This file defines all groups. The format of the file is:
group-name1:"description"
   user-name1
   user-name2
group-name2:"description"
   user-name1
   user-name2
 
Example
administrators: "TIBCO Enterprise Message Service administrators"
   admin
   Bob
jaas.conf
This file directs the TIBCO Enterprise Message Service server to the JAAS LoginModule. See Loading the LoginModule in the EMS Server for more information about the jaas.conf file.
queues.conf
This file defines all queues. The format of the file is:
[jndi-name1, jndi-name2, ...]queue-name property1, property2, ...
Note that, while including JNDI names is optional, the square brackets [ ] must be included around JNDI names if they are included. For more information about setting JNDI names, see create jndiname on page 133.
For example, you might enter:
test store=mystore,secure,prefetch=2
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.
For further information on the inheritance of queue properties, refer to Wildcards * and > and Inheritance of Properties.
Restrictions and rules on queue names are described in Destination Name Syntax.
routes.conf
This file defines routes between this TIBCO Enterprise Message Service server and other TIBCO Enterprise Message Service servers.
Routes may only be configured administratively, using the administration tool (see Chapter 6), or the administration APIs (see com.tibco.tibjms.admin.RouteInfo in the online documentation). Directly editing the routes.conf file causes errors.
The format of the file is:
[route-name] # mandatory -- square brackets included.
  url=url-string
  zone_name=zone_name
  zone_type=zone_type
  topic_prefetch=value
  [selector]*
  [ssl-prop = value]*
 
[route-name]
[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 secondary server.
If topic_prefetch is not set, the route uses the prefetch value specified for the destination. If a topic_prefetch is set for the route and a different prefetch is set for the destination, the topic_prefetch value overrides the destination prefetch.
See the prefetch destination property for valid settings.
Topic selectors (for incoming_topic and outgoing_topic parameters) control the flow of topics along the route.
Example
[test_route_2]
url = tcp://server2:7222
ssl_verify_host = disabled
stores.conf
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.
Each store configured is either a file-based store, mstore, or a database store. File-based store and mstore parameters are described here. Database store parameters are described in Chapter 11, Using Database Stores.
The format of the file is:
[store_name] # mandatory -- square brackets included
  type=file
  file=name
  file_destination_defrag=size
  [file_crc=true|false]
  [file_minimum=value]
  [file_truncate=value]
  [mode=async|sync]
  [processor_id=processor id]
[store_name]
  type=mstore
  file=name
  [mode=async|sync]
  [mstore_truncate=value]
  [processor_id=processor-id]
  [scan_iter_interval=time msec|sec|min|hour|day]
  [scan_target_interval=time msec|sec|min|hour|day]
 
[store_name]
[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.
mstore — for mstores.
dbstore — for database stores.
The mode determines whether messages will be written to the store 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.
When absent, the default for file-based stores is async. The default mode for mstores is sync.
Specify the processor-id as an integer.
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.
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 can 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.
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:
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:
When mstore_truncate is true, the EMS server occasionally attempts to truncate the mstore files, relinquishing unused disk space. Enabling mstore_truncate may increase the fragmentation of the store files.
This feature is not available by default. Before using it, you must run the tibemsdbconvert tool with option -version 8.3 on the required mstore files.
Example
[my_sync]
  type = file
  file = /var/local/tibems/my_sync.db
  file_destination_defrag=2MB
  file_crc = true
  file_minimum = 10MB
  file_truncate = true
  mode = sync
Example
[mstore1]
  type = mstore
  file = /var/local/tibems/mstore1.db
  mode = async
  mstore_truncate = true
  scan_iter_interval=100msec
  scan_target_interval=12hour
tibrvcm.conf
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.
The format of this file is
transport listenerName subjectName
 
Example
RVCM01 listener1 foo.bar
RVCM01 listener2 foo.bar.bar
topics.conf
This file defines all topics. The format of the file is:
[jndi-name1, jndi-name2, ...]topic-name property1, property2, ...
Note that, while including JNDI names is optional, the square brackets [ ] must be included around JNDI names if they are included. For more information about setting JNDI names, see create jndiname on page 133.
For example, you might enter:
business.inventory global, import="RV01,RV02", export="RV03", maxbytes=1MB
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.
For further information on the inheritance of topic properties, refer to Wildcards * and > and Inheritance of Properties.
Restrictions and rules on topic names are described in Destination Name Syntax.
transports.conf
This file defines transports for importing messages from or exporting messages to external message services, such as TIBCO FTL, TIBCO Rendezvous, and TIBCO SmartSockets.
The format of the file is:
[transport_name] # mandatory -- square brackets included
   type = tibftl | tibrv | tibrvcm | tibss # mandatory
   [topic_import_dm = TIBEMS_PERSISTENT |
                      TIBEMS_NON_PERSISTENT |
                      TIBEMS_RELIABLE]
   [queue_import_dm = TIBEMS_PERSISTENT |
                      TIBEMS_NON_PERSISTENT |
                      TIBEMS_RELIABLE]
   [export_headers = true | false]
   [export_properties = true | false]
   transport-specific-parameters
 
[transport_name]
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.
tibftl identifies TIBCO FTL transport
tibrv identifies TIBCO Rendezvous transport
tibrvcm identifies TIBCO Rendezvous Certified Messaging transport
tibss identifies TIBCO SmartSockets transport
Each transport includes additional transport-specific-parameters.
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 absent, the default is TIBEMS_NON_PERSISTENT.
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 you have multiple TIBCO Rendezvous transports configured in your transports.conf file, and if the EMS server fails to create a transport based on the last entry, the server will continue to traverse through the entries and attempt to create further transports.
Transport-specific Parameters
tibftl transports
If type = tibftl, the extended syntax is:
   [endpoint = endpoint-name]
   [import_subscriber_name = subscriber-name]
   [import_match_string = {"fieldname1":value1,...,"fieldnameN":valueN}]
   [export_format = format-name]
   [export_constant = constant1,value1]
   ...
   [export_constant = constantN,valueN]
See TIBCO FTL Parameters for descriptions.
tibrv transports
If type = tibrv, the extended syntax is:
   [service = service]
   [network = network]
   [daemon = daemon]
   [temp_destination_timeout = seconds]
   [rv_queue_policy = [TIBRVQUEUE_DISCARD_NONE |
                    TIBRVQUEUE_DISCARD_FIRST |
                    TIBRVQUEUE_DISCARD_LAST]:max_msgs:qty_discard]
See Rendezvous Parameters for descriptions.
tibrvcm transports
If type = tibrvcm, the extended syntax is:
   rv_tport = name # mandatory
   [cm_name = name]
   [ledger_file = file-name]
   [sync_ledger = true | false]
   [request_old = true | false]
   [explicit_config_only = true | false]
   [default_ttl = seconds]
   [rv_queue_policy = [TIBRVQUEUE_DISCARD_NONE |
                    TIBRVQUEUE_DISCARD_FIRST |
                    TIBRVQUEUE_DISCARD_LAST]:max_msgs:qty_discard]
See Rendezvous Certified Messaging (RVCM) Parameters for descriptions.
tibss transports
If type = tibss, the extended syntax is:
   [username = name]
   [password = password]
   [server_names = single_or_list_of_servers]
   [project = name]
   [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]
See SmartSockets Parameters for descriptions.
Example
[FTL01]
type = tibftl
endpoint = EP1
import_subscriber_name = sub1
  import_match_string = {"f1":"foo","f2":true}
export_format = format-1
export_constant = constant1,value1
export_constant = constant2,value2
export_constant = constant3,value3
[RV01]
   type = tibrv
   topic_import_dm = TIBEMS_RELIABLE
   queue_import_dm = TIBEMS_PERSISTENT
   service = 7780
   network = lan0
   daemon = tcp:host5:7885
[RVCM01]
   type = tibrvcm
   export_headers = true
   export_properties = true
   rv_tport = RV02
   cm_name = RVCMTrans1
   ledger_file = ledgerFile.store
   sync_ledger = true
   request_old = true
   default_ttl = 600
[SS01]
   type = tibss
   server_names = tcp:rtHost2A:5555, ssl:rtHost2B:5571
   username = emsServer6
   password = myPasswd
   project = mfg_process_control
   override_lb_mode = enable
   delivery_mode = gmd_some
[RV02]
   type = tibrv
   topic_import_dm = TIBEMS_PERSISTENT
   queue_import_dm = TIBEMS_PERSISTENT
   service = 7780
   network = lan0
   daemon = tcp:host5:7885
   rv_queue_policy = TIBRVQUEUE_DISCARD_LAST:10000:100
users.conf
This file defines all users. The format of the file is:
username:password:"description"
 
Table 43 User Parameters
User passwords are not entered in this configuration file, and remain empty (and therefore not secure) until you set them using the administration tool; see Assign a Password to the Administrator. You can also create users and assign passwords using API calls; see the API reference for the language you are working with.
Example
admin::"Administrator"
Bob::"Bob Smith"
Bill::"Bill Jones"
After the server has started and passwords have been assigned, the file will look like this:
admin:$1$urmKVgq78:"Administrator"
Bob:$2$sldfkj;lsafd:"Bob Smith"
Bill:$3$tyavmwq92:"Bill Jones"

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved