Yes, I've also noticed that thing. I just saw the source and found the
actual place (ProxyChannel.cxx):
line #
2631 ConfigReloadMutex.EndRead();
2632 const bool isReadable =
remote->IsReadable(2*setupTimeout);
2633 ConfigReloadMutex.StartRead();
2634 if (!isReadable) {
2635 PTRACE(3, "Q931\tTimed out waiting for
a response to Setup
message from " << remote->GetName());
2636 if( m_call )
2637
m_call->SetDisconnectCause(Q931::TimerExpiry);
2638 OnError();
2639 }
It looks like remote socket "is not readable"? Setup timeout has the
default value so gk has to wait 16 sec before disconnet call by timeout.
But it seems to me that if error was occured gk didn't need to wait and
went to the next lines (isReadable = 0, => PTRACE, disconnectCall by
TimerExpiry).
Regards,
Alex.
P.S. I'll do CPU/memory check at the next problem situation. Thanx for
advice.
Zygmuntowicz Michal пишет:
>Did you try to examine CPU/memory usage with top or other utility?
>One strange thing I notice is that in you log, the timeout happens
>immediatelly
>after connecting the socket.
>
>----- Original Message -----
>From: "Alex Golyshev" <[EMAIL PROTECTED]>
>Sent: Saturday, February 17, 2007 7:14 PM
>
>
>
>
>>Hi all.
>>
>>I've found a strange bug (?) in gnugk 2.2.5. After some working time gk
>>starts to drop calls with reason 102 (Recovery from timer expiry).
>>Log tells me that gk can't establish Q931 TCP connection wih remote party:
>>
>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2946) Q931 Connect
>>to xx.xx.xx.xx:1720 from yy.yy.yy.yy:0 successful
>>2007/02/17 18:45:12.290 3 yasocket.cxx(654) Q931d
>>xx.xx.xx.xx:1720 Error(1): Input/output error (12:57)
>>2007/02/17 18:45:12.290 3 ProxyChannel.cxx(2618) Q931 Timed
>>out waiting for a response to Setup message from xx.xx.xx.xx:1720
>>
>>So looks like gk gets some bad info from destinaion.. But from that
>>moment many calls to different ip-addresses drop with the same error.
>>I calculated that there was 15% of successful calls to usual value.
>>After restarting gk returns to the normal state: calls are going through
>>with no problem.
>>
>>I'm not sure that it is a gnugk problem, maybe calls drop due to tcp/ip
>>full socket buffers etc.
>>
>>Gnugk 2.2.5, release version with the prefix prioroty patch. Failover is
>>enabled, full proxy mode.
>>OpenH323 1.18.0, PWLib 1.10.0. FreeBSD 6.1-Release.
>>
>>Does anybody have similar problems?
>>
>>Regards,
>>Alex.
>>
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________________
>
>Posting: mailto:[email protected]
>Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
>Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
>Homepage: http://www.gnugk.org/
>
>
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________________
Posting: mailto:[email protected]
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
