Found nn messages in the processing-messages database

Kai Schaetzl maillists at conactive.com
Fri Apr 17 16:16:45 IST 2009


Julian Field wrote on Fri, 17 Apr 2009 15:49:25 +0100:

> Very likely. I don't know what that line means, but it doesn't sound 
> good does it?

This seems to be normal operation. As at the same time the refreshing of 
the MS children happened I wonder if it wasn't triggered by MS?

Anyway, (and without too much knowledge about how the processing of the 
queue in MS really works) I think the reason is that this message got 
saved to the processing db before MS refreshed itself and when MS 
processed it a second time it had a different MS id, so it didn't get 
removed.
So, the problem must be somewhere in the way that the message is kept in 
the queue and not in the db code. I see that the message got indeed 
archived with both ids, that seems to be done before any other 
scanning/processing by MS, that makes sense. Then MS closed down. Do you 
keep it in incoming? With the full MS id? The message then must have been 
there either as B48BFF9477.51697 and MS renames it or it must have already 
been renamed to B48BFF9477.D962D (and this didn't get logged so we can't 
see it) and thus not found in the db.

A simple cure to stop this might be to stop adding the extra stamp. What 
about an option? At least for my systems that seems to be safe. It might 
not be safe for other systems, that's why it should be an option.
And as the whole thing doesn't indicate any problem, anyway, maybe clean 
up old entries by yourself and add something to clean it manually (--
processing=clean)?

Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com





More information about the MailScanner mailing list