Bernd Fondermann wrote: >> 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. > > agreed, but as I understand it, performance _is_ an issue regarding > the growing traffic and recently surfacing spooling defects.
Yes, I agree on this point. But I wouldn't delay a release because of small speed factors. I also hope that we won't ever this problem because every new release will be better than the previous in term of speed ;-) >> While writing this mail, curiosity brought me testing my current postage >> setup against 2.2.0 and 2.3.0-current. > > yes, I did this before, too. you can really quickly drive 2.2 against > the wall, if you want. I didn't expect so much difference. I know that james 2.2.0 was not so good with file repositories and I always used 2.2.0 with db because I tested it under load with files and I found james crashing or throwing random exceptions too often. I don't know what is the change that made this possible but now it seems that file repositories have really improved (my guess is that the various fixes in the repos.lock()/repos.unlock() and the notification fixes did it as we didn't change the repositories too much). > <snip/> >> 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? > > Well, the "1" is a bug in Postage, not so cool ;-) Should I open a JIRA issue for this, or are you already tracking/working on this? > But yes, it is quite impressive. I also noticed similar behavior. 2.3 > is a substantial improvement over 2.2. but you know better than I do > :-) I always thought (and said) this ;-) , but I never expected *so* much. > <snip/> >> 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*. > > That is why I think that "memory leak" is a delicate term. > If what we currently have is "the best James ever", we should release > pronto. > But I expect problems to pop up, after such a long time with no > release and such big changes to the code base. > > If today someone steps up and says, "I have this config and only > changed releases, and before it ran for 10 days until restart and now > it's only 5 hours", it would not be acceptable to release the > software, because the server would not be ready for enterprise > production purposes. I get your point, and I really agree. The problem is that James 2.3 has been tested really from few people and many parts of james are probably not used by anyone using it in production. So, I'm sure that MAJOR bugs will be discovered only when we'll start publicizing much more the 2.3 release, but probably if we don't make a release we 'll never found that bugs. A possible solution could be to make 2.3.0RC3 more official than previous releases and publish it as the new best release in our website. Unfortunately the only early adopters for 2.3.0 alphas have been Norman and I. We don't use SMIME mailets, we don't use fetchmail, we don't use file repositories, we don't use mailing list mailets, we don't use SSL, we don't use JMX and so on... This means that most of this features are almost untested. And now I want to make 2.3.0 final, because I want to start using 2.4 alphas in some of my personal production servers ;-) >> 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. > > :-) This would mean a not-so-small refactoring, because the triggering > of "taking samples", e.g. sending mails, has to be completly revised. > With the changes I am about to check in you are only able to increase > the mail sizes which is not the same. Adaptive load is coming later, > except someone steps up with a solution. I'd be happy to help. Well, mail sizes is a good step by now! :-) Thank you, Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
