Found nn messages in the processing-messages database

[Glenn Steen]

2009/4/20 Julian Field <MailScanner at ecs.soton.ac.uk>:
>
>
> On 20/04/2009 08:31, Julian Field wrote:
>>
>>
>> On 17/4/09 16:16, Kai Schaetzl wrote:
>>>
>>> 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)?
>>
>> I want to keep the extra number on the end, as it is certainly needed on
>> some systems to identify messages. But what I am thinking is to not put the
>> extra number in the processing database, as messages should normally enter
>> and exit that database very quickly.
>>
>> That would be easy to implement, I'll try to get it done today.
>
> I'm going to use a very quick and easy checksum on the start of the file.
> I'm certainly not going to cksum or MD5 it, that's *way* slower than I need.
>
> Jules
>
And only for the processing DB, right?

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se