Re: Invoking methods from multiple threads - connection policy

[Toralf Lund <toralf lund pgs com>]

Frank Rehberger wrote:
> Quoting "Toralf Lund" <toralf lund pgs com>:
>
>   
> > Frank Rehberger wrote:
> >     
> > > Toralf,
> > >
> > > if I remember correctly, there are at least these two options:
> > > ORBIT_THREAD_HINT_PER_REQUEST
> > > ORBIT_THREAD_HINT_PER_CONNECTION
> > >
> > > I would recommend the second one (per-connection), if it comes to   
> > > near-real-time processing, to avoid priority inversion.
> > >
> > >       
> > It seems to me that if I use this in conjunction with a  
> > multi-threaded client, I essentially get single-threaded behaviour  
> > for CORBA calls (there will only be one thread on the server-side)  
> > if the CORBA object is shared between the threads on the client  
> > side. That's if the client is implemented the ORBit2 way, i.e. all  
> > operations on an object is sent across the same socket or whatever,  
> > regardless of which thread they come from. This is why some other  
> > ORBs will set up separate links for separate threads.
> >     
>
> that is true, if the threads in your process have different  
> priorities, using mutliple outbound connections (per thread) to same  
> server would make a difference.
>   
I'm not quite sure what you mean here.

The issue I'm facing is that to guarantee that there is one server-side 
thread for each client-side thread, I need a separate connection in each 
of the client-side threads, and with ORBit2 that also means one 
CORBA_Object per thread, based on duplicate calls to 
CORBA_ORB_string_to_object() or similar. Which isn't *that* hard to 
achieve, but it does require extra housekeeping that might be nice to 
avoid - mainly related to error handling.

But I might still be missing something...
> ORBIT_THREAD_HINT_PER_CONNECTION is most resource-efficient and scales  
> very well.
>
> ORBIT_THREAD_HINT_PER_REQUEST might cause quite overhead in terms of  
> number of threads being created in server (newly created), I have to  
> check implemention and useage of thread-pools. In general  I would  
> recommend this only for low-frequency in-bound messages.
>   
Fortunately, the server I'm writing right now only has moderate traffic, 
and is also just a "simulation" setup for a "real" server using a 
different ORB. Which is where omniORB comes into the picture. I might 
use this in client and test server, too, of course but I find some other 
features of ORBit2 more convenient, and of course, I have the code already.

Obviously, omniORB might have similar performance issues related to 
thread policies, but I believe it has a quite good thread-pool 
implementation at least.

- Toralf


> //Frank
>
>   
> > Or am I missing something?
> >
> > - Toralf
> >     
> > > Quoting "Toralf Lund" <toralf lund pgs com>:
> > >
> > >
> > >       
> > > > Frank Rehberger wrote:
> > > >
> > > >         
> > > > > Quoting "Toralf Lund" <toralf lund pgs com>:
> > > > >
> > > > >
> > > > >
> > > > >           
> > > > > > Am I correct in assuming that when I invoke CORBA methods (on  
> > > > > > the   same CORBA_Object) from different threads, they will by  
> > > > > > default   share the GIOP/linc/socket connection - i.e. data from  
> > > > > > different   threads is multiplexed? I know that some other ORBs  
> > > > > > will   (optionally) set up one connection per thread - see for  
> > > > > > instance    
> > > > > > http://omniorb.sourceforge.net/omni40/omniORB/omniORB008.html    
> > > > > > (section 8.3.) Is there any way I can configure ORBit2 to do this?
> > > > > >
> > > > > >
> > > > > >             
> > > > > You are asking for client side option: sorry, no
> > > > >
> > > > >
> > > > >           
> > > > That's what I thought, after reading some of the code... It's too   
> > > > bad, in a way, but at least I know for sure now that it can't be  
> > > > done.
> > > >
> > > > Fortunately, we also have the option of adapting the server we're   
> > > > connecting to, which is incidentally the one set up using omniORB   
> > > > (*without* "demultiplexing" support right now.)
> > > >
> > > > By the way, does this mean that ORBIT_THREAD_HINT_PER_REQUEST is  
> > > > the  only option if I want an ORBit2 server to execute requests in  
> > > >  different threads when they come from different client-side  
> > > > threads  that share the CORBA object? Or does the system have some  
> > > > other way  to distinguish requests from different client threads?
> > > >
> > > > - Toralf
> > > >
> > > >
> > > >
> > > > This e-mail, including any attachments and response string, may   
> > > > contain proprietary information which is confidential and may be   
> > > > legally privileged. It is for the intended recipient only. If you   
> > > > are not the intended recipient or transmission error has  
> > > > misdirected  this e-mail, please notify the author by return  
> > > > e-mail and delete  this message and any attachment immediately. If  
> > > > you are not the  intended recipient you must not use, disclose,  
> > > > distribute, forward,  copy, print or rely on this e-mail in any  
> > > > way except as permitted by  the author.
> > > > _______________________________________________
> > > > orbit-list mailing list
> > > > orbit-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/orbit-list
> > > >
> > > >
> > > >         
> > > _______________________________________________
> > > orbit-list mailing list
> > > orbit-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/orbit-list
> > >
> > >       
> > This e-mail, including any attachments and response string, may  
> > contain proprietary information which is confidential and may be  
> > legally privileged. It is for the intended recipient only. If you  
> > are not the intended recipient or transmission error has misdirected  
> > this e-mail, please notify the author by return e-mail and delete  
> > this message and any attachment immediately. If you are not the  
> > intended recipient you must not use, disclose, distribute, forward,  
> > copy, print or rely on this e-mail in any way except as permitted by  
> > the author.
> > _______________________________________________
> > orbit-list mailing list
> > orbit-list gnome org
> > http://mail.gnome.org/mailman/listinfo/orbit-list
> >
> >     
>
>
> _______________________________________________
> orbit-list mailing list
> orbit-list gnome org
> http://mail.gnome.org/mailman/listinfo/orbit-list
>   


This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.