[ciao-users] Antwort: Re: EXT :Re: Multithreaded dance_locality_manager method call dispatcher?

[kai-uwe.schieser at diehl.com]

Hi there!

thanks for your quick answers.
@Mark: Your problem description is close to mine.

To make things clearer I wouldlike to explain my system structure more 
detailed.
I have a dance_locality_manager process running with many different 
components on a single node. On the 'top-layer' of this system there are 
components that are accessed via naming service  from a different process 
(plain CORBA interfaces). Some of the opertation calls to these components 
are long-running, and since they are dipatched by a single thread only one 
after another is called in the dance_locality_manager process. The method 
invocation on the other process is multithreaded. 

I looked into documentation for some ORB options to handle this topic. Do 
you have some thoughts on  ''-ORBCollocationStrategy direct"  or maybe the 
"-ORBConcurrency thread-per-connection"?

Definiteley, to use more dance_locality_manager processes would be a wy to 
solve this. But I would prefer an simpler solution.

Thanks,
Kai





Von:    "Hayman, Mark (ES)" <mark.hayman at ngc.com>
An:     CIAO Users Mailing List <ciao-users at list.isis.vanderbilt.edu>
Datum:  13.05.2015 16:39
Betreff:        Re: [ciao-users] EXT :Re: Multithreaded 
dance_locality_manager method call dispatcher?
Gesendet von:   "ciao-users" <ciao-users-bounces at list.isis.vanderbilt.edu>



Kai,

Will's suggestion to use AMI4CCM will work well in term of eliminating 
unnecessary container work thread lockup due to synchronous/blocking calls 
from component client ports.

Perhaps you are instead worried about long-running operation 
implementations on servant/server side ports rather than client ports, and 
have 2 or more on the same component (or on multiple components mapped to 
the same DAnCE LM component server process) that will execute for an 
extended period before returning to the event queue, thus preventing other 
events from being dispatched & processed by that same container?  If so, 
my suggestion would be to allocate those server ports/operations to two 
different components instead, if they're on just one, and deploy the two+ 
components each to their own DAnCE LM component server process.  That's 
the easy approach to CIAO+DAnCE multi-threading.  Specifically, use 
multiple LM processes instead of multiple threads in the same process.  It 
has the nice added decoupling benefit of eliminating all the accidental 
complexities involved with having to write multi-threaded code and deal 
with concurrent access issues.
 
-Mark

-----Original Message-----
From: ciao-users [mailto:ciao-users-bounces at list.isis.vanderbilt.edu] On 
Behalf Of William Otte
Sent: Wednesday, May 13, 2015 9:59 AM
To: CIAO Users Mailing List
Subject: EXT :Re: [ciao-users] Multithreaded dance_locality_manager method 
call dispatcher?

Hi Kai -

Thanks for using the PRF.  I discarded your message to tao-users, in order 
to keep this discussion in the appropriate forum, but cleared your 
moderate flag for that list as well.

On 13 May 2015, at 8:37, kai-uwe.schieser at diehl.com wrote:

> CIAO VERSION: 1.2.3
> TAO VERSION : 2.2.3
> ACE VERSION : 6.2.3
>
> HOST MACHINE and OPERATING SYSTEM:
> Windows 7
>
> $ACE_ROOT/ace/config-win32.h
>
> THE PROBLEM AFFECTS: Execution
>
> TAO/CIAO are affected.
>
> SYNOPSIS:
> Multithreaded dance_locality_manager method call dispatcher?
> Interface calls to components in an single dance_locality_manager are 
> dispatched single threaded.
>
> DESCRIPTION:
>
> Hi there!
> I am using CIAO as CCM implementation and have the following problem:
> So far I deploy my components on a local machine (localhost) and they 
> are running in a single dance_locality_manager process. It seems that 
> all incoming interface calls (and also intercomponent calls) are 
> dispatched by a single thread in the dance_locality_manager. This is a 
> problem because some interface calls need long processing time. I 
> would like to call more interface methods in parallel. Is there a TAO 
> ORB option to enable some kind of multithreaded dispatching?
> Thanks in advance, Kai.

That is certainly possible using a svc.conf file (I'll refer you to the 
TAO documentation for the details on that, but can dig it up if you are 
still interested).  It is, however, not currently a currently tested (and 
thus not supported) configuration, and I don't know if there will be 
unintended side effects.

A better solution to your problem is to explicitly design for asynchronous 
behavior for such long-running method calls using AMI4CCM (
https://github.com/DOCGroup/ATCD/tree/master/CIAO/connectors/ami4ccm).

hth,
/-Will
_______________________________________________
ciao-users mailing list
ciao-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ciao-users
_______________________________________________
ciao-users mailing list
ciao-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/ciao-users



Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken müssen/ 
before printing, think about environmental responsibility.

Diehl Metering GmbH, Industriestraße 13, 91522 Ansbach
Telefon + 49 981 1806 0, Telefax +49 981 1806 615
Sitz der Gesellschaft: Ansbach, Registergericht: Ansbach HRB 69
Geschäftsführer: Frank Gutzeit (Sprecher), Dr.-Ing. Robert Westphal, 
Thomas Gastner, Adam Mechel

Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese 
E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise 
erhalten haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede 
unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung 
und/oder Publikation dieser E-Mail ist strengstens untersagt.

The contents of the above mentioned e-mail is not legally binding. This 
e-mail contains confidential and/or legally protected information. Please 
inform us if you have received this e-mail by mistake and delete it in 
such a case. Each unauthorized reproduction, disclosure, alteration, 
distribution and/or publication of this e-mail is strictly prohibited.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/cgi-bin/mailman/private/ciao-users/attachments/20150518/32b4eea9/attachment.html>