Re: Kannel resending old unsuccessful messges after a box restart. BUG?

Damjan wrote:

>>>I've notices that 'Message Queue is full' happens when the SMSC
>>>can't queue no more messages for some of its subscribers. This
>>>usually happens when the subscriber is offline. (the SMSC will
>>>hold some 10 messages per subscriber, and every other message for
>>>that user will return 'Queue full'. The proper behavior for
>>>kannel would be to postpone the message, with an exponetial
>>>timeout - like in mail servers, and at last drop the message 
>>>(it could be configurable when to drop the messages).
>>>      
>>>
>>That's nice, but the module does not control the queue's timing, and  
>>this is rather module specific so I don't see anyone implementing this
>>anytime soon. what I'd like to see is Kannel calculating validity of
>>messages and dropping messages that are left in the queue past their
>>validity time out.
>>    
>>
>
>I think the message queue in Kannel is a pretty important
>component, maybe the modules should have more access of the queue
>API. Maybe there is also a need to re-design or improve the queue
>functinality of Kannel. I think a good queue is very important
>when handling messages in any software, as well to the Kannel SMS
>component. 
>
>Unfortunately I don't have enough knowledge of Kannels internal 
>working to help in the programing of it. So all of this is
>going to stay just my wishlist :).
>
> 
>  
>
>>>A 'Throttling error' is a really temporary failure (it not even a
>>>failure, it's a policy of your provider). 
>>>Kannel should respond to messages like this by re-calculating its
>>>sending speed (though I don't think kannel has a mechanisam for
>>>this, not in the SMPP gateway, although there were some patches
>>>about this - I think).
>>>      
>>>
>>Current CVS version does handle 'Throttling Error' properly by stoping 
>>to send messages for a predetrmind time - 15 seconds currently.
>>    
>>
>
>Thats too much, I'm using my own scripts with a perl SMPP driver,
>usually I can send some 4 messages as fast as I can send them,
>and then I get the "Throttling Error", I then wait some 0.8
>seconds and then continue to send. Actually it depends of the
>settings your SMPP provider has set-up for your connection.
>  
>
Currently it's set as a compile time option, which you can change - 15 
seconds is what O2 required of us in their credentials tests. but I 
agree it's not the best course. Here at m-Wise we usually do that, since 
most time we don't think about other people's needs as much as we 
should, as Andreas Fink pointed out, and we usually put in new features 
with a compile time option, thinking - "If we ever find a provider that 
requires a different setting - we'll add a configuration option, as it's 
simple enough". I assure you that it is pure laziness and not because we 
are bad people :-)

If the developers have no objections, I'll implement a run-time 
configuration option which will default to the compile time option 
(currently 15 seconds), first thing sunday morn. alternativly - do you 
think its possible/needed/interesting implementing some kind of 
exponential backoff mechanism that will start at a small delay and 
increase it as long as it gets consecutive 'Throttling Errors' ?

-- 
Oded Arbel
m-Wise mobile solutions

::..
"An atheist is a man who has no invisible means of support." 
	-- John Buchan, Lord Tweedmuir