Alex, We have those parameters configured, and what Juan describes is what's actually happening:
If you configure it to retry X times every 30 seconds, and the app handling the DLR's doesn't answer, the DLR's are kept _in memory_ (not the store, so if you shutdown smsbox you lose them) and when the app starts answering they are retried, but one every 30 seconds. Regards, -- Alejandro Guerrieri [email protected] On 25/02/2010, at 17:32, Alexander Malysh wrote: > Hi Juan, > > as far as I see in source code, DLRs handled the same. So please try with > those 2 config options. > > Thanks, > Alexander Malysh > > Am 25.02.2010 um 14:54 schrieb Juan Nin: > >> Alex, I'm not sure if you were that night on Barcelona with Alejandro, >> Stipe, etc, but I asked him to ask you guys about DLR retries... >> DLR retries don't look at all into http-request-retry and >> http-queue-delay, or at least don't follow the expected behavior. >> >> Instead, each DLR that failed to be posted to it's dlr-url gets >> retried in a fashion of 1 DLR every 30 seconds. Not each separate DLR >> every 30 seconds, but _only_ 1 DLR every 30 seconds, which is >> obviously not good at all, since if you got many queued DLRs that >> failed to be posted, then they will take an eternity to be retried... >> >> And what was replied to Alejandro was that no doubt it was a bug. >> >> do you think this is something that could easily be fixed? >> >> >> On Thu, Feb 25, 2010 at 7:45 AM, Alexander Malysh <[email protected]> wrote: >>> Hi Arkadiy, >>> why don't you read userguide? >>> http-request-retry integer If set, specifies how many retries should be >>> performed for failing HTTP requests of sms-services. Defaults to 0, which >>> means no retries should be performed and hence no HTTP request queuing is >>> done. >>> http-queue-delay integer If set, specifies how many seconds should pass >>> within the HTTP queuing thread for retrying a failed HTTP request. Defaults >>> to 10 sec. and is only obeyed if http-request-retry is set to a non-zero >>> value. >>> Thanks, >>> Alexander Malysh >>> Am 25.02.2010 um 10:26 schrieb Arkadiy Kulev: >>> >>> Hello Guys, >>> >>> I am wondering, why are HTTP_MAX_RETRIES and HTTP_RETRY_DELAY >>> disabled in gw/smsbox.c? >>> >>> For instance, I use dlr-url to keep track of my deliveries (the url >>> itself has an internal ID of the message that I use in my software). >>> >>> What if my HTTP server goes down? I loose the notification. >>> >>> The access.log doesn't show the dlr-url, so I can't understand which >>> of the messages correspond to which message ids in my software. >>> >>> It would be cool, if I could configure kannel to keep resending the >>> DLR to my HTTP server every N seconds for Y times (or maybe forever), >>> until it gets through. >>> >>> So why is it disabled? >>> >>> Arkadiy Kulev mailto:[email protected] >>> +7 495 5070602 >>> Moscow, Russia >>> >>> >>> >>> >> >> >> >> -- >> Juan Nin >> 3Cinteractive / Mobilizing Great Brands >> http://www.3cinteractive.com >> > >
