Cool, thanks for the info.agw wrote:
The program tries to read aircraft details in batches, but there is no cap on the size of the batch. It looks like your instance of VRS has so many aircraft to lookup in one go that it's exceeding some limit imposed by SQLite. I should be able to reproduce that and get it fixed in a preview.
I don't think that would cause the OOM exception though. I suspect what may be happening is that messages are coming in faster than VRS can process them. You'll be able to tell if this is the case by opening the queues window and watching for message queues that seem to keep on growing. That was the problem with OOM exceptions in 2.3.0, I had done something to slow message processing down and large feeds were putting messages into the queue faster than VRS could take them out. Version 2.3.1 addressed the slow message processing problem but did not address the problem of messages coming in faster than they can be processed. I'll have a think about that one, but I suspect the only thing that VRS can do in that situation is to start dropping messages at the head of the queue.
Regarding the messages coming in faster than VRS can handle them, I'd say dropping messages and logging some type of alert would be preferable to crashing. Here's an idea, let's say a message from a certain aircraft comes in. If the queue gets big, maybe drop all subsequent messages regarding that aircraft for the next "x" seconds? That way, aircraft that may have excessive info coming from overlapping receivers will not drown out aircraft with only occasional data from a single receiver. (am I making sense?).
Also, here is what my queues look like. The "MergedFeedListenerMessages" jumps around a lot. Between 0 - 100,000, with the peak being about 1.1 million.
What resource should I be adding to allow VRS to process more messages? Lower latency storage (i.e. SSDs) for the basestation DB? More processing threads? (or if VRS is not multi-threaded, just a higher clocked processor?)