Resolving, unless we hear otherwise.

I've tested it for a while now (single user only, for now) and it 
works fine. Maybe there are also some other users who can confirm it.

Committed.  Thanks again.  Hopefully, this will allow us to close this ticket.

found some more small problems:

- Horde_Memcache::set() is still called from within set(), which 
doesn't work (at least here)

- when using Horde_Memcache::get() there is no need for prepend the 
'prefix' parameter to

   the key

- in order to avoid compression for the memcache oversize lookup 
table, the entries should

   not be set using Horde_Memcache::set(), but rather by using Memcache::set



The attached patch (Memcache-0725.php.patch) solves those points and 
works fine here.

Let's see where these changes get us.  Thanks for helping debug this code.

Yep - looks like this was a remnant from when we were directly calling 
the memcache methods from within this object.

Added all changes except the compression for memcache oversize lookup 
table - this table will be very small (a couple of entries at best) 
and since it needs to be loaded on every memcache lookup, no need to 
have this overhead.

No - this was by design.  I wanted a single lookup table for all 
prefixes.  But thinking about this a bit more... it doesn't really 
hurt to split this table into several tables.

... I think this patch to framework/Cache/Cache/memcache.php solves 
the array() key problem.

it is still seqfaulting with your latest changes, and I think found 
also some additional problems in the code. The attached patch works 
for me, and with this I'm also able to correctly open/download big 
attachments from gpg signed messages.



Please not the "TODO" comment. I found that sometimes we get arrays 
passed as cache keys, e.g. from horde/services/portal/sidebar.php or 
imp/mailbox.php. I added an error logging code to the patch to see 
what is in the arrays. Here some examples:



a:2:{i:0;s:27:"perm_exists_imp:max_folders";i:1;s:29:"perm_exists_imp:max_folders_e";

a:2:{i:0;s:34:"perm_exists_turba:sources:localsql";i:1;s:36:"perm_exists_turba:sources:localsql_e";}

a:2:{i:0;s:30:"perm_exists_imp:create_folders";i:1;s:32:"perm_exists_imp:create_folders_e";}



It seems that all of them are deriving from the perms system.



I'm not sure if erverything is correct in this patch, but I hope this 
helps to further optimize the memcache driver.

Just from looking at it:



I think line 161 should read:

  $os = $this->_memcache->get($this->_params['prefix'] . 'horde_memcache_os');

instead of:

  $os = $this->_memcache->get('horde_memcache_os');



right?

Correct.  This has been fixed.

Turns out that we were calling Horde_Memcache::get() from within get() 
instead of calling the function in the memcache object - this is most 
likely where the segfault was occuring.  This has been fixed.

...and shouldn't the substring start be something like "$i * 
MEMCACHE_MAX_SIZE" instead of just "$i" ? (Line 196)

The attached, patch at least solves the segfault problem, but I still 
can not open the pdf attachment (or other bigger attachemnts) when   
the message is pgp signed.

I also noted the following log in the error log, when opening the 
message with the pdf attachments:



PHP Notice:  Array to string conversion in 
/tmp/include/Horde/Memcache.php on line 190, referer: 
https://webmail.tugraz.at/cvs_dev/horde/imp/mailbox.php?mailbox=INBOX.sent-mail&start=67

:-(

With this patch my apache starts to seqfault....

Ironically enough, I committed some code relating to this same problem 
today, but for different reasons.  It has not yet been tested, so if 
you could provide feedback that would be great:

  http://lists.horde.org/archives/cvs/Week-of-Mon-20070716/069425.html

As I guessed, it is indeed a memcache max item size problem. The 
default memcached allows only for a max item size of 1Mb.

When dirty hacking the memached server to allow 2Mb items the gpg 
signed message including the attachment opens correcly, but that's not 
a clean solution.



BTW:

When the message is not gpg-signed, then it's no problem to open and 
download the attachment.

The pdf file, when attached and signed via IMP, can't be displayed or 
downloaded via IMP anymore. I get a blank message frame when trying to 
click on the download (diskette) item.

When clicking on the filename link I get  a randomly blank new window 
or a horde login page, or a horde portal page.

I guess it is again a memcache item size problem. This fle is about 
500kb, smaller files seem to work. I tried to disable the mailbox 
cache by stetting $conf['mboxcache']['use_mboxcache'] = false; but 
this didn't help.

I always get errors of this kind when opening the message:



PHP Notice:  Memcache::set() [<a 
href='function.Memcache-set'>function.Memcache-set</a>]: marked server 
'xxx.xxx.xxx.xxx:11211' as failed in /tmp/include/Horde/Memcache.php 
on line 151, referer: 
https://webmail.tugraz.at/cvs_dev/horde/imp/mailbox.php?mailbox=INBOX&start=3

I discovered several problems with adding attachments when the message 
is gpg-signed.

The attached file (Similaun-2007.kmz, wich is a zipped xml for 
google-earth) here will not be attached to the message at all.