strange problem with Asynchronous call

[wobbles]

Hi Everyone,

I've spent hours investigating why my Async (one way) call wasn't
invoking the method on my server.

Basically, if I remove " Console.ReadLine() ", the method DOESN'T get
invoked.

Can anyone tell me why? Does the call require a pause?
(ErrorInformation is a serializable struct - for those who are
wondering)
Here's my code:
=========
private void Write(ErrorInformation ei) {

HttpChannel channel = new HttpChannel();
ChannelServices.RegisterChannel(channel);
IRemoteObject obj = (IRemoteObject) Activator.GetObject(
typeof(IRemoteObject),
"http://localhost:50000/ServerExceptionLog.soap");

RemoteWriteDelegate rwrDelegate = new RemoteWriteDelegate(obj.Write);
IAsyncResult rwrAsyncres = rwrDelegate.BeginInvoke(ei, null, null);
try {
rwrDelegate.EndInvoke(rwrAsyncres);
}catch(Exception e) {
//do something
}

// wait for keypress
Console.ReadLine();

}
=========

[Nicholas Paldino [.NET/C# MVP]]

wobbles,

Is it possible that you are calling the Write method and then exiting
the application? If so, it is possible that your application is shutting
down before the call can be remoted to the server.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"wobbles" <no***************************@killspam.hotmail.co m> wrote in
message news:5f********************************@4ax.com...

Hi Everyone,

I've spent hours investigating why my Async (one way) call wasn't
invoking the method on my server.

Basically, if I remove " Console.ReadLine() ", the method DOESN'T get
invoked.

Can anyone tell me why? Does the call require a pause?
(ErrorInformation is a serializable struct - for those who are
wondering)
Here's my code:
=========
private void Write(ErrorInformation ei) {

HttpChannel channel = new HttpChannel();
ChannelServices.RegisterChannel(channel);
IRemoteObject obj = (IRemoteObject) Activator.GetObject(
typeof(IRemoteObject),
"http://localhost:50000/ServerExceptionLog.soap");

RemoteWriteDelegate rwrDelegate = new RemoteWriteDelegate(obj.Write);
IAsyncResult rwrAsyncres = rwrDelegate.BeginInvoke(ei, null, null);
try {
rwrDelegate.EndInvoke(rwrAsyncres);
}catch(Exception e) {
//do something
}

// wait for keypress
Console.ReadLine();

}
=========

[wobbles]

>wobbles,

Is it possible that you are calling the Write method and then exiting
the application? If so, it is possible that your application is shutting
down before the call can be remoted to the server.

Hope this helps.

Hi Nicholas,

Ah...yes...currently it's in a console application testbed.
Thinking about it, when I call the method from within a "normal" app
(ie windows form or similar) the app won't exit so the problem
shouldn't be there.

Thanks for that. I can see that in "real life", it won't be a problem.

From a technical point, what we're saying is: the app needs to be
alive for the call to persist?
Shouldn't the call continue onto the server even if the client app
exits? I thought that was the point of calling EndInvoke?

In that case, is there some way for me to know if the call has been
remoted or not, before my app exits?

Thanks again,
wobbles
P.S. The only reason I use "one way" is because I don't want my client
to care if the server is running or not. If it is running, great. If
not, it's not critical because it's only for logging.

[Nicholas Paldino [.NET/C# MVP]]

wobbles,

Well, yes, you have to disable one-way semantics (remove the OneWay
attribute) so that you get a notification when the call is complete. You
can either do this by making the method call (which will block), or by
setting up a callback for when the response returns.

The reason the call doesn't go through is that when your thread exits,
it shuts down the runtime, and chances are the call hasn't been placed on
the wire before the runtime shuts down, so the server never gets the call.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"wobbles" <no***************************@killspam.hotmail.co m> wrote in
message news:ld********************************@4ax.com...

wobbles,

Is it possible that you are calling the Write method and then exiting
the application? If so, it is possible that your application is shutting
down before the call can be remoted to the server.

Hope this helps.

Hi Nicholas,

Ah...yes...currently it's in a console application testbed.
Thinking about it, when I call the method from within a "normal" app
(ie windows form or similar) the app won't exit so the problem
shouldn't be there.

Thanks for that. I can see that in "real life", it won't be a problem.

From a technical point, what we're saying is: the app needs to be
alive for the call to persist?
Shouldn't the call continue onto the server even if the client app
exits? I thought that was the point of calling EndInvoke?

In that case, is there some way for me to know if the call has been
remoted or not, before my app exits?

Thanks again,
wobbles
P.S. The only reason I use "one way" is because I don't want my client
to care if the server is running or not. If it is running, great. If
not, it's not critical because it's only for logging.

[wobbles]

>wobbles,

Is it possible that you are calling the Write method and then exiting
the application? If so, it is possible that your application is shutting
down before the call can be remoted to the server.

Hope this helps.

I went through Ingo's book again and at the bottom of the page of
Async oneway calls, I found this:

<Quote>
"...The interesting thing is that when using [OneWay()], the call to
EndInvoke() finishes before the server completes the method. This is
because in reality the client just ignores the server's response when
using one-way method calls...."
</Quote>

I think I understand now why this is.
If the client doesn't care (or know) if the server is running,
"EndInvoke" wouldn't know how long to wait to find out if the method
has been invoked or not.

Personally, I would like to have seen EndInvoke do its business (as a
non-oneway Async call would do) with the difference being that if the
Server doesn't exist, NO exception is thrown.

Then again I don't know if this would have been possible due to the
reasons mentioned above.
Thanks again for your help!