hi,
i just experienced that if a message is larger than the php memory limit, then RCD simply fails to open it.
The msg was 85Mb (a large attachment), i set a 64Mb limit on php and i'm using the latest release version v0.1.1 and it was viewed in the preview mode.
Can anybody confirm this?
On Wed, May 21, 2008 at 11:52 AM, pete pete@teamlupus.hu wrote:
hi,
i just experienced that if a message is larger than the php memory limit, then RCD simply fails to open it.
The msg was 85Mb (a large attachment), i set a 64Mb limit on php and i'm using the latest release version v0.1.1 and it was viewed in the preview mode.
Can anybody confirm this?
In short: 64 MB < 85 MB :-D
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, 21 May 2008 11:57:05 +0200, till klimpong@gmail.com wrote:
On Wed, May 21, 2008 at 11:52 AM, pete pete@teamlupus.hu wrote:
hi,
i just experienced that if a message is larger than the php memory
limit,
then RCD simply fails to open it.
The msg was 85Mb (a large attachment), i set a 64Mb limit on php and i'm using the latest release version v0.1.1 and it was viewed in the preview mode.
Can anybody confirm this?
In short: 64 MB < 85 MB :-D
Till
Okay, i got it :)
Is there a way to modify this behavior to show some text, like "This message is too large to view it" instead of the message body and not to try to open it? From imap headers, it's possible to determine the msg size, and from PHP variables the amount of allowed memory, so technically it is possible.
pete wrote:
In short: 64 MB < 85 MB :-D
Till
Okay, i got it :)
Is there a way to modify this behavior to show some text, like "This message is too large to view it" instead of the message body and not to try to open it? From imap headers, it's possible to determine the msg size, and from PHP variables the amount of allowed memory, so technically it is possible.
we're waiting for your patch ;)
cheers, raoul
64 MB < 85 MB :-D
Are we making use of the imap server features to pull bodies versus attachments seperately? If so, I'd imagine that it'd be possible to stream attachments out instead of reading them as large blobs.
(I wish I could provide patches. but I realistically can't, not with my current employment.)
List info: http://lists.roundcube.net/dev/
On Wed, 21 May 2008 15:06:48 +0200, "Raoul Bhatia [IPAX]" r.bhatia@ipax.at wrote:
pete wrote:
In short: 64 MB < 85 MB :-D
Till
Okay, i got it :)
Is there a way to modify this behavior to show some text, like "This message is too large to view it" instead of the message body and not to
try
to open it? From imap headers, it's possible to determine the msg size,
and
from PHP variables the amount of allowed memory, so technically it is possible.
we're waiting for your patch ;)
Got it, again :D
Please, could you (or somebody core devel) outline where and how would be feasible to do such a modification? Eg. in which file, which function(s) .... I'd love to try a patch, and do it right.
Jason Fesler wrote:
64 MB < 85 MB :-D
Are we making use of the imap server features to pull bodies versus attachments seperately? If so, I'd imagine that it'd be possible to stream attachments out instead of reading them as large blobs.
Yes, we do only fetch the message structure from IMAP and read the part contents separately. In case a message has a 85MB attachment this actually should work. If the message body (text part) has this size, we're out of luck...
@Pete: could you post the message outline (mime structure) without the 85Mb content? Then we can be sure that we're all talking about the same.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, May 21, 2008 at 4:36 PM, Jason Fesler jfesler@gigo.com wrote:
64 MB < 85 MB :-D
Are we making use of the imap server features to pull bodies versus attachments seperately? If so, I'd imagine that it'd be possible to stream attachments out instead of reading them as large blobs.
I think so too. Also, PHP has stream wrappers etc., there has to be a way.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Wed, 21 May 2008 19:39:11 +0200, Thomas Bruederli roundcube@gmail.com wrote:
Jason Fesler wrote:
64 MB < 85 MB :-D
Are we making use of the imap server features to pull bodies versus attachments seperately? If so, I'd imagine that it'd be possible to stream attachments out instead of reading them as large blobs.
Yes, we do only fetch the message structure from IMAP and read the part contents separately. In case a message has a 85MB attachment this
actually
should work. If the message body (text part) has this size, we're out of luck...
@Pete: could you post the message outline (mime structure) without the 85Mb content? Then we can be sure that we're all talking about the same.
~Thomas _______________________________________________ List info: http://lists.roundcube.net/dev/
Well, i deleted the message meanwhile :( When i tried to reproduce the error, i raised the mem limit to 640M, and i tried to send a message with a large 77Mb attachment to myself over Roundcube.
The error message was in the log: [22-máj-2008 11:07:59] PHP Fatal error: Allowed memory size of 671088640 bytes exhausted (tried to allocate 208171409 bytes) in /path-to-rcd-root/program/lib/Net/SMTP.php on line 788
However, a draft was saved, with a reported size of 100M, and i was able to view it, even when i set the mem limit back to 64M.
pete wrote:
Well, i deleted the message meanwhile :( When i tried to reproduce the error, i raised the mem limit to 640M, and i tried to send a message with a large 77Mb attachment to myself over Roundcube.
The error message was in the log: [22-máj-2008 11:07:59] PHP Fatal error: Allowed memory size of 671088640 bytes exhausted (tried to allocate 208171409 bytes) in /path-to-rcd-root/program/lib/Net/SMTP.php on line 788
OK, this is another issue of the PEAR package which is unable to read from streams but composes all the message content in memory before it's passed to the SMTP server.
However, a draft was saved, with a reported size of 100M, and i was able to view it, even when i set the mem limit back to 64M.
This looks like the correct behavior when reading messages.
~Thomas
List info: http://lists.roundcube.net/dev/
This is an issue of the PEAR Package and also PHPMailer which is used quite frequently.
About a year ago I was searching for a good email composing and sending class, the result: SwiftMailer - http://www.swiftmailer.org/ Is used it several times, it's perfect. Fully OOP, Go PHP5.
Regarding the current issue let me quote from their website: "Send attachments of *any* size even with PHP's 8MB Memory Limit"
So why not switch to SwiftMailer?
Balázs
Thomas Bruederli wrote:
pete wrote:
Well, i deleted the message meanwhile :( When i tried to reproduce the error, i raised the mem limit to 640M, and i tried to send a message with a large 77Mb attachment to myself over Roundcube.
The error message was in the log: [22-máj-2008 11:07:59] PHP Fatal error: Allowed memory size of 671088640 bytes exhausted (tried to allocate 208171409 bytes) in /path-to-rcd-root/program/lib/Net/SMTP.php on line 788
OK, this is another issue of the PEAR package which is unable to read from streams but composes all the message content in memory before it's passed to the SMTP server.
~Thomas
hi,
On Thu, 22 May 2008 18:11:06 +0200, Horváth Balázs horvath.balazs@wgi.hu wrote:
This is an issue of the PEAR Package and also PHPMailer which is used quite frequently. the result: SwiftMailer - http://www.swiftmailer.org/ Is used it several times, it's perfect. Fully OOP, Go PHP5. "Send attachments of *any* size even with PHP's 8MB Memory Limit"
JQuery, Swiftmailer - reasonable changes, sounds good
On Fri, May 23, 2008 at 7:10 PM, pete pete@teamlupus.hu wrote:
hi,
On Thu, 22 May 2008 18:11:06 +0200, Horváth Balázs horvath.balazs@wgi.hu wrote:
This is an issue of the PEAR Package and also PHPMailer which is used quite frequently. the result: SwiftMailer - http://www.swiftmailer.org/ Is used it several times, it's perfect. Fully OOP, Go PHP5. "Send attachments of *any* size even with PHP's 8MB Memory Limit"
JQuery, Swiftmailer - reasonable changes, sounds good
I have no objections against Swiftmailer, I just don't know it well. :-)
I guess if people see a general "error" in the current code we use, the PEAR people are generally very open to patches and improvements (I know first hand).
We are also looking into ezComponents' mail classes for the imap backend, and maybe offering a more flexible approach to "accessing" your email (for example through Maildir, Mbox etc.).
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
till wrote:
I have no objections against Swiftmailer, I just don't know it well. :-)
I guess if people see a general "error" in the current code we use, the PEAR people are generally very open to patches and improvements (I know first hand).
Did someone sent them an "attachments streaming" patch from http://public.lanl.gov/jbarbuc/patches/roundcube/ ?
We are also looking into ezComponents' mail classes for the imap backend, and maybe offering a more flexible approach to "accessing" your email (for example through Maildir, Mbox etc.).
I think imap backend is no big problem, bigger problem is messages parsing.
On Fri, May 23, 2008 at 9:32 PM, A.L.E.C alec@alec.pl wrote:
till wrote:
I have no objections against Swiftmailer, I just don't know it well. :-)
I guess if people see a general "error" in the current code we use, the PEAR people are generally very open to patches and improvements (I know first hand).
Did someone sent them an "attachments streaming" patch from http://public.lanl.gov/jbarbuc/patches/roundcube/ ?
Just done!
We are also looking into ezComponents' mail classes for the imap backend, and maybe offering a more flexible approach to "accessing" your email (for example through Maildir, Mbox etc.).
I think imap backend is no big problem, bigger problem is messages parsing.
Well, that includes it.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Horváth Balázs -
Jason Fesler -
pete -
Raoul Bhatia [IPAX] -
Thomas Bruederli -
till