Am Samstag, den 29.04.2006, 13:54 -0400 schrieb Noel J. Bergman: > 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?
Nice to see that we can now config size. Nice patch :-) > > 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. I see no problems by dropping java 1.3 support. 1.4 is the last stable release if anyone want run james should at least upgrade to this . > 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] > >
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
