DatabaseReader together with scheduled weekly updates about geoip2-java HOT 7 CLOSED

You need to close and reopen the DatabaseReader. Updating automatically would create thread safety issues that we would prefer to avoid.

You are right that we should mention this in the docs. I'll leave this issue open until we add that.

from geoip2-java.

Thanks -- although:

Updating automatically would create thread safety issues that we would prefer to avoid.

Were there any specific issues you think we should watch out for here? if this library doesn't handle updates then each customer will need to wrap the library to handle them, and we might run into similar thread-safety issues, so it'd be good to know.

(To be honest, if every customer will need to handle this logic and there are some tricky subtleties to it, then I feel it'd be better to handle the associated issues in one place in this library, or some supported library wrapping it. Perhaps it would be easier to implement the updates in Java too if this helps to coordinate them with the java client library?)

Another question which would be good to answer if we need to "roll our own" on this front is: how does this library behave if the underlying database file is replaced underneath it? I'd guess (hope?) that the geoipupdate tool is writing the updated db to a fresh file and then switching it in, such that the old file is unlinked but not overwritten and remains available to any processes with open file handles on it. But this would be good to confirm if true.

from geoip2-java.

Sorry while I'm at it: I'm assuming DatabaseReader is thread-safe (?) -- but would be good to clarify this in the docs.

from geoip2-java.

As mentioned in the docs, the reader is thread safe. The potential thread safety issues that I referred to is the issue of synchronizing the threads when replacing the the database inside the object. This is much better handled at the application level where, for instance, you can set the appropriate lifecycle in the IoC container. This is especially true since there is no problems with having two DatabaseReader objects, one for the old database and one for the new, in use as once.

geoipupdate creates a new file and then replaces the old file with it.

from geoip2-java.

Cheers, sorry missed that in the docs (I was just looking at the javadoc).

I'm not using anything at the application level which would particularly
help with this (dropwizard FWIW which doesn't lean heavily on IoC
frameworks), but fair enough if most people are.

On Fri, Oct 17, 2014 at 2:12 PM, Gregory Oschwald [email protected]
wrote:

As mentioned in the docs
https://github.com/maxmind/GeoIP2-java#multi-threaded-use, the reader
is thread safe. The potential thread safety issues that I referred to is
the issue of synchronizing the threads when replacing the the database
inside the object. This is much better handled at the application level
where, for instance, you can set the appropriate lifecycle in the IoC
container. This is especially true since there is no problems with having
two DatabaseReader objects, one for the old database and one for the new,
in use as once.

geoipupdate creates a new file and then replaces the old file with it.

—
Reply to this email directly or view it on GitHub
#27 (comment).

from geoip2-java.

You need to close and reopen the DatabaseReader.

Ok. I did not find this in the doc. And I need to track that DB is updated, right? Should I create an RFE for this: to let the library to do it automatically?

from geoip2-java.

You can open a ticket, but it is unlikely that we will add support for automatic reloading of the database in the near future. The reloading would likely introduce new concurrency issues and increase the complexity of both the implementation and its external behavior.

from geoip2-java.