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 09:19:04 GMT
2010/4/28 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Wed, Apr 28, 2010 at 8:44 AM, Norman Maurer
> <norman.maurer@googlemail.com> wrote:
>> 2010/4/28 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>> On Wed, Apr 28, 2010 at 5:55 AM, Norman Maurer
>>> <norman.maurer@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 :-<

Just till upgrade ?

>>>> 2010/4/27 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
>>>>> On Tue, Apr 27, 2010 at 10:42 AM, Norman Maurer <norman@apache.org>
>>>>>> Hi all,
>>>>>> after spending some time over the weekend to fix some issues with
>>>>>> 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?

Yeah its still work in progress..
>>>>>> 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
>>>>>> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message