I was experiencing this bug fairly long enough and without any success in reproduction.
Setting sendTimout to more than 1 default minute was not a decision, because this obviously was not an execution time problem. So as I have described in the previous post about WCF diagnostic, I analysed logs and found out that the response was actually sent from the server towards client which the client somehow failed to recieve. How is that? After pondering some time on the problem I just modified an amount of simultaneous client connection.
This has resolved the issue, but soon after it became clear that I was looking in wrong direction: another two methods clogged the channel which led to above mentioned methods timeout.
Some links which might be helpful:
http://stackoverflow.com/questions/981475/wcf-timeout-exception-detailed-investigation
http://www.codeproject.com/Articles/36031/WCF-Tracing-FAQs
http://www.codeproject.com/Articles/420538/Simple-steps-to-enable-tracing-in-WCF
Setting sendTimout to more than 1 default minute was not a decision, because this obviously was not an execution time problem. So as I have described in the previous post about WCF diagnostic, I analysed logs and found out that the response was actually sent from the server towards client which the client somehow failed to recieve. How is that? After pondering some time on the problem I just modified an amount of simultaneous client connection.
This has resolved the issue, but soon after it became clear that I was looking in wrong direction: another two methods clogged the channel which led to above mentioned methods timeout.
Some links which might be helpful:
http://stackoverflow.com/questions/981475/wcf-timeout-exception-detailed-investigation
http://www.codeproject.com/Articles/36031/WCF-Tracing-FAQs
http://www.codeproject.com/Articles/420538/Simple-steps-to-enable-tracing-in-WCF
