Error Message: "Too many notify clients for user ..."

The clients (GUI, monitors, and -wl or nc wait) that are listening to the Accelerator vovserver's event stream are called "notify clients" and they take two file descriptors on the vovserver.

To prevent accidental or malicious denial-of-service attacks, the vovserver limits the number of regular and notify clients. The default for notify clients is 40, and it is controlled by a config(maxNotifyClients) in vnc.swd/policy.tcl.

# In policy.tcl
set config(maxNotifyClients) 100; ## Increase from default 40.

As with all configuration parameters, it is also possible to change this parameter on the fly with:

# Example of changing a parameter from the command line.
% vovsh -x 'vtk_server_config maxNotifyClients 100'

Reaching the limit of notify clients usually indicates that jobs are being submitted incorrectly. For example, you may have a user that submits a blocking job (that is, one the uses the option -wl or the option -w) and then puts that blocking job in the background. The waiting for the job to complete is done by tapping the event stream and therefore uses a NOTIFY client. If this is done in a script with tens or hundreds of jobs, then each one uses a NOTIFY client and the user may hit the limit.

Ask the user how he/she is submitting jobs and review the submission line. If the submission uses options -wl, -w or -Ir, evaluate whether that is really necessary. There may be more efficient ways to submit many jobs and then to wait for them to complete, for example using sets (see nc run -set SETNAME ...) and then waiting for the whole set with nc wait -set SETNAME.

Examples

Look at this submission:

% nc run -Ir ls -R &

The option -Ir implies waiting for the job to complete, so that we can show all I/O on the submission side, which normally requires tapping the event stream, while the final ampersand & implies "do not wait" (ls -R is just an example of a command ). If this is done for many jobs, you may exceed the maximum number of NOTIFY clients.

The recommended alternative would be to submit all jobs as non-interactive jobs and then wait for them:

% nc run -set MyUniqueSetName ls -R
% nc run -set MyUniqueSetName ls -R
...
% nc wait -set MyUniqueSetName

Debugging Tip

A useful method to debug the submission of jobs is to use the VOV_DEBUG_ORIGARGS environment variable. This will put a property named ORIGARGS on each job that will contain the submit command. Do not use this function unless it is needed, however, since it will cause the server to consume some extra amount of RAM with higher workloads.