DEL TRIBUNAL DE CONCILIACION Y ARBITRAJE Y DEL PROCEDIMIENTO ANTE EL MISMO

You can manage JMS triggers and the amount of resources they consume by changing the  state of a JMS trigger. A JMS trigger can have one of the following states:

Using the Integration Server Administrator, you can:

Enable, disable, or suspend all JMS triggers.

Enable, disable, or suspend specific JMS triggers.

You might want to change the state of all JMS triggers at once as a quick way of freeing up  server resources. This can be especially helpful in a situation in which Integration Server  is functioning under heavy load and additional resources are needed immediately.

You might want to change the state for a specific JMS trigger in the following situations:

When a back‐end system needs maintenance or is becoming unresponsive, you might  want to suspend JMS triggers that interact with the back‐end system. When the back‐

end system becomes available, you can enable the JMS triggers. 

After suspending or disabling all JMS triggers, you might enable specific JMS triggers. 

For example, if the server is functioning under an unusually heavy load, you might  first suspend all JMS triggers and then gradually enable JMS triggers, starting with  the JMS triggers involved in key processes. 

Trigger State Description

Enabled The JMS trigger is running and connected to the JMS provider. 

Integration Server retrieves and processes messages for the JMS  trigger. 

Disabled The JMS trigger is stopped. Integration Server neither retrieves nor  processes messages for the JMS trigger.

Suspended The JMS trigger is running and connected to the JMS provider. 

Integration Server has stopped message retrieval, but continues  processing any messages it has already retrieved.

After Integration Server suspends a serial JMS trigger automatically because a fatal  error occurred during message processing. For information about configuring a JMS  trigger for fatal error handling, see “Handling Fatal Errors for Non‐Transacted JMS  Triggers” on page 65.

The following procedure explains how to use Integration Server Administrator to change  the state of all or individual JMS triggers.

1 Open the Integration Server Administrator if it is not already open.

2 In the Settings menu of the Navigation panel, click Messaging.

3 Click JMS Trigger Management.

4 If you want to change the state of all JMS triggers, do the following:

a Under Individual JMS Trigger Controls, in the Enabled column, click edit all.

b On the Settings > Messaging > JMS Trigger Management > Edit State screen, in the New State list, select the state that you want to apply to all JMS triggers.

5 If you want to change the state of a specific JMS trigger, do the following:

a Under Individual JMS Trigger Controls, in the row for the JMS trigger that you  want to enable, disable, or suspend, click the text in the Enabled column

b On the Settings > Messaging > JMS Trigger Management > Edit State: triggerName screen,  in the New State list, select the state that you want to apply to this JMS trigger.

6 Click Save Changes.

Notes:

If you want to disable a JMS trigger, first suspend the JMS trigger and wait for all the  processing threads complete. Then, disable the JMS trigger. You can view the number  of threads currently used by a JMS trigger on the Settings > Messaging > JMS Trigger Management screen. 

When you disable a JMS trigger, Integration Server does the following:

If the JMS trigger is waiting before making a retry attempt, Integration Server  interrupts processing for the JMS trigger.

If the JMS trigger is currently processing messages, Integration Server waits a  specified amount of time before forcing the JMS trigger to stop processing  messages. If it does not complete in the allotted time, Integration Server stops the  message consumer used to receive messages for the JMS trigger and closes the  JMS session. At this point the server thread for the JMS trigger continues to run to  completion. However, the JMS trigger will not be able to acknowledge the  To enable, disable, or suspend JMS triggers

message when processing completes. If the delivery mode of the message is set to  persistent, this can lead to duplicate messages.

The time Integration Server waits between the request to disable the JMS trigger  and forcing the trigger to stop is specified by the 

watt.server.jms.trigger.stopRequestTimeout property.

Because administered objects, like destinations, are configured outside of Integration  Server, disabling a JMS trigger has no impact on the subscription.

If a JMS trigger is processing messages at the time it is suspended, the JMS trigger will  complete processing of those messages. The JMS trigger also acknowledges the  messages to the JMS provider. 

You can use built‐in services to enable, disable, and suspend one or more triggers. For  information about the pub.trigger:disableJMSTriggers, pub.trigger:enableJMSTriggers, and  pub.trigger:suspendJMSTriggers services, see the webMethods Integration Server Built‐In  Services Reference.

