I don't know what you mean by configurable globally? each box has it's own global config...
Thanks, Alexander Malysh Am 03.12.2009 um 12:47 schrieb Nikos Balkanas: > 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 > > >
