En nombre de todo el equipo me complace informar que finalmente hemos lanzado la versión 2.1.0 del SDK Java de Couchbase. En comparación con la rama 2.0 trae un montón de nuevas características, así como una miríada de pequeñas mejoras y correcciones de errores. Es el resultado de la increíble y valiosa retroalimentación que recibimos de más y más usuarios que están actualizando sus aplicaciones, así como de nuevos usuarios que exploran patrones de acceso a datos reactivos.
En esta entrada del blog nos centraremos en las nuevas funciones. Si desea consultar la lista completa de cambios, consulte la página Notas de publicación. Si tiene preguntas puede hacerlas en el Foros y si crees que has dado con un problema, por favor preséntalo en nuestro JIRA.
Por cierto, también hemos introducido algunos cambios que deberían mejorar el rendimiento en determinadas cargas de trabajo. Aunque no hay puntos de referencia en esta entrada del blog, es muy probable que veas una mejora de la latencia y el rendimiento en comparación con la versión 2.0.3.
Obtención del SDK
Como siempre, distribuimos la versión GA de Maven Central y como archivo.
Soporte N1QL DP4
Esta versión trae soporte oficial (aún experimental) para N1QL DP4. No es compatible con DP3 porque las respuestas de streaming subyacentes han cambiado bastante. Lo más destacado incluye:
- Declaraciones simples, parametrizadas y preparadas.
- Opciones de consulta ampliadas, como los tiempos de espera y la coherencia del escaneado.
- QueryResults síncronos y asíncronos mejorados para una gestión de errores más flexible.
Simon escribió hace dos semanas un estupendo artículo en su blog, así que si quieres saber más deberías Compruébelo aquí.
Consulta de vistas espaciales
Además del soporte para consultas View normales, hemos añadido soporte para consultas View espaciales. Ten en cuenta que el soporte de consultas espaciales es todavía experimental en Couchbase Server 3.0.2, pero pronto será soportado oficialmente. Además, la implementación en 2.1.0 no es compatible con versiones anteriores de Couchbase Server porque el formato de respuesta ha cambiado ligeramente.
Como ejemplo rápido, imagine que almacena información de una tienda:
A partir de este formato de datos puede definir una vista espacial que no sólo indexará la latitud y longitud, sino también sus horarios de apertura:
A continuación, puede consultarlo en las tres dimensiones, proporcionando un cuadro delimitador para la ubicación y también un intervalo de tiempo en el que la tienda debería estar abierta:
En un futuro próximo, a medida que nos acerquemos a una versión totalmente compatible con el servidor, podrás ver más entradas en el blog y ejemplos.
Heartbeats/Keepalive del zócalo inactivo
Cuando no hay carga a través del cliente hacia un socket específico, existe la posibilidad de que un cortafuegos (u otra cosa) esté cortando la conexión porque piensa que está obsoleta. Para evitar esto, el SDK ahora envía un mensaje heartbeat cada 30 segundos a través de sockets inactivos. Por supuesto, estos mensajes no se envían si el tráfico regular está fluyendo en este intervalo.
Puedes cambiar el intervalo en el entorno y si quieres desactivarlo sólo tienes que ponerlo a 0.
Estrategias de reintento conectables
Una característica muy solicitada era proporcionar formas de fallar rápidamente si la solicitud no puede ser despachada inmediatamente. Por ejemplo, el tiempo entre que un nodo falla y es fallado en el cluster, un subconjunto de documentos no puede ser escrito (todos los que tienen como objetivo las particiones específicas en este nodo). Por defecto, el SDK reintentará la operación un poco más tarde y eventualmente se agotará el tiempo de espera en el lado del llamante.
En su lugar, el nuevo modo fail fast cancelaría inmediatamente la petición, proporcionando bucles de respuesta más rápidos a la persona que llama, que entonces puede determinar si la petición debe volver a intentarse o no. Esta nueva estrategia se puede activar en el entorno de la siguiente manera:
Además, hemos hecho la estrategia de reintento pluggable para que puedas incluso definir la tuya propia. Como esto es bastante avanzado, no está cubierto en esta entrada del blog, pero puedes esperar más información pronto en la documentación sobre ese tema. Mientras tanto, si tienes curiosidad, echa un vistazo a las estrategias (bastante simples) que vienen con el SDK.
Por último, se ha añadido al entorno un "tiempo de vida máximo de la solicitud" configurable, que es utilizado por la estrategia predeterminada de "mejor esfuerzo" para determinar si la solicitud debe reintentarse o, por el contrario, se cancela. Esto es necesario para evitar que las solicitudes den vueltas durante mucho tiempo y ocupen valiosos espacios en los RingBuffers.
Bus de eventos suscribible
Se ha añadido al entorno un bus de eventos genérico que es utilizado por el núcleo y el cliente para publicar eventos a potenciales suscriptores de la aplicación. Actualmente, sólo se publican eventos de apertura/cierre de cubos y de conexión/desconexión de nodos, pero en el futuro planeamos ampliarlo en gran medida recogiendo y publicando también métricas de rendimiento y otros tipos de eventos y avisos.
Es muy fácil suscribirse y reaccionar a ese tipo de eventos, gracias a RxJava y a la naturaleza de streaming de nuestros Observables:
DNS SRV Bootstrap
Ahora es posible obtener la lista de nodos de arranque a través de un registro DNS SRV. Esto permite a los administradores del sistema centralizar la configuración de su lista de nodos de arranque de una manera muy sencilla. Es necesario habilitarlo en el entorno para que funcione. Puede encontrar más información en aquí.
¿Y ahora qué?
Aunque ya tenemos muchas ideas para la versión 2.2, ahora estamos dando un paso atrás y estamos planeando estabilizar aún más esta rama con versiones de corrección de errores según sea necesario. Además, nos estamos centrando en mejorar la integración con el framework y con la "pila superior", así que permanece atento en las próximas semanas a las publicaciones del blog y a los anuncios.
