Tickets :: [#12729] Throttle new mail queries

6.0.0-alpha10

5/15/25

Summary	Throttle new mail queries
Queue	IMP
Queue Version	Git master
Type	Enhancement
State	Duplicate
Priority	1. Low
Owners
Requester	slusarz (at) horde (dot) org
Created	10/01/2013 (4244 days ago)
Due
Updated	11/12/2013 (4202 days ago)
Assigned
Resolved	11/12/2013 (4202 days ago)
Milestone
Patch	No

11/12/2013 06:55:34 PM	Michael Slusarz	Comment #4 State ⇒ Duplicate	Reply to this comment
#12705

10/14/2013 01:49:07 PM	Jan Schneider	Summary ⇒ Throttle new mail queries

10/14/2013 01:48:53 PM	Jan Schneider	Version ⇒ Git master Queue ⇒ IMP

10/14/2013 01:48:36 PM	Jan Schneider	Comment #3	Reply to this comment
[Show Quoted Text - 14 lines][Hide Quoted Text] 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.

10/01/2013 10:10:51 PM	Michael Rubinsky	Comment #2 State ⇒ Feedback	Reply to this comment
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.

10/01/2013 06:53:35 PM	Michael Slusarz	Comment #1 Priority ⇒ 1. Low Type ⇒ Enhancement Summary ⇒ Pool multiple requests Queue ⇒ Kronolith Milestone ⇒ Patch ⇒ No State ⇒ New	Reply to this comment
From ~~#12705~~: [Show Quoted Text - 10 lines][Hide Quoted Text] 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.