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 09:48, Glenn Steen wrote:
>>
>> 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?
>>
>
> No, for everything with Postfix. It will just mean a change in algorithm to
> produce the 5-digit key, no change in logging, data stored or anything else.
>
> Jules
>
Ok. Beta soonish?

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