Brian,

Thanks for your response.  I didn't spot code to eliminate TTL 0 records
when I did my first pass looking at the code.  If I get some time, I'll look
again.

We could modify the code to use the result from cache.addMessage.  When the
code was updated from dnsjava 1.2.3 to dnsjava 1.3.2, I don't believe that
Serge noticed the change in cache handling.

If we could use your code directly, that would be even better.  That way we
would not have to maintain the DNS lookup code.  The problem is supporting
logging.  Our DNSServer.rawDNSLookup method, is pretty closely derived from
the Lookup.lookup() method, and dns.lookup() before that, adapted for our
logging needs.

http://cvs.apache.org/viewcvs/jakarta-james/src/java/org/apache/james/dnsser
ver/DNSServer.java

Do you have a suggestion as to how we can address the logging situation?  We
can't use JDK 1.4 logging: there is no implementable interface, just a
heavyweight logging object.  However, we could easily use the Jakarta
Commons Logging log interface:

http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/Log
.html

        --- Noel

-----Original Message-----
From: Brian Wellington [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2003 12:34
To: Noel J. Bergman
Cc: James Users List
Subject: RE: DNS problem?


On Thu, 12 Jun 2003, Noel J. Bergman wrote:

> Brian (on the BCC list),
>
> Would you care to comment on this?  The code in James appears to be
> essentially the same as your Lookup method, except for adaptations.
>
> The claim is that the algorithm checks the cache, finds nothing, does a
> lookup, puts the record into the cache, and then queries the cache.  But
> since TTL is 0, the cache wouldn't have the record.
>
> >From what I see in the Cache.Element code, the cache should be valid for
the
> second within which the value is cached.  Of course, if that happens at
the
> trailing edge, then the value will be missing, but then the process should
> repeat, and should be valid.

If the element was added to the cache, it would be valid for the remainder
of the second.  However, there's code to avoid putting 0 TTL elements in
the cache, for the reason mentioned by Jeff - records with 0 TTL should
not be cached at all.

> Jeff, you should turn on DEBUG in environment.xml to see what gets logged.
> Jeff, also to answer your question, the reason why the cache is used is
that
> the result of a lookup is a Message.  The dnsjava Cache class has the code
> for handling the set of records in that Message.  The lookup code doesn't
> replicate that code.  It leverages the cache to do the work.

Is there some reason you're not using the Lookup class?  If you're not
able to (and it's not easily fixable in a future version of dnsjava), I'd
recommend using the same logic, where it uses the result of
cache.addMessage instead of looking up the cache entry again; it was
explicitly added to work with the 0 TTL case (as well as being a lot
faster, since it avoided a cache lookup).

Brian


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to