On Wed, Apr 28, 2010 at 5:55 AM, Norman Maurer <norman.mau...@googlemail.com> wrote: > Hi Robert, > > nice to see you are back ;)... Comments inline..
i'm really busy ATM (exams, projects, reports) :-/ this will probably have to be my last post for a while... > 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. +1 sessions that select a mailbox have to be updated by operations done by other sessions on that mailbox >>> 1) UidChangeTracking: the API uses a listeners and events to manage updates to UIDs etc. this design may need to be revised. >>> 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. AFACT the OpenJPA stuff shouldn't be caching the mailboxes in the manager (caching should be managed internally by OpenJPA). sounds like a session management problem is much more likely. ATM sessions cache entity managers for the duration. if you're running a lot of concurrent connections, they need to be pooled. FWIW in IMAP, a session may: * have a long term interest in a mailbox spanning multiple requests * need to perform multiple operations on one or more mailboxes to execute a single protocol request IMHO the failure to cleanly and clearly separate these is a major flaw in current API. the Mailbox caching issues are just a consequence. fixing these would require a major rewrite with knowledge of the current foibles... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
