On Tue, Oct 9, 2012 at 3:38 AM, Juergen Nickelsen <juergen.nickelsen@xxxxxxxxxxxx> wrote: > [TLDR: taking out imapproxy resolved the issue; we'll live with that for > now] > > Hello, > > three weeks ago, I wrote this: > >> [...] in a few single cases, users have complained that the download of a >> large attachment failed due to the object being no longer present, >> according to SquirrelMail, and after clicking on the folder name, >> SquirrelMail showed the folder as empty. Only after logout and login >> again their messages were shown in the folder as before. >> >> This *seems* to correlate with the IMAP server (Dovecot) complaining, >> e.g., "Disconnected for inactivity in reading our output >> bytes=3588/19231114". > > First, thanks for the comments and detail questions regarding this > issue! Please excuse me for not following up earlier -- you know how it > is sometimes. > > In between, summer break nearly over, user complaints about this problem > became more frequent. As we more and more suspected the imapproxy to be > part of it, we configured it out of the loop a week ago, and lo, user > complaints stopped. > > Now a colleague of mine succeeded to reproduce the problem reliably on a > test system, where the imapproxy is still in use, by cancelling the > download of a large attachment. Following that, SquirrelMail shows all > mail folders as empty -- just as our users had reported it -- until the > cached connection in the imapproxy expires. This behaviour is not seen > when the imapproxy is not used. > > Actually, the IMAP chain is even longer: > > SquirrelMail <--> imapproxy <--> Perdition <--> Dovecot* > > The user mailboxes are distributed over a number of Dovecot servers for > performance reasons, and Perdition relays the IMAP connection to the > responsible server. Why not Dovecot Director? If you have testing resources, you could see if removing Perdition also takes care of the problem. > I looked around the imapproxy source if there were any additional tuning > or scaling parameters and didn't find any; unfortunately I will not be You can watch log messages from IMAP Proxy and see if it thinks its cached connection is as normal. If so, I'd suspect that it's as simple as Dovecot got tired of waiting around and closed that connection out from under the proxy(ies) (which the Dovecot log message you found seems to support). When you reproduced it in testing, was that Dovecot log message always there? If this is the case, I'd suspect that the problem is more on the Dovecot side, possibly because one of the layers above it reads and holds/serves the attachment but doesn't close the connection until the browser is finished. There may be some timeout settings you can tweak, and you might need to reconsider your attachment size limitations. > able short-term to dig deeper into it to find out if this is a problem > with imapproxy in general or perhaps only in interaction with Perdition. Well keep us updated and thanks for the follow-up. > While having imapproxy taking load off Perdition would be nice, we can > do without for now. If anyone has a specific idea what can be done about > the problem, I'd love to hear about it, but otherwise I'll leave it at > that for the moment. > > Thanks again for your effort to help -- I appreciate that a lot. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
