[RCD] keep-alive changes

Claudio Kuenzler ck at claudiokuenzler.com
Tue May 1 13:04:27 CEST 2012


On Tue, May 1, 2012 at 12:49 PM, A.L.E.C <alec at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.roundcube.net/pipermail/dev/attachments/20120501/ba58f725/attachment.html>


More information about the dev mailing list