Clint
10/28/2004 5:02:00 AM
Thanks for taking the time to look into this. I don't know either why it
doesn't work as expected. Very strange. I don't want to use [OneWay]
because I may in the future want to obtain a result of the call I am making,
if possible. And I expect that, as you surmise, there would be a "hung"
thread in that case as well.
I haven't looked or tried to find the sscli code that would implement this,
I don't really have the time to go trawling through there just now.
However, I expect one might find some clues there as to what is going on.
-Eric Twietmeyer
"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:uJtyvy7uEHA.3752@TK2MSFTNGP10.phx.gbl...
> I found what you said surprising, but I'm able to replicate exactly what
> you've stated. What I found was that if the server went down between calls
> to the remote object, then the behavior you would expect actually
occurs --
> the callbak is invoked and the call to EndInvoke() raises an exception
> indicating that the connection was lost. But, if the server goes down
while
> the client blocks waiting for a response from the server, the async
callback
> is never invoked.
>
> That said, another way of performing asynchronous remoting calls it to use
> the OneWay attribute on the methods you plan to invoke asynchronously
> (assuming they will always be invoked asynchronously). You already said
you
> don't care about the result of the call -- you were just calling EndInvoke
> to ensure proper cleanup of the async data. That's the perfect scenario
for
> using OneWay since you will receive not return value (or errors) from the
> server and don't have to worry about setting up a delegate or callback.
>
> That said, I assume that, internally, the implementation of the OneWay
> attribute is essentialy the same thing you've done -- create a delegate,
> invoke it asynchronously and set up a bogus callback for it so EndInvoke()
> will be called. So, it stands to reason you'd end up losing a thread pool
> thread either way if the call dies on the server.
>
> I have to admit I don't understand why this doesn't work as expected. This
> really goes against my understanding of how asynchronous calls via
delegate
> work.
>
> Ken
>
>
>
> "Eric Twietmeyer" <notvalid@noisp.com> wrote in message
> news:%23Itqec7uEHA.3828@TK2MSFTNGP12.phx.gbl...
> > Hello,
> >
> > I'm using asynchronous delegates to make an asynchronous call to a
remote
> > object. I'm using AsyncCallback to handle the requirement of calling
> > EndInvoke appropriately when the method finishes.
> >
> > For testing purposes, I am simply calling Environment.Exit in the remote
> > object method being called to see what occurs on the client side. I had
> > expected that I would see the AsyncWaitHandle associated with this async
> > call to be signalled, followed by a call to the AsyncCallback method,
> where
> > my call to EndInvoke would then throw an exception.
> >
> > When I make a synchronous remote object call and the remote (server) app
> is
> > killed while that call is in progress then this call on the client
throws
> an
> > exception (unexpected socket closure or something like that). I had
> > expected the same would occur in an asynchronous call.
> >
> > However, what I find is that the AsyncWaitHandle associated with this
> remote
> > object call is never signalled if the server shuts down while the call
is
> in
> > progress. And so the AsyncCallback never occurs, so I can never call
> > EndInvoke.
> >
> > Why is this? Is there some way I can terminate a "hung" async remote
> object
> > call in some way? The docs are pretty explicit that for every
BeginInvoke
> > there should be a corresponding EndInvoke, as there are internal objects
> > associated with async calls that can only be cleaned once EndInvoke is
> > called.
> >
> > Any pointers on how to detect and/or handle unexpected termination of
the
> > process handling the remote call would be appreciated.
> >
> > Thanks!
> >
> > -Eric Twietmeyer
> >
> >
>
>