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 >
