Hi Robert, nice to see you are back ;)... Comments inline..
2010/4/27 Robert Burrell Donkin <robertburrelldon...@gmail.com>: > On Tue, Apr 27, 2010 at 10:42 AM, Norman Maurer <nor...@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 Thx, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
