On Tue, May 1, 2012 at 12:49 PM, A.L.E.C <alec@alec.pl> wrote:
Digging into session issues I've found this keep-alive thing a little
bit overcomplicated and unclear. The keep-alive setting handles two
things: session keeping and new-mail checking. Some plugins also bind to
keep-alive to do some recurring actions (e.g. to display calendar
alarms, etc.).

I think we should split these functionalities. So keep-alive action
should be used only for session keeping. In such case we need to execute
keep-alive action only after some inactivity time (e.g. session_lifetime
- 1min [or 5%]). It means timer should be resetted on every reequest.
Also it means we don't need a separate config option, because the
interval would be calculated from session_lifetime. For
session_lifetime=0 there would be no keep-alive requests.

Wasn't the whole keep-alive timer removed in change 6135 ?

I'm currently testing this changeset adapted to my 0.7.2 installation. Am logged parallel to
a) Roundcube without 6134/6135
b) Roundcube with changes 6134/6135
So far no erros on both, but it could take some time until I get into the session problem.
 

Another thing is recurring check for new-mail. This would work as is,
but... see below.

Last but not least. We should provide some "global" recurring action
which would work across all tasks so, plugins could bind to it. One
"global" action to minimize session race-conditions when few plugins
will create their own recurring requests on the same time. In mail task
we could "bind" our check-recent action to this global action.

In my opinion this would be a much clearer solution and would give as
some additional possibilities:
- possibility to disable recurring checks (for new mail etc.) at all,
- better overall performance because keep-alive out of mail task will be
executed less frequently

I think also, we could rename keep_alive option description ("Check for
new messages on") into something like "Update system state (check for
new mail, etc.) on", and move it to User Interface section, so we could
use it as our global action interval.

Agree!

By the way, since applying R6134 and 6135, the following entries are added every 5min to sessions log:

[01-May-2012 12:40:58 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 12:40:00
[01-May-2012 12:40:58 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: S53fabb9110e91180a0496334c87df7aac72d70d9
[01-May-2012 12:45:58 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 12:45:00
[01-May-2012 12:45:58 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: S961ba77407fec5c916f36782b63a4f0f8dc1395e
[01-May-2012 12:50:58 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 12:50:00
[01-May-2012 12:50:58 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: Se02d5ff4dd57e85adabddb48842a1fccb557d923
[01-May-2012 12:55:58 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 12:55:00
[01-May-2012 12:55:58 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: S8ad4d623dbc54cdc3e9d103f22c4e85965f867f7
[01-May-2012 13:00:38 +0200]: Session auth check failed for tmuc32t92k18dhpn0brnjtcra6; timeslot = 2012-05-01 13:00:00
[01-May-2012 13:00:38 +0200]: Send new auth cookie for tmuc32t92k18dhpn0brnjtcra6: S37c35e2013651e30185cb6aa621db6cdc8233e69