ОШИБКА WCF: сервер не дал значимого ответа;

пожалуйста, кто-нибудь может помочь мне узнать, что произошло. У меня есть служба WCF, которая отлично работает, и теперь у меня есть эта ошибка:

Сервер не дал значимого ответа; это может быть вызвано несоответствием контракта, преждевременным отключением сеанса или внутренней ошибкой сервера

Я должен сказать, что он по-прежнему работает, когда я выбираю несколько тысяч записей, но когда данные огромны, я получаю эту ошибку, хотя до того, как она работала нормально!

    private static string ConnString = "Server=127.0.0.1; Port=5432; Database=DBname; User Id=UName; Password=MyPassword;"
    DataTable myDT = new DataTable();

                NpgsqlConnection myAccessConn = new NpgsqlConnection(ConnString);
                myAccessConn.Open();
        string query = "SELECT * FROM Twitter";

                NpgsqlDataAdapter myDataAdapter = new NpgsqlDataAdapter(query, myAccessConn);

                myDataAdapter.Fill(myDT);
                foreach (DataRow dr in myDT.Rows)
                {
   **WHEN I HAVE TOO MANY RECORDS IT STOPS HERE**
        ...

web.config

<configuration>
    <system.web>
        <compilation debug="false" targetFramework="4.0" />
      <httpRuntime maxRequestLength="2147483647" executionTimeout="100000" />
    </system.web>
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="Traces4.svclog"/>
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
  <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IDBService" closeTimeout="00:30:00"
                    openTimeout="00:30:00" receiveTimeout="00:30:00" sendTimeout="00:30:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="2147483647" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Streamed"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647"
                        maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
    <client>
      <endpoint address="" binding="basicHttpBinding" 
          bindingConfiguration="BasicHttpBinding_IDBService" contract="DBServiceReference.IDBService"
          name="BasicHttpBinding_IDBService" />
    </client>
        <behaviors>
            <serviceBehaviors>
                <behavior name="">
                  <serviceMetadata httpGetEnabled="true" />
                  <serviceDebug includeExceptionDetailInFaults="true" />
                  <dataContractSerializer maxItemsInObjectGraph="2147483646" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="false" multipleSiteBindingsEnabled="true" />
    </system.serviceModel>
</configuration>

Конфигурация клиента (Отредактировано)

<configuration>
        <system.serviceModel>
            <bindings>
                <basicHttpBinding>
                    <binding name="BasicHttpBinding_IRouteService" maxBufferSize="2147483647"
                        maxReceivedMessageSize="2147483647">
                        <security mode="None" />
                    </binding>
                    <binding name="BasicHttpBinding_IDBService" closeTimeout="00:30:00"
                        openTimeout="00:30:00" receiveTimeout="00:30:00" sendTimeout="00:30:00"
                        maxBufferSize="2147483647" maxReceivedMessageSize="2147483647"
                        transferMode="Buffered" >

                        <security mode="None" />
                    </binding>
                </basicHttpBinding>
                <customBinding>
                    <binding name="CustomBinding_IRouteService">
                        <binaryMessageEncoding />
                        <httpTransport maxReceivedMessageSize="2147483647"
                            maxBufferSize="2147483647" />
                    </binding>
                </customBinding>
            </bindings>

            <client>
                <endpoint address="http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc"
                    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IRouteService"
                    contract="BingRoutingService.IRouteService" name="BasicHttpBinding_IRouteService" />
                <endpoint address="http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc/binaryHttp"
                    binding="customBinding" bindingConfiguration="CustomBinding_IRouteService"
                    contract="BingRoutingService.IRouteService" name="CustomBinding_IRouteService" />
                <endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IDBService"
                    contract="DBServiceReference.IDBService" name="BasicHttpBinding_IDBService" />
            </client>
        </system.serviceModel>
    </configuration>

В моем файле scvlog я не получаю никакого исключения! У меня нет другой идеи, что еще я могу сделать, чтобы понять, где проблема. Пожалуйста, помогите мне!

ОТВЕТЫ

Ответ 1

Другой ответ, на всякий случай, когда кто-нибудь приезжает сюда, поскольку я искал общий ответ на вопрос.

Похоже, что DataContractSerializer, который делает работу осла, невероятно тонкий, но не всегда передает реальную ошибку клиенту. Серверный процесс умирает сразу после сбоя - следовательно, ошибка не может быть найдена. В моем случае проблема была перечислением, которое использовалось в качестве флагов, но не украшено атрибутом [Flags] (придирчивым или каким!).

Чтобы решить эту проблему, я создал экземпляр сериализатора и проверил ошибку в отладчике; здесь фрагмент кода, так как у меня это есть.

EDIT: В ответ на запрос в комментариях...

Изменен фрагмент кода, чтобы показать вспомогательный метод, который я сейчас использую. То же самое, что и раньше, но в удобной универсальной оболочке.

public static T CheckCanSerialize<T>(this T returnValue) {
    var lDCS = new System.Runtime.Serialization.DataContractSerializer(typeof(T));

    Byte[] lBytes;
    using (var lMem1 = new IO.MemoryStream()) {
        lDCS.WriteObject(lMem1, returnValue);
        lBytes = lMem1.ToArray();
    }

    T lResult;
    using (var lMem2 = new IO.MemoryStream(lBytes)) {
        lResult = (T)lDCS.ReadObject(lMem2);
    }

    return lResult;
}

И чтобы использовать это, вместо того, чтобы возвращать объект, возвращайте объект после вызова вспомогательного метода, поэтому

public MyDodgyObject MyService() {
    ... do lots of work ...
    return myResult;
}

становится

public MyDodgyObject MyService() {
    ... do lots of work ...
    return CheckCanSerialize(myResult);
}

Любые ошибки в сериализации затем бросаются до того, как служба перестает обращать внимание, и поэтому ее можно проанализировать в отладчике.

Заметка; Я бы не рекомендовал оставлять вызов в производственном коде, у него есть накладные расходы на сериализацию и десериализацию объекта без реальной выгоды после отладки кода.

Надеюсь, это помогает кому-то - я потратил около 3 часов, пытаясь отследить его.

Ответ 2

Я не знаю, действительно ли это может быть ответом, но я попытался изменить в web.config из <security mode="None"/> в <security mode="Transport"/> и он работал !!!

Я хотел бы обратить внимание на то, что эта часть должна быть изменена только в web.config и в конфигурации клиента остается <security mode="None"/>, потому что с Transport в обоих это не работает!

Поэтому после этого я решил попытаться вернуться к None security и он работал несколько минут, а затем снова остановился, и она вернула ошибку:

Сервер не дал значимого ответа; это может быть вызвано несоответствием контракта, преждевременным отключением сеанса или внутренней ошибкой сервера

Так что кажется, что решение в моем случае - установить в web.config

security mode to Transport

Ответ 3

В моем случае я работал над проектом приложения Windows, связанным с веб-службой WCF. Веб-служба, используя netTcpBinding, возвращала объект Stream (изображение).

Поскольку приложение Windows не имеет файла конфигурации, значения по умолчанию используются для привязок. И просто расширение MaxReceivedMessageSize на клиентской стороне бэкэнд-кода решило мою проблему.

var API = new StreamService.StreamServiceClient(
  new System.ServiceModel.NetTcpBinding(System.ServiceModel.SecurityMode.None)
  {
    MaxReceivedMessageSize = 2147483647
  },
  new System.ServiceModel.EndpointAddress("net.tcp://machine/app/service.svc")
);

Ответ 4

Иногда эта проблема вызвана негативным сообщением, которое было вырезано из-за значений по умолчанию в привязке.

Вы должны добавить maxReceivedMessageSize, maxBufferPoolSize и maxBufferSize с некоторыми достаточно большими значениями для привязки в файле app.config - это должно сделать трюк :)

