|Anonymous | Login | Signup for a new account||22 May 19 16:16 BST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000309||Messenger Pro||misc||public||19 Jan 15 18:45||17 Apr 15 15:03|
|Summary||0000309: Are log datasets being flushed properly?|
|Description||MP V126.96.36.19902 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).
|Tags||No tags attached.|
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.|
14 Apr 15 13:21
Because of my XP systems' disk problems I've just installed MP V188.8.131.5281 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.
17 Apr 15 15: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.
|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 13:21||JNicoll||Note Added: 0000406|
|14 Apr 15 13:21||JNicoll||Status||resolved => feedback|
|14 Apr 15 13:21||JNicoll||Resolution||fixed => reopened|
|17 Apr 15 15:03||JNicoll||Note Added: 0000407|
|17 Apr 15 15:03||JNicoll||Status||feedback => assigned|
|Copyright © 2000 - 2019 MantisBT Team|