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

Hello Nikos,

Fine. Can you put dlr-url in access.log then please?
I would simply have to write a parser that would read access.log
every 10 seconds. That would be pretty reliable.

Friday, February 26, 2010, 4:05:32 AM, you wrote:

> Hi Alex,

> Just to refresh your memory a bit about store:

> 1) Store is handled only by bearerbox
> 2) When it sends a message either to smsc or to smsbox and it receives an
> ACK (message accepted), it will do a store_ack.
> 3) Store_ack deletes the message

> Therefore, it doesn't look to me feasible that store will wait until a
> succesful GET of the dlr-url is done. Furthermore, smsbox doesn't have an
> open transaction with bearerbox at this point. For this to work, a new
> protocol across smsbox/bearerbox would have to be devised, and break 
> store_ack architecture. A db storage for DLRs wouldn't help either, because
> DLRs are deleted (memory, db) as soon as  they are matched in bb, so 
> messages are kept in smsbox memory, not dlrs.

> BR,
> Nikos
> ----- Original Message ----- 
> From: "Alejandro Guerrieri" <[email protected]>
> To: "Arkadiy Kulev" <[email protected]>
> Cc: "kannel_dev_mailinglist Devel" <[email protected]>
> Sent: Thursday, February 25, 2010 7:26 PM
> Subject: 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
>>




Arkadiy Kulev                         mailto:[email protected]
+7 495 5070602
Moscow, Russia