Environment variables

Tools
Tools covers the tools and utilities you use to work with Teradata and its supporting ecosystem. You'll find information on everything from the Teradata Eclipse plug-in to load/extract tools.
Teradata Employee

Environment variables

All of the following environment variables are managed within the Administration UI .  These variables are stored persistently in the "TERAJMS_VARIABLES" table.  This table will reside in the default database specified in the default DataSource.  This table does not need to be created manually.

Manage Environment Variables

  • Off the main screen of the Administration UI  click on [Environmental Variables]. 
  • This will bring up a screen of all the current environment variables. 
  • From here you can click on either the [View] or [Edit] link next to the Environment Variable.

Application

Version [view only]

Variable Name: version

Type: java.lang.String

Description: Version information of Teradata JMS Universal Connector.

Application Log

Variable Name: loggerLevel

Type: java.lang.String

Default: INFO

Valid values: {DEBUG, INFO, WARN, ERROR}

Description: Log level across all logging within JMS Universal Connector. Valid values in ascending order of strictness are: DEBUG, INFO, WARN, and ERROR.

Error File Path

Variable Name: errorFilePath

Type: java.lang.String

Default: null

Description: The file system directory to store the invalid message when the [Rollback invalid format message to Queue/Topic = false]. One file is generated for each invalid message which contains the whole jms message with error reasons. The file name can be traced at the Error log View of Display Service function. Default: null

Maximum Retries

Variable Name: maxRetries

Type: java.lang.Integer

Default: 10

Valid values: {1 - 1000}

Description: Maximum number of system errors allowed. When a service reaches the maximum number of system errors allowed, the service will shut down. System errors do not include data related errors. All services must be restarted for modification to take effect.

Note: maxRetries count is calculated per service – if service encountered 2 errors and each error is caused by same or different reason, current error count for the service is 2. Also, if one message had a problem and is rolled back to the source queue when maxRetries is set to 10, the service will continue until it reaches maxRetries=10, then the service will be stopped.


Note: Exception Destination in WebSphere

  • When you create a queue or topic in WebSphere, "System" is selected with Maximum failed deliveries=5 by default in Exception Destination in Service Integration > Buses > [your_bus_name] > Destinations > [your_queue_or_topic_name].
  • You will see 3 options with "None", "System", "Specify"  in the "Exception destination". This option determines where a message will be routed to by the JMS provider when the message is rolled back by the JMS Universal Connector.

Note: Redelivery Limit in WebLogic

  • When you create a queue or topic in WebLogic, "Redelivery Limit=-1" will be set by default in Home > JMS Modules > [your_jms_module_name] > [your_ queue_or_topic_name] > Delivery Failure.
  • Redelivery Limit: The number of redelivery tries a message can have before it is moved to the error destination. This setting overrides any redelivery limit set by the message sender. If the redelivery limit is configured, but no error destination is configured, then persistent and non-persistent messages are simply dropped (deleted) when they reach their redelivery limit.
  • Error Destination: The name of the target error destination for messages that have expired or reached their redelivery limit. If no error destination is configured, then such messages are simply dropped. If a message has expired or reached its redelivery limit, and the Expiration Policy is set to Redirect, then the message is moved to the specified Error Destination.

Note: NetWeaver

  • There is no set-up required for exception destination for NetWeaver.
  • By default, NetWeaver behaves as "None" in WebSphere or "Redelivery limit=-1" in WebLogic

Note: ActiveMQ

  • There is no set-up required for exception destination for ActiveMQ.
  • Please refer to deadLetterStrategy in ActiveMQ
  • By default, ActiveMQ behaves as "None" in WebSphere or "Redelivery Limit=-1" in WebLogic

Note: IBM WebSphere MQ

  • There is no set-up required for exception destination for IBM WebSphere MQ.
  • By default, IBM WebSphere MQ behaves as "None" in WebSphere or "Redelivery Limit=-1" in WebLogic

Loader

Use Properties

Variable Name: useProperties

Type: java.lang.Boolean

Default: true

Valid values: {true, false}

Description: When set to true the service properties are controlled from the saved properties. When set to false it enables a service to start without having any saved properties - instead properties are defined at runtime via JMS message properties.

Receive Timeout

Variable Name: receiveTimeout

Type: java.lang.Integer

Default: 10

Valid values: {1 - 600}

Description: Maximum number of seconds the Loader will wait on a JMS Queue or Topic. If the maximum number of seconds is reached and the Queue or Topic is still empty, the Loader will stop waiting on the JMS Queue or Topic in order to process outstanding work before attempting to wait on the JMS Queue or Topic. All loader services must be restarted for modification to take effect.

Extractor

Query Timout

Variable Name: queryTimeout

Type: java.lang.Integer

Default: 10

Valid values: {1 - 600}

Description: Maximum number of seconds the Router will wait on the Queue Table for more data. If the maximum number of seconds is reached and the Queue Table is still empty, the Router will stop waiting on the Queue Table in order to process outstanding work before attempting to wait on the Queue Table. All router services must be restarted for modification to take effect.