traccar
LBS location cache
When a device is out of GPS range (e.g. in a garage) it will send LBS location. Traccar will query the external service (Google API) to locate it with every packet, which is inefficient and can be costful.
This PR adds a simple ehcache-based cache of LBS locations.
Closes #3790
@tananaev Is there any cache? After ~2-3 weeks of just one device sitting in my home (without GPS), sending location updates every 3 minutes, I got a bill for ~$30 for google location services. This is just a quick in-memory cache for devices that are missing GPS signals but are still regularly sending LBS/wifi updates.
So, you have changed the code without noticing that there is already an in-memory cache available?
Sorry, it's available for geocoding, but I don't think we should use entirely different solution for geolocation.
I wanted to have a quick working solution before the bill from Google ruins me :) I have very little experience with Java, so I looked for as out-of-the-box'ish solution to the problem as possible and ehcache seemed to fit perfectly. The solution used for geocoding might not work here, as there's no garbage collection and no timeouts - we need to eventually get rid of old entries, and LBS data changes over time. An insert-only map would be a possible memory leak here (while it might not be a problem in most real-life cases, it definitely could be a surface attack to DoS the server - by sending a bunch of random LBS/wifi only messages).
OK, now I see it. That still doesn't solve the 'old data' problem though, unless we'd add a manual 'timeout' field, and that'd complicate it even further. For me, the ehcache solution seems cleaner for this case.
