El process de pago de SVN falla con "el delimitador de fragment no es válido"

ERRORES:

Cuando revisamos un proyecto grande, recibimos un error en un file aleatorio en el proyecto:

  • No se pudo leer el cuerpo de la respuesta: error de SSL: error de desencryption o mac de logging incorrecto

La respuesta fue deshabilitar SSL y reiniciar SVNServer.

Volvió a probar y obtuve este error:

  • el delimitador de fragment no es válido

Así que examinó el logging SVNserver:

  • Error al escribir datos base64: APR no entiende este código de error [500, # 620018]

  • El proveedor encontró un error al transmitir una respuesta de INFORMAR. [500, # 0]

  • Ocurrió una falla al manejar el editor de informes de actualización [500, # 620018]

Podemos recrear el anterior 100% del time.


INTENTÓ:

Desde aquí probamos:

Actualizado OpenSSL a la última versión. Resultaron en los mismos errores anteriores.

Copió el REPO en un REPO nuevo para garantizar que no se dañe el file. Resultaron en los mismos errores anteriores.

Instalado SVNserver localmente y probado tomando la networking de nuestra ecuación. Resultó en el mismo error anterior.

Creemos que esto puede estar aislado de la versión de OpenSSL que estamos utilizando con algún otro componente instalado con VisualSVN.

¿Alguien conoce este problema y cómo resolverlo?


COMPONENTES / CONFIGURACIÓN:

  • Windows 2008 Server R2
  • Apache Subversion 1.7.6
  • Servidor Apache HTTP 2.2.22
  • OpenSSL 0.9.8x
  • Neón 0.29.6
  • Serf 1.0.0
  • SQLite 3070603
  • ZLib 1.2.3
  • VisualSVN 2.5.6
  • SSL habilitado
  • Nodos de cliente Pro de Windows 7 x64

¿Tienes Nod32 instalado? Si es así, deshabilitar el filtrado de protocolos puede ayudar. La mejor solución es agregar una exception para SVN.

Nod32 -> Configuración avanzada -> Web y correo electrónico -> Filtrado de protocolos -> Aplicaciones excluidas -> revisa tu cliente, el mío es TortoiseProc.exe

El error real es Too many open files [500, #24] . Supongo que estás usando el server Subversion basado en * nix. En este caso, aumente el número de descriptor de file abierto con el ulimit :

ulimit -n 99999

Ver también: https://serverfault.com/questions/48717/practical-maximum-open-file-descriptors-ulimit-n-for-a-high-volume-system