SNMP: dropped message due to a full queue


We found SNMP Message Queue dropped a message due to a full queue in Prizm System Log:

09/03/06 18:25:02 WARN SYSTEM SNMP Message Queue dropped a message due to a full queue
09/03/06 18:25:11 WARN SYSTEM SNMP Message Queue dropped a message due to a full queue
09/03/06 18:25:33 WARN SYSTEM Element faield Bridge OP:rs4447_NKRSM_10.198.130.137_Home
09/03/06 18:25:33 WARN SYSTEM Bridge OP Error:SNMPIOException:, error code: 9, varbind index

The PrizmEMS mamaged about 200 APs, SMs, BHs, and CMMs, version is 2.0. Prizm server Max memory is 508 MB, Total memory is 127 MB and Free memory is 30M, poolsize=10 wihtout set to monitor prizm itself.

Does anyone who knows the issue, please help. Thanks a lot!!

Is your server being flooded with SNMP Traps?
Check your Event Log, Filter by Traps.
Or use a packet sniffer.


Thank you for the help!
There were lots of polling failure messages in the system log caused by customer offline SMs. As I am very new in Prizm, would you please provide/conduct me more details:
- How to check the server is flood with SNMP Traps?
- How to filter by Traps? or how to use a packet sniffer?

Thank you and appreciate!!


Do you know how to increase the queue size? As the PrizmEMS managed about 200 devices, do you think we need increase queue size? Thank you

i have the same problem.
how can i increase the queue size?

You can increase the queue size by modifying /config/snmplib.xml and increasing the maxTrapQueueSize field. But this may only increase the threshold before you see the warning.

You may want to find out why you are seeing a flood of traps. Look at your Prizm Event Logs (From the Gui, Select Events-> Open a View-> New, then set up a criteria to show Source = SNMP Trap , for last 10 minutes or so). This will tell you what traps have been logged).

In general, Prizm uses traps only as triggers for resynchronizing with network elements (out of cycle polling). So, loss of them is not critical to the operation of the EMS (This is because traps by nature are not guranteed to reach the EMS since they are sent as UDP packets with no acknowledgement of reception or resend)