Failure to draw in some circumstances - lost items

[johnhtodd]

https://view.quad9.net/?autoRotateGlobe=false&showCountersKey=false&startupZoom=4&startupLat=39.09&startupLon=-94.57&websocketUrl=wss%3A%2F%2Fview.quad9.net%2Fwebsocket%2F5004&showEventCountersLast5m=false&showEventCountersLast1m=false&showEventCountersLast10s=false&countersTitle=Estimated+Queries&countersLabel=Queries&popFilter=qmci2

Trying to view the data contained in this WS URL. It's a lot of events in the general stream, but I am condensing down to any that contain "qmci2" in the pop field.

It works... sometimes. The data is very bursty; this is expected due to the source. Many events will stream through quickly, and they all have draw_delay (between 15000 and 30000) set on them to smooth the drawing out over time (bursts of data that match that filter are around every 15 seconds.) I'm watching the set of data headed to the websocket via "vector tap" and I see lots of events but they are not shown on the map, ever. It seems maybe once a minute or so there is a burst of points that appear on the map, but much is lost, and this latest one that I'm looking at here has gone now for 4m without drawing anything, but there have been perhaps 8 or 10 bursts of data that match that filter (again, looking at "vector tap --inputs of ")

Is this because there is too much data in the output stream? Something wrong with "draw_delay"? (this is only the second or third time I've used it.)

[esensar]

Is it possible that we have an issue in the websocket server component?
I have tried looking at the input data with bots wscat and the GoW and they seem to be matching the intervals of when qmci2 data comes in (of course, with the draw_delay in GoW, but the event counter updates immediately).

[esensar]

@johnhtodd is this issue still valid?