Found nn messages in the processing-messages database

[Julian Field]

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

-- 
Julian Field MEng CITP CEng
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

Need help customising MailScanner?
Contact me!
Need help fixing or optimising your systems?
Contact me!
Need help getting you started solving new requirements from your boss?
Contact me!

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.