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
