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 <[email protected]> > *To:* Nikos Balkanas <[email protected]> > *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 <[email protected]> > *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 > > >
