Got a packet bigger than 'max_allowed_packet'

Got the following error after somebody provided comment via email with
the attachement. Attachment was about 1.3MByte which is lower then the
limit of the message on my sendmail (sendmail.mc: O
MaxMessageSize=100000000) and rt (RT_SiteConfig.pm:
Set($MaxAttachmentSize , 10000000);). The ticket was processed three
more times in one hour intervals and then looping stopped.
Here is the error in /usr/local/rt3/var/log/rt.log:

[Wed Jun 11 00:36:00 2003] [debug]: Found a ticket ID. It’s 2189
(/usr/local/rt3/lib/RT/EmailParser.pm:261)
[Wed Jun 11 00:36:00 2003] [warning]: DBD::mysql::st execute failed: Got
a packet bigger than ‘max_allowed_packet’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 386.
(/usr/local/rt3/lib/RT.pm:226)
[Wed Jun 11 00:36:00 2003] [warning]: RT::Handle=HASH(0x99ecf60)
couldn’t execute the query ‘INSERT INTO Attachments (Subject,
ContentType, Filename, Headers, Creator, Parent, Created, ContentEncodi
ng, Content, TransactionId) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 393.
(/usr/local/rt3/lib/RT.pm:226)

Any ideas? Thanks
-Peter

Peter Ziobrzynski, mailto:pzi@pzi.net

I will answer my own question:
A classic case of RTFM - this parameter is the MySQL parameter that is
set in /etc/my.cnf and by default is 1M and can be as big as 16M.

Peter Ziobrzynski wrote:

Got the following error after somebody provided comment via email with
the attachement. Attachment was about 1.3MByte which is lower then the
limit of the message on my sendmail (sendmail.mc: O
MaxMessageSize=100000000) and rt (RT_SiteConfig.pm:
Set($MaxAttachmentSize , 10000000);). The ticket was processed three
more times in one hour intervals and then looping stopped.
Here is the error in /usr/local/rt3/var/log/rt.log:

[Wed Jun 11 00:36:00 2003] [debug]: Found a ticket ID. It’s 2189
(/usr/local/rt3/lib/RT/EmailParser.pm:261)
[Wed Jun 11 00:36:00 2003] [warning]: DBD::mysql::st execute failed:
Got a packet bigger than ‘max_allowed_packet’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 386.
(/usr/local/rt3/lib/RT.pm:226)
[Wed Jun 11 00:36:00 2003] [warning]: RT::Handle=HASH(0x99ecf60)
couldn’t execute the query ‘INSERT INTO Attachments (Subject,
ContentType, Filename, Headers, Creator, Parent, Created, ContentEncodi
ng, Content, TransactionId) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 393.
(/usr/local/rt3/lib/RT.pm:226)

Any ideas? Thanks
-Peter

Peter Ziobrzynski, mailto:pzi@pzi.net

Does this mean that 16M is the biggest record mysql can handle? Ouch, I
am in deep shit then. We use rt to recieve advertisements for a
newspaper, and some attachments can be way more than 16 M. Anyone know
a workaround for this?

MarcusOn torsdag, jun 12, 2003, at 02:04 Europe/Oslo, Peter Ziobrzynski wrote:

I will answer my own question:
A classic case of RTFM - this parameter is the MySQL parameter that is
set in /etc/my.cnf and by default is 1M and can be as big as 16M.

Peter Ziobrzynski wrote:

Got the following error after somebody provided comment via email
with the attachement. Attachment was about 1.3MByte which is lower
then the limit of the message on my sendmail (sendmail.mc: O
MaxMessageSize=100000000) and rt (RT_SiteConfig.pm:
Set($MaxAttachmentSize , 10000000);). The ticket was processed three
more times in one hour intervals and then looping stopped.
Here is the error in /usr/local/rt3/var/log/rt.log:

[Wed Jun 11 00:36:00 2003] [debug]: Found a ticket ID. It’s 2189
(/usr/local/rt3/lib/RT/EmailParser.pm:261)
[Wed Jun 11 00:36:00 2003] [warning]: DBD::mysql::st execute failed:
Got a packet bigger than ‘max_allowed_packet’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 386.
(/usr/local/rt3/lib/RT.pm:226)
[Wed Jun 11 00:36:00 2003] [warning]: RT::Handle=HASH(0x99ecf60)
couldn’t execute the query ‘INSERT INTO Attachments (Subject,
ContentType, Filename, Headers, Creator, Parent, Created,
ContentEncodi
ng, Content, TransactionId) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)’ at
/usr/lib/perl5/site_perl/5.8.0/DBIx/SearchBuilder/Handle.pm line 393.
(/usr/local/rt3/lib/RT.pm:226)

