I have modified getSMTPHostAddresses to call findMXRecords and then use the
Iterator from that collection. We could go back to using MxSorter (the
comment I just put in about being able to us MxSorter within findMXRecords
is wrong, since we don't ever see a Collection over which to iterate; we get
an iterator), if we make some changes to it.
The more important change in DNSServer was reverting to the previous
technique of using InetAddress.getAllByName to get the IP addresses for the
SMTP hosts, rather than the Type.A lookup. The code was failing to resolve
hosts that use CNAME on the right hand side of an MX record. That may be an
incorrect DNS configuration, but it is all too common as I have noticed over
the past couple weeks of testing the new code.
Comments? Any strong feelings either way about using MxSorter to sort on
the fly versus pre-sorting, which is what findMXRecords does? If people
want to use MxSorter, the fixes should be fairly straightforward. The
drawback is having two sections of code doing largely the same thing, but if
we end up deprecating findMXRecords, that issue goes away.
I am not sure if MxSorter is faster unless there would be a lot of records.
Even if you are using the first record, we have already got the records, and
sorting a small Collection in place is quick. MxSorter makes a linear pass
through the entire Collection, engages in object creation (at the least, it
has to call toString()) for each host matching the then leastPriorityFound,
and may create and delete entries from its working collection depending upon
the order in which they are present from the lookup call. At least that's
my take on the code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
