Gestión de los Big Files en inside. Probar limitación de 6 MB de INSIDE. Analizar y discutir comportamiento con CSV Storage

El 21/06/19 hemos tenido una reunión esta mañana para hablar de los BigFiles y me ha surgido la duda del límte que tiene Inside para ficheros grandes.

He encontrado ésto en el documento de FAQs de INSIDE "FAQ - Preguntas Frecuentes.pdf": ¿Qué tamaño deben tener los archivos que forman los documentos? Los archivos que queramos firmar no pueden pesar más de 6Mb. De lo contrario, Inside dará un error de firma.

Revisamos esta limitación. Pensamos que este límite se refiere a ficheros que queremos firmar - INSIDE permite firmar ficheros y subirlos desde el interfaz Web, no lo sabía. De cualquier manera esa funcionalidad no la utilizamos. Hago una prueba de subir fichero firmándolo con el interfaz Web - Prueba 7 MB - Como Extensión pdf -> PADES/PDF - y lo firmo en cliente - Abre el Autofirma y me da este error de Error en el proceso de firma: No se pudo realizar la firma, inténtelo más tarde o contacte con el administrador y una pantalla de error que parece que es del Autofirma con este texto Ha ocurrido un error realizando la operación. Tiene pinta de que es por la limitación de 6Mb.

Hago otra prueba con el SOAPUI con altaDocumentoOtros de un pdf de 9 MB y me ha funcionado, ha devuelto esta referencia ENI de documento: ES_A14013937_2019_DOCH179897619M1561123798800RNU y ha tardado 22''. La petición está en el proy. Sandra-pru-v1 y el nombre de la petición es "pet08 PRU Big Files Test"