Any ideas? Thanks
-Peter


Peter Ziobrzynski, mailto:pzi@pzi.net


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

This e-mail has been protected by Song Networks’ virus-scan service:
http://www.securemail.no

Does this mean that 16M is the biggest record mysql can handle?

With MySQL 3.23, yes. MySQL 4 can handle up to 2G, though I don’t know
what DBD::mysql supports.

Sebastian

Sebastian Flothow
sebastian@flothow.de

Because it reverses the logical flow of conversation.
Why is top posting frowned upon?

Hmm, I’m running MySQL 4, and still getting these errors on inserting a
25mb mail with max_allowed_packet set to 200MB Weirdness.
Hmm, seems like
http://groups.google.com/groups?q=mysql4+max+blob&hl=en&lr=&ie=UTF-
8&oe=utf-8&selm=balmqh%2416hu%241%40FreeBSD.csie.NCTU.edu.tw&rnum=1
describes an alternative approach to huge blobs. This seems to have
some advantages over how RT is doing it today?

MarcusOn torsdag, jun 12, 2003, at 13:49 Europe/Oslo, Sebastian Flothow wrote:

Am Donnerstag den, 12. Juni 2003, um 12:56, schrieb Marcus Ramberg:

Does this mean that 16M is the biggest record mysql can handle?

With MySQL 3.23, yes. MySQL 4 can handle up to 2G, though I don’t know
what DBD::mysql supports.

Sebastian


Sebastian Flothow
sebastian@flothow.de

Because it reverses the logical flow of conversation.
Why is top posting frowned upon?

This e-mail has been protected by Song Networks’ virus-scan service:
http://www.securemail.no

||Here is a quote from 4.x mysql manual:

max_allowed_packet||
The maximum size of one packet. The message buffer is initialized to
|net_buffer_length| bytes, but can grow up to |max_allowed_packet|
bytes when needed. This value by default is small, to catch big
(possibly wrong) packets. You must increase this value if you are
using big |BLOB| columns. It should be as big as the biggest |BLOB|
you want to use. The current protocol limits |max_allowed_packet| to
16M.

Sebastian Flothow wrote:

Am Donnerstag den, 12. Juni 2003, um 12:56, schrieb Marcus Ramberg:

Does this mean that 16M is the biggest record mysql can handle?

With MySQL 3.23, yes. MySQL 4 can handle up to 2G, though I don’t know
what DBD::mysql supports.

Sebastian


Sebastian Flothow
sebastian@flothow.de

Because it reverses the logical flow of conversation.
Why is top posting frowned upon?


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Peter Ziobrzynski, mailto:pzi@pzi.net

oops, I was quoting from 4.0.0alpha manual on my disk. I went to
internet
http://www.mysql.com/documentation/mysql/bychapter/manual_MySQL_Database_Administration.html#MySQL_Database_Administration
updated copy and see 1G as the limit. Here is the quote:

|max_allowed_packet| The maximum size of one packet. The message buffer
is initialised to |net_buffer_length| bytes, but can grow up to
|max_allowed_packet| bytes when needed. This value by default is small,
to catch big (possibly wrong) packets. You must increase this value if
you are using big |BLOB| columns. It should be as big as the biggest
|BLOB| you want to use. The protocol limits for |max_allowed_packet| is
16M in MySQL 3.23 and 1G in MySQL 4.0.

Peter Ziobrzynski wrote:

||Here is a quote from 4.x mysql manual:

max_allowed_packet||
The maximum size of one packet. The message buffer is initialized to
|net_buffer_length| bytes, but can grow up to |max_allowed_packet|
bytes when needed. This value by default is small, to catch big
(possibly wrong) packets. You must increase this value if you are
using big |BLOB| columns. It should be as big as the biggest |BLOB|
you want to use. The current protocol limits |max_allowed_packet| to
16M.

Sebastian Flothow wrote:

Am Donnerstag den, 12. Juni 2003, um 12:56, schrieb Marcus Ramberg:

Does this mean that 16M is the biggest record mysql can handle?

With MySQL 3.23, yes. MySQL 4 can handle up to 2G, though I don’t
know what DBD::mysql supports.

Sebastian


Sebastian Flothow
sebastian@flothow.de

Because it reverses the logical flow of conversation.
Why is top posting frowned upon?


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Peter Ziobrzynski, mailto:pzi@pzi.net