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 · Accepted solution]

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

[BenSaunders1]

Hey RJ,

Thanks so much for the response - it does indeed help.

Our issue is we have a feed that has tracks that just simply disappear when no longer alive - never to be seen again. So we are looking for ways to pick up on their absence from the feed so we may remove them from our database. While the Track Gap Detector does that, it was our fear that tracks would simply accumulate.

We have come up with another solution in the meantime, so hopefully later this week I will start another thread, or dare I say make a blog post, describing our solution and looking for any feedback.

In the meantime though, thanks again for taking the time to research that!

Ben

[BenSaunders1]

OK, so it didn't happen that week. But the deed is done - I blogged about our solution.

So please read through it and feel free to give back ideas or any feedback for that matter. Hopefully it makes sense...

Ben