[jira] [Commented] (IMAP-371) MailboxManager::getMailbox called very often

["Andrzej Rusin (JIRA)" <se...@james.apache.org>]

    [ 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