c# - puede - ¿Cómo abortar un flujo del servicio WCF sin leerlo hasta el final?
hasta los cuantos meses se puede abortar (3)
Este es un problema que he estado investigando en la última semana y no puedo encontrar ninguna solución. Encontré publicaciones que preguntan lo mismo pero nunca obtuvieron una respuesta, con suerte esto también ayudará a otros.
Tengo un servicio WCF que devuelve un objeto que contiene un stream dentro de él. Utilizo basicHttpBinding con transferencia transmitida y Mtom para enviarlo al cliente.
El cliente llama al servicio WCF y cierra el proxy inmediatamente después de que recibe el objeto de respuesta.
A continuación, el cliente lee el flujo que obtuvo del servicio WCF y lo escribe en un archivo en el disco local. Todo esto funciona bien.
Mi problema es cuando el cliente desea cancelar la operación y dejar de descargar los datos del servicio WCF. Si llamo a .close() en la transmisión, por ejemplo: serverReply.DataStream.Close(); luego bloquea y lee todo el flujo desde el servicio WCF hasta su final antes de continuar. El flujo puede ser bastante grande y la red no siempre es rápida.
Esto es muy indeseable para el uso de recursos de la red, que básicamente se desperdicia en datos que ya no tienen uso. Y dado que basicHttpBinding permite solo dos conexiones TCP simultáneas (de manera predeterminada) al servidor de servicio WCF, bloquea otros intentos de conexión hasta que la secuencia se lee hasta su final.
Podría aumentar el número de conexiones simultáneas, pero eso sería una mala solución, ya que crearía una apertura para problemas.
Por ejemplo, 20 descargas abortadas que todavía están descargando los datos para desecharlos. Necesito hacer que la transferencia se detenga por completo.
En el cliente, el objeto de flujo es solo una clase de Stream regular, por lo que solo tiene el método de cerrar, nada más.
Llamar a .close() o .abort() en el objeto proxy no ayuda, tampoco lo destruye usando .dispose() o cualquier otro método. En el lado del servidor, manejo el evento OperationContext.OperationCompleted , pero no se activa hasta que los datos de la stream se leen hasta el final.
Entonces, la pregunta es, ¿cómo cierro / aborto el flujo sin leerlo por completo?
¿Has intentado jugar con el binding.MaxBufferSize ?
¿Ha intentado jugar con la configuración del archivo app.config, por ejemplo:
<bindings>
<wsHttpBinding>
<binding name="default" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"
closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" >
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="4096" maxNameTableCharCount="16384"
maxDepth="64" maxStringContentLength="2147483647" />
</binding>
</wsHttpBinding>
</bindings>
Minimizaría los tiempos de espera y la duración de los búferes e intentaría abortar o cerrar y ver qué sucede.
Creo que simplemente estás recibiendo el búfer después de cerrar. Debe establecer maxBufferSize en un valor más bajo.
Es posible que también desee restringir la cantidad de datos leídos en el servidor envolviendo su flujo y anulando la lectura. Use trozos más pequeños si tiene un cliente con poco ancho de banda y devuelva un conteo correspondiente del método de lectura para que coincida con la cantidad que realmente leyó. Esto restringiría la tasa de llenado del búfer.
Mis propias pruebas sobre este tema me involucraron en escribir un NeverEndingStream y devolver datos siempre. En algún momento llamé a close en el cliente y casi inmediatamente se llamó al cierre en el servidor. Esto sugiere que el búfer simplemente se vació porque claramente nunca podría leer mi flujo hasta el final.
Si aún experimenta problemas, le sugiero que realice un seguimiento de la sincronización del método de Lectura en su transmisión anulada. Si currentReadtime - lastReadTime es> x, entonces podría llamar Cerrar y lanzar una excepción. Eso lo matará seguro.
Después de la investigación, descubrí que el cliente de WCF continuará leyendo desde la secuencia hasta que se cierre el tiempo de cierre, y luego abortará la conexión. Puede reducir closeTimeout en el cliente para minimizar el problema.
NOTA: debe ajustar el código que desecha una secuencia en el bloque try / catch. El método stream.Dispose () lanzará TimeoutException, lo que frena una pauta de no lanzar excepciones en el método Dispose .