views:

2240

answers:

2

Hi,

How can I unit test the effect of each WCF timeout setting? I want to ensure that I select good values and I also want to make sure that my exception handling code is solid.

I created client program and a server WCF service to test the timeout settings. In my service implementation, I added a Thread.Sleep(5000). On the client-side, the only setting that causes a timeout to happen is sendTimeout.

No matter which value I use in all the other settings, the timeout never occurs. How to I test all the other settings?

Here are the settings I would like to test: sendTimeout, receiveTimeout, closeTimeout, openTimeout and inactivityTimeout (in reliableSessions).

Edit 19 feb 2009 : This edit is just to indicate that I still haven't found a way to unit test the WCF timeout settings.

A: 

Not a complete answer, but the explanation of the timeout values linked below may be helpful.

http://social.msdn.microsoft.com/forums/en-US/wcf/thread/84551e45-19a2-4d0d-bcc0-516a4041943d/

Brian
Thanks Brian, that is a helpful link indeed. It does not answer my question on how to unit test the timeouts but it will help nonetheless.
Sly
A: 

If you look in the right place, you can get the channel events and modify your test to be aware of them. Connect is a boolean method on the WCF service. I used svcutil to generate a proxy class using async methods.

private StateManagerClient _stateManagerClient;
private InstanceContext _site;

public New()
{
    _site = new InstanceContext(this);
    _serviceClient = new ServiceClient();
    _serviceClient.ConnectCompleted += ServiceClient_ConnectCompleted;
}

private void ServiceClient_ConnectCompleted(object sender, ConnectCompletedEventArgs e)
{
    //Bind to the channel events
    foreach (IChannel a in _site.OutgoingChannels) {
        a.Opened += Channel_Opened;
        a.Faulted += Channel_Faulted;
        a.Closing += Channel_Closing;
        a.Closed += Channel_Closed;
    }
}

private void Channel_Opened(object sender, EventArgs e)
{
    
}

private void Channel_Faulted(object sender, EventArgs e)
{
    
}

private void Channel_Closing(object sender, EventArgs e)
{
    
}

private void Channel_Closed(object sender, EventArgs e)
{

}

I hope this provides you some value.

Chris Porter
Hi Chris, thanks for your answers. That is useful to track the channel events but that does not help me cause the timeout exceptions. I really need to cause the timeout exceptions in order to prove that my error handling code is correct.
Sly
I'm not aware of any code that can force a timeout but you could drop your values in order to make them easier to trigger.
Chris Porter
Hi Chris, I did that; I dropped all timeout values to 1 sec, on both sides (client/service). The only setting that is effective is sendTimeout, raised by the client. All the other timeout settings are ineffective, which is the reason why I'm posting this question. How am I supposed to select good values and ensure I have good timeout handling code if there is no way to reproduce each kind of timeout in a controlled environment?
Sly
Have you tried to put sleep code in the open/close/receive events to cause them to timeout? For the Opening/Closing methods, just slow them down enough to cause the timeout. For the receive event, increase the amount of data to something big enough that it will take more than 1 second to transmit.
Chris Porter
Thanks again for your help. Those are really good ideas. I'm going to try them and let you know the results. Do you know if similar events exist on the server side API and on which interface are they exposed?
Sly