> Yes, the copy-on-write behavior is the one that I am most concerned about > from the perspective of performance and memory footprint.
About performance it is one more call for every mimemessage method to read and 3 more calls (simple method calls) for every mimemessage write methods. These is not reflection or other "slow" stuff. About memory footprint the wrapper should be almnost invisible (it only store a reference to the real mimemessage and a reference to a referenceCounter. The referenceCounter simply introduce an "int" value. I added tests to be sure that the real mimemessage is not duplicated every time it's possible to know it's no more shared. Anyway this is a critical bug fix so we can't trade it for performances: The whole proxy has been introduced to make the fix as performant as possible but the previous behaviour was wrong. Maybe (I hadn't investigated on that) that the new proxy will help us in some optimization elsewhere. A minor performance improvement would be to create a third wrapped that merge the features of MimeMessageWrapper and MimeMessageCopyOnWriteProxy so that we don't need a double proxy for messages read from the repositories. I did not run performance tests but I'm confident that the performance loss is almost unrecognizable. > I haven't looked, > but it is an interesting question whether or not the Message-ID should be > changed, too. But that really depends upon the nature of a change, and is > entirely application semantic dependent. Probably the best thing would be to change the message-id every time the proxy detect the need for a new copy and create it. > The recent change to SMTP and POP3 may also fix an older and relatively > boring issue that a totally empty message, i.e., DATA<CR><LF>.<CR><LF> would > not be supported. We'll have to test it. I committed them to have a direct reference to the patch but I think we should not ship the next version with this change. This, hopefully, fix the issues but introduce a "serious" backward compatibility issue that we avoided in past. This release is storage compliant with 2.2.0 if we don't break this with that patch. My spare-time is almost finished but I plan to look at the possible MimeMessageWrapper workaround to this problem. Or maybe we should leave this patch in and simply check for the ending CRLF in the mimemessagewrapper and eventually add it if missing. >> I thought about moving these issues to 3.0 but IMHO they are >> too critical to release 2.3.0 without them. > > And this is part of why I keep thinking that we should call this release > 3.0. I'm still for 2.3.0 but I'm aware that this is a personal preference. I'm not -1 for a 3.0 versioning scheme. This latest changes are mostly bugfixes that should be invisibile to the users: they need "critical" changes in the code but I think that the version is a number for the users and not for developers and, as such, I feel 2.3.0 better reflects this release. We have a few major steps beyond: - remove javamail dependency from Mailet API / James? - remove avalon dependency? - change the repository interfaces? I don't know wether we'll be able to implement one or more of them, but even if we add just one of them then we would need a major version, so I would avoid to start using only the first number of our product version :-) >> About "tests" I felt free to commit the good starting work from Bernd > > Given the volume of work we're getting from Bernd, I'd like to ask if he > would please submit a CLA. :-) And perhaps work towards Committer status. > :-) It would be cool to have more people working on the sources! I don't know much about but I remember that a few tests was already present in the old "merger" branch. I'm not sure wether they can easily ported to the current trunk or not, maybe Bernd would like to look at them: http://svn.apache.org/repos/asf/james/server/tags/pre-v2and3-merger-trunk/tests/ >> We will discuss how to handle the ristretto/junit jar later! >> (IIRC latest news from Apache said that we can ship MPL jars >> if there is full consensus by committers). > > We can run this by Cliff. > > --- Noel Sorry, what/who is Cliff? To complete my previous statement I think that if we limit the ristretto usage to tests we can also avoid to include the libraries in our repository. Developers could simply download the jar from the site (as we already do with javamail and activation). Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
