Hello Alejandro, 1. Can this be fixed? (only one in 30 seconds is not good). 2. Can you put DLRs in store just in case smsbox dies?
I suppose reliability in problem cases should be a issue here. Thursday, February 25, 2010, 7:42:20 PM, you wrote: > 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 >>> >> >> Arkadiy Kulev mailto:[email protected] +7 495 5070602 Moscow, Russia
