[omniORB] Re: ThreadPool model and ORBmaxServerThreadPerConnection (Solved, patch attached)

[Serguei Kolos]

Hello

I believe I have found the reason of this problem. This is of course the 
race condition
between giopServer::notifyRzReadable and giopServer::notifyWkDone.
It happens because the connection's socket is made selectable 
(giopServer.cc:1008)
before the current worker is destroyed in the giopServer::notifyWkDone. 
In this case the
giopServer::notifyRzReadable function can be called in between of this 
two things and it
might set the conn->pd_has_hit_n_workers_limit to 1 because the 
conn->pd_n_workers
is still equal to 1 (giopServer.cc:815), but then the worker is 
destroyed by the
giopServer::notifyWkDone and nobody takes care about the connection, 
which is really
readable. Below is the patch.
Cheers,
Sergei

*** giopServer.cc    Fri Feb 27 11:30:57 2004
--- giopServer-new.cc    Fri Feb 27 11:30:54 2004
***************
*** 1004,1012 ****
        }
      }
 
-     // Connection is selectable now
-     conn->setSelectable(1);
-
      // Worker is no longer needed.
      {
        omni_tracedmutex_lock sync(pd_lock);
--- 1004,1009 ----
***************
*** 1014,1019 ****
--- 1011,1018 ----
        if (conn->pd_n_workers == 1 && ( conn->pd_dying || pd_state == 
INFLUX )) {
      // Connection is dying. Go round again so this thread spots
      // the condition.
+     // Connection is selectable now
+     conn->setSelectable(1);
      omniORB::logs(25, "Last worker sees connection is dying.");
      return 1;
        }
***************
*** 1021,1026 ****
--- 1020,1028 ----
        delete w;
        conn->pd_n_workers--;
        pd_n_temporary_workers--;
+      
+       // Connection is selectable now
+       conn->setSelectable(1);
      }
      return 0;
    }


Serguei Kolos wrote:

> Hello
>
> I'm sorry , I was sending my previous messages to the wrong list.
> Here is the problem, which I have with the omniORB 4.0.2. ( I have 
> tested also
> 4.0.3 and the behavior is the same.)
> If I use the following options for my server
> -  threadPerConnectionPolicy 0
> -  threadPoolWatchConnection 0
> -  maxServerThreadPerConnection 1
>  (All the other options have their default values.)
> then sometimes (not always but very often) my client hangs trying to 
> communicate with the server.
> Using the traceLevel=50 option I have found that a second request, 
> which is sent by the client is
> not received on the server. The server and client traces are attached 
> below.
> The problem can be solved by setting the maxServerThreadPerConnection 
> to a value greater then 1,
> but this is not what I want.
> Cheers,
> Sergei