Showing results for 
Search instead for 
Did you mean: 

meaning of 'Disconnecting due to queue limit exceeded' in Prognosis error log / wvlog


meaning of 'Disconnecting due to queue limit exceeded' in Prognosis error log / wvlog

What causes the 'Disconnecting due to queue limit exceeded' message that is logged by IRNETRTR when the GUI disconnects from the server?

The GUI is disconnected from the server and subsequently reconnected. The following error is logged to the wvlog on the server when this occurs:
2001-06-04 16:58:42 S-05162072 msgmgrp 05484 IRNETRTR 7.04.03 000302 - Disconnecting due to queue limit exceeded IRGUI#303 at Node \NAME limit is 10 MB.

where \NAME is the name of the machine on which the disconnected GUI is running.
The IRNETRTR process imposes a limit on the amount of memory which can be consumed by any single queue to a GUI.

The limit prevents a GUI from consuming all available IRNETRTR memory. This can occur, for example, when a GUI is connected over a slow dial-up link, and the rate of data being requested is more than the rate at which data can be transported across the connection, or in circumstances where the GUI is connected to the server over a high-speed link, but the amount of data being requested is so high that it cannot be passed over the connection at the same rate at which it is being requested. Should the limit be exceeded, the IRNETRTR will disconnect from the GUI.

The default limit for the queue to each GUI is 10 MB. This can be increased or decreased by adding the following section to the NETRTR ini file (on Unix and NT, irnetrtr.ini, or, on NSK, IRNETRTI )

where 'n' indicates the limit in megabytes. Values less than 2 MB, or greater than the maximum memory of the NETRTR less 7 MB, will be adjusted accordingly. The IRNETRTR process will need to be restarted once this change is made for the setting to take effect. As IRNETRTR is critical to the operation of PROGNOSIS this can most easily be done by restarting PROGNOSIS service as a whole.

This error and scenario can occur in one of two ways - either recurring, or as a 'one-off'. If the situation occurs as a one-off then it is likely that transient conditions are what caused the problem, such as higher traffic on the network or some extra data being requested for a short time. Under these circumstances, the error can be ignored, or the limit can be changed as described above to prevent a reoccurence. However, if the problem is occurring on an on-going or recurring basis then there is a more fundamental issue of excessive data being requested. Under these circumstances, increasing the GUI queue limit will serve only to delay the symptoms, and will not solve the underlying problem. Instead the data being requested should be reviewed to tune the request - that is, more stringent where clauses can be used to restrict the data being requested, or refresh rates can be increased so that the data is being delivered less often. A combination of these actions should reduce the amount of data that needs to be passed across the link between the GUI and the server, and thus prevent the queuing of data, and the subsequent disconnection. Note that the PVIEWS record (and packaged PROGNOSIS Traffic displays) can be used to identify requests that cause high data volumes.