Question

I’m setting up a WCF client and server scenario that needs to be reliable and scalable and as part of that I’m trying to make it multithreaded. Admittedly I don’t have extensive multithreading experience.

On the client, the callback from the server (in this case “OnMessage”) fires a client-side event that should be passed off in the background. I have the client’s CallbackBehavior ConcurrencyMode set to Single (at least, for now). So in order to do a reply to the callback, rather than calling the handler as normal (either handler(sender, eventargs, or handler.Invoke…) I’m calling handler.BeginInvoke.

Everything works fine, but in the callback I’m wondering if I need to explicitly call EndInvoke or if I can basically do nothing (here’s my lack of multithreading experience showing).

public void OnMessage(Message message)
{
    EventHandler<MessageEventArgs> handler = OnServerMessage;
    if (handler != null)
        handler.BeginInvoke(this, new MessageEventArgs(message), CompleteHandler, handler);
}

public void CompleteHandler(IAsyncResult result)
{
    ((EventHandler<MessageEventArgs>)result.AsyncState).EndInvoke(result);
}

Can I replace CompleteHandler with a direct reference to handler.EndInvoke, or an empty method, or perhaps is there something more I should be doing?

Also, at the moment, the event subscriber blocks waiting on user input from the console. When the application is complete, it would either block waiting on the database, or be asynchronous bottom-to-top (so this may not be necessary, but I’d still like to know).

Answer 1

Yes you have to. Only way to find out if the invoked method threw an exception. And to cleanup the remoting state of the call so it can be garbage collected instead of letting it linger for another 10 minutes.