[omniORB] Canceling a blocking function

[Haarek Ryeng]

I've been following your discussion - quite impressive task you've undertaken.
Interesting!

I dont have a perfect solution  however  I have found that in almost every
case a Transient exception is thrown (if the proxy already exist), or a
Comm_Failure if there never has been communication with the remote object (no
proxy exist).
The Transient exception  as you may be aware of  is by default caught by the
proxy (for ever), causing the timeout" before your application receives the
exception veeeerrrrryyyy long.
By installing an exception handler for the proxy the exception can be thrown to
your application code immediately.

Ex. for a new default ex. handler: (you would install it only for the 10E2
server proxies)
/*----------------------------------------------------------------------*/
/* CORBA::TRANSIENT default exception handler, used by all proxies  */
/*----------------------------------------------------------------------*/
CORBA::Boolean my_transient_handler1 (void* cookie,CORBA::ULong retries,const
CORBA::TRANSIENT& ex)
{
 cout << "Default Transient exception handler called." << endl;
 return false; // causes the proxy to throw the exception to the application
code.
}

Combine this with tuning out call timeouts, and an appropriate pool of worker
threads to do the (" Push the request out ... ") thing. This should give the
system more responsiveness (one worker thread only hangs as long the
out-call-timeout).

For more info: Chapter 7 and 8 in the OmniORB2 doc describes it in detail.

Good luck!

- Haarek

Han Kiliccote wrote:

> > -----Original Message-----
> > From: Tres Seaver [mailto:tseaver@palladion.com]
> > Sent: Wednesday, April 05, 2000 11:53 AM
> > To: Han Kiliccote
> > Cc: omniorb-list@uk.research.att.com
> > Subject: Re: [omniORB] Canceling a blocking function
> >
> >
> > Han Kiliccote wrote:
> > > <I wrote>
> > > > I guess I'm dense, but I can't see the point of distributing such
> > > > a request across 10E5 peers -- each client will spend vastly more time
> > > > negotiating with its peers than it would spend processing the whole
> > > > request internally.  In particular, what is the point of cancelling
> > > > requests?  The chances of being able to signal a cancellation to the
> > > > peer before the peer completes the request are vanishingly small.
> > > >
> > > > Looking back at your original question, I guess you may not need to
> > > > signal cancellation to peers -- you seem merely to want to free up
> > > > client-side resources associated with the request.  You also seem to
> > > > be talking only to 10E2 of the possible 10E5 at a time:  How do you
> > > > manage this without some form of centralization?  Random-selection
> > > > from a known universe of object references equires either a
> > centralized
> > > > server which performs the selection, or one which serves up the entire
> > > > list of OR's to clients (ICK!)).  Do you intend to "compute" the OR's,
> > > > somehow?
> > >
> > > Excellent points. This is why what we are doing is called a research
> > > project. Our solution involves generating a virtual
> > interconnection network
> > > (e.g., a hypercube) on top of the existing network. This way
> > every client
> > > (or server, there is no difference) knows/maintains
> > connectivity with only a
> > > small percentage (e.g., 20-1000 out of 10E5) of other clients but their
> > > combined effort maintains the network reliably.
> > >
> > > The location of the data/services is selected deterministically
> > so that when
> > > the users need to read the data or request a service, the users can find
> > > which 100 out of 10E5 stores it (or serves the service) and uses the
> > > interconnection network to eliminate dependencies on individuals.
> >
> > Ok, here is a solution which doesn't rely on any centralized event channel
> > server (it effectively places an "event channel" within each client):
> >
> >  * Before pushing the request out to the 10E2 servers, construct
> > a callback
> >    object to collect the responses.  Have its notification method block
> >    on a condition variable which you lock.
> >
> >  * Push the request out to the peers, passing the callback object as a
> >    parameter.  Drop into a loop, waiting on the condition, and break out
> >    of it when you have received "enough" responses.  Extract the
> >    collected results, destroy the callback object, and continue
> >    processing.
> >
> >  * Peers push the response to the callback object on request completion.
> >    If the callback has already been destroyed, they should receive a
> >    CORBA::NOT_EXIST exception, which they can safely ignore.  Actually
> >    the peer should ignore any CORBA exceptions -- you are working with
> >    what is effectively "best effort" semantics, anyway.
> >
>
> This is a good solution. But the second step (" Push the request out ... ")
> needs to be nonblocking. Without AMI, corba can only do one-way functions
> which does not guarantee message delivery (Correct me if I'm wrong. I'm not
> a corba or omniorb expert). For one-way functions, omniorb does async tcp/ip
> messages, which at first seems excellent. However MS Windows blocks async
> messages after an internal buffer fills up when there are unavailable
> servers.
>
> We cannot switch to another platform due to lack of such platforms at our
> lab. So we are stuck with MS Windows.
> We really don't want to switch to another orb because omniorb is really fast
> (fastest?).
>
> It seems to me that we are stuck with multiple threads solution. (Unless
> we/MS can solve the async message buffer problem).
>
> Does omniorb plan to support ami any time soon?
>
> Does omniorb create a separate port for all function calls?
>
> Since we are desperate, we are ready to accept an omniorb specific solution.
> In omniorb there is  tcpSocketStrand::shutdown() which sends a
> GIOP::CloseConnection to the socket which should unblock a socket. Can we do
> anything with this?
>
> > This design won't scale well beyond the number of peers you are planning
> > for (actually, I have only used it with dozens of peers, rather than
> > hundreds, and I was waiting for *all* responses, with a timeout).  It does
> > have the nice property that it requires no new threads in the client, as
> > long as the ORB can process the incoming callback invocations while the
> > "main" request is blocked.
> >
> > > I can send a copy of the paper we are submitting to ieee srds if you are
> > > interested.
> >
> > I'd be glad to look at it.
>
> The deadline is tomorrow and we are still collecting data. I'll post it to
> our web site as soon as it is available.
>
> >
> > > > > I though omniorb does not support AMI. Am I wrong?
> > > >
> > > > I don't know -- TAO has increasingly good support for it;
> > > > comp.soft-sys.ace is where I have seen the benefits of AMI discussed.
> > >
> > > We already invested a lot of time on omniorb (and we really
> > like it). I'm
> > > looking for a solution that uses omniorb. For example can we
> > send a dummy
> > > message to the port that waits for the responses to cancel
> > these calls? Will
> > > this work? Of course how do we find the port number of that the
> > thread that
> > > waits?
> > >
> > > Or can I kill the thread and except not to leave the omniorb in
> > an unstable
> > > state?
> >
> > I wouldn't try that -- hard thread kills are dangerous for lots
> > of reasons.
> > Even if it happens to work in some circumstances, it can never be
> > portable or
> > "safe":  think of locks held by the killed thread, for instance -- the OS
> > may or may not release them (most don't).
> >
> > --
> > =========================================================
> > Tres Seaver  tseaver@digicool.com   tseaver@palladion.com

[demime 0.97b removed an attachment of type text/x-vcard which had a name of haarek.ryeng.vcf]