[#12729] Throttle new mail queries
Summary Throttle new mail queries
Queue IMP
Queue Version Git master
Type Enhancement
State Duplicate
Priority 1. Low
Owners
Requester slusarz@horde.org
Created 2013-10-01 (2479 days ago)
Due
Updated 2013-11-12 (2437 days ago)
Assigned
Resolved 2013-11-12 (2437 days ago)
Milestone
Patch No

Comments
Michael Slusarz <slusarz@horde.org> 2013-10-01 18:53:35
From #12705:

> When 'Display notification when new mail arrives?' in the Mail 
> preferences is selected, it looks like this check is performed for 
> each POST request. This means that if multiple POST requests are 
> send more or less simultaneously, this check is run many times in 
> parallel. For instance, if in a month view of Kronolith I move to 
> the next month, 13 POST requests are fired off within a few 
> milliseconds (in my agenda there are six calenders, five address 
> books, one tasklist and one holidays). Each of these will run
>
>     horde/services/ajax.php/kronolith/listEvents

These requests should be pooled into a single listEvents (or 
equivalent) action.

Michael Rubinsky <mrubinsk@horde.org> 2013-10-01 22:10:51
I disagree with some of this.

Calendars can come from any source; internal to kronolith, 
listTimeObjects, remote calendars, etc... Rolling *all* of these up 
into one listEvents call would prevent the UI from displaying any 
entries until ALL of the results are returned from all of the calendar 
providers. Remote calendars, especially, could slow the process down. 
IMO, it's better to update the UI quicker with the locally stored 
calendars while waiting for any slower calendars to load.

If anything, we might be able to batch all "external", "remote" and 
"internal" providers into separate calls, but not everything into a 
single monster listEvents call.

Jan Schneider <jan@horde.org> 2013-10-14 13:48:36
> I disagree with some of this.
>
> Calendars can come from any source; internal to kronolith, 
> listTimeObjects, remote calendars, etc... Rolling *all* of these up 
> into one listEvents call would prevent the UI from displaying any 
> entries until ALL of the results are returned from all of the 
> calendar providers. Remote calendars, especially, could slow the 
> process down. IMO, it's better to update the UI quicker with the 
> locally stored calendars while waiting for any slower calendars to 
> load.
>
> If anything, we might be able to batch all "external", "remote" and 
> "internal" providers into separate calls, but not everything into a 
> single monster listEvents call.

That's exactly the reason why I replaced the single 
Kronolith::listEvents() call from the basic interface with individual 
Kronolith_Driver::listEvents() calls for the dynamic interface.

This issue doesn't have anything to do with listEvents calls anyway, 
this should be cached (or rather skipped) with some sane TTL in 
IMP_Notification_Handler_Decorator_NewmailNotify instead.

Michael Slusarz <slusarz@horde.org> 2013-11-12 18:55:34
#12705