Re: Re[2]: reenable HTTP_MAX_RETRIES and HTTP_RETRY_DELAY for dlr-url

1. I hope so! At this stage we're just researching if is this actually a bug or maybe some misconfiguration on our side. If it proves to be a bug I'll try to fix it of course.

2. Afaik, smsbox doesn't actually use the store, but yes I agree that some persistence mechanism is needed.

Regards,
--
Alejandro Guerrieri
[email protected]



On 25/02/2010, at 18:08, Arkadiy Kulev wrote:

> 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
>