Miscellaneous non-critical issues may occur while the Handler is being executed. The Handler will handle such issues on its own; thus, no special handling is required. However, sometimes it's reasonable to be notified about such events. For this reason, the Handler exposes the WarningListener interface and the Handler::registerWarningListener member to subscribe to and handle warnings.
Once an instance of WarningListener is assigned to the Handler, it invokes the WarningListener::onWarning member each time a warning occurs. The WarningListener::onWarning member has two input parameters: the warning code (identifier) and a human-readable explanation or description of the warning.
The KnownWarnings type contains constants and descriptions for the warnings that may occur while processing market data from the Multicast Price Feed.
PacketQueueOverflow Signals that one of the Handler's internal packet queues is full and the oldest packets are being discarded to make room (the log reads "Number of enqueued packets exceeded configured limit"). The Handler buffers incoming packets in these queues only while snapshot recovery is in progress - that is, when the Handler enters snapshot recovery (at startup, or after a sequence gap), both the live and the snapshot feed switch to queue mode. The snapshot feed leaves queue mode once the first live message is received, while the live feed stays queued until resynchronization finishes. In steady live operation (no recovery in progress) the queues are not used and this warning cannot occur.
During a recovery window the warning therefore fires when the volume of packets arriving in that window exceeds the queue limit. Two factors drive this, and they compound: a spike in incoming packet volume (the usual trigger for an otherwise well-sized queue) and a long recovery window (the longer recovery takes, the more live packets accumulate while it runs). Note that there are two independent queues - the live queue and the snapshot queue - and either can overflow and raise this same warning.
The queue limits are configured via maximumSizeOfLiveMessageQueue and maximumSizeOfSnapshotMessageQueue inside SnapshotRecoveryOptions. Both default to 300, a conservative baseline that is well suited to conformance testing and quiet, low-volume markets. For production use on active markets you should size these queues explicitly: scale them up by one or more orders of magnitude - tens to hundreds of thousands of packets is a realistic range for busy markets. If the warning persists at a given value, increase it by another order of magnitude and observe whether the overflow stops. A value that is comfortable early in the trading day may be insufficient mid-session, when both packet rates and the chance of activity-driven recovery are higher.
When multiple processes on the same host subscribe to the same multicast group, CPU scheduling between them can also contribute: a process that is briefly starved of CPU drains its queue more slowly during recovery and can overflow it, while peers on the same group - scheduled normally - do not raise the warning.
