Collating from the entire thread ...
Serge Knystautas wrote:
> Is there anyway we can cap this cache size
Yes. Please see the patch that I just committed. Are you in a position to
test the result in-situ?
> or ideally send it to disk?
Actually, I suspect that from a performance perspective, this might be
counter-productive. Let your local DNS servers provide additional caching,
rather than get involved in disk I/O.
Stefano Bagnara wrote:
> AFAIK dnsjava should use weakreferences for its cache
Actually, not. dnsjava uses a subclass of java.util.LinkedHashMap for its
cache. Which, by the way, requires Java 1.4+, so we have dropped Java 1.3
compatibility. Not that I consider that under debate nor dispute; just
pointing it out.
Serge added:
> > - 44MB in an xbill cache held by Lookup code that is held
> > by an avalon policy class holder.
> - 87.3MB total heap used
> - 75.6MB DNS.Lookup via that policy class holder.
Ok, so this is clearly the big one. The cause is that Lookup defaults to
maintaining its own cache, which is not shared with the one that we use
internally, even though we share the same resolver. I'll fix that, which
will give us more control.
> > - 3.2MB in an xbill cache held by DNS server
> - 5.4MB DNS.Lookup via the James DNSServer
This is the one we intend to be using. The space doesn't seem all that bad,
but is just for the lookups going through DNSServer. All of the ones that
directly involved Lookup were going to a separate, unmanaged (by us) cache.
> > - 1.7MB in a cache behind java.net.InetAddress
> - 2.7MB via java.net.InetAddress
Should see where this is coming from, since we should generally use
InetAddress as little as possible, due to its naive implementation.
Stefano added:
> We could set our own caches to dnsjava and size them as we prefer.
Yes.
> We should also remove the cache done in the DNSServer: why should we add
> our own cache lookup (on dnsjava objects) when dnsjava already support
> this?
Keep in mind that we don't call Lookup in DNSServer. We call the resolver
directly. Therefore, there is no caching unless we implement it.
Steve Brewin suggested:
> 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.
Actually, I seem to recall running into some issues with the standard Java
code sticking its figurative nose where it doesn't belong, and not giving us
a clean chain down to the DNS SPI. We would have to see if that is (still)
the case. Personally, I'd prefer to stick with a dnsjava, and can agree
with Stefano that we could expose the DNSServer service and use it, rather
than call the static methods in dnsjava directly.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
