|
Test on generating calls for Gnugk Version 2.2.2: The following test was performed: 1.) I used screens to create a separate session on Linux and set
ulimit to be 65 sockets for gnugk to run with. 2.) I had signaling handlers set to 15 and with h225 routed and
h245 being tunneled. No media proxying. 3.) Generated 3 sets of 10 calls each to Gnugk. 4.) During the second set of initiated calls Gnugk displayed the
following error: Assertion fail: Operating System error, file tlibthrd.cxx, line 730,
Error=24 <A>bort, <C>ore dump, <I>gnore? 5.) Once this error appear one could continue to send calls to
the system, but no more Sockets were being created and released when Checking the total sockets with lsof – p
29621 | wc –l. 6.) I repeated this same test a few more times and the same error
appeared. I then decided to perform the test on an old version of 2.2b5 that I had
been using for many months before moving to 2.2.2 The same errors occur as in 2.2.2. I also did not see any new sockets
being created or released when issuing lsof – p 29621 | wc –l. The status port was blank with _ characters appearing. I used the following Call Generator command. callgen323 -m 10 -r 10 --tmaxest 5
--tmincall 3 --tmaxcall 3 --tminwait 1 --tmaxwait 1 -u gen2 -g xxx.xxx.xxx.xxx CISCO5850E From:
openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Freddy Parra Here are some current results: When max sockets are reached the following behavior was noted: For this test I had the following conditions set: 1.) I used screens to create a separate session window on Linux and set
ulimit to be 60 sockets for gnugk to run with. 2.) I had signaling handlers set to 15 and with h225 routed and h245
being tunneled. No media proxying. 3.) I was able to create 3 telnet instances to the status port and on
the 4th instance I got a blank telnet response. This meant I ran out of sockets which is the state I wanted gnugk to be in. 4.) When I issued a reload on one of the telnet sessions all endpoints
that were registered suddenly unregistered. 5.) I retested the same case scenario and this time had a segmentation
fault (core dump). 6.) I performed the following test a few times over and the same
scenarios played out, with endpoints un-registering and segmentation fault
happening. I'm in the process of creating some test with the call generator and
see what the behavior is when calls are being sent to the system when max
sockets are reached. Freddy -----Original Message----- Hi Todd, That's interesting. I was thinking of maybe running the call generator program that comes with openh323 and setting the ulimit for total sockets on gnugk to a very small number like 20, then generating like
50 or more calls at the same time using the call generator. Maybe like
this we can duplicate this behavior and see if this is the actual problem. I will try later on today if I find something and post my findings. Freddy -----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of R. Todd Wallace Sent: Tuesday, February 22, 2005 5:55 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: Non-Responsive Something that was noticed was that the GNU had a ton of sockets in
wait state. It looks like there was a blip in IP and these sockets did
not get released and the GNU had them in wait state. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real
users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick _______________________________________________________ List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id…49 Homepage: http://www.gnugk.org/ |
