<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">HI Duncan<div class=""><br class=""></div><div class="">Thank you for your help. Please find a log file in Google Drive:</div><div class=""><a href="https://drive.google.com/file/d/17Ux9HVmyBe8U-CkJk__gFgcWijU6SoOW/view?usp=sharing" class="">https://drive.google.com/file/d/17Ux9HVmyBe8U-CkJk__gFgcWijU6SoOW/view?usp=sharing</a></div><div class=""><br class=""></div><div class="">This application, called RootController, can receive commands from another process and when this happens it starts a pre-defined number of processes on a set of remote computers by sending requests to the CORBA servers running on these computers. This is exactly where the BIDIR communication happens as the processes are started asynchronously: the RootController sends requests to the CORBA servers running on remote computers asking them to start new processes and when the process are started these CORBA servers send back notifications to the RootController. When BIDIR protocol is used, the RootController very often gets into a state where it takes more than a minute to process a new command. The error is manifested by the following pattern in the log file:</div><div class=""><ul class="MailOutline"><li class="">A message indicating a new connection attempt from the application that sends command to the current one is printed. It looks like: <ul class=""><li class="">omniORB: (1) 2022-01-31 13:36:02.679839: Server accepted connection from giop:tcp:188.184.2.99:46166</li></ul><li class="">But the actual processing of this request happens only a minute later: </li><ul class=""><li class="">omniORB: (42) 2022-01-31 13:37:01.521949: Accepted connection from giop:tcp:188.184.2.99:46166 because of this rule: "* unix,tcp,bidir"</li><li class="">omniORB: (32) 2022-01-31 13:37:01.522292: Dispatching remote call 'makeTransition' to: root/rc/commander<SwRodTest.rc.commander.RootController> (active)</li></ul></li></ul><div class=""><br class=""></div>I have kept the RootController running for a while and made multiple attempts to send commands to it, so there are several cases in the log file showing that external commands had been processed with a very long delay.</div><div class=""><br class=""></div><div class="">Just for the record, here is a log file of the same RootController application with bidirectional GIOP been disabled. In this case everything works as expected.</div><div class=""><a href="https://drive.google.com/file/d/1ZzRyRSH1MWg_LxquFNSkb-3Hax1sU59j/view?usp=sharing" class="">https://drive.google.com/file/d/1ZzRyRSH1MWg_LxquFNSkb-3Hax1sU59j/view?usp=sharing</a></div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Serguei<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 30 Jan 2022, at 15:24, Duncan Grisby <<a href="mailto:duncan@grisby.org" class="">duncan@grisby.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div class=""><div class="">Hi Serguei,</div><div class=""><br class=""></div><div class="">It's not a known issue, although the combination of bidirectional with thread pool mode is somewhat unusual. Bidirectional GIOP requires extra threads to manage the interactions on the bidirectional connections, so something is probably interacting badly.</div><div class=""><br class=""></div><div class="">Please can you get traces from the server with these tracing options:</div><div class=""><br class=""></div><div class=""> traceLevel 25</div><div class=""> traceInvocations 1</div><div class=""> traceInvocationReturns 1</div><div class=""> traceThreadId 1</div><div class=""> traceTime 1</div><div class=""><br class=""></div><div class="">That will give a lot of output, but it should make it possible to see what is going on.</div><div class=""><br class=""></div><div class="">Duncan.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">On Fri, 2022-01-28 at 16:05 +0100, kolos via omniORB-list wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex" class=""><div class="">Hi guys,<br class=""></div><div class=""><br class=""></div><div class="">Can anyone help me out please with the following problem. <br class=""></div><div class=""><br class=""></div><div class="">We are using omniORB 4.2.5 on CentOS 7 Linux and we have recently tried to use bidir GIOP for some of our<br class=""></div><div class="">services. Everything works fine for the servers that use thread-per-connection mode, but the applications which are<br class=""></div><div class="">using thread-pool mode get stuck when the number of external connections reaches the number of threads in the <br class=""></div><div class="">pool. There is a clear correlations between these numbers, which we verified by varying the number of threads in the <br class=""></div><div class="">pool. The symptom is that when the number of external connections reaches the number of threads in the pool the <br class=""></div><div class="">server starts accumulating connections in the CLOSE_WAIT state and an attempt to communicate with it resulted <br class=""></div><div class="">in a timeout. After a while (a few tens of seconds) all connections in the CLOSE_WAIT state disappeared and the <br class=""></div><div class="">server becomes responsive again. <br class=""></div><div class=""><br class=""></div><div class="">Is this a known behaviour or otherwise where should I look at to investigate and possibly fix this problem?<br class=""></div><div class=""><br class=""></div><div class="">Cheers,<br class=""></div><div class="">Serguei<br class=""></div><div class="">_______________________________________________<br class=""></div><div class="">omniORB-list mailing list<br class=""></div><div class=""><a href="mailto:omniORB-list@omniorb-support.com" class="">omniORB-list@omniorb-support.com</a><br class=""></div><div class=""><a href="https://www.omniorb-support.com/mailman/listinfo/omniorb-list" class="">https://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br class=""></div></blockquote><div class=""><br class=""></div><div class=""><span class=""><pre class="">-- <br class=""></pre><pre class=""> -- Duncan Grisby --
-- <a href="mailto:duncan@grisby.org" class="">duncan@grisby.org</a> --
-- <a href="http://www.grisby.org" class="">http://www.grisby.org</a> --
</pre></span></div></div>
</div></blockquote></div><br class=""></div></body></html>