Noel J. Bergman wrote:
Stefano Bagnara wrote:
In the mean time I fixed the following DNSServer related bugs in Trunk
I can review the code changes, but I seem to recall that we can much
backport the entire DNSServer from trunk, so long as we preserve the static
method rather than change the deployment descriptors.
A couple of specifics:
DNSServer does not properly cache MX lookups for CNAMEd domains
https://issues.apache.org/jira/browse/JAMES-672
We should review this again, because there are rules against allowing a
CNAME as the target of an MX record.
You (probably) misunderstood the problem. I spoke about MX lookups for
CNAMEd domains and not of CNAMEs used as MX records. This is a
completely different story ;-)
Btw feel free to overview that code: 2 more eyes are always helpful.
In the issue comment I explained exactly what was the problem and what
are the iteresting rfc paragraphs. I also added a test case for this
problem, so it should be really easy to review it.
Make sure our container use an expiration for cached dns data
https://issues.apache.org/jira/browse/JAMES-679
This one is a workaround that would avoid JAMES-592 to happen, with no
changes to the code.
It disables the cache, and that means taking a performance hit on most
lookups. I get 100's of 1000s of connections daily, and they do tend to
come in waves from the same IP, so I would not get the benefit from having
already done the lookup. Plus, when dnsjava goes to process the IP, we
would not have already populated it into the cache.
You told that the IPs are very different in your request and hardly
repeated (you told this). So it should not change to much your
performance ;-)
The correct fix is in trunk (and in my patch). I don't understand why
people insist on forcing a crippled fix on v2.3 when we have already made
the correct one in trunk.
"Correct" or I would better say "appropriate" seems to be subject to our
technical ideas.
This is why I remove the "full backport from trunk" from the options,
because as Noel pointed out, we would break assembly.xml compatibility
and we cannot do this in a point release.
As I said, I will need to review the two branches, but we can look at
backporting the entire DNSServer from trunk, so that we do not have major
code differences between the two. All that we need to do for compatibility
is introduce the static method in the v2.3 branch so that the client code
can call it without the assembly issue.
The main purpose of my latest fixes in trunk has been to remove any
static usage of the Lookup class. This means that you will have to
change the code to backport it if you don't want to change the assembly.
Using a single static will be not enough. You will have to switch every
configuration/attribute of dnsserver to static fields. I believe this is
not a good choice for 2.3.1, too much changes considering we have
alternative workarounds.
3) Define where to add the
"java.security.Security.setProperty("networkaddress.cache.ttl" , "0");"
apply it to trunk and backport it (if you vote this please tell your
preferences about the place to add this code).
IIRC, it must happen before other things so placement in a container
enviroment is interesting. I'm offline with no Internet access at the
moment, so I can't check.
Personally, I'd backport the DNSServer fixes, reintroduce the static method,
and if we can find the right place add the networkaddress.cache.ttl as a
catch-all for bad third party code.
--- Noel
I think I understand you, but please put also vote numbers in addition
to all this sentences, so your opinion can be officially counted in the
vote result.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
