Re: Invoking methods from multiple threads - connection policy

Quoting "Toralf Lund" <[email protected]>:

> 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.

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.

//Frank

> Or am I missing something?
>
> - Toralf
>> Quoting "Toralf Lund" <[email protected]>:
>>
>>
>>> Frank Rehberger wrote:
>>>
>>>> Quoting "Toralf Lund" <[email protected]>:
>>>>
>>>>
>>>>
>>>>> 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
>>> [email protected]
>>> http://mail.gnome.org/mailman/listinfo/orbit-list
>>>
>>>
>>
>>
>> _______________________________________________
>> orbit-list mailing list
>> [email protected]
>> 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
> [email protected]
> http://mail.gnome.org/mailman/listinfo/orbit-list
>