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
