Tickets :: [#3649] Improve memory usage in history view with attachments

6.0.0-beta1

9/5/25

Summary	Improve memory usage in history view with attachments
Queue	Whups
Type	Enhancement
State	Resolved
Priority	1. Low
Owners
Requester	jhart (at) webroot (dot) com
Created	03/18/2006 (7111 days ago)
Due
Updated	04/25/2006 (7073 days ago)
Assigned	03/18/2006 (7111 days ago)
Resolved	04/25/2006 (7073 days ago)
Milestone
Patch	No

04/25/2006 04:18:08 AM	Chuck Hagenbuch	Comment #9 State ⇒ Resolved	Reply to this comment
Should be much better now - please test with the latest SQL driver (http://cvs.horde.org/framework/VFS/VFS/sql.php) and let me know. I'm merging to FW_3 also.

04/25/2006 04:11:08 AM	Chuck Hagenbuch	Comment #8	Reply to this comment
Currently using SQL Database backend (horde defaults). Here's the key; in the SQL VFS driver we fetch the whole file in _listFolder instead of just the size, which is what we want. I'm fixing it now, but ran into some other ... trouble in the VFS code.

04/25/2006 03:34:27 AM	Chuck Hagenbuch	Comment #7	Reply to this comment
Which makes sense, because the mime viewer links are created based on the mime type, and we get the mime type with mime magic from analyzing the attachment contents. Something I just realized; we don't show mimetypes in Whups. :)

04/12/2006 11:04:48 PM	Jan Schneider	Summary ⇒ Improve memory usage in history view with attachments

04/12/2006 11:04:15 PM	Jan Schneider	Type ⇒ Enhancement State ⇒ Accepted Priority ⇒ 1. Low

04/12/2006 10:53:56 PM	Chuck Hagenbuch	Comment #6	Reply to this comment
I think we should be able to at least make it so that the limiting factor is the size of the _largest_ attachment, not the total size of all attachments.

04/12/2006 10:49:38 PM	Jan Schneider	Comment #5	Reply to this comment
Is there anything we want to change about this, or are we accepting that this is how it technically has to work?

03/20/2006 04:46:55 PM	Jan Schneider	Comment #4	Reply to this comment
Just to be completely clear, this happens when displaying the ticket history, not when doing anything specific with the attachments, right? Correct, this is when displaying the ticket history. Which makes sense, because the mime viewer links are created based on the mime type, and we get the mime type with mime magic from analyzing the attachment contents.

03/20/2006 04:30:24 PM	jhart (at) webroot (dot) com	Comment #3	Reply to this comment
Just to be completely clear, this happens when displaying the ticket history, not when doing anything specific with the attachments, right? Correct, this is when displaying the ticket history. Which VFS backend are you using? Currently using SQL Database backend (horde defaults).

03/18/2006 05:55:24 AM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
Just to be completely clear, this happens when displaying the ticket history, not when doing anything specific with the attachments, right? Which VFS backend are you using?

03/18/2006 12:01:41 AM	jhart (at) webroot (dot) com	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ Tickets with attachments > php memory limit do not get displayed Queue ⇒ Whups State ⇒ Unconfirmed	Reply to this comment
I did not think it should make a difference how much was attached to a ticket at one time, but it looks like that if a file is attached greater than the memory limit of PHP, the ticket cannot be displayed. It seems sometimes it will display the summary information, but not the history. This also happens with many attachments which have a combined size over the memory limit. The only error (even with E_ALL) I'm seeing in any log is in the apache error log: Allowed memory size of 16777216 bytes exhausted (tried to allocate 79 bytes) Raising the memory size did temporarily fix the problem, but I can only imagine it will happen again.