Re: Invoking methods from multiple threads - connection policy



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.

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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]