Closed Bug 10543 Opened 25 years ago Closed 25 years ago

Correct time is not displayed for the initial PoP message folder download

Categories

(MailNews Core :: Networking, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bsharma, Assigned: scottputterman)

Details

For Messenger Performance on Windows 95, 133 MHz and 48 MB machine: Steps: 1. Delete all msf files. 2. Click on 100/500/1000 messages Folder. Time is displayed on the console which is not correct. Need this feature for Performance automation. Right now doing it manually and results are not reliable because there is no notification on UI so I have to click on the scroll bar to get to the last message.
Assignee: mscott → putterman
hey putterman...I think Bindu's talking about your timer measurements for how long it takes us to parse a mail folder. I'm sending this one to you.
Here's the situation: Scott Putterman helped us with performance testing by displaying the total time it takes to load a mail folder into the console window. However, the total time that gets displayed is not accurate when a folder which does not have a .msf file gets selected. We have been asked to track the time it takes to select a folder which needs to have a .msf file built for it. Bindu is doing this manually for now, but we need to have some automatic way to do so. I'm not sure the reasons behind why the time displayed is inaccurate when there is no .msf file. So, that's what this bug report is tracking. Thanks.
The reason I did it for the other case is because it was easy. I have ideas on how this could be done, but I make no assurances this will get done in 5.0. It's all a matter of time.
OK. I have the ability to do this. It'll start when ParseMailbox gets an OnStartRequest and end with it gets an OnEndRequest. You might see this get printed out for other things besides loading folders and you'll also see the other message for loading folders get printed out as well. In addition, I currently don't have the folder name getting printed out, so you'll see something like "time to parse = 180 seconds". But since this will come after some output listing the name of the folder, this should be ok. The same pref as before should be turned on. I'll try to get this checked in after the tree reopens for further development. I won't be ready for today.
Thank you! :-) Will this be for all platforms? (Just wondering if I need to change the platform field to All.)
OS: Windows NT → All
Hardware: PC → All
Changing platforms to ALL. This will only work for Pop though.
Target Milestone: M10
Setting M10 until I know more about M9.
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this works now. It's not saying the name of the folder, but it'll come after the other message that will say the name of the folder, so you should be able to find it. you will need the same mail.showMessengerPerformance pref set.
Bindu, to respond to your question, I think the pref needs to be set to TRUE.
Status: RESOLVED → VERIFIED
The time that is displayed on the console is not same as the time it takes to download the messages and display them on the Messenger window for any folder. When I click on the 100 Folder the "Document Done" string appears right away on the console but the status bar of the Messenger is still downloading the messages. Since, I use the console data to get the timing in automation script, I cannot get the results for Performance report for this week for both Pop and Imap.
The time that is displayed on the console is not same as the time it takes to download the messages and display them on the Messenger window for any folder. When I click on the 100 Folder the "Document Done" string appears right away on the console but the status bar of the Messenger is still downloading the messages. Since, I use the console data to get the timing in automation script, I cannot get the results for Performance report for this week for both Pop and Imap.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
I don't understand. "Document done" should have nothing to do with this. In addition, this bug wasn't meant for Imap.
If the timimg information is not applicable to Imap then we need one for Imap. Should I file a separate bug for it?
Yes, there should be a different bug for IMAP. But, I still don't understand why you can't time POP. Also, sometime within the next week I wil probably break this for pop again.
Target Milestone: M10
Bindu - are you still having problems with opening a local POP folder? What is the bug number you filed for IMAP? Or, do you want me to file one?
Target Milestone: M11
M11
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
OK. I made some changes. This is going to work differently. The preference stays the same but both the .msf case and the non .msf case will print out the same message with the name of the folder. The non .msf case will no longer print out multiple times. In theory, this also will give times for opening a news and imap folder if it's the first time you've downloaded the headers, but I'm not saying this will always work. I'm marking fixed because POP should be done now.
Status: RESOLVED → VERIFIED
This has been working for our performance testing that Bindu does for a while now.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.