Bernd Fondermann wrote: > So how do we reproduce this beast? Do we have a "no load" reproduction > raising OOMs?
I tried reproducing Noel issue a lot of times. I ran profilers and I ran postage with a lot of configurations but I have not found any leak. Imo the issue is invalid and closed as cannot reproduce until we get much more informations. The fact that Noel's production server does not work with an updated JVM (1.4.2 09=>12) is already weird enough to be considered a special case where maybe the JVM has problems and not James itself. This is not a question of a pathetic leak: this is a question of reproducible leak. If I were able to reproduce the OOM using Xmx 5M I would also find the leak and we could decide wether we want to fix it or not, but now we don't even know if this bug exists at all. I already questioned the "confirmed" word used by Noel. Imho a bug is confirmed when I can reproduce it in a clear way, and memstat is not a index for this. So until Noel won't decide to use a real profiler (with per-instance allocation time tracking) and not hprof :-P (which leave us guessing where the problem is) or won't provide us at least the config.xml I stop my tests. About your comparison between 2.2.0 and 2.3.0: it should be done in a controlled environment (postage). I don't expect the number of spam connections to Noel's server in these days to be the same of an year ago, or even few months ago. My personal server have almost an average of 5 times traffic than 1 year ago and I receive/send the same amount of valid emails. Furthermore I think that 2.3.0 is already faster than 2.2.0 but I don't care too much of this issue: imo the real goal is that 2.3.0 should be more RFC compliant and have less bugs (or at least less critical) than 2.2.0. If you look at the changelog you will see that 2.2.0 has really bad bugs. If 2.3.0 fixes that bugs (without introducing worse bugs) and work 5% slower it would be a good thing anyway. While writing this mail, curiosity brought me testing my current postage setup against 2.2.0 and 2.3.0-current. I use Xmx5M for both. I use standard setup for both. I run a 5 minutes test cloned by "debug" and changed to have 300 smtp/minutes (100+100+100) and 120 pop/minute. James 2.3.0-current finisced after 5 minutes having matched 1475 mails. James 2.2.0 simply put mails into the main spool and after less than 2 minutes it start throwing a lot of OOM without delivery a single mail. So I increased the memory for James 2.2.0 to 10M. After 1 minute postage say "unmatched: 299, matched: 0".. I don't know if this is an incompatibility between james 2.2 and postage, but I also see all the messages still in the spool. After 2 minutes "unmatched: 586, matched: 5", after 3 minutes "unmatched: 878, matched: 13".. then again OOM. This time I increased the Xmx to 20M. After 3 minutes again "unmatched: 879, matched: 14", this time no OOM.. At the end of the test "1451 unmatched" (UNDELIVERED) and 31 matched. So I decided to switch back to my dear 2.3.0 with Xmx5M and increase the load to see if I simply was on its limit. I doubled smtp and pop connections (600smtp/minute+240pop/minute) This time 2.3 is not able to keep up with the flow, but the good new is that the spool is always empty. The mails accumulates in the outgoing (we have 1 outgoing thread by default) and in the inboxes (maybe the postage pop threads do not read enough). After the 5 minutes I had almost 500 messages in outgoing that have been ALL succesfully delivered to postage in the "2 minutes" window postage wait at the end of the test. So the raw result was: "matched: 2616, unmatched: 1". Isn't this cool? Last test. 900smtp/minute and 360pop/minute. This time increasing deliverythreads to 3 and decreasing spoolthreads to 6 (we don't need so much spoolthreads). The spool still run empty.. mail accumulate in outgoing and inboxes.. Again james succesfully delivered everything. At the end of the test the unmatched mails where in the inbox and not in the spool (like 2.2.0 did). At the end of the test "matched: 2645, unmatched: 1". So I reached the limit, because probably my pc running both postage and james have been not able to put more than 530mail/minute via smtp. Please note that I never tested 2.2.0 before: this is simply my current "random" 2.3.0 test applied to 2.2.0. And the difference is imo *impressive*: James 2.2.0 needed 20MB for the 300mail/minute test, James 2.3.0 did 500mail/minute (under stress pressure) using 5MB and without throwing OOM. Furthermore James 2.2.0 had an increasing spool size while 2.3.0 had no problem on the spool. Again, this is not a test to demonstrate that 2.3.0 is better than 2.2.0. Maybe there are tests that works better on 2.2.0 or tests that works even better on 2.3.0. But as a fist try I would simply say *WOW*. Bottom line: I really would love to have an "adaptive" Postage configuration that simply try to find out what is the maximum flow for the given configuration. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
