james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Review/Help for Phoenix trunk upgrade (Noel?)
Date Tue, 03 Jan 2006 19:17:06 GMT
> 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>
> 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:

>> 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).


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message