The issue I could think of would be cf-engine would detect the death of the proxy and would try to resurrect it. This can loop indefinitely until mongo is up. This si fine for as long as the resurrection loop would not eat up cpu and kill the system beyond recovery. I suggest that the first thing proxy init does is a mongo health check prior to creating media relay syms. This is the heavy part of proxy init.
On 04/26/2012 09:20 AM, Douglas Hubler wrote: > If proxy cannot connect to a mongo instance, it should die IMHO > because then call will go to a proxy that can handle the call. The > problem is that nothing attempts to restart proxy. That's a TODO to > investigate snmpd for that as it has that capability, if not snmpd, > then something like monit. > > thoughts? before responding, think thru how successful proxy would > actually be w/o any of the information in mongo. > > CC sipx-dev > > On Wed, Apr 25, 2012 at 8:23 PM, Joegen Baclor<[email protected]> wrote: >> This will happen if mongo is propagating exceptions which i think it is now >> when Douglas made the recent changes. Also in the old implementation, the >> auto-reconnect flag is set. We need to put this back. >> >> >> On 04/26/2012 06:44 AM, George Niculae wrote: >>> Hi Joegen, >>> >>> while investigating http://track.sipfoundry.org/browse/XX-10084 I >>> managed to recreate same behavior but with sipXproxy: if I stop >>> mongodb then sipXproxy will exit with: >>> :LOG:CRIT:test.mydomain.ro::7fccacb6e700:SipXProxy:"Error occurred. >>> Unknown exception type." >>> see below >>> >>> This global error is handled in sipXproxymain.cpp line 178 then >>> sipXproxy exits, however I think the correct behavior would be >>> sipXproxy to retry to connect to mongo (so it could kind of recover >>> after a mongo failure). >>> Could you please comment, >>> >>> Thanks >>> George >>> >>> >>> >>> "2012-04-25T22:19:28.891313Z":9903:HTTP:DEBUG:test.mydomain.ro:AsynchMediaRelayRequestSender-15:7fccad08e700:SipXProxy:"HttpMessage::get[4] >>> read returned 572 bytes" >>> >>> "2012-04-25T22:19:28.891423Z":9904:HTTP:DEBUG:test.mydomain.ro:AsynchMediaRelayRequestSender-15:7fccad08e700:SipXProxy:"HttpMessage::get[4] >>> returning 200 response" >>> >>> "2012-04-25T22:19:28.892175Z":9905:XMLRPC:INFO:test.mydomain.ro:AsynchMediaRelayRequestSender-15:7fccad08e700:SipXProxy:"XmlRpcRequest::execute >>> XML-RPC received valid response = \n<?xml version=\"1.0\" >>> encoding=\"UTF-8\"?><methodResponse >>> >>> xmlns:ex=\"http://ws.apache.org/xmlrpc/namespaces/extensions\";><params><param><value><struct><member><name>status-code</name><value>ok</value></member><member><name>nbridges</name><value>1500</value></member><member><name>instance-handle</name><value>sipxbridge:5951533788619736352</value></member></struct></value></param></params></methodResponse>" >>> >>> "2012-04-25T22:19:30.701398Z":9906:SIP:DEBUG:test.mydomain.ro:SipUserAgent-0:7fccaca6d700:SipXProxy:"SipUserAgent[SipUserAgent-0]::handleMessage >>> calling garbageCollection()" >>> >>> "2012-04-25T22:19:38.701432Z":9907:SIP:DEBUG:test.mydomain.ro:SipUserAgent-0:7fccaca6d700:SipXProxy:"SipUserAgent[SipUserAgent-0]::handleMessage >>> calling garbageCollection()" >>> >>> "2012-04-25T22:19:42.042526Z":9908:LOG:CRIT:test.mydomain.ro::7fccacb6e700:SipXProxy:"Error >>> occurred. Unknown exception type." >>> _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
