element: <BackendMax>

Value: positive integer

The <BackendMax> element gives the maximum number of simultaneous connections allowed between the verifier and the verification server. Each verifier maintains a pool of connections to its verification server. Whenever a request to verify, authenticate, discover, or enumerate is received, the application attempts to re-use an existing connection. Once such a command completes, the connection is stored in a pool of available connections.

Sometimes there are no available established connections, either because none have yet been established, or all the established connections are in use. In this case, the application adds a new connection to the pool and assigns it to the requesting command.

In order to control the load a verifier places upon the verification servers, the application imposes a limit on the maximum number of connections it will make for a verifier. This limit is stored in the <BackendMax> element. Note that, even though multiple hosts may be specified within a given verifier, it is the total number of connections across all hosts (even if some have zero connections) that count towards this maximum. When there are <BackendMax> active connections, additional requests for email address verification are enqueued until a connection becomes free. However the application will impose a time limit of 60 seconds on each verification request.

attribute: enumMax

Value: positive integer or integer percentage

The <BackendMax> element also may contain an optional enumMax attribute. The enumMax attribute limits how many of the available <BackendMax> connections can be used for enumeration. The enumMax attribute is either a positive integer no greater than <BackendMax> or an integer percentage.

Because enumeration commands receive priority in the job queue, servers that support enumerations over many connections in parallel could starve out all other requests until the enumeration completes. Enumerations can take up to ten minutes to complete for large domains. The enumMax attribute exists to prevent such starvation. Note that once an enumeration is successful, no verification servers are needed to service the typical verification request, even while a subsequent enumeration command is underway.

The following table shows the default connections for each verifier type:

For Multi verifiers, you can specify zero or one <BackendMax> element in the <Multi> element itself, and also zero or one <BackendMax> element in each sub-verifier. If there is no <BackendMax> in the Multi verifier itself, then each sub-verifier has its normal default value that can be overridden with a locally scoped <BackendMax> element.

If the Multi verifier does have a <BackendMax> element, then it becomes the default for any sub-verifier that does not contain its own <BackendMax> element. The value of the enumMax attribute uses the above defaults when unspecified and propagates down automatically when it is inherited within a Multi verifier. See Communigate Example and Multi Verifier Example 4 for examples of this usage.