Memory Safe Guard

Bandwidth limiting is, by its nature, very prone to leading to memory growth. Since outgoing messages are queued up to be sent out over time instead of sent as quickly as possible, the queues can grow large in size. If unchecked, this could lead to process memory exhaustion. As such, this functionality has a built in safe guard to avoid that problem.

When bandwidth is being limited, the process's private bytes are constantly being checked and compared against the configured private bytes limit specified by the server parameter, Bridge Message Bandwidth Limiter Maximum Process Private Bytes. If that limit is exceeded, the memory safeguard kicks in. The memory safeguard is designed to remove or drastically reduce the potential for memory growth caused by bandwidth limiting that can lead to dangerous memory levels and memory exhaustion. It does so by suppressing non-essential messages while the memory safeguard is active. The effort is made to allow essential/critical client activity while the memory safeguard is engaged. This basic functionality is represented by all of the high priority messages.For more information, see High Priority Messages.

While the memory safeguard is engaged, any large message that does not appear in the high priority message list is suppressed. A large message is defined as a message that is larger than the configured small message byte limit.For more information, see Configuration. For suppressed responses, the response payload is replaced with an error message explaining that Session Manager is overloaded. For suppressed notifications, a new NotificationSuppressed notification is sent to let the client know what type of notification was suppressed. When queue updates are suppressed, a QueueSuspended notification is sent so that the client will grey-out its queue views so they do not get out of sync while updates are being suppressed. Once the memory drops to a safe point below the limit, QueueUnsuspend notifications are sent to any clients that received QueueSuspend messages. Currently with this functionality, any interactions that existed before the QueueUnsuspend notification was sent will not show up and be updated in the client view. New interactions will show up correctly. In order to fix this, Session Manager would have to send a large burst of queue notifications with the full contents of all queues that were suspended. Sending those large updates could lead to bandwidth limiting getting behind or memory issues, two things that we are trying to avoid at this point.