[imp] large session entries in horde_sessionhandler

[Michael M Slusarz]

Quoting liam hoekenga <liamr at umich.edu>:

>>> What session *variable* contains these messages? This might help
>>> trapping down where it gets into the session data, if you are sure that
>>> message caching is turned off on your production server.
>>
>> If you can suggest a way to split the contents of session_data into its
>> component elements, I can tell you.
>
> Ok, got it...
>
> The stuff is hanging out in horde_session_objects.  A typical entry 
> looks like..
>
>            [2b0fe832996f2aaa63be59ce45f51c15] => Array
>                (
>                    [data] =>
> O:12:"imp_contents":19:{s:5:"_body";N;s:9:"_bodypart";a:0:{}s:6:"_index";s:2:"24";s:6:"_strip";b:0;s:8:"_message";O:12:"mime_m
> essage":22:{s:6:"_build";b:1;s:14:"_defaultServer";s:18:"web.mail.umich.edu";s:5:"_type";s:4:"text";s:8:"_subtype";s:5:"plain";s:9:"_contents";s:0:"";s:17:"
> _transferEncoding";s:4:"7bit";s:16:"_currentEncoding";N;s:11:"_encode7bit";b:1;s:12:"_description";s:0:"";s:12:"_disposition";s:6:"inline";s:22:"_dispositio
> nParameters";a:0:{}s:22:"_contentTypeParameters";a:1:{s:7:"charset";s:8:"us-ascii";}s:6:"_parts";a:0:{}s:12:"_information";a:1:{s:2:"id";b:0;}s:5:"_cids";a:
> 0:{}s:7:"_mimeid";i:1;s:4:"_eol";s:1:"
> ";s:6:"_flags";a:1:{s:7:"setType";b:1;}s:6:"_idmap";a:0:{}s:9:"_boundary";s:14:"=_2vsv700tg56o";s:6:"_bytes";i:1340;s:10:"_contentid";N;}s:13:"_cachemessage
> ";O:12:"mime_message":22:{s:6:"_build";b:1;s:14:"_defaultServer";s:18:"web.mail.umich.edu";s:5:"_type";s:4:"text";s:8:"_subtype";s:5:"plain";s:9:"_contents"
> ;s:0:"";s:17:"_transferEncoding";s:4:"7bit";s:16:"_currentEncoding";N;s:11:"_encode7bit";b:1;s:12:"_description";s:0:"";s:12:"_disposition";s:6:"inline";s:2
> 2:"_dispositionParameters";a:0:{}s:22:"_contentTypeParameters";a:1:{s:7:"charset";s:8:"us-ascii";}s:6:"_parts";a:0:{}s:12:"_information";a:1:{s:2:"id";b:0;}
> s:5:"_cids";a:0:{}s:7:"_mimeid";i:1;s:4:"_eol";s:1:"
> ";s:6:"_flags";a:1:{s:7:"setType";b:1;}s:6:"_idmap";a:0:{}s:9:"_boundary";s:14:"=_2vsv700tg56o";s:6:"_bytes";i:1340;s:10:"_contentid";N;}s:4:"_atc";a:0:{}s:
> 6:"_parts";a:1:{i:1;s:4699:"
> =====snip cached message=====
> ;}s:8:"_summary";a:1:{i:1;a:8:{i:0;s:66:"<img
> src="/horde/themes/graphics/mime/text.png" alt="" title=""
> />";i:1;i:1;i:2;s:310:"<a href="#" on
> click="view('/horde/imp/view.php?popup_view=1&amp;index=24&amp;mailbox=INBOX&amp;actionID=view_attach&amp;id=1&amp;mimecache=2b0fe832996f2aaa63be59ce45f51c1
> 5', '1'); return false;" onmouseout="window.status='';"
> onmouseover="window.status='View unnamed'; return true;"
> title="unnamed">unnamed</a>";i:3;s:12:"[tex
> t/plain]";i:4;s:7:"1.31 KB";i:5;s:380:"<a
> href="/horde/services/download/?module=imp&amp;thismailbox=INBOX&amp;index=24&amp;mailbox=INBOX&amp;actionID=downl
> oad_attach&amp;id=1&amp;mimecache=2b0fe832996f2aaa63be59ce45f51c15&amp;fn=%2Funnamed"
> onmouseout="window.status='';" onmouseover="window.status='Download un
> named'; return true;"><img src="/horde/themes/graphics/download.png"
> alt="Download" title="Download"
> /></a>";i:6;N;i:7;N;}}s:12:"_summaryType";N;s:15:"_sess
> ionCacheID";s:32:"2b0fe832996f2aaa63be59ce45f51c15";s:12:"_viewerCache";a:0:{}s:12:"_displayType";i:0;s:8:"_mimekey";N;s:7:"_viewID";a:2:{s:8:"download";s:1
> 5:"download_attach";s:4:"view";s:11:"view_attach";}s:6:"_links";b:1;s:5:"_base";N;s:10:"_attach822";i:0;s:12:"_driverCache";a:1:{s:14:"text/plain|imp";O:8:"
> stdClass":3:{s:6:"driver";s:5:"plain";s:5:"exact";b:1;s:6:"module";s:3:"imp";}}}
>                    [prune] => 1
>                )
>
> The current largest session in our database hase 20 such entries, 
> many of them
> with large attachments.  That session file is 109MB.

These are cached rendered MIME parts.  This is *not* the same as 
caching message bodies.

Right now, this is mandatory for IMP to work properly (and has been 
throughout all IMP 4.x releases - this is not something that has been 
recently added).  Search the mailing lists a year or two back for the 
very long explanation I gave about why this is necessary (a search for 
"embedded MIME parts" will probably return the results you need).  
Quick explanation: caching rendered parts is the only way we currently 
can pass embedded MIME part data to another page without having to 
write hundreds of lines of rendering code in each IMP page.

michael

_______________________________________
Michael Slusarz [slusarz at curecanti.org]