[
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: [email protected]
For additional commands, e-mail: [email protected]
