2014-07-08 4 views
2

У меня проблема с отправкой большого xml с клиента в службу WCF net.tcp, а клиент на определенных машинах выдает исключение из памяти при вызове метода, который я не могу воспроизведите на моем локальном компьютере: Сообщение об исключении: Не удалось выделить буфер управляемой памяти 33554432 байт. Объем доступной памяти может быть низким.Служба WCF NetTcp и потоковая передачаmode

Так что, прочитав способы решения этого вопроса, это было похоже на то, что поток швов был правильным. Поэтому я изменил привязку на клиенте и обслуживание соответственно:

<netTcpBinding> 
     <binding name="NetTcpBinding_IPricerDataService" closeTimeout="00:10:00" transferMode="Streamed" 
      openTimeout="00:10:00" sendTimeout="00:10:00" maxBufferPoolSize="2147483647" 
      maxReceivedMessageSize="2147483647" /> 
</netTcpBinding> 

Однако, я был под впечатлением, что это означало также изменение сигнатуры метода службы принять параметр потока: http://msdn.microsoft.com/en-us/library/ms789010(v=vs.110).aspx

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

Означает ли это, что потоковый трансформатор используется не так, как ожидалось, или мне не нужно менять сигнатуры метода для поддержки потоковой передачи? Любые идеи, как я могу действительно проверить?

ответ

2

Если вы не меняете сигнатуры своего метода, вы не строго передаете данные, а отправляете их точно так же, как и раньше, независимо от конфигурации сервера. В документации MSDN вы связаны состояния:

  • Параметр, который содержит данные, подлежащие потоковой передаче должен быть единственным параметром в методе. Например, если входное сообщение является потоковым, операция должна иметь ровно один входной параметр. Аналогично, если выходное сообщение должно быть потоковым, операция должна иметь либо ровно один выходной параметр , либо возвращаемое значение.
  • По крайней мере, один из типов параметра и возвращаемого значения должны быть либо поток, сообщение или IXmlSerializable.

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

Это показано в следующем ServiceContract:

[OperationContract] 
Stream GetStream(string data); 
[OperationContract] 
bool UploadStream(Stream stream); 
[OperationContract] 

Если вы не указываете свои методы, как показано выше, вы не будете в конечном итоге потоковой передачи данных между клиентом и службой - вы будете использовать точно так же, как и до изменения конфигурации сервера. Это также причина, по которой ваши методы все еще работают, хотя вы указали, что хотите использовать потоковое вещание в конфигурации, но не изменили свои методы.

Измените эти методы, чтобы они соответствовали критериям, изложенным в статье MSDN, и вы должны правильно передавать потоки данных. Просто убедитесь, что вы берете всю вещь вверх/вниз по течению, так как она будет отменена для клиента и сервера.

На стороне записки, Ваше сообщение исключение:

Исключение Сообщение: Не удалось выделить управляемый буфер памяти 33554432 байт. Объем доступной памяти может быть низким.

Указывает, что система не может выделить 32 МБ данных для лежащего в основе буфера, содержащего ваши данные. Эта проблема может продолжаться, даже если вы правильно выполняете потоки. Буферы с 32 МБ не должны быть проблемой при нормальных условиях.

+0

@ DanielKelley Как это не отвечает на вопрос? «Означает ли это, что потоковый трансформатор не используется, как ожидалось, или мне не нужно менять сигнатуры методов для поддержки потоковой передачи?», А также некоторые отклонения от того, что буфер не выделяется. – aevitas

+0

@ DanielKelley Спасибо, я отредактирую ответ, чтобы просто указать «Да, вы должны». как кажется, это то, что вам нужно. Не стесняйтесь, если вы чувствуете, что не отвечает на вопрос. – aevitas

+0

@ DanielKelley Спасибо, я разработал свой ответ. – aevitas