Serge Knystautas wrote: > On 4/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > dsnjava 2.0.1 currently caches up to 50000 records for each > DNS type. <<snipped>> > > On the InetAddress side, I see that dnsjava is an SPI for > dns lookups. > > Adding "sun.net.spi.nameservice.provider.1=dns,dnsjava" we > would make > > all the dns calls to use dnsjava the way we configured it. > > > > Should we use the spi approach or try to propagate the > > DNSServer.staticMethods usage we currenlty use sometimes?? > > I thought we had already gone the spi approach, or at least had > considered it at one point. I thought there was some issue with > different results, but I don't remember any specifics.
It isn't clear from a quick search of http://www.dnsjava.org, but I believe that the spi capability was added in v2. We first switched when it was at v1. Shame really, as we now have explicit dependencies on the dnsjava packages and have added some workarounds in parts to accomodate the specifics of dnsjava's behaviour. It would be good to revert to the SPI approach for V3, but for V2 its too late and too hard to gauge how many workarounds would need to be undone. > In terms of caching, is there a way we can make this configurable, > i.e., how does the dnsjava Cache get instantiated? Is it static, or > is there a singleton we create somewhere to handle this? If we > instantiate the singleton in the DNSServer, we could expose the cache > impl or limitations from the dnsserver conf block. I wonder how the > spi would instantiate it. If we want specific issues with dnsjava fixing, such as a hardcoded cache size, we could discuss it with them, maybe even offer a patch. They seem responsive. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]