Re: Could we call this a CRASH?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The following thread was opened back to late November. To refresh your mind, I had a problem with version 2.2.1. It was freezing after a while with no chance of getting into the status port using Telnet.
 
I was told that probably it is a socket issue and was recommended to use version 2.2.3-2 because it has a better socket management. At the time version 2.2.3-2 was causing call drops with cause code 41 and that's why I preferred to use the 2.2.1.
 
Finally I was frustrated and decided to use the version 2.2.3-2 to not experience the freezing problem again. Unfortunately, the version 2.2.3-2 has also the same symptom and would freeze after a while. The only good thing is that this version will provide more information in the log which might help to understand what the cause could be .
 
I could see a bunch of unpleasant error messages through the log and if I bring them all up here it would be more confusing than helpful so I'd provide two of them here for now.
 
The following is one of these error messages which most probably has a close connection with the problem.
 
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3930 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3932 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3934 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3936 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3938 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3940 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3942 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:39.701 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:3944 not available - error 7/24: Cannot allocate memory
 
 
There were about 7500 of this message until reaching to the following part of the log.
 
2006/01/15 07:20:45.202 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:49928 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:45.202 1       ProxyChannel.cxx(3059)  RTP     RTP socket 0.0.0.0:49930 not available - error 7/24: Cannot allocate memory
2006/01/15 07:20:45.202 2       ProxyChannel.cxx(3076)  RTP     Logical channel 0 could not be established - out of RTP sockets
2006/01/15 07:20:45.202 1       ProxyChannel.cxx(3613)  Proxy   Error: Can't create fast start logical channel id 1
2006/01/15 07:20:45.204 1       ProxyChannel.cxx(2316)  Q931d   Could not open/connect Q.931 socket at xxx.xxx.xxx.xxx:0 - error 7/24: Cannot allocate memory
2006/01/15 07:20:45.204 3       ProxyChannel.cxx(2328)  Q931    yyy.yyy.yyy.yyy:1720 DIDN'T ACCEPT THE CALL
 
 
Most probably the developers know in what condition this might happen and give me a clue about the remedy.
 
To give you an idea, the GNUGK was running on a double Xeon with 1G memory and the maximum number of connected sessions was about 100 so the amount of available memory or lack of cpu time shouldn't be the case.
 
I also could see the following error message as well which might be interesting.
 
2006/01/15 06:20:57.339 0             assert.cxx(108)   PWLib   Assertion fail: Operating System error, file tlibthrd.cxx, line 746, Error=24
 
Maybe this error message shed a light on what the problem is.
 
Regards,
Bahram.


 
----- Original Message -----
Sent: Thursday, November 24, 2005 3:01 PM
Subject: Re: Could we call this a CRASH?

Maybe your accounting/authentication modules slow down.
Also make sure you have CallSignalHandlerNumber set to something
greater than 1.

----- Original Message -----
From: "Bahram S. Biria" <bsbiria@xxxxxxxxxxxxx>
Sent: Thursday, November 24, 2005 8:41 PM


I retested with version 2.2.3-2 but as before this version was killing most of the calls with dcc 41. So, I couldn't get to the
point to see if the freezing problem would happen with this version.

All the timers that were available in the [RoutedMode] section were increased for retest and it didn't change anything. I am not
sure if reading and setting this timers should have been written in the logs since I didn't see anything. Please let me know if it
is supposed to be shown in the logs then I would know that I didn't set them properly.

I increased the fdset number from 4096 to 32768 and again it didn't change anything. The version 2.2.1 froze even with the higher
number of fdset. The maximum no of calls on the GNUGK was about 50 and I am not sure if lack of socket with this number of
concurrent calls is something to think about !

The OS that I am using is RedHat 9. If there is something else that I should do to increase the number of sockets beside increasing
the fdset and in OS level, please let me know and I'll go for it.

Thanks,
Bahram.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/

[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux