Skip to main content

C# WPF Tutorial - WCF Callbacks Hanging [Beginner]


Here's a bug that has driven me nuts over the past few days. I have a WPF application that communicates with a pretty basic WCF service. Whenever a callback is issued in the middle of a request, the WPF application completely hangs. It's obviously a synchronization issue, however I've gone through the forums and articles and set every imaginable attribute on every imaginable object with no successful outcome.

In the end, the answer was unexpectedly simple, however not one I would have ever guessed. I accidentally stumbled across the solution during a round of trying totally crazy things in an attempt to make something work. All I had to do was create my channel on a thread other than the application's main thread. Let me demonstrate with some examples.
public partial class Window1 : Window
{
  IStringReverser _channel;

  public Window1()
  {
    InitializeComponent();

    Callbacks callbacks = new Callbacks(_btnReverse);

    var factory = new DuplexChannelFactory<IStringReverser>(
      callbacks,
      new NetNamedPipeBinding(),
      new EndpointAddress(
         "net.pipe://localhost/PipeReverse"));

    _channel = factory.CreateChannel();
  }

  private void _btnReverse_Click(object sender, RoutedEventArgs e)
  {
    //ReverseString results in the server firing a callback.
    //Making this call will freeze the application.
    _channel.ReverseString("Hello World");
  }
}
 
If the correct attributes are not set on the client's implementation of the callback interface and the server's implementation of the service contract, I would actually expect a deadlock to occur, however the app still hangs regardless of the configuration.

The solution is to simply wrap the CreateChannel call in a new thread.
public partial class Window1 : Window
{
  IStringReverser _channel;

  public Window1()
  {
    InitializeComponent();

    Callbacks callbacks = new Callbacks(_btnReverse);

    var factory = new DuplexChannelFactory<IStringReverser>(
      callbacks,
      new NetNamedPipeBinding(),
      new EndpointAddress(
         "net.pipe://localhost/PipeReverse"));

    ThreadPool.QueueUserWorkItem(new WaitCallback(
      (obj) =>
      {
        _channel = factory.CreateChannel();
      }));
  }

  private void _btnReverse_Click(object sender, RoutedEventArgs e)
  {
    //This call no longer freezes the app 
    //and the callback is received correctly.
    _channel.ReverseString("Hello World");
  }
}
 
The callback now works without hanging the application, but there's one more hurdle. In order to do anything to the user interface, you're going to have to use the dispatcher and invoke a call. If you do this, the application will again hang - invoking onto the UI thread is exactly what got us into this mess in the first place. This can be easily fixed by using the dispatcher's BeginInvoke function.
public void MyCallbackFunction(string callbackValue)
{
  //doing this will hang the application
  _dispatcher.Invoke(new Action(
    () => _someControl.Text = callbackValue;));

  //this will not cause the application to hang
  _dispatcher.BeginInvoke(new Action(
    () => _someControl.Text = callbackValue;));
}
 
The _dispatcher variable is something you're going to have to get a hold of at some point during the creation of the callback interface. I typically create the interface on the UI thread then simply call Dispatcher.CurrentDispatcher and save that to my variable.

I've read several things stating that all that's actually required is to set the IsOneWay property on the callback's OperationContract attribute. In theory, that's how it should work, since if that is true, WCF will not perform any locking when sending that data. Unfortunately, that doesn't work. You should still keep that property set though, since it does other things you really will want.

The other major piece of information I came across was the UseSynchronizationContext property on the callback implementation's ServiceBehavior attribute. This one sounded really promising. When set to false, the callback will not automatically synchronize with the UI thread. This seems to be the source of the deadlock anyway, so I thought this was definitely it, but again, no luck.

All-in-all it came down to a simple fix that required a lot of headache to find. I'm not totally happy with the outcome, so if anyone else out there experienced this problem and has found a real solution, please let me know.

Edit: Check out this solution recommended by an alert reader to this problem.
[CallbackBehavior(ConcurrencyMode=ConcurrencyMode.Multiple, UseSynchronizationContext=false)]
Labels:

Comments

Post a Comment

Popular posts from this blog

C# Snippet - Shuffling a Dictionary [Beginner]

Randomizing something can be a daunting task, especially with all the algorithms out there. However, sometimes you just need to shuffle things up, in a simple, yet effective manner. Today we are going to take a quick look at an easy and simple way to randomize a dictionary, which is most likely something that you may be using in a complex application. The tricky thing about ordering dictionaries is that...well they are not ordered to begin with. Typically they are a chaotic collection of key/value pairs. There is no first element or last element, just elements. This is why it is a little tricky to randomize them. Before we get started, we need to build a quick dictionary. For this tutorial, we will be doing an extremely simple string/int dictionary, but rest assured the steps we take can be used for any kind of dictionary you can come up with, no matter what object types you use. Dictionary < String , int > origin = new Dictionary < string , int >();
1 comment
Read more

C# Snippet - The Many Uses Of The Using Keyword [Beginner]

What is the first thing that pops into your mind when you think of the using keyword for C#? Probably those lines that always appear at the top of C# code files - the lines that import types from other namespaces into your code. But while that is the most common use of the using keyword, it is not the only one. Today we are going to take a look at the different uses of the using keyword and what they are useful for. The Using Directive There are two main categories of use for the using keyword - as a "Using Directive" and as a "Using Statement". The lines at the top of a C# file are directives, but that is not the only place they can go. They can also go inside of a namespace block, but they have to be before any other elements declared in the namespace (i.e., you can't add a using statement after a class declaration). Namespace Importing This is by far the most common use of the keyword - it is rare that you see a C# file that does not h
Post a Comment
Read more

C# WPF Printing Part 2 - Pagination [Intermediate]

About two weeks ago, we had a tutorial here at SOTC on the basics of printing in WPF . It covered the standard stuff, like popping the print dialog, and what you needed to do to print visuals (both created in XAML and on the fly). But really, that's barely scratching the surface - any decent printing system in pretty much any application needs to be able to do a lot more than that. So today, we are going to take one more baby step forward into the world of printing - we are going to take a look at pagination. The main class that we will need to do pagination is the DocumentPaginator . I mentioned this class very briefly in the previous tutorial, but only in the context of the printing methods on PrintDialog , PrintVisual (which we focused on last time) and PrintDocument (which we will be focusing on today). This PrintDocument function takes a DocumentPaginator to print - and this is why we need to create one. Unfortunately, making a DocumentPaginator is not as easy as
Post a Comment
Read more