Hi Tibor,
as I wrote in my first email the limits were changed up to 8MB. The
entries are:
php.ini:
memory_limit: 16MB
upload_max_filesize: 8MB
post_max_size: 8MB
max_input_time: 300
mysql.ini:
max_allowed_packet: 8MB
Apache was restarted and MySQL was reloaded. The admin will restart
MySQL at the end of the day. So I can test it tomorrow again.
The problem is still there. :( Any other suggestions?
Regards
Frank Tilmans
Frank,
I had similar problems before to display issues which had large
attachments. The real problem was not around the display attempt but
earlier when the attachment was stored during the incoming email
processing. My problem was the size limit being too small. At email
processing time the attachment storage failed resulting in improper
state of the issue in the database (that's another question why that
happens) which prevented proper display of the issue later.
I had to increase the corresponding limits in both php.ini and mysql.ini
AND restart Apache to get the changes in effect. MySQL has some
packet_size or something like that to increase - if you need the exact
name let me know.
I am not sure you hit the same problem but could be close.
Tibor
Frank Tilmans wrote:
Hi,
okay, I understand the advantages of saving attachments in the database.
It was just a thought of saving the attachments in folders - in order to
solve my problem. ;-)
I didn't also thought that MySQL could habe problems saving huge
attachments. But I sent yet another test email (zipped some files up to
4MB). And it happened again.
The only way to solve the problem is to decrease the file attachment
size to 2.5MB or 3MB. Btw, what happens with emails which are send
directly to eventum and the file size is higher than the maximum size?
Here ist the javascript error I got when I click on the plus:
Line: 232
Character: 5
Error: 'null' is Null or no object
Code: 0
URL: http://[urltoeventum]/view.php?id=263
Regards
Frank
Hi,
The main problem apart, I very much like the idea of having even
attachments in the DB because we have all the data required in one
place
and taking backups and restoring from backups are a breeze. Also
Integrity of data is ensured here - no dangling references to file
attachments that are deleted somehow in the File Server!!
In olden days, where space occupied in the DB was a big concern, they
used to have the scheme of storing the file paths in a file server
with
the actual data in the latter. But I guess and I strongly hope that
in
today's DBs especially MySQL, having such file attachments in the DB
itself however large, shouldn't be a problem.
Thanks and rgds,
Watson
Message
From: Frank Tilmans [mailto:tilmans (AT) incas-voice (DOT) de]
Sent: Tue, 29-Aug-2006 15:28
To: eventum-users (AT) lists (DOT) mysql.com
Subject: Problems with huge attachments
Hi,
this morning I found out that I couldn't reply to an associated email.
I
got a very blank page. Also, when I clicked on the plus (+) in the
associated email list I got an javascript error. The issue had an
attachment with a size of 4MB, so my first thought was: It's too
great.
All entries in php.ini and mysql.ini where changed to 8MB. So where's
the problem?
After a little bit testing I found out, that it was indeed the huge
attachment. Sending another email with a 4MB attachment to a
testproject
caused the same problem.
So I looked into the database with phpmyadmin. But I had problems to
open the related entries in the tables eventum_issue_attachment_file
and
eventum_support_email_body. The only way to solve it was to delete the
entry in eventum_issue_attachment_file and to update the column
seb_full_email in eventum_support_email_body to any text.
Is it possible that MySQL cannot handle with such huge entries?
Is there a way to save attachments in folders and to save in the
database the link to this file instead of saving the attachment in the
database?
Best regards
Frank Tilmans

Lets hope that the MySQL restart will do the job - I have no other idea

Frank Tilmans wrote:

>Hi Tibor,
>
>as I wrote in my first email the limits were changed up to 8MB. The
>entries are:
>
>php.ini:
>memory_limit: 16MB
>upload_max_filesize: 8MB
>post_max_size: 8MB
>max_input_time: 300
>
>mysql.ini:
>max_allowed_packet: 8MB
>
>Apache was restarted and MySQL was reloaded. The admin will restart
>MySQL at the end of the day. So I can test it tomorrow again.
>
>The problem is still there. :( Any other suggestions?
>
>Regards
>Frank Tilmans
>
>
>
>Frank,
>
>I had similar problems before to display issues which had large
>attachments. The real problem was not around the display attempt but
>earlier when the attachment was stored during the incoming email
>processing. My problem was the size limit being too small. At email
>processing time the attachment storage failed resulting in improper
>state of the issue in the database (that's another question why that
>happens) which prevented proper display of the issue later.
>I had to increase the corresponding limits in both php.ini and mysql.ini
>AND restart Apache to get the changes in effect. MySQL has some
>packet_size or something like that to increase - if you need the exact
>name let me know.
>I am not sure you hit the same problem but could be close.
>
>Tibor
>
>Frank Tilmans wrote:
>Hi,
>
>okay, I understand the advantages of saving attachments in the database.
>It was just a thought of saving the attachments in folders - in order to
>solve my problem. ;-)
>
>I didn't also thought that MySQL could habe problems saving huge
>attachments. But I sent yet another test email (zipped some files up to
>4MB). And it happened again.
>
>The only way to solve the problem is to decrease the file attachment
>size to 2.5MB or 3MB. Btw, what happens with emails which are send
>directly to eventum and the file size is higher than the maximum size?
>
>Here ist the javascript error I got when I click on the plus:
>
>Line: 232
>Character: 5
>Error: 'null' is Null or no object
>Code: 0
>URL: http://[urltoeventum]/view.php?id=263
>
>Regards
>Frank
>
>

>Hi,
>
>The main problem apart, I very much like the idea of having even
>attachments in the DB because we have all the data required in one

>place

