4

I have a Web API controller method that calls an external REST API service using the HttpClient. The results of the external REST call are then passed to a WCF Service via a call to its proxy.

If I call the WCF proxy first and then call the external REST service everything works as expected. If I reverse the order of the calls, the WCF proxy call fails because the InnerChannel (m_inner_channel = m_channel_factory.CreateChannel()) on the proxy is null.

Here is an example for illustration purposes:

 //Call to external REST API Service (works)
 user = await m_http_client.GetProfileAsync(id).ConfigureAwait(false);

 //Call to WCF Service (works)
 using (WCFServiceProxy wcf_proxy = new WCFServiceProxy())
 {
     config = await wcf_proxy.GetConfigAsync(user.ssid).ConfigureAwait(false);
 }

The code above works, however if I implement the code below the WCF proxy's InnerChannel (m_inner_channel = m_channel_factory.CreateChannel()) is null when I make the call to the service:

 //Instantiate WCF Proxy - Creates ChannelFactory
 WCFServiceProxy wcf_proxy = new WCFServiceProxy()

 //Call to external REST Service (works)
 user = await m_http_client.GetProfileAsync(id).ConfigureAwait(false);

 //Call to WCF Service (InnerChannel is no longer instantiated)
 config = await wcf_service.GetConfigAsync(user.ssid).ConfigureAwait(false);

If I change the order of the calls as shown below it works again:

 //Instantiate WCF Service
 WCFServiceProxy wcf_proxy = new WCFServiceProxy()

 //Call to WCF Service (works)
 config = await wcf_service.GetConfigAsync("2423432").ConfigureAwait(false);

 //Call to external REST Service (works)
 user = await m_http_client.GetProfileAsync(id).ConfigureAwait(false);

Can anyone help me determine what is going on here? The problem still occurs if I change the ConfigureAwait values to true, so it's not a context switching issue.

There are several Web API methods within this same service that call the WCF proxy above without any issues, the problem only occurs when I call an external service before making a call to the WCF proxy object.

Any help and/or insights would be greatly appreciated.

Thank you, Andrew

Andrew Bromfield
  • 103
  • 6
  • can you post the stack trace? – 1.618 May 05 '16 at 17:59
  • have you tried disposing HttpClient after calling the external service? – 1.618 May 05 '16 at 18:01
  • Thank you for the suggestions above, I am disposing the HttpClient, it's instantiated in a "using" statement and the variable that references the instantiated HttpClient object is set to null in my finally statement. – Andrew Bromfield May 05 '16 at 18:13
  • My stack trace in this instance isn't revealing anything useful, just that the object is not instantiated. What's even stranger is that there isn't any errors in my WCF trace logs (SvcTraceViewer.exe). – Andrew Bromfield May 05 '16 at 18:21
  • 1
    I've seen something like that happen when Dispose() gets called on an object earlier than expected as a result of an exception. This can happen with HttpListener, for example. – 1.618 May 05 '16 at 18:25
  • Also, if I call the method repeatedly, every once in a while the expected result will be returned (less than 1/4 of the time). The proxy object is managed by Simple Injector's DI (Scoped), but the same issue appears when I manually instantiate the proxy as I did in my code examples above. It's been a while since I've been stumped like this. The one thing I know for sure is that making that call to the external REST service causes the proxy to fail the majority of the time. Thanks again for trying to help me out with this, I really appreciate it. – Andrew Bromfield May 05 '16 at 18:26

1 Answers1

0

I finally resolved my issue above. I retrieve the ClientChannel from a property called InnerChannel, which uses Monitor.TryEnter to ensure the creation of the channel is performed by a single thread. There was a problem with the creation of this lock, which resulted in the InnerChannel not being instantiated. I rewrote the critical section of the Monitor code to solve the problem.

Thank you for your assistance 1.618.

Andrew

Andrew Bromfield
  • 103
  • 6