You are absolutely right. In fact it is easier than i thought. I will get right to it. And let's make default timeout to something easier on the eye, ie 60".
BR, Nikos ----- Original Message ----- From: Alejandro Guerrieri To: Nikos Balkanas Cc: Alexander Malysh ; [email protected] Sent: Thursday, December 03, 2009 1:24 PM Subject: Re: Kannel timeouts / connectivity issues http smsc's works from bearerbox I think 2009/12/3 Nikos Balkanas <[email protected]> Hi Alex, Right now all client connections have a set limit of 240" hardwired in code. It is easy to make this configurable globally, and I think it would be an improvement over the hardcoded one. Now, from your sayings, this should be done /box (let's not forget wapbox) and this is more of a hussle. Smsbox & wapbox can use the same setting, and i don't know of any bb http client connections. Do you? Besides I don't have time right now for /box timeout support. But the global one is trivial to do and can do it. Is this OK? I don't need it, but it seems that David does. BR, Nikos ----- Original Message ----- From: Alexander Malysh To: Nikos Balkanas Cc: [email protected] Sent: Thursday, December 03, 2009 11:35 AM Subject: Re: Kannel timeouts / connectivity issues 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
