Proxy Close() blocks with an OneWay operation

http://social.msdn.microsoft.com/Forums/en/wcf/thread/a1dad52a-44ef-4aa3-975a-5a3231d480e5

I found out that closing a proxy can make your application block until the service operation is done for oneway operations. This happens in cases where sessions are used in the binding like with message security and or reliable sessions.

Now for wsHttpBinding you can disable sessions on the service contract via SessionMode.NotAllowed. If you do this then it works just fine again: closing the proxy isn't blocking anymore until the service operation is done.

But why is this not the default behavior? Even if using reliable sessions or message security I'd still like to return the client when the message is delivered at the service. I don't want to wait until it's done.

Or does SessionMode.NotAllowed make any changes to how message security and or reliable sessions are working?

• Reply
• Quote

All Replies

• Monday, March 15, 2010 4:25 AM

  Steven Cheng - MSFT

  (MSFT)

  12,980 Points

   
  

  0

  Sign In to Vote

  Hi Gerbenvl,
  
  As for wshttpbinding, it adds support for those WS-* protocols like security, reliable message(which is not provided in basicHttpbinding). Therefore, wsHttpBinding itself is supposed to be used for scenarios that you will need to turn on those features and reliable message and security is turn on by default for this binding. Of course, you can manually disable reliable message or turn off security in binding configuration or just make your WCF serviceContract not to use it. If such kind of feature is useless in your case, you can even consider using basicHttpBinding instead, basichttpbinding is more interop oriented.
  
  Here are some web articles that have discussed the difference between them:
  
  #Difference between BasicHttpBinding and WsHttpBinding
  http://www.codeproject.com/KB/WCF/HttpBinding.aspx

  #WCF : BasicHttpBinding compared to WSHttpBinding at SOAP packet level.
  http://geekswithblogs.net/claeyskurt/archive/2008/04/22/121508.aspx
  
  
  
  

  ---

  Please remember to mark the replies as answers if they help and unmark them if they provide no help.
  • Reply
  • Quote
• Tuesday, March 16, 2010 4:40 PM

  gerbenvl

  325 Points

   
  

  0

  Sign In to Vote
  I want the WS* features, but I also want to use them oneway without blocking Proxy.Close() calls.
  
  When setting SessionMode.NotAllowed my calls to Proxy.Close() don't block anymore. Though I'm still seeing SecurityContext handshakes and sequence requests comming over the wire in the message logs when enabling reliable messaging and or message security. Even while sessions are disabled.
  
  So what is SessionMode.NotAllowed doing under the covers? Does it make any changes to how message security and or reliable sessions are working? Can't see any difference in the message logs.
  • Reply
  • Quote
• Wednesday, March 17, 2010 5:26 AM

  Steven Cheng - MSFT

  (MSFT)

  12,980 Points

   
  

  0

  Sign In to Vote
  Hi gerbenvl,
  
  AS for SessionMode.NotAllowed,when you set it on ServiceContract, that means the service will not be allowed to use any binding protocol that is naturally session oriented, such as netTcpBinding(If you use it with SessionMode.NotAllowed you will get exception). For WSHTTPBinding, the http protcol itself is not naturally session oriented, and the session is implemented through the other message layer features such as WS-reliable message or ws-secureConversaion. When you set SessionMode.NotAllowed, there should be some of these features that are restricted which might be the reason you see different on Proxy.close() call. Since there is no definte document on the detailed implementation, you can use fiddler or service tracing to watch the message exchange process when you set it to allowed and now allowed for the difference.
  

  ---

  Please remember to mark the replies as answers if they help and unmark them if they provide no help.
  • Reply
  • Quote
• Wednesday, March 17, 2010 3:59 PM

  gerbenvl

  325 Points

   
  

  0

  Sign In to Vote

  Thanks Steven, I checked this with Fiddler, good idea:
  
  No differences in the messages themselves that go over the wire. There are only differences in timing. The last message when sessions allowed on the contract are send after the service operation if fully done. The last messages are TerminateSequence for reliable messaging and Security Token cancel message for message security. Only after they are send the client call to proxy.Close() is released.

  When disabling sessions on the service contract these last messages are send immediately, without waiting for the service operation. Proxy.Close() is also directly released.
  
  Documented the cases where proxy.Close() blocks here:
  http://bloggingabout.net/blogs/gerben/archive/2010/02/01/wcf-best-practice-5-one-way-is-not-always-really-one-way.aspx
  
  So my remaining question is: why are these last messages not send immediately in the default configuration (SessionMode.Allowed)? This makes oneway blocking in cases where you don't want and expect it.