Adapter Thread Pools - Removed!

Overview

In Worklight 6.2 and earlier, the server uses designated thread pools to enforce timeouts and manage concurrency in adapter procedure invocation. This was achieved by running the backend invocation on a different thread, and controlling the run time of that thread. The number of available threads is actually the concurrency of backend invocation. These thread-pools, while helping to control the timeout and concurrency of backend calls, create several problems:

  • WAS container security and monitoring can't be used, as it's incompatible with non-container-managed thread-pools
  • Standard server-managed thread-pools configuration has no effect over the backend invocation concurrency
  • The backend call does not adhere to the procedure timeout, and when the procedure times out the server might still wait for the backend
  • Threads are valuable resources on a container, and each adapter uses two of them simultaneously

To remedy the above problems, in IBM MobileFirst Platform 6.3 the use of designated thread-pools in adapters was removed. Now all backend invocations run on the original HTTP request thread.

Timeout and Concurrency Changes

As a result of not using a thread to manage the timeout and concurrency, the ability to define a server side timeout on the overall execution of a procedure is now no longer supported. Instead, timeouts and concurrency are now enforced using the underlying back-end connection mechanisms in HTTP-based adapters (HTTP, SAP and Cast-Iron adapters). If such a timeout is needed it can be enforced on the client side by changing the default timeout (30 sec) in the call to WL.Client.invokeProcedure.

In fact, the roles of the timeouts are now more distinct and well defined. The client side timeout makes sure the client request returns in a reasonable time, and server side timeouts protect against slow or misbehaving back-end systems.

For HTTP, SAP, and Cast-Iron adapters, timeout and concurrency configuration is enforced by the HTTP framework. Instead of a single timeout on the entire procedure execution, the adapter support the standard HTTP timeouts: connection timeout (time until connection is established) and socket timeout (time between two consecutive packets). The maximum concurrent connections setting is still applicable for these types of adapters, though it is specified in a different way (see below).

For SQL and JMS adapters both concurrency and timeout settings may no longer be specified in the adapter xml. For SQL adapters, these values may be set by configuring the SQL connection pool using a JNDI reference.

XML Structure Changes

As a result of the changes mentioned above, the structure of the adapter xml file has changed:

  • The 'procedure' element no longer has the 'requestTimeoutInSeconds' attribute.
  • The 'loadConstraints' element was removed completely.
  • For HTTP, SAP, and Cast-Iron adapters, there are 3 new elements under the 'connectionPolicy' element. These elements are: 'connectionTimeoutInMilliseconds', 'socketTimeoutInMilliseconds', and 'maxConcurrentConnectionsPerNode'.

Note: timeouts are now specified in milliseconds instead of seconds.

Take a look at the following old and and new adapter XMLs and notice the changes in the HTTP connection policy:

Old Adapter XML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<wl:adapter name="HttpAdapter"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:wl="http://www.worklight.com/integration"
	xmlns:http="http://www.worklight.com/integration/http"></p>
<displayName>HttpAdapter</displayName>
	<description>HttpAdapter</description>
	<connectivity>
		<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
			<protocol>http</protocol>
			<domain>rss.cnn.com</domain>
			<port>80</port>
			<!-- Following properties used by adapter's key manager for choosing specific certificate from key store
			<sslCertificateAlias></sslCertificateAlias>
			<sslCertificatePassword></sslCertificatePassword>
			-->
		</connectionPolicy>
		<loadConstraints maxConcurrentConnectionsPerNode="2" />
	</connectivity></p>
<procedure name="getStories" requestTimeoutInSeconds="30"/></p>
<procedure name="getStoriesFiltered"/></p>
</wl:adapter>

New Adapter XML

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<wl:adapter name="HttpAdapter"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:wl="http://www.ibm.com/MFP/integration"
	xmlns:http="http://www.ibm.com/MFP/integration/http">  <!-- Changes in the XML schema -->
	<displayName>HttpAdapter</displayName>
	<description>HttpAdapter</description>
	<connectivity>
		<connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
			<protocol>http</protocol>
			<domain>rss.cnn.com</domain>
			<port>80</port>
			<connectionTimeoutInMilliseconds>30000</connectionTimeoutInMilliseconds> <!-- Worklight's defaults -->
			<socketTimeoutInMilliseconds>30000</socketTimeoutInMilliseconds>
			<maxConcurrentConnectionsPerNode>50</maxConcurrentConnectionsPerNode>
			<!-- Following properties used by adapter's key manager for choosing specific certificate from key store
			<sslCertificateAlias></sslCertificateAlias>
			<sslCertificatePassword></sslCertificatePassword>
			-->
		</connectionPolicy>
	</connectivity>
	<procedure name="getStories" /> <!-- No requestTimeoutInSeconds at all -->
	<procedure name="getStoriesFiltered"/>
</wl:adapter>

Specifying Timeouts per Backend Invocation

The timeout values defined in the XML file are the default values that apply to all back-end connections in all of the procedures of the adapter. When a finer control is needed for specific backend invocation, these values may be overridden in the procedure's JavaScript code. Two optional parameters were added to the invokeHTTP method, connectionTimeoutInMilliseconds and socketTimeoutInMilliseconds. Explicitly specifying these values will override the defaults set in the adapter xml.

An example of these paramteres in JavaScript:

1
2
3
4
5
6
7
8
9
10
function getStories(interest) {
    var path = getPath(interest);
    var input = {
          method: 'get',
          path: path,
          connectionTimeoutInMilliseconds: 15000,
          socketTimeoutInMilliseconds: 25000
          };
    return WL.Server.invokeHTTP(input);
}

Backwards Compatibility

Adapters from previous versions can be deployed to 6.3 server, also server that was migrated to 6.3 will continue to run already deployed adapters. However, in both cases these adapters will behave differently in regard to timeout and concurrency:

  1. Maximum concurrent connections will continue to be enforced by HTTP, SAP, and Cast-Iron adapters, and ignored by JMS and SQL adapters.
  2. Procedure timeouts will no longer be enforced. Instead, any value specified as procedure timeout will be treated as both socket and connection timeout on HTTP, SAP, and Cast-Iron adapters, and ignored by JMS and SQL adapters.

A warning message will be logged whenever an old adapter is deployed, or when a server starts and detects that one or more of the deployed adapters are old.

Conclusion

To make MobileFirst server more robust, we removed the use of thread-pools in adapters backend invocations. This removal changes the way the adapter handles timeout and concurrency: timeouts are now conforms to HTTP standard timeouts, while concurrency still applies, but only to HTTP adapters. For more information see: Adapter timeout and concurrency The element of the HTTP adapter

Last modified on May 01, 2016
Share this post: