On Wed, Apr 28, 2010 at 8:44 AM, Norman Maurer <norman.mau...@googlemail.com> wrote: > 2010/4/28 Robert Burrell Donkin <robertburrelldon...@gmail.com>: >> 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... >> > > Ok, hope to see you back in some time..
thunderbird 3 hates our IMAP so i'm having mail issues :-< >>> 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 > > Yes I'm aware of this.. I'm still trying to get my head around of a > good solution to see without breakin to much ;) >>>>> 1) UidChangeTracking: >> >> the API uses a listeners and events to manage updates to UIDs etc. >> this design may need to be revised. > > I think the event stuff is good. Just the Tracker is not needed and > add a "useless" layer of complexity to the api.. AFACT in https://svn.apache.org/repos/asf/james/imap/trunk UIDChangeTracker is only used by Torque. why not just move it into that package then leave it alone? >>>>> 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. >> > > Yeah we should remove the caching of mailboxes at all from the > MailboxManager, because (as you already stated) it depend on the > implementation if a cache is needed and how a cache is implemented. > > At the moment I refactored the openjpa stuff to use one EntityManager > per request. This seems to work out well so far. Even better would be > to use one entitymanager per mailboxsession. for JPA, they should really be pooled, then obtained per request - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
