On May 5, 1:32pm, sbaid...@redhat.com (Stanislav Baiduzhyi) wrote:
-- Subject: Re: DNS resolution fails after resolv.conf update
| Hi Christos,
|
| On Monday 04 May 2015 21:16:40 Christos Zoulas wrote:
| > I don't think it is the job of the JDK to handle this. For example
| > many systems (like NetBSD for example) work just fine without
| > needing this, because their libc keeps track of resolv.conf changes.
|
| Normally I would agree with you, but if the OS does not provide that
| functionality for any reason we still have to provide working solution from
| java perspective.
I still maintain that it is the wrong place to fix this. The proof
to this will be the difficulty you'll have providing a portable
solution that works across a variety of OS's. Fixing it for linux
and glibc is not very hard, but you'll need to limit your solution
to that in order not to break other OS's.
| > On other systems, calling res_init() does not even work properly
| > because the getaddrinfo() call uses the re-entrant API to be thread
| > safe (res_ninit()/res_nsend() etc.).
| >
| > Additionally res_init() isn't even thread-safe (on most implementations),
| > so multiple threads calling it at the same time can corrupt the
| > resolver state.
| >
| > Fixing it the way you propose means that every application that
| > does hostname/address resolution would need to be modified in order
| > to work.
|
| Good point. I see that some patches to glibc to handle this issue are using
| lock mechanism, plus Bernd suggested to use a separate thread for this. I'll
| try implementing both of those variants and will return with another webrev.
Well, even if you are going to call res_init() periodically, you
will still have to contend with two races:
- calling getaddrinfo() from another thread while res_init() is
being called, will possibly access a partially inited _res (If
your implementation's getaddrinfo() is using _res that is).
- calling getaddrinfo() immediately after resolv.conf is updated
and before res_init() is called (will fail to find new hosts
-- the problem you are trying to solve).
It is 2015, not the 80's anymore where it was acceptable to restart
programs to have them re-read configuration files. Libc API's such
as getaddrinfo() need to be robust. It does not cost that much
after all to do a stat() to see if resolv.conf changed in libc as
opposed to having a thread in java baby-sitting it.
christos
