2

I can seem to find a definitive answer on this subject. I'm aware of the using() { } problem with the client proxy. But we have a client that is eating all exceptions returned by our service, and it seems like after the exception occurs, the client isn't able to communicate with the service anymore (we get no results in our service traces). The client is a web application (.NET 3.5). Has anyone experience this behavior?

Here is the client code:

public static bool ValidateDigitalSignatureCredentials(string barNumber, string PIN)
{

    UserInfo userTicket = JTAC.INcite.Framework.Security.Authentication.CurrentUser;
    DigitalSigning.DigitalSignatureClient client = null;

    bool validSigning = false;

    try
    {
        client = new DigitalSigning.DigitalSignatureClient();
        client.ClientCredentials.UserName.UserName = "foo";
        client.ClientCredentials.UserName.Password = "bar";
        validSigning = client.VerifyCredentials(barNumber, PIN);

        if (client.State != CommunicationState.Faulted)
        {
            client.Close(); // (timeout);
        }
        else
        {
            client.Abort();
        }
    }
    catch (CommunicationException)
    {
        client.Abort();
    }
    catch (TimeoutException)
    {
        client.Abort();
    }

    return validSigning;
}
Dylan Vester
  • 2,686
  • 4
  • 29
  • 40
  • Check client status. Is it in Faulted state? If it is then re-open it. – Asdfg Jul 12 '11 at 15:33
  • Try typecasting your client to ICommunicationObject and see if it still timesout? Also i think if it is in the faulted state, you may want to call Abort rather than close. not sure on that though. – Asdfg Jul 12 '11 at 15:40
  • It's good to turn on "break on all exceptions" in the Visual Studio debugger - then you'll see precisely what exception is being raised. Here, for example, I wonder if there's some other kind of exception being raised which is causing `client` to be invalid - perhaps an issue with credentials? – Jeremy McGee Jul 12 '11 at 15:42
  • I may be following a bad coding style, but I always use `var client = new client(); try { var result = client.call(); } catch (Exception) { client.Abort(); } finally { if (client.State == faulted) client.Abort(); else client.Close(); }`. – Brad Christie Jul 12 '11 at 15:43
  • check this http://stackoverflow.com/questions/315736/how-do-i-prevent-a-wcf-service-from-enter-a-faulted-state – Asdfg Jul 12 '11 at 15:44

1 Answers1

0

Some observatiosn/suggestions:

  1. Set includeExceptionDetailInFaults to true in the config file for the service - this will convert exceptions to a FaultException (should only be used for debugging). It's in the behaviors section of the config file, in the serviceDebug element.

  2. You can save some code by removing the check on the CommunicationState in your try block and simply call:

    client.Close();

    If an error is thrown, the catch blocks will catch it and abort the channel.

  3. If you try step 1, you might want to add another catch block:

    catch (FaultException) { }

  4. Also, I'd add (for debugging purposes) another catch block to handle Exception:

    catch (Exception) { }

Most likely the service is throwing an unhandled exception, which will fault the communication channel. Hopefully some of what I've put above will help you determine what the exception is so you can address it.

Tim
  • 28,212
  • 8
  • 63
  • 76