Summary:	ASTERISK-07095: API Manager close connections in less than a minute with medium to high load.
Reporter:	Fernando Romo (el_pop)	Labels:
Date Opened:	2006-06-04 22:11:09	Date Closed:	2006-08-21 14:57:20
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/ManagerInterface
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	API Manager close the connections made by application, Telnet o any socket connection in less than a minute. We alredy check the suggest made in the related (and i don't know why) closed bugs: 5247, 5352 and 5355 I test with a Perl program writing directly to the API Manager and Notice a Missing Events and Overwriting of anothers. Initialy, i think the problem could be my program, but testing with a simple telnet session to port 5038, show the same arratical behaivor and close the telnet session too. Well, you can think is a network problem, but the disconnections happen in the same machine connected via localhost (127.0.0.1) and put the "writetimeout = 1000" (and other higher values) ... (slow connections in localhost?... umm). When i make a lot of originates (by Telnet and app), the CLI show a lot of messages with the leyend "Unable to create ZAP/g1/XXX", with 4 E1's available (120 trunks Free!). The we start to put a little delay of 1 and 2 ms becoming to a full second between Originates Dial Try's and we could stop the error, but the connection to the API Still closing. We  test with asterisk 1.2.4 to 1.2.8 and head and we note in higher versions a disconnection more faster. We try with a old 1.0.7 and 1.0.9 and we can't provoque the disconnection error. We test deply in a new install with head version 32160 (write now) and the error still happen. If the error was corrected in the previously bugs, why is happen again? ****** ADDITIONAL INFORMATION ****** well i found the following: 1) API Manager can't handle fast requests, we need a little delay between packets. 2) API Manager is missing and mixup Events 3) The connections propertys don't work prorperly. Tomorrow night we try to make test with 3 PBX and diferents versions. one client has 10 E1 in heavy load and we try to test this more detailed.
Comments:	By: Fernando Romo (el_pop) 2006-06-05 18:34:58 We encounter this rule in the fail frecuency: With more number of line and extensions, the Packets events grow and the rate o disconnections too. Thas mean if we test in a low traffic system, the disconection frecuency are more long in time, with more E1's the rate of events grow and the time between fails are more short. I see a kind of "Buffer overflow" in the api manager handler array. This must be work like a FIFO (First In, First Out), but when Api manager try to process the request, another arrive and the API disconnect to protect the connection. By: Serge Vecher (serge-v) 2006-06-28 13:56:01 Are you able to narrow this down to specific code? If you can't do it yourself, the it is probably best that you provide root access to your system to one of the developers on #asterisk-dev By: Serge Vecher (serge-v) 2006-07-12 13:40:54 el_pop: what's the status here -- did you try my suggestions? By: Fernando Romo (el_pop) 2006-07-18 01:47:10 Verchers: excuse the delay, i am out several days and cannot read the bugtracker. I coordinate to make the acces to the affected system. tomorrow i keep in touch with the irc people. By: Serge Vecher (serge-v) 2006-08-08 13:33:16 what happened here? By: Serge Vecher (serge-v) 2006-08-21 14:57:20 trunk is moving way too quickly to wait 2 weeks for responses on issues like these through the bugtracker. When you are ready: 1) Update to the latest trunk (r>40000) 2) Make sure you have an unmodified installation compiled with DONT_OPTIMIZE option enabled in menuselect. 3) If you are still able to reproduce the issue, please contact a developer on #asterisk-dev channel for help.