dr0i
commented
6 years ago The problem goes further than just a sometimes not-expiring cache: the data is checked after a new daily-data-update, and if the checked data was cached <24h before that update a lookup will always produce the old data. Thus a check must fail. Now it would be nice to configure the cache to expire at a given date (say 04:30 when the updates are supposed to be done (read "suppose" as "not really predictable)). Or even better make the cache resetable with an http-API-call.
A simple workaround, since we have a load balancer and two API-daemons, is to restart the API just after the data was updated. I will go with this since also possible memory leaks are workarounded with this and since this is easy to setup (installing monit on weywot[45] and configuring emphytos).
The script which checks if the daily updates are ETLed incorrectly told us often that the resources weren't up-to-date for a lookup via browser showed that everything was updated. The cause is #356 (different cache-keys for the two different ways of getting a json document (the script uses curl without an
format-parameter)) in conjunction with an obviously problem with the Cache: the cached object was as old as the play-instance (around 2 weeks), while the expiraton-date is set to one day. Could prove that by using the web app on the other server and by restarting the web app (which made the resource up-to-date in all cases).. I couldn't find an obvious bug in the java code, though.