Tickets :: Comment on [#3404] Rare random Logouts due loss of IMAP connection

* Your Email Address
* Spam protection	Enter the letters below: .__ ._. __ .__.. , [__) \| / `\| \| \./ \| \_\|_\__.\|__\| \|
Comment	> I'm right now monitoring a strange problem on a internal horde/imp > setup serving about 70 user. Authentication is IMAP-only and imp is > the login-app. > > > > These users normally log on to their emails in the morning and keep > that window up and running until they leave work in the evening. They > all have set up a mailreminder to be instantly informed about new > mail - so they never get a session-timeout. > > > > Strangely sometimes one or more get logged of from horde while others > stay logged on at that point of time. This logoff occures on any > action that results in refreshing the webpage. And theres no timeout > - klick and you're back at login-page. Users who are writing a new > mail loose their work if the background-window with its refreshing > INBOX gets logged of, because the compose-popup is closed, too. This > is really nasty! > > You can't define a certain time-spot, any coincident or a method to > cause the users to get logged out. > > > > I traced this thing down in a time consuming honeypot-method (as i > named it) placing a mail-sender at a prominent place to provide me > with information of imps state when someone gets logged off. By > letting the honeypot move backwards from the place the horde-log > message "LOGIN FAILURE" i slowly traced back to the origin of imps > logout-reason. Everytime i made a change i had to wait from several > minutes to several hours for someone getting logged off unreasonable. > > I found the logout-reason in imp/lib/IMAP.php in the function > 'openIMAPStream' which returned 'false' on every case of > logged-off-users. So i looked at imap_errors() and found constantly > the same msg: > > "Connection failed to 127.0.0.1,143: Die Wartezeit für die Verbindung > ist abgelaufen" > > The german part of this message means something like "connection > timeout" - i don't know why this message is partly german. > > > > Since horde/imp and the IMAP-server reside on the same machine i > don't see a reason for timeout, but i thought imp might need to retry > to 'imap_open' the IMAP stream a little more often. > > I changed a part of the code in IMAP.php as you can see in the > attached file, where i documented the before- and after-state. Unless > the last imap_error is not something like 'login failure' my routine > gives imap_open 10 chances to return a stream-result with a timeout > of 0.3 sec between each try. That would result at worst case in a >3 > sec. delay before a user finally gets thrown out of horde/imp. > > My statistics on these rare cases show, that most imap_open that fail > on first try do succeed within 1 retry. The worst case so far had to > do 2 retries. > > > > I do think this is not a problem of imp! The imap server seems to be > the "bad boy" in this scenario, but this "feature" might be a nice > improvement to imp. > > > > How about? > > > > Regards Andreas
Attachment
Watch this ticket

Saved Queries