In Websphere Mq Plugin v8.6.0, new feature  Activity Pooling is included on Browse, Get, Inquire, Publish, Put, and RequestReply activities. 
 

Information regarding new feature Activity Pooling added in Websphere MQ plugin v8.6.0.

Activity Pooling feature allows the activity to pool all the MQ resources associated with the respective activity at the process level. Use of Activity Pooling option causes pooling to be done at a higher level than merely pooling the connection. All destinations used by the activity are kept open and the connection resource specified are not pooled in the usual way even if that resource has pooling enabled. This option is used when the server to which you are connected experiences very high latency such that opening, closing, and pooling of connections cause unacceptable performance degradation.

For Activity Pooling a separate tab is added for the activities Browse, Get, Inquire, Publish, Put, and RequestReply. The Activity Pooling tab is included on Browse, Get, Inquire, Publish, Put, and RequestReply. Below are the options available in Activity Pooling tab:

1)Pool Activity: Select the Pool Activity check box to activate pooling for the client objects used by the activity. 

2)Pool Max: Determines the maximum number of connections in the pool. When this limit is reached, subsequent activities fail with the following message:
"Activity Pool is exhausted: [Timeout waiting for idle object] Either enlarge the pool, allow it to grow, or increase the blocking time."

3)Pool Max Idle:    Determines the maximum number of idle connections in the pool. When the number of unused connections reaches this number, the idle connections are disconnected and closed, freeing resources on the server. Amounts over the Max Connections value are ignored.

4)Exhausted Action:    Select one of the following options:
        a) FAIL - The activity fails immediately after the pool is exhausted.

        b) BLOCK - The activity waits for the "Pool Wait" interval before failing. If an MQ client is available before the timeout, the activity acquires it.

        c)GROW - The pool grows past its maximum parameters.

5)Pool Wait: If exhausted action is set to "BLOCK", the pool waits for the "Pool Wait" interval for an activity to become available before failing.


The primary consideration for choosing pooling parameters is the number of available connections to the queue manager. Choose values that do not create unnecessary resource consumption in the queue manager, and leave available connections for other applications (including other pooled connections and activities, remember that the application might be deployed on multiple engine instances).

****Please note that when using Activity Pooling the MQ connection used in the Activity should be unpooled connection i.e connection pooling should not be enabled in the MQ connection that is going to be used in the Activity were Activity Pooling is used. Otherwise it will throw below error:
*******************************************************************************************
<ns0:MqActivityError xmlns:ns0="http://ns.tibco.com/bw/palette/mqexception">
    <msg>500261-{ActivityName=Put, ProcessName=activitypoolingtestput.module.Process, ModuleName=ActivityPoolingTestPut.module}</msg>
    <msgCode>TIBCO-BW-PALETTE-MQ-500261: Activities using activity pool cannot use a pooled connection. Select an unpooled connection.</msgCode>
    <mqCompCode>0</mqCompCode>
    <mqReasonCode>0</mqReasonCode>
    <mqErrorCode />
</ns0:MqActivityError>
*******************************************************************************************