transporter.props Configuration
The transporter.props file contains general Transporter configuration properties. transporter.props, if specified, is located under the config directory relative to the Transporter install location.
If you used the defaults to install the Transporter on a Windows machine where the TA and Client Manager are installed, the properties file can be found here:
Example: C:\Program Files\TIDAL\Transporter\config
The configuration options which are controlled through transporter.props are as follows:
|
Transporter Properties |
Description |
Default |
|---|---|---|
|
JAVA_HOME |
The location of the Java driver. |
C:\Program Files\Java\jre7 |
|
UseUnixId |
Specifies whether to execute Unix id command to gather user information. The Transporter uses context information unique to the login user to encrypt sensitive data so no one else can comprise its secrecy. By default, this user information is gathered using javax.security.auth.login.LoginContext API. If the runtime platform is a Unix system and, for any reason, it does not fully support this API, you can set this property to true and the Transporter will gather user information by the id command instead. |
False |
|
Logging Properties Valid options are SEVERE, WARNING, FINE, FINER, and FINEST where SEVERE is the least granular (only logging the most severe incidents) while FINEST is the most comprehensive. |
||
|
TransporterLog |
Used to control logging of general categories including non-job transports. |
FINE |
|
TransporterJobLog |
Used to control logging of job transport operations. |
FINE |
|
TransporterDataLog |
Used to control logging of data related operations. |
FINE |
|
TransporterUILog |
Used to control logging of general UI operations. |
FINE |
|
File Maintenance Properties |
||
|
MaxLogFiles |
Used to control the number of Transporter log files retained. |
50 |
|
MaxSessionFiles |
Used to control the number of Transporter session files retained. |
50 |
|
Timeout Properties |
||
|
CONNECT_TIMEOUT |
Used to specify a timeout in milliseconds; in this example, a time of 20 sec has been defined. |
20000 |
|
READ_TIMEOUT |
Used to specify a read timeout in milliseconds. |
20000 |
|
Security Property |
||
|
Truststore |
This is used to specify the fully-qualified path of the SSL trust store file to be used if you wish to connect Transporter to an SSL enabled Client Manager(s). A truststore file is a key database file that contains the public keys for target servers. Example: c:\\temp\\mytruststores\\demo-truststore Note that the use of escaped backslashes for windows directories. If this configuration option is not specified, you will be unable to define a secured during the process of defining files. See Creating Definitions. There are various tools that allow you to generate keys and certificates and among them is the Java Keytool program that comes with the Java JRE installation. All keystore entries (key and trusted certificate entries) are accessed via unique aliases. An alias is specified when you add an entity to the keystore using the -genkey command to generate a key pair (public and private key) or the -import command to add a certificate or certificate chain to the list of trusted certificates. Subsequent keytool commands must use this same alias to refer to the entity. When connecting to multiple Client Manager servers configured for SSL, your trust store must contain entries for each Client Manager server you intent to connect to via HTTPS. You can use the alias to refer to each of these servers. See your Java Keytool documentation for specific details. |
None |
|
TrustStorePassword |
TrustStorePassword is mandatory for storetype PKCS12 and optional for JKS. For example, TrustStorePassword=OBF: obfuscatepassword. Note: It is necessary to append OBF: before the Obfuscated password, otherwise TA considers the password as plain password. To obfuscate password, refer Obfuscating Passwords for SSL. |
None |
|
Performance Properties These configurations are available in order to provide improved performance for unfiltered job reads. Multiple options have been provided for flexibility and the option to be configured may require some tuning based on specific user environments. For tuning purpose, it is best to run Transporter in debug mode with an open console so that you can view how the reads are performing. Note: Only one parameter, READJOBS_PAGINATED, READJOBS_BATCHES, or READJOBS_ALL should be set to “true” at a time. Parameter READ_BATCHES applies to READJOBS_PAGINATED or READJOBS_BATCHES. If none of these parameters is set, the default configuration is READ_BATCHES=500, READJOBS_BATCHES=true. |
||
|
READJOBS_PAGINATED |
Configures Client Manager to return job data in pages of READ_BATCHES batches. Example: READ_BATCHES=1000 and READJOBS_PAGINATED=true tells Client Manager to return job data in batches of 1000. This approach reduces the overhead on Client Manager as data is sent in smaller batches, as opposed to the entire job data in one request. Increasing the READ_BATCHES will reduce the number of requests sent to Client Manager, since the jobs are returned in larger batches. Note: This approach may have less benefit given many jobs (i.e. 50K or more). The batching is done at the Client Manager level. |
None |
|
READJOBS_BATCHES |
Reads jobs given a range of job id’s, where the range is specified via READ_BATCHES. If you have 50K job records with job IDs starting at 1 and ending at 50,000, and you have set READ_BATCHES=1000 and READJOBS_BATCHES=true, requests will be sent to Client Manager to query job records, in ranges as follows, until no more records are returned.
Note: This approach appears to be more beneficial when there are many job records, for example, 50,000 or more. |
None |
|
READJOBS_ALL |
This reads all jobs given the first and last job id. The result is that all jobs will be read in a single request. This approach is different from the job.getList call in that while they return all jobs, this request adds a query condition to the request, which seems to produce better performance. However, because all records are returned in a single request, Client Manager will need to process all the records for return to Transporter. If there are many job records, the overhead on Client Manager may be to high. |
None |
|
XPORTER_DEBUG |
Specify YES to run the Transporter in debug mode. Run the Transporter using the transporter.cmd script located in bin. |
None |
|
Kerberos Properties |
||
|
security.kerberos.krbpath |
Specifies the location of the krb5.ini file. The customer can provide their own path in which the files are located. |
C:\\Program Files\\Tidal\\ Transporter\\ config\\krb5.i ni |
|
security.kerberos.confpath |
Specifies the location of the spnego.conf file. The customer can provide their own path in which the files are located. |
C:\\Program Files\\Tidal\\ Transporter \\config\\spn ego.conf |
|
security.kerberos.keytabpa th |
Specifies the location of the keytab file. The customer can provide their own path in which the files are located. |
C:\\Program Files\\Tidal\\ Client Transporter \\config\\cliu ser.keyab |
|
security.kerberos.debug |
Logging flags. |
False |
|
security.kerberos.kinittime rdelay |
Specifies the timer delay to generate the KTGT for the logged in user on Client box. |
35999000 |