RE: [PATCH] Kannel resending old unsuccessful messges after a box restart.BUG?

Agreed.  I was just strict to an exponential backoff alghorithm.

> -----Original Message-----
> From: Oded Arbel [mailto:[email protected]]
> Sent: terça-feira, 27 de agosto de 2002 12:58
> To: Mauricio Ramos; Damjan; [email protected]
> Subject: RE: [PATCH] Kannel resending old unsuccessful messges after a
> box restart.BUG?
> 
> 
> Currently it'll continue to double the wait time with no 
> upper limit. since I assume that eventually the SMPP server 
> will agree to send a message w/o responding with a throttling 
> error, and the double type can hold enough data to represent 
> time length much longer then a year ( ;-> ) then I don't 
> think it's a problem.
> 
> --
> Oded Arbel
> m-Wise mobile solutions
> [email protected]
> 
> +972-9-9581711 (116)
> +972-67-340014
> 
> ::..
> When I was 16, I thought there was no hope for my father.  By 
> the time I was
> 20, he had made great improvement.
> 
> 
> > -----Original Message-----
> > From: Mauricio Ramos [mailto:[email protected]]
> > Sent: Tuesday, August 27, 2002 4:06 PM
> > To: Oded Arbel; Damjan; [email protected]
> > Subject: RE: [PATCH] Kannel resending old unsuccessful 
> > messges after a box restart.BUG?
> > 
> > 
> > Hi Oded,
> > 
> > A backoff alghorithm would be nice!  It sounds like Postifx MTA.
> > 
> > But, is there a limit or Kannel would be backing off until forever?
> > 
> > Regards.
> > 
> > > -----Original Message-----
> > > From: Oded Arbel [mailto:[email protected]]
> > > Sent: domingo, 25 de agosto de 2002 14:58
> > > To: Oded Arbel; Damjan; [email protected]
> > > Subject: [PATCH] Kannel resending old unsuccessful messges 
> > after a box
> > > restart.BUG?
> > > 
> > > 
> > > Hi list.
> > > 
> > > Attached is a patch to introduce configurable throttling 
> > > delay with backoff. the patch adds another configuration 
> > > option: 'throttling-delay' that is used as the base delay for 
> > > a simple backoff mechanism that will simply double the last 
> > > sleep time and sleep again, if it after sleeping and sending 
> > > it received another throttling error.
> > > 
> > > Warning - this patch is _not_ tested ! it simply compiles. I 
> > > would like to have comments on the code, the solution methods 
> > > and the new configuration option name. testing would be nice 
> > > too :-) I'll try to find time to upload the changes to a test 
> > > platform tommorow.
> > > 
> > > --
> > > Oded Arbel
> > > m-Wise mobile solutions
> > > [email protected]
> > > 
> > > +972-9-9581711 (116)
> > > +972-67-340014
> > > 
> > > ::..
> > > In shallow waters, shrimps make fools of dragons.
> > > 	-- Chinese Proverb
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Oded Arbel 
> > > > 
> > > > >>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' ?
> > > 
> > 
>