Re: PROBLEM: Successful failure notification making messages to b e resended

Mauricio Ramos wrote:

>Hi,
>
>It's good (or not) to know that somebody else has the same problem.
>
>I don't agree to you idear at all since I use the Kannel's notification
>feature (sendsms cgi with dlrmark/dlrurl fields) to makes my Application
>aware of the failure and than the Application itself takes charge of the
>resending process.  It means if the Application deliver the message
>successfuly next time, Kannel will improperly resend the obsolete message,
>when being restarted, based on store-file.
>
>Once Kannel notifies the Application that a message wasn't delivered to SMSC
>(escape %d = 16) it shouldn't keep resending the message.  Actually, Kannel
>doesn't "keep resending" the message, but when it's restarted, for some
>reasone it reads the failed messages from store-file and resends them again.
>It's inconsitent in my point of view.
>
>I think the solution is:
>
>Each DLR successfuly delivered to an Application MUST be removed from
>store-file.
>
>I consider this a bug.  Unfortunatelly I don't have resources to assess the
>source code and try to fix it, but will be pleased to help on testing.
>
>Any other opinions?
>
>Mauricio
>
>-----Original Message-----
>From: Kaido Karner [mailto:[email protected]]
>Sent: quinta-feira, 1 de agosto de 2002 08:20
>To: Mauricio Ramos; [email protected]
>Subject: RE: PROBLEM: Successful failure notification making messages to
>be resended
>
>
>re
>
>  
>
>>I realized that every time Kannel successfuly notify my Application that
>>messages hadn't been delivery to SMSC (escape %d = 16) it write a new line
>>in store-file, so every notification of a message not sent increases the
>>store-file.
>>
>>The actual problem is when I restart Kannel.  When it happens,
>>Kannel resend
>>all those messages written in store file which in my point of
>>view shouldn't
>>happen because my Application looked after those messages when it had
>>received the original DLR.
>>    
>>
>
>I have the same problem - if by some reason (network error for example) the
>message is not sent and is waiting in the storefile. no attempt is made to
>resend it, before the bearerbox is restarted. imagine this can happen says
>later - the message is obsolete at this time anyway. so - the good solution
>would be to try to resend the message if some reasonable time is passed - or
>even better - when the appropriate smsc connection seems to be alive again.
>the quick-and-dirty solution would be clearing the storefile at graceful
>shutdown of the bearerbox - loosing some messages seems a better alternative
>to me than resending them days later.
>
>now I'm start to think that implementation of resending them at some
>reasonable time (several minutes for example) after failure should not be
>very big work .. add a thread to poll the store at some interval for
>messages old enough and trying to re-send them. however, the store should
>have something to know if the attempt to send a particular message is even
>performed. this is easily implemented by adding a special message type
>(send_attempt or something) and adding this to store each time the message
>just before sending the message. then the polling thread can look the store
>for messages which have been attempted to send, but don't have ack after
>some time, and resend them. did I miss something?
>
>maybe somebody have appropriate patch already?
>  
>
I've encountered this problem too, but for looking at the source code - 
I can't say why it happens : the source code for handling of message 
ACKs seems to be correct.

--
Oded Arbel
m-Wise mobile solutions

::..
Reasons to Run Away 39-"You just cast a fireball at the villain down a 10X10 hallway and he slams a heavy stone door..."