james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Rusin (JIRA)" <server-...@james.apache.org>
Subject [jira] [Commented] (IMAP-371) MailboxManager::getMailbox called very often
Date Tue, 09 Apr 2013 13:18:16 GMT

    [ https://issues.apache.org/jira/browse/IMAP-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626572#comment-13626572
] 

Andrzej Rusin commented on IMAP-371:
------------------------------------

I verified that AbstractMailboxProcessor::addFlagsResponses(final ImapSession session, final
SelectedMailbox selected, final ImapProcessor.Responder responder, boolean useUid) can lazily
retrieve the mailbox.
It reduces retrieving the mailbox in most used commands cases (when there is no unsolicited
responses):
- for NOOP command from 1 to 0 times,
- for IDLE command from 1 to 0 times,
- for (UID) FETCH command from 2 to 1 times,
- for SEARCH command from 2 to 1 times.

The optimized method looks this way:

    private void addFlagsResponses(final ImapSession session, final SelectedMailbox selected,
final ImapProcessor.Responder responder, boolean useUid) {
       
        
        try {
        	// To be lazily initialized only if needed - in minority of cases
            MessageManager mailbox = null;
            final MailboxSession mailboxSession = ImapSessionUtils.getMailboxSession(session);

            // Check ifwe need to send a FLAGS and PERMANENTFLAGS response before the FETCH
response
            // This is the case if some new flag/keyword was used
            // See IMAP-303
            if (selected.hasNewApplicableFlags()) {
            	mailbox = getMailbox(session, selected);
                flags(responder, selected);
                permanentFlags(responder, mailbox.getMetaData(false, mailboxSession,  MessageManager.MetaData.FetchGroup.NO_COUNT),
selected);
                selected.resetNewApplicableFlags();
            }
            
            final Collection<Long> flagUpdateUids = selected.flagUpdateUids();
            if (!flagUpdateUids.isEmpty()) {
                Iterator<MessageRange> ranges = MessageRange.toRanges(flagUpdateUids).iterator();
                while(ranges.hasNext()) {
                	if (mailbox == null) 
                		mailbox = getMailbox(session, selected);
                    addFlagsResponses(session, selected, responder, useUid, ranges.next(),
mailbox, mailboxSession);
                }

            }
        } catch (MailboxException e) {
            handleResponseException(responder, e, HumanReadableText.FAILURE_TO_LOAD_FLAGS,
session);
        }
    }


I have problems providing patches, as my trunk build environment got destroyed by the changes
to project directory structure.
                
> MailboxManager::getMailbox called very often
> --------------------------------------------
>
>                 Key: IMAP-371
>                 URL: https://issues.apache.org/jira/browse/IMAP-371
>             Project: James Imap
>          Issue Type: Improvement
>          Components: Processor
>    Affects Versions: 0.3
>            Reporter: Andrzej Rusin
>            Assignee: Eric Charles
>
> MailboxManager::getMailbox(MailboxPath mailboxPath, MailboxSession session) is getting
called extremely often. 
> On my custom RDBMS-based Mailstore implementation it is the biggest hot spot.
> I had to resort to caching the return value of it on Memcache, but even after that it
uses up around 15% of spent CPU time. It is far too much in my opinion.  (before I started
caching it, fully indexed RDBMS getting of the mailbox was taking more than 50% of the global
RDBMS load).
> My suspect is the method AbstractMailboxProcessor::addFlagsResponses(final ImapSession
session, final SelectedMailbox selected, final ImapProcessor.Responder responder, boolean
useUid).
> It gets the mailbox from MessageManager each time, even if it may be not needed. 
> This method is called in many CommandProcessors during the unsolicitedResponses phase.
> After I am able to really profile and confirm that it's the core of problem, I will provide
a patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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