MDI requires lots of memory when many GPS fixes need to be transmitted

[eclipse-sailing-analytics-bot]

Field	Value
Reporter	@axeluhl
Assignee	@axeluhl
Product	Sailing Race Analytics
Component	Server
Version	unspecified
Hardware	All
OS	All
Severity	normal
Priority	P2
Created	2026-03-27T12:19:24Z
Original Bug	Bug 6227

---

TopLevelMasterData acquires all GPS fixes from the DB and materializes them in memory before starting to serialize anything.

This hinges on the assumption that the TrackedRaces are not necessarily loaded into memory ("tracked") when the MDI is requested. In other words, this also works when none of these races have been loaded into memory.

But even if we'd like to stay with this assumption and way of working, we could benefit from the fact that the response is sent as a StreamingOutput response. MasterDataResource.AbstractStreamingOutput uses standard java.io.ObjectOutputStream / Serializable for writing the content. We could benefit from this with a specialized writeObject method for the fixes collections, constructed in such a way that the MongoDB query and result iteration happens dynamically as the fixes are to be streamed into the response. This way, the complete fixes collection at no point needs to reside in memory.

[eclipse-sailing-analytics-bot]

@axeluhl commented:

Another thing is that for smartphone-tracked races we can usually know their tracking time ranges even without the races actually being loaded. If start times are inferred from start mark passings, we must have an explicit start-of-tracking marker is required in the race log. Otherwise, we have a start time in the race log, and there should be finishing/finished times, too. If not, again, an explicit end-of-tracking time should usually be expected. If those are found, we have a TimeRange we can add to a MultiTimeRange for what needs to be loaded.

Of course, as soon as one or more races have no proper end-of-tracking time point, we still end up with an open-ended loading time range, but this case should be unlikely, and it may still only affect later fixes, not earlier ones.

So we should intersect the device mapping time ranges used today to determine which fixes to serialize with those RaceLog-inferred tracking time ranges for the races from the leaderboards to be sent.