View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000309Messenger Promiscpublic19 Jan 15 18:4517 Apr 15 14:03
Assigned Tomark 
PlatformWindowsOSXPOS VersionHome
Summary0000309: Are log datasets being flushed properly?
DescriptionMP V2.72.0.3902 4.8.6 XP Home (32-bit)

I've found recently several logs that appear not
to have as much data in them as they should and
am beginning to wonder if they're being flushed
properly before they are closed.

For example in one experiment I started MP, did
one import of a message from a file (with mail
filters on) then shut MP. The app log neither
showed tracing of all filters (which I'd have
expected in that instance), nor anything to do
with MP shutting down (though I have no idea if
I should expect the latter).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
mark (administrator)
04 Mar 15 14:49

By default MPro doesn't flush logs on each update in order to maintain performance, although this is configurable. However, it does appear that if flushing is disabled and there are pending updates when MPro is shut down, these writes won't take place. I've put a fix for this in v2.73.1.
JNicoll (reporter)
14 Apr 15 12:21

Because of my XP systems' disk problems I've just installed MP V2.73.1.4181 Qt 5.4.1 on a newish Win 8.1 (64-bit) machine, and populated its data folder with the contents of my most-recent (a fortnight old, unfortunately) set of files from a v2.72 MP install on one of my borked machines (files from Dropbox - hooray for Dropbox!).

When I first started the v2.73 app I left the LAN cable unplugged and immediately configured all the fetching accounts not to do an auto-fetch, because I don't fancy a deluge of activity as MP tries to catch up, especially when I don't yet have my MP log archiving mechanism installed on this new machine. That'll be tonight's activity, I think...

After that I cautiously tried to enable one nntp fetcher, knowing it would have only a handful of posts to collect... which it did. I opened a W8 file manager viewer and found the directory corresponding to that account... and - knowing that v2.73.1 is meant to flush its logs every 5 seconds - was surprised to see the Log file shown as having no content.

I then used MP's View - Transfer Logs dialog to peek into the log concerned, at which point file manager showed it now had data in it. So I think there must be some doubt whether the new flushing logic is being called at every opportunity.
JNicoll (reporter)
17 Apr 15 14:03

I've also had an instance of a log that MP had finished writing to (at least I assume so as it was maybe 15 seconds after the status bar in MP had reverted to 'Ready' at the end of a fetch) which I could not open with a text editor because 'another process' had it in exclusive use. After using MP's View - Transfer Logs - thataccount - Close, I was able to open it externally. Is MP not closing log files after a flush? The logs - indeed the whole app - are on a SSD, if that matters.

In Options there's an option for having the log files updated all the time; I don't have that ticked. I'm assuming that that writes all updates out to disk as soon as they are appended to a log and would be very slow. I'm not asking for that, but do think that when a fetch comes to an end that the corresponding account's log file should be uptodate and closed.

- Issue History
Date Modified Username Field Change
19 Jan 15 18:45 JNicoll New Issue
03 Mar 15 12:47 mark Status new => acknowledged
04 Mar 15 14:49 mark Note Added: 0000397
04 Mar 15 14:49 mark Status acknowledged => resolved
04 Mar 15 14:49 mark Resolution open => fixed
04 Mar 15 14:49 mark Assigned To => mark
14 Apr 15 12:21 JNicoll Note Added: 0000406
14 Apr 15 12:21 JNicoll Status resolved => feedback
14 Apr 15 12:21 JNicoll Resolution fixed => reopened
17 Apr 15 14:03 JNicoll Note Added: 0000407
17 Apr 15 14:03 JNicoll Status feedback => assigned

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker