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
