Re: SquirrelMail aborting large attachment download?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[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.

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
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.

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.

Best regards, Juergen.

-- 
<Juergen.Nickelsen@xxxxxxxxxxxx> Tel. +49.30.838-50740
Zentraleinrichtung fuer Datenverarbeitung, Central Systems (Unix)
Freie Universitaet Berlin, Fabeckstrasse 32, 14195 Berlin, DE

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

------------------------------------------------------------------------------
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

[Index of Archives]     [Video For Linux]     [Yosemite News]     [Yosemite Photos]     [gtk]     [KDE]     [Cyrus SASL]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux