0

I noticed that when I set <serviceThrottling maxConcurrentCalls="2" [only for a test] in a wcf service endpoint and I activate two calls that are kept alive and I activate a third call, that then the channel on the client side is created and opened without any problem.

I would have expected that opening fails due to maxConcurrentCalls, but it doesn't. Only after the sendtimeout is reached the communication gives an exception.

I would prefer that opening a channel would fail when maxConcurrentCalls has been reached. Is it possible to configure such a behaviour?

Gerard
  • 13,023
  • 14
  • 72
  • 125

1 Answers1

1

Gerard ... having an open connection between a host and client is not the same thing as a concurrent call. Concurrent, in this context, means that calls are in process on the host (that moment after the host receives the request and the response is sent). maxConcurrentCalls deals with how many calls are processed concurrently, but going over that limit simply queues the remaining requests until one of the other calls is completed and a new slot is ready - no error is sent. I don't believe you can make it throw an error when the limit's hit.

Also, unless you're bombing the host with calls, it's not easy to actually reach three concurrent calls since calls are processed so quickly.

Interestingly, I'd had to do a bunch of performance/load testing on an industrial-size WCF site (basichttpbinding) and having the maxconcurrentCalls (and the other throttling settings) set to 1 or 1000 doesn't have a huge impact on how fast you can process requests. In fact, the fastest I was able to get our servers going (>180 calls/second, each uploading a file) was turning off the throttling and just letting WCF manage itself.

Brian
  • 3,653
  • 1
  • 22
  • 33
  • I missed the queue thing, that it waits for a free slot. I thought that only occurs in message queueing? Is it not possible to forbid queueing? Btw, I left the connections open in the test, never closed them. – Gerard Jan 15 '14 at 15:00
  • I don't know for sure if you can forbid queuing. I don't think so; I think the queuing behavior is automatic. As for closing or not closing the connections, that's something to consider when you pick your binding. If you're using one of the http-centric bindings like basichttpbinding or wshttpbinding, closing the connection has no affect on the host, only the client. However, if you're using an TCP binding, then I think the connections can persist and, therefore, you should close the connection explicitly. – Brian Jan 15 '14 at 15:04
  • We are using wshttpbinding, but when I dispose the connections on the client, the host has a free slot, when I do not dispose it has not. – Gerard Jan 15 '14 at 15:19
  • 1
    If it's a problem, you might try this. I'm not a big user of wshttpbinding, but apparently it will create sessions that can persist even after your work is finished. Hence, when you close the connection from the client, the host opens up a work slot. But there's a setting you can add: which (from what I've read) makes the wshttpbinding host skip the whole session process, which you probably don't need anyway. Here's a link: http://stackoverflow.com/questions/832871/wcf-concurrent-requests-piling-up-on-the-server-when-using-wshttpbinding – Brian Jan 16 '14 at 07:49
  • I don't observe any different behaviour. Also a receiveTimeout on the server of e.g. 3 seconds doesn't help. Besides I have – Gerard Jan 16 '14 at 14:39
  • I'm not sure what to suggest at this point. Maybe try BasicHTTPBinding instead and see if you get different results. BasicHTTPBinding doesn't do sessions at all. – Brian Jan 16 '14 at 15:00