james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: [IMAP] Over-designed /Some thoughts ?
Date Wed, 28 Apr 2010 04:55:44 GMT
Hi Robert,

nice to see you are back ;)... Comments inline..

2010/4/27 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Tue, Apr 27, 2010 at 10:42 AM, Norman Maurer <norman@apache.org> wrote:
>> Hi all,
>> after spending some time over the weekend to fix some issues with IMAP
>> I started to feel its a big "over-designed" ...
> i started out with that impression. after digging around i came to the
> conclusion that IMAP has some annoying requirements..

Oh well... its some kind of a pita.

>> I think it would be a good think to "simplify" the api a bit to make
>> it a bit easier to understand. So some points which came to me mind:
>> 1) UidChangeTracking:
>> Is this really necessary ? It does some kind of caching but I don't
>> see something else for which its useful. Why not just fire the events
>> directly with a shared MailboxEventDispatcher which is the same for
>> all Mailboxes?
> i'm not convinced it's needed but beware...
> this is one of the few areas retained from the design before i started
> reworking. i had hoped to replace it but never really worked out how
> to do that without crippling performance or breaking IMAP.

I'm currently testing imap without the UidChangeTracker and so far it
seems like its not really slower then before..

>> 2) Global Mailbox caching
>> At the moment the Mailbox is cached in a HashMap. The problem with
>> this is it will never get recycled by the GC. This can generate a OOM
>> over long time
> i run IMAP with approx 1.5G spread over around a hundred mailboxes.
> i've never had an OOM. so i never bothered changing this.

I think you use Torque right ? Maybe it behave a bit different there.
I'm using JPA and its reproducable with feeding a mailbox with ca 1
million emails. You will see the memory usage just grow and grow..
When I took a heap dump it seems like the OpenJPA objects where never
released, because the where hold in the HashMap.

>> The other problem with this is, the Mailbox should be "tight" to the
>> MailboxSession. Let me explain why. For example in JCR we could use
>> the User/Pass which is bound to the MailboxSession to access different
>> parts of the JCR Repository etc..
> i thought this too originally but i couldn't work out how to do so
> without cripple performance or breaking IMAP.

Sure good performance is a must, but I would prefer to have a "good"
api first ;)

> IIRC these are related issues. the essential function is caching and
> synchronization. in performances terms, i think much higher
> performance could be achieved by replacement by something asynchronous
> and event driven using a blocking queue. this would be a substantial
> change.

I agree with you here. But as you outlined already, its not a "easy"
thing todo, without rewrite a lot of stuff.

I even tend to believe we should do something similar to what we have
in SMTP/POP3.  Just have some kind of LineHandler which push data in
the processor when a CRLF was detected and so not using blocking
streams as input at all.

> - robert


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

View raw message