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

Hi,

Yes, I could add this option to custom logs, but it would never make it to 
CVS if a better persistent solution is in the works.

@Alex: What do you think, is it worth it as a temporary workaround, or 
should we wait for the regular persistent solution?

BR,
Nikos
----- Original Message ----- 
From: "Arkadiy Kulev" <[email protected]>
To: "Alejandro Guerrieri" <[email protected]>
Cc: "Nikos Balkanas" <[email protected]>; <[email protected]>
Sent: Friday, February 26, 2010 9:43 AM
Subject: Re[6]: reenable HTTP_MAX_RETRIES and HTTP_RETRY_DELAY for dlr-url


> Hello Alejandro,
>
> smsblox.log is overloaded with too much information, too much
> overhead.
>
> access.log is perfect, it has only message-related entries, why not
> put it in there?
>
> Friday, February 26, 2010, 10:35:36 AM, you wrote:
>
>> Check on smsbox.log, if you have the log level low enough you'll get the 
>> urls in there.
>
>> Regards,
>> --
>> Alejandro Guerrieri
>> [email protected]
>
>
>
>> On 26/02/2010, at 07:13, Arkadiy Kulev wrote:
>
>>> 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
>>>
>
>
>
> Arkadiy Kulev                         mailto:[email protected]
> +7 495 5070602
> Moscow, Russia
>