Esta versión es otra corrección de errores/estabilidad que se concentra en mejorar el algoritmo de reintento para las vistas y añadir un registro más refinado al cliente, junto con otras correcciones varias.

Mejorar la consistencia de las operaciones View es importante dado que Couchbase es una base de datos distribuida y los nodos pueden salir o entrar del cluster en cualquier momento. Esto se vuelve problemático para los clientes de Couchbase cuando, por ejemplo, un nodo específico abandona el cluster mientras una operación dirigida a ese nodo está en pleno vuelo. La pregunta es, ¿qué hacer después? Podríamos _simplemente_ fallar y permitir que la aplicación anfitriona maneje el error y quizás reintente la operación por sus propios medios, pero no creemos que ese sea el enfoque correcto o el tipo de experiencia que un desarrollador de aplicaciones usando el cliente apreciaría.

Con la versión 1.3.4, cuando falla una operación de visualización, el cliente utiliza el código de estado HTTP y algunos criterios heurísticos para determinar si debe reintentar la operación o si debe enviar el mensaje de error a la aplicación con el valor de éxito establecido en false. Si es necesario reintentar, el cliente utiliza una estrategia de retardo exponencial en la que, por cada reintento, se duplica la duración entre reintentos hasta que se alcanza el límite máximo o la operación tiene éxito. El primer intento no se cuenta, pero el cliente hace una pausa para cada reintento posterior: 1ms, 2ms, 4ms, etc. Esto garantiza que el cliente dé tiempo al clúster para resolver cualquier problema de estabilidad antes de fallar la operación sin provocar un ataque de denegación de servicio al clúster.

El algoritmo es ajustable a través de la propiedad ViewRetryCount dentro de la configuración y por defecto es 2. Tenga en cuenta que con este ajuste de 2, el cliente intentará la operación cuatro veces antes de rendirse: el primer intento no se cuenta, luego el cliente lo intentará a 1ms, luego a 2ms, y finalmente a 4ms. Puedes elegir un ajuste entre 0 y 10; 0 desactivará los reintentos y 10 hará su último reintento a 1024ms (en realidad es la suma de tiempo entre el primer intento y el último, por lo que el tiempo total es mucho mayor). Tenga en cuenta que este algoritmo puede cambiar en versiones posteriores.

Las notas de la versión oficial se encuentran en aquí.

Autor

Publicado por Jeff Morris, Ingeniero Superior de Software, Couchbase

Jeff Morris es Ingeniero de Software Senior en Couchbase. Antes de unirse a Couchbase, Jeff pasó seis años en Source Interlink como Arquitecto Web Empresarial. Jeff es responsable del desarrollo de los SDK de Couchbase y de cómo integrarse con N1QL (lenguaje de consulta).

3 Comentarios

  1. Hola Jeff,

    Recientemente nos hemos enfrentado a algunos problemas de conectividad con Couchbase desde nuestro código .net. Mientras depurábamos el problema descubrimos que el número de conexiones TCP que se estaban creando con el servidor Couchbase era muy alto (casi 10k por servidor). Un poco más de investigación en el tema nos señaló que la presión de conexión tiene que ver con nuestro consumo actual del cliente Couchbase. Leyendo el código y escribiendo algunas pruebas unitarias encontramos que el pool de conexiones está asociado al objeto CouchBaseClient. Nuestro código estaba creando un nuevo objeto cliente para cada petición y confiando en el destructor para deshacerse del objeto. Como resultado, había una inmensa presión de conexión en el servidor, lo que provocaba tiempos de espera y otros problemas de conectividad.

    Basándonos en las observaciones anteriores, hemos cambiado nuestro código para consumir el objeto cliente como singleton y hemos reducido el tamaño mínimo del grupo de conexiones de 10 a 3. Estos cambios parecen haber resuelto el problema. No se han registrado problemas de conectividad en los últimos 3 días de pruebas de estrés.

    Me gustaría saber si este es el patrón de consumo previsto. Puedo compartir más detalles si es necesario.

    Le agradezco mucho sus comentarios al respecto.

    Gracias

    -VM

    1. Hola VM -

      Sí, tienes razón, el cliente debe ser un objeto de larga duración; lo creas cuando el proceso o appdomain se inicia y lo destruyes antes de que el proceso se destruya. Un singleton o una instancia estática pública es perfecto; el cliente es seguro para los hilos.

      Puede leer más aquí: http://docs.couchbase.com/couc

      Por lo que veo, estás haciendo las cosas "correctamente".

      -Jeff

  2. ¡[...] Lanzamiento de Couchbase .NET Client 1.3.4! Lea el blog y vea las notas de la versión [...]

Dejar una respuesta