ОШИБКА 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