Пример:

<bindings>
<netTcpBinding>
<binding 
name="ExampleBinding" closeTimeout="00:01:00"
maxReceivedMessageSize="73400320"
maxBufferPoolSize="70000000"
maxBufferSize="70000000"/>
</netTcpBinding>
</bindings>

Удачи!

Ответ 5

В моем случае я работал над приложением MVC, и я изменил

maxReceivedMessageSize ="10000000"

в

maxReceivedMessageSize ="70000000"

и это сработало! Это потому, что ответ с веб-сервера превышает maxReceivedMessageSize ="10000000",
поэтому я увеличил maxReceivedMessageSize до maxReceivedMessageSize ="70000000".

Ответ 6

Для меня это был ленивый список элементов, извлеченных из БД.

Приемник WCF попытается выполнить итерацию, которая будет пытаться перейти к БД, что явно не сработает.

Ответ 7

В моем опыте этой ошибки просто проверьте журнал событий хост-компьютера службы, чтобы узнать, что является фактическим корневым исключением.

Ответ 8

В BizTalk мы используем эту проблему.

В основном проблема возникает из-за размера сообщения от службы. Поэтому нам нужно увеличить размер получающего сообщения с 65,356 до 2,365,60. Это сработало для меня.

введите описание изображения здесь

Ответ 9

Приложения ASP.NET могут выполняться с идентификатором Windows (учетной записью пользователя) пользователя, отправляющего запрос. Олицетворение обычно используется в приложениях, которые используют Microsoft Internet Information Services (IIS) для аутентификации пользователя. Олицетворение ASP.NET по умолчанию отключено.

Включите это, ваш API начнет работать - он в аутентификации IIS