Closed
Bug 32222
Opened 24 years ago
Closed 23 years ago
Send mail and duplicate in Sent should happen asnchronously
Categories
(MailNews Core :: Backend, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: jefft, Assigned: mscott)
References
Details
(Whiteboard: [nsbeta1+])
Attachments
(2 files)
Users cannot do anything when sending big attachment over slow momdem (say 56k modem). It will be a very bad first-hand experience to the user.
Comment 3•24 years ago
|
||
Jeff, you don't mean that you want to put a copy in the Sent folder before the message was successfully sent, do you?
No. What I meant is all the sending and copying process should happen in the background or at least time slicing it. We shouldn't tight up the cpu so that user cannot do anything other than sit there waiting...
Comment 5•24 years ago
|
||
Not M16 stopper, marking M17. Please add beta2 keyword if you think this is a beta2 stopper.
Target Milestone: M16 → M17
This is being talked about as an "exception" item in the PDT meetings. Marking nsbeta2 keyword so it can be official whether we are going to have this for beta2 or now.
Keywords: nsbeta2
Comment 7•24 years ago
|
||
It's actually not on the current exception proposal list. If you think it's a feature that we have to have for beta2, rather than a bug we can fix after beta2, perhaps it should be on the exception list.
Putting on [nsbeta2-] radar. Putting on the nsbeta2 radar.
Keywords: nsbeta3
Whiteboard: [nsbeta2-]
Comment 10•24 years ago
|
||
- per mail triage
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
Target Milestone: M17 → Future
Reporter | ||
Comment 11•24 years ago
|
||
Adding mail1 keyword. We need to address this sooner than later....
Keywords: mail1
Reporter | ||
Comment 12•24 years ago
|
||
*** Bug 34070 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
reassigning jefft's bugs to naving
Assignee: jefft → naving
Status: ASSIGNED → NEW
Comment 14•24 years ago
|
||
Bug 34070 (Mail appears to hang upon sending large messages) is a dupllicate of this, verifying it as such. However the summary of this bug makes it awkward to compare bugs to, espcially is reporting a new bug. Suggest summary altered. Something like 'sending large mail messages too slow'
Comment 15•24 years ago
|
||
I think Jeff was going to try to fix this and then it turned out to be hard. Any ideas on how much work this would be?
Comment 16•24 years ago
|
||
Scott or David, do you have any idea about the amount of work this would take?
Comment 17•24 years ago
|
||
It's just a matter of either doing this as part of a url (e.g., a file: url) or using timers to simulate time slicing (e.g., start a recurring timer whose callback does 16K of the work) and then stops the timer when done, and picks up the send operation where it left off. The hard part might be that last bit.
Assignee | ||
Comment 18•24 years ago
|
||
Naving, do you mind if I take this? I have to fix this in order to implement progress on the smtp send operation.
Comment 19•24 years ago
|
||
Go ahead
Assignee | ||
Comment 20•24 years ago
|
||
Thanks. I've been working with the necko folks to add the ability to properly implement AsyncWrite (well they did all the work I just nodded by head =)). We should now be able to leverage off of that to send the message in chunks instead of sitting in a blocking while loop sending the entire message.
Assignee | ||
Comment 22•24 years ago
|
||
I've implemented AsyncWrite for both smtp and news and re-written how we do posting to leverage this. This should make a huge change for perceived performance of message posting. Unfortunately these changes are blocked by changes I need from the necko branch dougt is on. Without those changes AsyncWrite does not work. This bug blocks 65209 which is "report progress on sending messages". If the sending isn't Async then there is never any progress to report =).
Blocks: 65209
Status: NEW → ASSIGNED
Assignee | ||
Comment 23•24 years ago
|
||
Comment 24•24 years ago
|
||
pretty cool, Scott, sr=bienvenu. One thing, though, can we come up with a better error code than NS_ERROR_FAILURE? We're going to have to get rid of all of those at some point.
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
Great news, this actually works! Now that the necko branch landed I was able to actually try it out. I can really notice the "perceived" performance gain when sending large files now that we no longer block the UI for the duration of the smtp send. This patch just contains some changes to make it build with the necko changes. Many thanks to darin and doug for making AsyncWrite on a socket work! One cool side effect: we don't need to read the message into a buffer in order to scan for "LF." pairs before sending. I was able to write the send code to check for this case by "peeking" into the input stream and not actually reading the data out into a buffer. Hopefully I'll land this, this weekend.
Assignee | ||
Comment 27•23 years ago
|
||
*** Bug 72857 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 28•23 years ago
|
||
I just checked a modified version of the patch from 2/10 into the tree. I had to add code to pause and resume the file transport used to asynchronously read in the post data file to fix some problems with large attachments. We weren't sending data out faster than the file transport was reading it in. QA: to test this, first make sure that basic sending works for you =). Varada, Jean-Francois and I have been running a variant of this code in our trees for a couple weeks to make sure it was okay but you never know. It was tricky code. Try sending yourself some messages with really large attachments. Before, when you hit the send button, the 3-pane would freeze since the UI thread blocked until the message was sent. Now you should be able to do other operations and the UI should be very responsive during the send operation.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 29•23 years ago
|
||
Does this bug verification depend on 65209? Or can I verify this without 65209 fixed?
Comment 30•23 years ago
|
||
verified by sending large files which took a while to send and also made sure that it did not block the UI for that duration. Could perform other operations while it was in progress. Cool! 2001050706-win98 2001050209-mac 2001050708-linux verified on the dial up machine in the lab on buildid: 2001043008
Status: RESOLVED → VERIFIED
Comment 31•23 years ago
|
||
*** Bug 79790 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•