6.0.0-git
2019-03-24

[#5965] attachments randomly not attaching
Summary attachments randomly not attaching
Queue IMP
Queue Version 4.1.5
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester babita.rana (at) ualberta (dot) ca
Created 2007-12-05 (4127 days ago)
Due
Updated 2007-12-21 (4111 days ago)
Assigned 2007-12-05 (4127 days ago)
Resolved 2007-12-18 (4114 days ago)
Milestone
Patch No

History
2007-12-21 21:39:17 webadmin (at) ualberta (dot) ca Comment #15 Reply to this comment
Yes, it should be.  There is at least one large install (millions of
users) that has been using memcache (circa Horde 3.2) as both the
cache and session backend since this summer without significant
issues.
Where is this large install?  I'd be curious to know their setup for 
so many users.
2007-12-21 21:34:13 Michael Slusarz Comment #14 Reply to this comment
I believe it is production quality in 3.2, although Michael can say
more.
Yes, it should be.  There is at least one large install (millions of 
users) that has been using memcache (circa Horde 3.2) as both the 
cache and session backend since this summer without significant issues.
2007-12-20 21:08:45 Chuck Hagenbuch Comment #13 Reply to this comment
I believe it is production quality in 3.2, although Michael can say 
more. Horde 3.2 should be final before too long - we just branched, so 
the (hopefully) final RC should be just around the corner. There are 
patches and upgrade instructions in the RCs already, though you'll 
need to grab new binary files like images and compiled translations.
2007-12-20 16:36:20 webadmin (at) ualberta (dot) ca Comment #12 Reply to this comment
memcache is probably nowhere near being production ready in Horde
3.1.x, especially when it comes to session handling.  Many months of
work have gone into improving this for 3.2.
So do you feel it IS production-ready in 3.2?  If so, when do you 
expect 3.2 to go final?  Will there be a patch upgrade path from 3.1.x 
or is a fresh install recommended?
2007-12-20 08:38:04 Michael Slusarz Comment #11 Reply to this comment
We've been rebooting the memcached machines nightly and we haven't
seen the issue again since.  Coincidentally we also were seeing
problems with logins - after entering your username and password
you'd get kicked back to the login screen with no "login failed"
message.  That problem has also vanished with nightly memcached
reboots.
memcache is probably nowhere near being production ready in Horde 
3.1.x, especially when it comes to session handling.  Many months of 
work have gone into improving this for 3.2.
2007-12-18 22:33:31 Jan Schneider State ⇒ Not A Bug
 
2007-12-18 19:57:44 webadmin (at) ualberta (dot) ca Comment #10 Reply to this comment
Did this issue re-appear, or is it gone since the last reboot?
We've been rebooting the memcached machines nightly and we haven't 
seen the issue again since.  Coincidentally we also were seeing 
problems with logins - after entering your username and password you'd 
get kicked back to the login screen with no "login failed" message.   
That problem has also vanished with nightly memcached reboots.
2007-12-18 18:52:08 Jan Schneider Priority ⇒ 1. Low
 
2007-12-18 18:51:59 Jan Schneider Comment #9 Reply to this comment
Did this issue re-appear, or is it gone since the last reboot?
2007-12-06 21:27:11 webadmin (at) ualberta (dot) ca Comment #8 Reply to this comment
PHP 4 is fine.
Okay.  That's one less variable to worry about then.



Just to add to the problem description, we've rebooted the horde 
machines as well as the machines running memcached.  Since the reboot 
we haven't been able to replicate the problem.  We did the same thing 
last week, but within a few days the problem had returned.  It may be 
a coincidence and have no relevance to the problem but I figured I 
should include it anyway.
2007-12-06 20:56:22 Jan Schneider Comment #7 Reply to this comment
PHP 4 is fine.
2007-12-06 20:24:02 webadmin (at) ualberta (dot) ca Comment #6 Reply to this comment
I would recommend a fresh install since there aren't patches to go
directly to the RCs, and there are some new graphics and other binary
files.
Do you recommend going to PHP5 or should it work as well with 4 (we're 
running 4.4.1)?
2007-12-06 19:30:17 Chuck Hagenbuch Comment #5 Reply to this comment
I would recommend a fresh install since there aren't patches to go 
directly to the RCs, and there are some new graphics and other binary 
files.
2007-12-05 23:14:27 babita (dot) rana (at) ualberta (dot) ca Comment #4 Reply to this comment
Would it be possible for you to try Horde 3.2-RC1 and IMP 4.2-RC1 and
see if the problem is reproducible there?
sure thing. and sorry, it's horde 3.1.5, not 3.1.4. can we upgrade to 
the RC1 versions via patches or do you recommend a fresh install?




2007-12-05 22:55:33 Chuck Hagenbuch Comment #3
State ⇒ Feedback
Reply to this comment
That's interesting - that would indicate that this isn't an upload 
issue, or even (likely?) a VFS issue, but an issue with how we build 
the MIME message.



Would it be possible for you to try Horde 3.2-RC1 and IMP 4.2-RC1 and 
see if the problem is reproducible there? If it happens within 3-4 
tries for you reproducing it without deploying to your whole cluster 
should be possible.



At the same time, or if that's not possible, I'd focus your debug 
logging in the attachFilesFromMessage() and addUploadAttachment() 
methods in imp/lib/Compose.php.
2007-12-05 22:48:40 webadmin (at) ualberta (dot) ca Comment #2 Reply to this comment
I was able to replicate this quite quickly (within 3 or 4 attempts).   
All I had to do was to forward a message that had an attachment.  The 
compose window comes up with the file showing up in the attachments 
section, but when you click preview there's nothing to see.  On the 
attempts that succeeded I did the exact same thing but the preview 
actually showed the file that was supposed to be there.  I tested this 
on the same message each time.
2007-12-05 22:09:26 babita (dot) rana (at) ualberta (dot) ca Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 3. High
Summary ⇒ attachments randomly not attaching
Queue ⇒ IMP
New Attachment: compose.tiff Download
Reply to this comment
Our setup:



20x horde machines:



         OpenBSD 4.1 (i386)

         Horde: 3.1.4

         Imp: H3 (4.1.4)

         Turba: H3 (2.1.4)

         PHP Version: 4.4.1



4x Session Machines:

         OpenBSD 4.1 (AMD64)

         memcached 1.1.12



Database:

         OpenBSD 4.1 (i386)

         MySQL 14.12 Distrib 5.0.33



Round Robin Clustering via PF and CARP



shared NFS volume for uploaded attachments.





uploaded files are randomly not being attached, nor can they be 
previewed despite the upload confirmation. included is a screen shot 
of the composition window after uploading the file where the preview 
fails (preview shows blank and the file does not actually get sent 
with the message, though the information in the compose window says 
the file should be successfully attached). we've modified the logging 
system to narrow down the source of the problem. this is the output 
from a failed attempt:



--

Dec  5 14:42:56 src@twc1 HORDE[14828]: [imp] webmail2 uploading file 
'snmp.txt' with temp filename '/www/tmp/phpSIVDm14828' [on line 465 of 
"/var/www/horde/imp/lib/Compose.php"]

Dec  5 14:46:19 src@twc1 HORDE[15844]: [imp] webmail2 attempting to 
send message with 0 attachments [on line 302 of 
"/var/www/horde/imp/compose.php"]

Dec  5 14:46:20 src@twc1 HORDE[15844]: [imp] 129.128.11.58 -- CCID 
webmail2 sent message to webmail2@ualberta.ca [on line 1166 of 
"/var/www/horde/imp/compose.php"]

--



this is a successful attempt:



--

Dec  5 14:33:42 src@twc1 HORDE[31967]: [imp] webmail2 uploading file 
'snmp.txt' with temp filename '/www/tmp/phpNebwF31967' [on line 465 of 
"/var/www/horde/imp/lib/Compose.php"]

Dec  5 14:33:45 src@twc1 HORDE[31967]: [imp] webmail2 attempting to 
send message with 1 attachments [on line 302 of 
"/var/www/horde/imp/compose.php"]

Dec  5 14:33:45 src@twc1 HORDE[31967]: [imp] webmail2 attaching file 
'snmp.txt' [on line 794 of "/var/www/horde/imp/lib/Compose.php"]

Dec  5 14:33:46 src@twc1 HORDE[31967]: [imp] 129.128.11.58 -- CCID 
webmail2 sent message to webmail2@ualberta.ca [on line 1166 of 
"/var/www/horde/imp/compose.php"]

--



rebooting the machines seems to 'fix' the problem temporarily, but it 
shows up again and now it seems to occur more frequently. we thought 
it might have been a PEAR issue but the problem occurs on the latest 
version as well.



one other thing to note is on subsequent testing we found that if a 
second file is uploaded in the same message as one that has already 
failed (not showing in preview) the second file appears as attachment 
number 1 with the original attachment now gone.




Saved Queries