james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: [IMAP] Over-designed /Some thoughts ?
Date Tue, 27 Apr 2010 21:40:22 GMT
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...

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

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

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

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.

- robert

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


Mime
View raw message