[omniORB] Connection management behaviour

[David Riddoch]

Hi Jorge,


This is actually a problem with how omniORB allocates connections on the
client side.  Once we have reached the maximum (5 by default) the orb then
always allocates the first connection in the list of connections to a
particular address space, and they then _have_ to proceed serially.

I'll have a look at doing something about it tomorrow.


Cheers,
David



On Fri, 21 Jan 2000, Jorge Garcia wrote:

> Hi,
> 
>    I have a question about how omniOrb processes multiple remote
> requests.
> 
>    I have done a client that spawns 10 threads, each thread performs a
> remote method
>   invocation and prints the result.
> 
>   The remote method's code is:
> 
>     long Libreria_i::suma(long value)
>    {
>      sleep(20); // delay
>      value++;
>      return value;
>    }
> 
>    I have not modified the omniORB::maxTcpConnectionPerServer, (I'm
> using the default value '5').
> 
>    When I launch the client the server receives the 10  requests and it
> creates 5 concurrent threads
>    to answer 5 of them and other ones remain blocked.
> 
>    The client receives the answers in the following manner: the first 5
> come almost at the same time,
>   (aprox. in 20 seconds), but the following answers  are received with a
> constant delay ,
>   (between answers), of 20 seconds.
> 
>    It looks like after processing the 5 first requests, the remote
> server only processes requests
>    one by one, even if it has capacity for processing 5 at the same time
> (threads that are already  finished)
> 
>    Is this behavior correct ?.
> 
>    How can the server be forced to accept the next 5 requests at the
> same time ?