Introduction . . . 110 watt.server.jms . . . 110

Introduction

This appendix contains a description of the JMS‐related parameters you can specify in the  server configuration file (server.cnf), which is located in the 

IntegrationServer_directory\config directory. Typically you will use the Settings > Extended screen from the Integration Server Administrator to update this file, but there might be  times when you need to edit the file directly using a text editor. If you edit the file directly,  you should first shut down the Integration Server before updating the file. After you make  the changes, restart the server.

The server uses default values for many of the parameters. If a parameter has a default, it  is listed with the description of the parameter. Many of these parameters are set as you  administer the webMethods Integration Server using the Integration Server 

Administrator.

watt.server.jms

watt.server.jms.connection.pingPeriod

Specifies how often, measured in seconds, Integration Server should ping the JMS  provider. The ping serves as a keep alive request sent to the JMS provider. The default is  300 seconds (5 minutes). 

watt.server.jms.connection.retryPeriod

Specifies the length of time, in seconds, that Integration Server waits between connection  attempts when a connection to the JMS provider or JNDI provider fails. The default is 20  seconds.

watt.server.jms.csq.batchProcessingSize

Specifies the maximum number of messages Integration Server retrieves from the client  side queue and then sends to the JMS provider. Integration Server places sent messages in  the client side queue when the connection to the JMS provider fails. Integration Server  begins to drain the client side queue after the connection to the JMS provider becomes  available. The default is 25.

watt.server.jms.debugTrace

Enables an extra level of verbose logging for JMS triggers that can be controlled globally  or at the individual JMS trigger level. 

Important! You must restart Integration Server for the new value to take effect.

Important! You must restart Integration Server for the new value to take effect.

Important! You must restart Integration Server for the new value to take effect.

To enable debugTrace logging for all JMS triggers, set the watt.server.jms.debugTrace 

watt.server.jms.trigger.monitoringInterval

does not work with all adapters. If you are working with an adapter, such as the SAP  adapter, that requires the session ID to be unique, set this property to false. The default is  false. 

watt.server.jms.trigger.stopRequestTimeout

Specifies the maximum amount of time, measured in seconds that Integration Server  waits after a JMS trigger is disabled before forcing the JMS trigger to stop processing  messages. The default is 3 seconds. 

You can disable a JMS trigger by invoking the pub.trigger:disableJMSTrigger service or by using  or via the Settings > Messaging > JMS Trigger Management screens in Integration Server  Administrator. For more information about disabling JMS triggers, see “Enabling,  Disabling, and Suspending JMS Triggers” on page 106.

When you save a JMS trigger in Developer, Integration Serverstops and then restarts the  trigger. In this situation, Integration Server waits 3 seconds before forcing the JMS trigger  to stop processing messages. This value cannot be configured. 

watt.server.jms.wmjms.lms.readTimeout

Specifies the amount of time (measured in milliseconds) that Integration Server waits for  the next portion of an input stream before throwing WmReadTimeoutException. The read  timeout only applies after Integration Server retrieves the initial piece of the input stream. 

The default is 30000 milliseconds.

Important! You must restart Integration Server for the new value to take effect.

Important! You must restart Integration Server for the new value to take effect.

Overview . . . 116 Service Requirements . . . 116

Overview

A resource monitoring service is a service that you create to check the availability of  resources used by a trigger. Integration Server schedules a system task to execute a  resource monitoring service after it suspends a trigger. Specifically, Integration Server  suspends a trigger and invokes the associated resource monitoring service when one of  the following occurs:

During exactly‐once processing, the document resolver service ends because of an  ISRuntimeException and the 

watt.server.trigger.preprocess.suspendAndRetryOnError property is set to  true (the default).

A retry failure occurs for a non‐transacted trigger and the configured retry behavior is  suspend and retry later. 

A transient error occurs for a transacted JMS trigger and the configured behavior  when transaction roll back occurs is to suspend the JMS trigger and recover the  message 

The same resource monitoring service can be used for multiple triggers. When the service  indicates that resources are available, Integration Server resumes all the triggers that use  the resource monitoring service.