tags:

views:

158

answers:

2

I am getting the following error when trying to use the WCF Test Client to hit my new web service. What is weird is every once in awhile it will execute once then start popping this error.

Failed to invoke the service. Possible causes: The service is offline or inaccessible; the client-side configuration does not match the proxy; the existing proxy is invalid. Refer to the stack trace for more detail. You can try to recover by starting a new proxy, restoring to default configuration, or refreshing the service.

My code (interface):

[ServiceContract(Namespace = "http://rivworks.com/Services/2010/04/19")]
public interface ISync
{
    [OperationContract]
    bool Execute(long ClientID);
}

My code (class):

public class Sync : ISync
{
    #region ISync Members
    bool ISync.Execute(long ClientID)
    {
        return model.Product(ClientID);
    }
    #endregion
}

My config (EDIT - posted entire serviceModel section):

<system.serviceModel>
  <diagnostics performanceCounters="Default">
    <messageLogging logMalformedMessages="true" logMessagesAtServiceLevel="true"
      logMessagesAtTransportLevel="true" />
  </diagnostics>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
  <behaviors>
    <endpointBehaviors>
      <behavior name="JsonpServiceBehavior">
        <webHttp />
      </behavior>
    </endpointBehaviors>
    <serviceBehaviors>
      <behavior name="SimpleServiceBehavior">
        <serviceMetadata httpGetEnabled="True" policyVersion="Policy15"/>
      </behavior>
      <behavior name="RivWorks.Web.Service.ServiceBehavior">
        <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
        <serviceMetadata httpGetEnabled="true"/>
        <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
        <serviceDebug includeExceptionDetailInFaults="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>

  <services>
    <service name="RivWorks.Web.Service.NegotiateService" behaviorConfiguration="SimpleServiceBehavior">
      <endpoint address=""
                binding="customBinding"
                bindingConfiguration="jsonpBinding"
                behaviorConfiguration="JsonpServiceBehavior"
                contract="RivWorks.Web.Service.NegotiateService" />
      <!--<host>
        <baseAddresses>
          <add baseAddress="http://kab.rivworks.com/services"/&gt;
        </baseAddresses>
      </host>
      <endpoint address=""
                binding="wsHttpBinding"
                contract="RivWorks.Web.Service.NegotiateService" />-->
      <endpoint address="mex"
                binding="mexHttpBinding"
                contract="RivWorks.Web.Service.NegotiateService" />
    </service>
    <service name="RivWorks.Web.Service.Sync" behaviorConfiguration="RivWorks.Web.Service.ServiceBehavior">
      <endpoint address="" binding="wsHttpBinding" contract="RivWorks.Web.Service.ISync" />
      <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
  </services>

  <extensions>
    <bindingElementExtensions>
      <add name="jsonpMessageEncoding" type="RivWorks.Web.Service.JSONPBindingExtension, RivWorks.Web.Service, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
    </bindingElementExtensions>
  </extensions>

  <bindings>
    <customBinding>
      <binding name="jsonpBinding" >
        <jsonpMessageEncoding />
        <httpTransport manualAddressing="true"/>
      </binding>
    </customBinding>
  </bindings>    
</system.serviceModel>

2 questions:

  1. What am I missing that causes this error?
  2. How can I increase the time out for the service?

TIA!

A: 

Found the problem(s)...

  1. Had an error inside the web service that was not handled.
  2. The test app does not do an ABORT when it sees an error. Instead, it is left unhandled (and unreported) AND the channel is now locked because of the error.

Putting a try/catch around the inside method makes it so I can log the error and the test app does not lock up.

Keith Barrows
A: 

I'm getting the same error when connecting to IBM.iseries database via wcf.What will be the reason

renjucool