Hi Nikos, the issue is that when you set timeout in configuration it's valid for _all_ http client connections.
If you think it this config option would be useful, please provide patch for this because I'm too busy now :) I would suggest to set it in group = core for bearerbox and group = smsbox for smsbox. Thanks, Alexander Malysh Am 03.12.2009 um 05:22 schrieb Nikos Balkanas: > Hi, > > According to Changelog, Alexander M. on 6/8/2006 added a function in > gwlib/http.c: > > void http_set_client_timeout(long timeout) > > which sets the timeout for the http outgoing connections. Unfortunately it is > ghost and not used anywhere in the code or configuration. As a result the > http_client_timeout is hardwired into the code: > > static int http_client_timeout = 240; > > It's a rather trivial matter to add it in the configuration, but I think that > Alex, the original contributor, should do it. If he cannot I could. > > What do you say Alex? > > Of course 15' timeout seems an overexaggeration. The OS kernel should drop > the connection before that. > > BR, > Nikos > ----- Original Message ----- > From: David Ritchie > To: [email protected] > Sent: Thursday, December 03, 2009 12:06 AM > Subject: Kannel timeouts / connectivity issues > > Anybody know what Kannel’s expected behavior when HTTP connections timeout or > fail? > > We have a situation with 120+ “sms-service” services defined, but have > noticed a few of them behave in a peculiar manner where, very occasionally, > HTTP requests don’t occur until 16 minutes after being received by Kannel. > This will happen “out of the blue” without any errors logged in smsbox.log or > kannel.log. This occurs in a transient fashion – there doesn’t appear to be > any rhyme or reason to when this occurs. > > This only appears to happen with a particular subset of SMS services which > happen to be hosted outside of our immediate hosting environment, suggesting > there’s some sort of network disruption causing this problem. Potentially > this is some of retry based on a 1-minute timeout, followed by a retry 15 > minutes later; however this would be “out of character” since in my > experience with Kannel most timeouts / 404s / 500s usually generate > everyone’s favourite “Couldn’t fetch content, sorry”-type messages. I also > can’t find any reference to timeouts of these values in the user’s guide or > the configuration files. > > Until recently the get-urls for these services had the SMSC included in the > URLs (i.e. “&smsc=%i”) but, as these were the only services using this, I’ve > removed this in case there’s some sort of problem caused by this. > > Has anybody else had a similar situation where these sorts of delays have > happened? > > David > >
