[Tickets #2315] Uploading attachment uses too much memory

bugs@bugs.horde.org bugs at bugs.horde.org
Fri Jul 29 06:22:20 PDT 2005


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=2315
-----------------------------------------------------------------------
 Ticket             | 2315
 Updated By         | nomis80 at lqt.ca
 Summary            | Uploading attachment uses too much memory
 Queue              | IMP
 Version            | 4.0.3
 State              | Feedback
 Priority           | 1. Low
 Type               | Bug
 Owners             | 
-----------------------------------------------------------------------


nomis80 at lqt.ca (2005-07-29 06:22) wrote:

=== OFF TOPIC, JUMP DOWN IF NOT INTERESTED ===

> I really am not sure what I said to set you off so much.  I was not 
> trying to be condescending, and I am sorry you took it that way.

Let me explain by rephrasing and condensing your initial reply. I submitted
a bug and you said approximately the following: "Even though I haven't
tested it, I don't think this bug is real. And you haven't done your
homework because it's in plain sight in the mailing list archives and in the
bug index, but I haven't taken the time to verify that claim. Please don't
bother us again, we're busy." Don't you understand now?

Let me take this further and explain to you how you *should* have replied,
so that you may learn from this experience. (Side note: Yeah, I am being
condescending on purpose, but in a sarcastic way.)

First, before any reply, if you think this bug has been discussed before you
absolutely need to search for the URL. If you can't be bothered to do that
you just can't reply telling me that this bug has already been discussed.
That would be considered rude. Let other people search for yourself instead
and see the bug closed without your intervention. If you think it is so
evident that the bug has already been discussed, it is so much in plain
sight, it shouldn't be hard for you to find a URL. Taking the time to find
the URL also has the advantage of preventing you from being wrong, as you
were with me. When you give a URL you have proof of your claim: the bug
really has been discussed before.

Assuming you have determined that the bug hasn't been discussed before, the
second step is, still before any reply, trying to reproduce that bug,
assuming you have any interest in fixing it. If you don't have any interest
in fixing it then you can just ignore the bug, other people will try. If you
can't reproduce it, you reply something along the lines of "Couldn't
reproduce. Test setup: mysql X.Y.Z, IMP 3.X, Apache X.", you set the state
to feedback and you wait for more info. If you can reproduce it, then you
may confirm the bug. Assuming you still are interested in fixing it, you may
proceed to actually fixing it.

Through all these steps, if you are not interested in fixing the bug, just
leave it alone. Other people will be interested.

> As far as providing a URL where you could find information - 
> unfortunately, I am not a paid support agent of Horde.  I would 
> really love to help everyone, and if I had a URL close at hand I 
> would have given it.  Instead I suggested a place you could search.

And by doing this you took a risk: maybe you were wrong, and such a URL
didn't exist. And this time, you were indeed wrong. Another guideline: don't
suggest places where one can search. That's condescending. It's exactly as
if I explained to you the initial steps in the bug fixing process (oops, I
already did that it seems).

=== BACK TO ON TOPIC STUFF ===

> First of all, internet mail is 
> not the place to be sending around 10 MB files but this religious 
> argument has already taken place on the mailing lists and I will not 
> address it anymore here.

That's not the point, but I agree: let's not be religious.

> Second, I can send 10 MB files without PHP 
> using anywhere near 320 MB of memory so it is clearly not 
> reproducible for everyone.

AH! New information! Thanks for finally trying to reproduce the bug. Can you
elaborate on what versions were used in your test setup? Were you using the
VFS for storing attachments? Let's try to isolate the bug.

> Third, this *is* a PHP issue as much as 
> you don't believe it is.

I think you misunderstand what this bug is about. This is not about "I can't
send attachments of size N or bigger". It is about "I can't send attachments
of the size IMP has been configured to accept". If I set the maximum to 10M,
I can send attachments up to about 1M. If I set the maximum to 2M, it's
about 500K. As I go smaller, the maximum size goes smaller too. But the
actual limit is never equal to what IMP has been setup to accept. That's the
problem.

Analogy: the speedometer on my car tells me I'm going at 100 km/h but I'm
really at 50. Then I go down to 50, it tells me I'm at 25. That's a
calibration problem, and it's the same kind of problem that this bug is
about.




More information about the bugs mailing list