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
