matteobaccan/owner

Accessing properties file on an unreachable host returns default values, doesn't raise exceptions

Closed this issue · 5 comments

gvnnn commented

While trying to replicate a network/infrastructure problem, i've come across this behaviour: trying to access a property on a remote file server (e.g. a SMB/CIFS share) that is unreachable or doesn't exist (host is down or DNS name does not resolve to a valid IP address), properties for which a default value is set are returned, while null is returned for every other.

Is this intentional? If so, is there a way to disable such behaviour?

Hi @gualican,

First of all, thanks for using OWNER.

The intended behaviour in OWNER is that, if one configuration file disappears (it gets deleted, or the connection is lost with the remote drive) the configuration is reloaded as if that file is missing: so other configuration files apply (see loading strategies) or default values are returned.

I understand that sharing drives can be helpful to distribute the same configuration over multiple instances, but having that relying on network shares is possibly not the best solution. I suggest you to have a scheduled task (cron or something) to copy the files from the network drive to the local drive periodically. Or, better, using some versioning like git or svn to pull the changes from a remote drive into a local drive. This would exclude the problem of disappearing configuration resources, and also benefit from the versioning.

Let me know. Have a nice day.

Luigi

There are also a couple of tests that verify the behaviour of OWNER when the configuration file becomes unavailable (in the test case, they get deleted)

See:

https://github.com/lviggiano/owner/blob/master/owner/src/test/java/org/aeonbits/owner/reload/AsyncAutoReloadTest.java

https://github.com/lviggiano/owner/blob/master/owner/src/test/java/org/aeonbits/owner/reload/SyncAutoReloadTest.java

So, yes, this is the intended behaviour.

To solve your problem, I would store the configuration files in a local git repository in each application, that periodically (or on demand) fetch the configuration from a central storage.

I would not use remote shared folders for application resources whatsoever exactly for the issue you are facing: I would in fact expect this kind of problems to arise.

If you don't have additional question I would close this issue.

Thanks.

gvnnn commented

Thank you for your feedback.
I agree with you, keeping the network share as a mirror and periodically pulling properties files locally seems to be a better solution.
I think this approach is particularly well suited for CI/CD so that the process of pulling and placing properties files may be OS agnostic as opposed to rely on OS-specific software like cron and its counterparts.
Since you've cleared any doubts about this particular use-case I'm closing the issue.

Thanks.

One side effect of this, is that you can use OWNER to check if a network drive is reachable 😁

gvnnn commented

Given how much time I have to wait for the operations team to add the Icinga checks I ask I might even consider using Owner instead 😂