Found nn messages in the processing-messages database

[Julian Field]

On 22/4/09 15:55, Mark Sapiro wrote:
> Julian Field wrote:
>    
>> On 22/4/09 00:43, Mark Sapiro wrote:
>>      
>>> Julian Fieldwrote:
>>>
>>>        
>>>> On 21/4/09 21:11, Mark Sapiro wrote:
>>>>
>>>>          
>>>>> On Tue, Apr 21, 2009 at 06:58:30PM +0100, Julian Field wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> Please also try MailScanner 4.76.15 and let me know how you get on. I
>>>>>> have neatened up the code quite a bit.
>>>>>>
>>>>>> Jules.
>>>>>>
>>>>>> On 21/4/09 18:04, Julian Field wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> In /usr/lib/MailScanner/MailScanner/Message.pm, around line 1243, you
>>>>>>> will find a line that says
>>>>>>> next if $message->{abandoned};
>>>>>>> Please try commenting out that line by putting a '#' at the start of it.
>>>>>>>
>>>>>>> Then restart MailScanner, and let me know if that solves the problem.
>>>>>>>
>>>>>>> Thanks for your patience in helping me resolve this issue!
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>> I installed 4.76.15. Am I also supposed to comment the above line in
>>>>> 4.76.15 or was that just for 4.76.14? I did not comment the line, and
>>>>> I am still seeing messages left in the database.
>>>>>
>>>>>
>>>>>            
>>>> It was just for .14. I am really running out of ideas here. There is no
>>>> way the thing would fail unless the DELETE was failing.
>>>> If it doesn't manage to find the complete message, it doesn't add it to
>>>> the database. I made extra doubly sure of that in .15, so I really can't
>>>> see how it is getting left in there. If it was doubly added to the
>>>> database, it would still get deleted, unless the delete itself was
>>>> failing. I wonder if the DBI parameter substitution is handling the
>>>> parameter string incorrectly if it's all decimal digits, thinking it's a
>>>> number and not a string?
>>>>
>>>> Here's a patch for 4.76.15 for you to try that will test this hypothesis.
>>>>
>>>> ---PATCH START---
>>>> --- MessageBatch.pm.old    2009-04-21 21:33:37.000000000 +0100
>>>> +++ MessageBatch.pm    2009-04-21 21:35:03.000000000 +0100
>>>> @@ -1259,7 +1259,8 @@
>>>>
>>>>      foreach $id (keys %gotridof) {
>>>>        next unless $id;
>>>> -    $sth->execute($id);
>>>> +    #$sth->execute($id);
>>>> +    $MailScanner::ProcDBH->do("DELETE FROM processing WHERE (id='$id')");
>>>>      }
>>>>      $sth->finish;
>>>>
>>>> ---PATCH END---
>>>>
>>>> As you can see, it's a simple one-liner. Please let me know if it makes
>>>> any difference.
>>>>
>>>>          
>>> I have installed the patch and it is encouraging so far. While it is
>>> too soon to say for sure that there won't be any residual entries in
>>> the database, I've been running for over 2 hours and processed at
>>> least one large batch of outgoing messages, and don't have any yet.
>>>
>>>
>>>        
>> If it proves that solves the problem, I have another alternative I would
>> like you to try as it will be faster, if it works around the Perl bug.
>> Instead of
>>      $MailScanner::ProcDBH->do("DELETE FROM processing WHERE (id='$id')");
>> make the line say
>>      $sth->execute("$id");
>> and give that a go. Notice it is *almost* the same as the line was
>> before, but with quotes around the $id. That may be enough to circumvent
>> this bug.
>>      
>
> I am certain the first patch fixed the problem.
Wonderful!
In that case, a big "Well done" to whomever noticed that all the 
messages stuck in the database were all numeric before the decimal 
point, as that's what finally alerted me to the possibility of this 
being a Perl bug.

>   I am now trying the
> alternative. I will report back this evening (my time - tomorrow UTC).
>    
Thanks. If the alternative works, it will be faster.

Jules

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

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
PGP public key: http://www.jules.fm/julesfm.asc


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