>and taking backups and restoring from backups are a breeze. Also
>Integrity of data is ensured here - no dangling references to file
>attachments that are deleted somehow in the File Server!!
>
>In olden days, where space occupied in the DB was a big concern, they
>used to have the scheme of storing the file paths in a file server

>with

>the actual data in the latter. But I guess and I strongly hope that

>in

>today's DBs especially MySQL, having such file attachments in the DB
>itself however large, shouldn't be a problem.
>
>Thanks and rgds,
>Watson
>
Message
>From: Frank Tilmans [mailto:tilmans (AT) incas-voice (DOT) de]
>Sent: Tue, 29-Aug-2006 15:28
>To: eventum-users (AT) lists (DOT) mysql.com
>Subject: Problems with huge attachments
>
>Hi,
>
>this morning I found out that I couldn't reply to an associated email.

>I

>got a very blank page. Also, when I clicked on the plus (+) in the
>associated email list I got an javascript error. The issue had an
>attachment with a size of 4MB, so my first thought was: It's too

>great.

>All entries in php.ini and mysql.ini where changed to 8MB. So where's
>the problem?
>
>After a little bit testing I found out, that it was indeed the huge
>attachment. Sending another email with a 4MB attachment to a

>testproject

>caused the same problem.
>
>So I looked into the database with phpmyadmin. But I had problems to
>open the related entries in the tables eventum_issue_attachment_file

>and

>eventum_support_email_body. The only way to solve it was to delete the
>entry in eventum_issue_attachment_file and to update the column
>seb_full_email in eventum_support_email_body to any text.
>
>Is it possible that MySQL cannot handle with such huge entries?
>
>Is there a way to save attachments in folders and to save in the
>database the link to this file instead of saving the attachment in the
>database?
>
>Best regards
>Frank Tilmans

--

Frank,

Frank Tilmans wrote:
Hi Tibor,

as I wrote in my first email the limits were changed up to 8MB. The
entries are:

php.ini:
memory_limit: 16MB
upload_max_filesize: 8MB
post_max_size: 8MB
max_input_time: 300

upload_max_filesize and post_max_size deal with uploads from a browser,
not email attachments. Everytime you go to view an email, we use the
mime_decode class to parse the email. Unfortunately, this class is very
wasteful, and can take between 2 and 5 times the memory. Just for
testing purposes, try increasing the memory limit in php.ini, and seeing
if it works. You can also just increase it in config.inc.php by calling
ini_set('memory_limit', '64M');

/bryan

mysql.ini:
max_allowed_packet: 8MB

Apache was restarted and MySQL was reloaded. The admin will restart
MySQL at the end of the day. So I can test it tomorrow again.

The problem is still there. :( Any other suggestions?

Regards
Frank Tilmans

Frank,

I had similar problems before to display issues which had large
attachments. The real problem was not around the display attempt but
earlier when the attachment was stored during the incoming email
processing. My problem was the size limit being too small. At email
processing time the attachment storage failed resulting in improper
state of the issue in the database (that's another question why that
happens) which prevented proper display of the issue later.
I had to increase the corresponding limits in both php.ini and mysql.ini
AND restart Apache to get the changes in effect. MySQL has some
packet_size or something like that to increase - if you need the exact
name let me know.
I am not sure you hit the same problem but could be close.

Tibor

Frank Tilmans wrote:
Hi,

okay, I understand the advantages of saving attachments in the database.
It was just a thought of saving the attachments in folders - in order to
solve my problem. ;-)

I didn't also thought that MySQL could habe problems saving huge
attachments. But I sent yet another test email (zipped some files up to
4MB). And it happened again.

The only way to solve the problem is to decrease the file attachment
size to 2.5MB or 3MB. Btw, what happens with emails which are send
directly to eventum and the file size is higher than the maximum size?

Here ist the javascript error I got when I click on the plus:

Line: 232
Character: 5
Error: 'null' is Null or no object
Code: 0
URL: http://[urltoeventum]/view.php?id=263

Regards
Frank

Hi,

The main problem apart, I very much like the idea of having even
attachments in the DB because we have all the data required in one

place

and taking backups and restoring from backups are a breeze. Also
Integrity of data is ensured here - no dangling references to file
attachments that are deleted somehow in the File Server!!

In olden days, where space occupied in the DB was a big concern, they
used to have the scheme of storing the file paths in a file server

with

the actual data in the latter. But I guess and I strongly hope that

in

today's DBs especially MySQL, having such file attachments in the DB
itself however large, shouldn't be a problem.

Thanks and rgds,
Watson

Message
From: Frank Tilmans [mailto:tilmans (AT) incas-voice (DOT) de]
Sent: Tue, 29-Aug-2006 15:28
To: eventum-users (AT) lists (DOT) mysql.com
Subject: Problems with huge attachments

Hi,

this morning I found out that I couldn't reply to an associated email.

I

got a very blank page. Also, when I clicked on the plus (+) in the
associated email list I got an javascript error. The issue had an
attachment with a size of 4MB, so my first thought was: It's too

great.

All entries in php.ini and mysql.ini where changed to 8MB. So where's
the problem?

After a little bit testing I found out, that it was indeed the huge
attachment. Sending another email with a 4MB attachment to a

testproject

caused the same problem.

So I looked into the database with phpmyadmin. But I had problems to
open the related entries in the tables eventum_issue_attachment_file

and

eventum_support_email_body. The only way to solve it was to delete the
entry in eventum_issue_attachment_file and to update the column
seb_full_email in eventum_support_email_body to any text.

Is it possible that MySQL cannot handle with such huge entries?

Is there a way to save attachments in folders and to save in the
database the link to this file instead of saving the attachment in the
database?

Best regards
Frank Tilmans