By using Work Managers the IFS Connect framework can achieve
thread isolation when executing native code within Connector Senders and
Readers, but also when calling BizAPIs or other operations within Service
Handlers. Furthermore Work Managers can be used for better control of
Message Driven Beans (MDBs) behavior used by the IFS Connect
framework.
IFS Connect framework is using Work Manager API, from the
commonj.work Java package, to run native code in Connector Senders
and Readers, but also BizAPIs and service handler operations, in a
separate thread. Work Managers and the associated threads are controlled by the
Middleware Server. With this concept it is possible to run a particular piece of
code in another thread while the caller is waiting for the thread execution to
be finished. It is also possible to define a maximum amount of time (work
timeout) the caller is supposed to wait for the thread to finish. If the code
executed in another thread takes too long time, for example because of it is
hanging on external resource, the caller can abandon the called code in the
other thread and continue with the flow. The other thread may finish its
execution later on or may be hanging, but the result will not be delivered to
the caller in such situation and the actual Application or Reader
Message will be marked as failed.
Work timeouts can be specified in Setup IFS Connect window located in Solution Manager / Integration / IFS Connect
You can specify the work timeout for each instance of Connector Sender or
Reader in Setup IFS Connect window. On each sender or reader instance you'll
find a parameter with name WORK_TIMEOUT that is accepting an integer value
representing work timeout in seconds. If not specified the
default value is
taken.
In Setup IFS Connect window, Servers, configuration of
J2EE_SERVER instance
you will find a grid allowing you to enter work timeouts for BizAPIs, Service
handler operations and PL/SQL methods:
Here you can enter a BizAPI name or operation/method name in the left column and
define work timeout in seconds in the right column. A list of available BizAPIs
is presented as a drop down list, but to enter an operation name not connected
to a BizAPI you have to enter the handler name and operation name on form
HandlerName:OperationName. When entering PL/SQL method name use form
Package.Method. On save the entered data is validated against
the system and if a BizAPI or operation is not found the warning will be
displayed, but the data will be saved anyway. The PL/SQL method name is not
validated. A syntactic incorrect name will however generate an error.
Note however that both validation and population of the drop down list with BizAPIs are done by connecting to the Integration cluster, which may not be reachable of different reasons when configuring timeouts.
If work timeout for a particular BizAPI, operation or PL/SQL method is not specified the default value will be taken then.
Read more about how to work with grid parameters.
If work timeout for a particular instance is not specified the default value
will be taken. The default work timeout can also be defined in the Setup IFS
Connect window, Servers, configuration of J2EE_SERVER instance. Here you will
find an integer parameter with name DEFAULT_WORK_TIMEOUT that will allow you to
specify the default timeout in seconds:
All Message Driven Beans used by the IFS Connect framework (see also Batch Processor) have corresponding Work Managers defined in the Middleware Server. By default only some of them have additional constraints defined, but it is possible to add/modify constraints to all Work Manages, if necessary.
For best performance, low latency and good throughput, all Message Driven Beans and Connect Senders involved in processing of outbound synchronous message have their Work Managers defined with additional constraints (Forwarder MDB, Invoke MDB, Connect Sender Invoke; both Main and Integration cluster).
The defined constraints are:
Fair Share Request Class with value of 100 will guarantee
the high priority of the invoke request.Minimum Thread Constraint (Forwarder 3, others 16)
allocates a pre-defined number of threads exclusively for the actual Work
Manager for the lowest possible latency. Normally the value for
Invoke MDB and Connect Sender should be the same and correspond
to the number of concurrent requests.Maximum Thread Constraint (Forwarder 16, others 64)
limits the maximum number of threads that the actual Work Manager may
request. Default is 16 if the constraint is not set.The default values should be sufficient in the most of cases, but if necessary can be changed to values more suitable for the actual installation. It is possible to enable statistics and with help from R&D organization find out the proper values of the constraints.