[tao-users] EXTERNAL: Re: How to force explicit parallelism with TAO?

[Melton, Jim]

I think I have a solution. If I set the private connection policy for the client, and thread-per-connection policy on the server, I don't seem to get strangled trying to service multiple high-volume client threads.

Perhaps this is self-evident to the TAO gurus among us, but it didn't make sense to me until I had banged my head against the wall sufficiently to re-shape my brain in the TAO mold. Also, http://www.cs.wustl.edu/~schmidt/TAO/RT-CORBA.ppt was very helpful and the most thorough explanation of the various RTCORBA extensions of anything I've found.

--
Jim Melton
Software Architect, Fusion Programs
Lockheed Martin IS&GS
(720) 922-5584


> -----Original Message-----
> From: tao-users [mailto:tao-users-bounces at list.isis.vanderbilt.edu] On
> Behalf Of Melton, Jim
> Sent: Monday, April 20, 2015 1:53 PM
> To: tao-users at list.isis.vanderbilt.edu
> Subject: Re: [tao-users] EXTERNAL: Re: How to force explicit parallelism with
> TAO?
> 
> I've been wrestling with trying to get this going, and I've run across the
> following limitations. I don't know if these are constraints or bugs.
> 
> * Linking with libTAO_RTCORBA causes intermittent errors unless
> libTAO_RTPortableServer is also included. The major symptom of this is at
> runtime an exception is thrown from resolve_initial_references("RootPOA")
> trying to contact the name service via multicast. That is all kinds of wrong for
> several reasons, but simply adding RTPortableServer keeps that from
> happening.
> 
> * Creating a POA thread pool requires execution in a real-time context. This
> precludes (on Solaris 11) running in a default configured zone, or as any user
> but root. The examples in $TAO_ROOT/DevGuideExamples/RTCORBA
> confirm this. They only ran on the global zone as root.
> 
> I have scoured Google and even the OCI Developer's Guide, but can't seem
> to get past this. Why is it so hard to get predictable connection semantics
> from TAO? Surely I'm missing something obvious?
> --
> Jim Melton
> Software Architect, Fusion Programs
> Lockheed Martin IS&GS
> (720) 922-5584
> 
> 
> > -----Original Message-----
> > From: Phil Mesnier [mailto:mesnier_p at ociweb.com]
> > Sent: Friday, March 27, 2015 3:20 PM
> > To: Melton, Jim
> > Cc: tao-users at list.isis.vanderbilt.edu
> > Subject: Re: EXTERNAL: Re: [tao-users] How to force explicit
> > parallelism with TAO?
> >
> > Hi Jim,
> >
> > > On Mar 26, 2015, at 8:00 PM, Melton, Jim <jim.melton at lmco.com>
> wrote:
> > >>
> > >> I don't think I have a clear enough understanding of your
> > >> architecture. Are you saying that you want a single subscriber /
> > >> repository session to have a dedicated thread on the server side?
> > >
> > > Dedicated would be OK, but not necessary. What I don't want is for
> > > client
> > requests to be blocked waiting for a server thread to become available
> > (so maybe that is what I want). The key thing is that we need to move
> > data quickly. The infrastructure must not be a cause for (excessive) delay.
> > >
> >
> > Maybe POA thread pooling is what you need. We've talked about it a
> > couple of times. The dynamic thread pool feature was designed to
> > emulate Orbix. It was funded by a defense contractor performing a
> > major migration from Orbix to TAO. They also sponsored the ImR
> > redesign, improved redundancy services and lightweight load balancing
> integrated with the naming service.
> >
> >
> > >> If you use RTCORBA on the client you can set up exclusive
> > >> connections on the repository object references, then with TPC on
> > >> the server side you'll have a single subscriber thread interacting
> > >> with a single repository
> > thread.
> > >
> > > OK. This is sounding familiar. I think we might have done that in
> > > our first
> > (aborted) attempt to migrate to TAO 10+ years ago, because I've had a
> > bunch of commented out RTCORBA stuff in the code for ages, and Orbix
> > didn't require or implement the RTCORBA spec.
> > >
> >
> > Unfortunately we are not privy to Orbix's implementation. Who knows
> > what tricks they perform. Best we can do is characterize the desired
> > behavior sufficiently enough to define requirements for TAO. If you
> > are able to fund the effort, I'd be happy to do it.
> >
> > >> You keep using past tense describing the problems so is there still
> > >> an
> > issue?
> > >
> > > There were two problems. One was the interleaving of calls between
> > subscribers on the client. Refactoring to make the "do it" part of
> > callback() a separate thread resolved those issues.
> > >
> > > The other is the data starvation of (at least) one of the
> > > subscribers during
> > heavy load. I don't believe this is resolved, but neither does it
> > happen every day.
> > >
> >
> > OK.
> >
> > > On the other hand, there was a race condition where a subscriber
> > > could
> > lose its reference to the publisher that I've fixed but not tested.
> > It's possible that the race condition was the cause of the starvation
> > and not unpredictable thread behavior on the server. Because, as you
> > point out, the evidence is that the server is using some number of
> > threads to service requests from the clients, as the policies should enforce.
> > >
> > > I won't get to test again until next week. I'll let you know if
> > > there are
> > further issues.
> > >
> >
> > Ah. Good luck with the testing!
> >
> > Best regards,
> > Phil
> >
> > --
> > Phil Mesnier
> > Principal Software Engineer and Partner,   http://www.ociweb.com
> > Object Computing, Inc.                     +01.314.579.0066 x225
> >
> >
> >
> 
> _______________________________________________
> tao-users mailing list
> tao-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/cgi-bin/mailman/listinfo/tao-users