Pool

Description

The pool configuration provides a way to tune the setting used to setup the connection pooling associated with various for other configuration items. For example a Data Source and ArcGIS Server Map Engine.

The pool tag itself is not used as a top level configuration item but is instead embedded within other tags.

...

• maxActive controls the maximum number of objects that can be borrowed from the pool at one time. When non-positive, there is no limit to the number of objects that may be active at one time. When maxActive is exceeded, the pool is said to be exhausted. If 'whenExhaustedAction' is 'grow' this value is not used.
• maxIdle controls the maximum number of objects that can sit idle in the pool at any time. When negative, there is no limit to the number of objects that may be idle at one time.
• whenExhaustedAction specifies the behavior when the pool is exhausted:
  • When whenExhaustedAction is 'fail', pool will throw an Exception.
  • When whenExhaustedAction is 'grow', pool will create a new object and return it(, essentially making maxActive meaningless.)
  • When whenExhaustedAction is 'block', pool will block (invoke Object. wait until a new or idle object is available. If a  If a positive maxWait value is supplied, the pool will block for at most that many milliseconds, after which an Exception will be thrown. If maxWait is non-positive, the server method will block indefinitely. You should always set a positive maxWait value if you use 'block'.
• When testOnBorrow is set, the pool will attempt to validate each object before it is returned from the pool. Objects that fail to validate will be dropped from the pool, and a different object will be borrowed.
• When testOnReturn is set, the pool will attempt to validate each object before it is returned to the pool. Objects that fail to validate will be dropped from the pool.
  Optionally, one may configure the pool to examine and possibly evict objects as they sit idle in the pool. This is performed by an "idle object eviction" thread, which runs asychronously. The idle object eviction thread may be configured using the following attributes:
• timeBetweenEvictionRunsMillis indicates how long the eviction thread should sleep before "runs" of examining idle objects. When non-positive, no eviction thread will be launched.
• minEvictableIdleTimeMillis specifies the minimum amount of time that an object may sit idle in the pool before it is eligible for eviction due to idle time. When non-positive, no object will be dropped from the pool due to idle time alone.
• testWhileIdle indicates whether or not idle objects should be validated. Objects that fail to validate will be dropped from the pool.
• maxAgeMillis is only available for ArcGIS map engine pools and specifies how log Weave should keep and connection to the server open for, it should be less than the "The maximum time a client can use a service" setting in ArcGIS Server. ArcGIS Server Settings - Pooling and Processes

When Weave makes a request to map engine or database it needs to establish a connection to the resource and creating a connection each time Weave needs to make an interaction with the resource will cause a delay and use additional memory as the number of connections increases, to mitigate this Weave uses an object ‘pool’ where each request shares a pre-allocated connection object with other requests.

Using a pre-allocated collection of resource connections provides two benefits to Weave, firstly it means that the overhead of creating a new connection on each request is removed, resulting in better response times for the user.

And, secondly, it means that Weave can use less resources on the backend server by limiting the total number of connections that can be allocated at once, so for example if 50 requests are being processed at the same time then without connection pooling Weave would need to create 50 connections to the backend resource, but with a connection pool that's limited to a maximum of 10 connections then only 10 connections will be created to the backend service. The downside of this is that user requests will have to wait until a connection becomes available in the pool before it can proceed.

Determining the correct setting for a connection pool is not something that can be easily done without knowledge about how the backend service is configured and possibly other information about the general IT infrastructure.

Namespace

urn:com.cohga.server.pool#1.0

Tags

pool

Properties

Sub-tags

None

Content

None

Examples

<pool:pool>
        <maxActive>16</maxActive><minIdle>4</minIdle>
        <maxWait>1000</maxWait>
   <maxIdle>8</maxIdle>
    <testOnBorrow>true</testOnBorrow>
   
    <testOnReturn>false</testOnReturn>
        <testWhileIdle>false<<testWhileIdle>true</testWhileIdle>
   
    <timeBetweenEvictionRunsMillis>60000</timeBetweenEvictionRunsMillis>
    <minEvictableIdleTimeMillis>300000</minEvictableIdleTimeMillis>
    <whenExhaustedAction>grow</whenExhaustedAction>
</pool:pool>