Where is this large install?  I'd be curious to know their setup for 
so many users.

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.

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.

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?

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.

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.

Did this issue re-appear, or is it gone since the last reboot?

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.

PHP 4 is fine.

Do you recommend going to PHP5 or should it work as well with 4 (we're 
running 4.4.1)?

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.

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?

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.

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.

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.