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

PS: You don't need a parser to parse every 10' the whole log. You can just 
open it as a stream once and parse it as you go. You can even use a script 
for that (awk, bash, etc).

BR,
Nikos
----- Original Message ----- 
From: "Nikos Balkanas" <[email protected]>
To: "Arkadiy Kulev" <[email protected]>; "Alejandro Guerrieri" 
<[email protected]>
Cc: <[email protected]>
Sent: Friday, February 26, 2010 10:14 AM
Subject: 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
>>
>