WCF NetTcpBinding + Single Instance + Single Concurrency = Blocking/Dropping Calls?

Question

I have a simple WCF service hosted in a windows service. The service itself does nothing but simulating a long transaction that takes 10 seconds to complete. I also have code in the service to log entries to my database so I know it's being invoked, operation completed,...etc. Here's the summary of service configurations:

1. Binding: NetTcpBinding
2. SessionMode: Allowed (doesn't really matter)
3. IsOneWay: true
4. InstanceContextMode: single
5. ConcurrencyMode: single

Then I have my test client to call the service method 4 times in a row. What I expect to see in the log is that everything is being executed sequentially and multiple calls are queued up and served when the service is done with the previous call.

However, I can see only the 1st call being logged and the rest are dropped. If I put a 15 seconds gap in between each call then every one will be served and logged. I've messed around with all kinds of settings (inactivityTimeout, listenBackLog,...etc.) but nothing helped.

What am I missing here?

Answer 1

• InstanceContextMode: single creates a singleton - there's only ever gonna be a single instance of your service class capable of servicing requests.

• ConcurrencyMode: single means: that singleton service class can only handle a single request at a time, e.g. it will sequentially handle incoming requests

By using these two settings, you've created yourself a nice bottleneck.... yes, requests will be served sequentially, one by one. So obviously, at some point, the second and subsequent request must run into something like a timeout or something and get dropped. Those timeouts normally are set to 1 minute, so a 10 second transaction shouldn't really cause any grief....

It really depends on how you do these calls, and since you provided no code at all, I can only guess. Are you using a single WCF client-side proxy? Or do you really have four separate app instances, each sending out a request?

Are you getting any error or faults on the client side where you send out the requests?? If so: what kind of errors? Does your client code cause a session to start?

Just out of curiosity: is this just a thought experiment, or is there any specific reason why you want to arbitrarily create such a bottleneck in your system?? The recommended best practice would be to have InstanceContextMode=PerCall, and that would solve all those issues, I'm pretty sure: all four requests would get their own copy of the service class and they should be handled concurrently, just fine.