Track Gap Processor cache limit

BenSaunders1

Is there a limit to the cached tracks in the Track Gap Processor? In other words, what is the fate of a track that never shows up again? Do tracks pile up, or is there an expiration process behind the scenes that weeds things out? Or is there a hard ceiling and that's that?

I can come up with more speculative questions, but hopefully this is a good start...!

Thanks!

RJSunderman

Hello Ben -

Thanks for the question. There is no hard-coded limit or expiry rule for the number of track identifiers a Track Gap Processor will cache. Perhaps there should be. As you suggest, a track identifier that is at some point received will remain in the processor's cache consuming system resources even if that track identifier will never reasonably be seen again.

I asked one of the developers for a code review and tested what he told me to verify. It appears that the Track Gap Processor not only caches the identifier for every TRACK_ID it encounters, it also spawns a thread and associates the thread with the cached TRACK_ID.

So, at the 10.3 / 10.3.1 release, you can expect  that a GeoEvent Service which incorporates a Track Gap Detector will remember every TRACK_ID it encounters and the number of threads associated with the JVM's java.exe process will increase until a system resource is exhausted -- unless you alter the GeoEvent Service and publish your changes (or cycle the GeoEvent Windows Service).

Spawning so many threads strikes me as unnecessary and we will probably change the threading model in the future to not spawn so many threads. You likely would not notice, however, unless you were monitoring that particular system resource.

If you encounter any problems with the 10.3 / 10.3.1 release, please submit a product enhancement request with Esri Technical Support. That will help ensure that an issue is logged against the product for the development team to address.

Hope this information helps -

RJ