Ahora quiero probarlo firmándolo antes (el de 9 MB), con mi certificado de la FNMT, con altaDocumentoOriginal. La petición está en el mismo proy. es "pet08 PRU Big Files Test" En 47'' devuelve un error el Proxy debido a que efectivamente, el timeout que hay en PRU del PROXY de INSIDE es de 45'':

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p>
<p>Please contact the server administrator at  [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.</p>
<p>More information about this error may be available in the server error log.</p>
</body></html>

Ahora quiero probar un docx firmado, con mi certificado de la FNMT, con altaDocumentoOriginal. En este caso el documento ocupa 7,5 MB. La petición está en el mismo proy. es "Pet12 PRU Big Files Test Docx Cades" En 32'' HA FUNCIONADO PERFECTAMENTE. La referencia ENI que me ha dado en PRU es ES_A14022328_2019_DOCH179897619M1561125243803RVO ASÍ QUE LA CONCLUSIÓN ES QUE SÍ QUE FUNCIONAN, EL LÍMITE ESTARÍA EN EL TIMEOUT QUE TENGA EL PROXY O EL SOCKET SANDRA-INSIDE O EL DE INSIDE-ALFRESCO.

Copio los documentos que he usado para hacer las pruebas en mi local en C:\alp\SANDRA\2019 06 21 #19 Big Files Probar limitación de 6 MB de INSIDE-Sí funcionan documentos más grandes Aunque están como peticiones SOAPUI en los proyectos correspondientes

Del email que he documentado en un comentario, una conclusión es que CSV Storage/CSV Broker limita a 8 MB el tamaño máximo de fichero original (sin firmar).

La conclusión de todo ésto es que si no limitamos de algún modo la subida de Big Files comprobando antes el tamaño, que podría estar en una propiedad de SANDRA, nos exponemos a que se estén guardando Big Files que el sistema no es capaz de realizar correctamente, porque hay un timeout de los proxies de INSIDE actualmente de 45'' que puede producir sobrecarga ya que aunque se realice la desconexión del socket INSIDE y ALFRESCO realizarían igualmente el almacenamiento del Big File, que quedaría 'Zombie'

Hago una prueba de subir fichero firmándolo con el interfaz Web ES_A14002961_2019_163 Nombre natural: Prueba 9 MB ManualRentaPatrimonio2018_V7_es_es.pdf A14022314 Como Extensión pdf -> PADES/PDF Y lo firmo en cliente. Abre el Autofirma y me da este error de Ha ocurrido un error realizando la operación.

Error SAF Al firmar documento y Subirlo desde Frontal Web Inside

El 16/07/19 recibo email tamaño máximo documento. Me ha enviado este email con asunto tamaño máximo documento Este es documento que describe el uso del CSVstorage / CSVbroker para ficheros grandes. Gestión de Documentos de Gran Tamaño CSV Storage

Acerca de la gestión de los Big Files nos gustaría analizar / discutir con la empresa que está realizando la migración de los documentos cómo se comporta CSV Storage con los ficheros grandes. Hay un servicio WS en CSV Storage pero hay muy poca documentación. Está muy relacionado con inside ya que hemos detectado dependencias de inside-services con el módulo artifact es.gob.aapp.eeutil:bigDataTransfer ¿Es capaz inside de gestionar big files entendiéndose con CSV Storage a través de ese WS? Hemos podido comprobar que hay unas propiedades de configuración acerca de Big Files en la 2.0.8 (mirar manual de instalación INSIDE) para CSV Storage, supongo que es para poder gestionar con otra instancia distinta los Big Files de INSIDE y así que no interfieran en el funcionamiento del sistema principal.

Desde el día 28/10/19 tenemos migrado el repositorio de documentos de INSIDE. Estaba en Alfresco EE - unos 6M de documentos - y ahora está en CSV Storage dentro de un NFS. Hemos podido comprobar con una sencilla consulta de la BD de CSVST que el documento más pesado es de 80 MB. SELECT TO_CHAR(created_at, 'dd/mm/yyyy') dia, COUNT(0) docs, MAX(tamanio_fichero) max FROM csvst_documento GROUP BY ROLLUP(TO_CHAR(created_at, 'dd/mm/yyyy')) ORDER BY TO_DATE(TO_CHAR(created_at, 'dd/mm/yyyy'), 'dd/mm/yyyy') ASC; Parece ser que el único control de peso que se realiza es el de PRESENTADOR y sólo para sus anexos. He podido comprobar que por ejemplo el día 08/11/19 entraron unos 130 documentos de más de 40 MB. SELECT * FROM csvst_documento WHERE TO_CHAR(created_at, 'dd/mm/yyyy') = '08/11/2019' ORDER BY tamanio_fichero DESC; Uno de estos documentos pesados era de las ayudas de Agricultura o SGA, que parece que suelen cargarse sobre las 15:00 h. (parece que ocurre todos los días). Uno de los errores SANDRA, así como los detalles que aparecen en Elastic, de uno de esos Big Files son (del día 07/11/19):

"aplicacion" : "EVA", "servicio" : "altaDocumentoOtros", "procedimiento" : 3115, "documento" : "DA703", "duracion" : 56927, (57 segundos) "error" : "S-500", "traza" : null, "@timestamp" : 1573136738693, Thu Nov 07 2019 15:25:38 "departamento" : 1467, "idtransaccion" : "null", "referenciaorigen" : "ofuscado", "texto_mensaje" : "Error interno de Sandra. -- javax.xml.ws.WebServiceException: Could not receive Message. / SocketTimeoutException invoking https://inside.carm.es/inside/ws/InsideUserTokenService: Read timed out / Read timed out --"

Busco uno cualquiera de después de desplegar el día 07/11/19, a las 15 h. (Hubo un par de errores y pensamos que ocurrieron por lo de los big files). Este es uno que funcionó (datos de la tabla csvst_documento):

6569785 221856 application/xml/opt/tomcat-csvstorage/datos/docs/INSIDE/2019/11/07/154/A14002961 07/11/19 15:40:19 ES_A14028316_2019_DOCH179897352M1573137582851RNI ad6f523a-4fa1-4929-91b9-5a280be17ffb 1 45184 1 1

La descarga desde el WS de CSVST por MTOM tarda sólo 6’’. Realmente era de 34 MB porque estaba en Base64. Se trata de Resoluciones de ayuda, es un documento de 900 páginas. Lo que me parece chocante es que no tiene ningún CSV en el margen izquierdo, así que no debe de haber funcionado. Pregunto y parece ser que es un bug de la eA, que debería estar limitado a 14 MB en Base64. Todo ésto me lo guardo en local en C:\alp\SANDRA\9 Big Files en SANDRA

Parece que es necesario limitar el tamaño de los documentos que se almacenan en SANDRA. Planteamos 14 MB como una buena opción, ya que las peticiones SOAP manejan estos documentos en base64, de manera que el máximo tamaño de documento sería 10 MB. Por otra parte está el asunto de decidir de qué manera limitarlo. Se puede hacer a nivel de PROXY, a nivel de servidor TOMCAT o a alto nivel, a nivel de aplicación SANDRA, INSIDE o CSV Storage.

Vuelvo a hacer otra petición pero esta vez con CSV Storage. Está en el proy. SOAPUI Sandra-pru-v1 y el nombre de la petición es "Pet17 PRU Big Files Test Pdf Firmado Pades 9MB" que es suficientemente descriptivo. La operación es altaDocumentoOriginal. Da error en 46,836'' (se supone que en el entorno de pruebas el tiempo máximo para recibir la respuesta es 45'') y el error parece que viene del proxy:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 [no address given] to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>

Pero realmente en el índice de Elastic sale un error con duración 48,018'' (llega a indexar el error) y lo devuelve SANDRA ya que la petición a INSIDE no ha devuelto la respuesta en ese tiempo:

       "_index" : "servicios",
        "_type" : "evento",
        "_id" : "servapp-pru-sa5.carm.es-45-1573564457661",
        "_score" : null,
        "_source" : {
          "aplicacion" : "PRESENTADOR",
          "servicio" : "**altaDocumentoOriginal**",
          "procedimiento" : 3718,
          "documento" : "AN54",
          "duracion" : 48018,
          "error" : "S-500",
          "traza" : null,
          "@timestamp" : 1573564457661,
          "departamento" : 480,
          "idtransaccion" : "null",
          "referenciaorigen" : "ALP-2019/11/12-1413",
          "texto_mensaje" : "Error interno de Sandra. -- javax.xml.ws.WebServiceException: Could not receive Message. / SocketTimeoutException invoking https://inside-pru.carm.es/inside/ws/InsideUserTokenService: Read timed out / Read timed out --"

La conclusión es que por una parte en el SOAPUI llega el error 500 HTML del PROXY que es a los 45'' y por otra parte en el Elastic sí que se indexa el error de SANDRA que es de otro timeout de respuesta a los 45''. Deberíamos modificar este timeout a 40'' para distinguirlo del de los PROXYs pero no es importante, ya que en producción los PROXYs tienen 60'' de límite.

¿No quedamos que las pruebas serían en local?

Sí, quedamos en hacer la prueba en local. Sin embargo finalmente he preferido realizar la prueba de Big File contra el entorno de pruebas directamente para comprobar que salta el timeout del CXF. Para ello hemos modificado el timeout que existe entre SANDRA e INSIDE a través del cliente Apache CXF, que estaba en 45'' y es el mismo que tienen los PROXYs en el entorno de pruebas. Eso está mal porque el error que llega a los clientes SANDRA es el del HTML, no refleja la realidad. Modificamos el timeout SANDRA-INSIDE a 40'' y desplegamos SANDRA (con algunos problemas por las dependencias del Back-End ENI). Lanzo la misma prueba y el resultado ha sido el esperado, efectivamente se eleva al SOAPUI el error que debe reportarse: WebServiceException: Could not receive Message. / SocketTimeoutException.

carm-es / inside

Gestión de los Big Files en inside. Probar limitación de 6 MB de INSIDE. Analizar y discutir comportamiento con CSV Storage #19