Noel J. Bergman schrieb: >>>> 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). >> > > As I said, they tend to come in batches. Over the past 20 hours, we have > had about 150K connections, of which about 10K were duplicates within a > fraction of a second. These would result in redundant queries, as would > others over a period of time. > > I really don't understand why you steadfastly refuse to allow anyone to > apply the same quality of fix to JAMES that we have already applied to > trunk. Unless that is your actual goal: to prevent effective changes on v2, > so that only trunk can be developed. > > --- Noel > > I think is more likely to try to limit the diffrences about the code in trunk and 2.3 branch. I just don't like to backport the whole DNSServer. This will bring more risk to 2.3 branch and the change is to "big" for a bugfix release (IMHO). Maybe i not understand it correct, but why we not just add the security property setting the the phoenix-loader ? So if someone upgrade he just need to replace the james.sar and the phoenix-loader.jar ?
bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
