A través de este blog publicamos la primera versión preliminar para desarrolladores del SDK Java 1.4.0. Aparte de las habituales correcciones de errores y mejoras, esta nueva versión menor proporciona soporte para la gestión optimizada de conexiones que se introdujo recientemente en Couchbase Server 2.5.0. Más información sobre las novedades a continuación.
Puede descargar la vista previa en Maven Central o un archivo zip con todos los JARs incluido.
Actualización: La vista previa para desarrolladores se ha actualizado a 1.4.0dp2 a partir del 4 de abril de 2014.
Gestión optimizada de las conexiones
Servidor Couchbase 2.5.0 introdujo una nueva forma de obtener una configuración de clúster hace un par de semanas. Además de la forma anterior de cargarla a través del puerto 8091 (http), ahora es posible que el SDK la cargue directamente a través del protocolo binario subyacente (puerto 11210). Anteriormente, para realizar un seguimiento de los cambios en curso en el clúster, el cliente tenía que establecer una conexión de streaming con el puerto de configuración (que enviaba nuevos fragmentos de configuración al cliente). Ahora, el cliente recibe nuevas configuraciones junto con respuestas de operaciones de datos a través del puerto binario. Esto hace que el arranque sea mucho más rápido y eficiente, facilitando la gestión de grandes despliegues.
Cuando se utiliza el SDK de Java, no hay nada que deba cambiarse en cuanto a la API, pero dado que el proceso de arranque cambia ligeramente, es bueno entender lo que realmente está pasando. Para una introducción general a este tema, recomiendo Entrada del blog de Mark Nunberg sobre los cambios similares en libcouchbase, que cubre muchas de las partes circundantes.
El Java SDK toma la lista de nodos bootstrap pasados, pero ignora todo lo de la URI aparte del nombre de host por ahora. Intenta contactar con el servidor de destino en el puerto 11210. Si el servidor responde con una configuración válida (lo que ocurre si es un nodo 2.5.0 o posterior y un bucket couchbase), esta configuración se almacena inmediatamente y se utiliza. No se adjunta ninguna conexión de streaming, pero esta conexión binaria se reutiliza para obtener actualizaciones de configuración bajo demanda según sea necesario. Si el servidor no responde con una configuración válida, se intenta con todos los demás nodos de la lista bootstrap con el mismo comportamiento. Si ninguno de ellos devuelve una configuración válida (por ejemplo, si se utiliza un bucket memcache o todos los nodos del clúster son de la versión 2.2 o anteriores), el cliente vuelve al (antiguo) bootstrap de tipo HTTP y a la conexión de streaming. Aunque este proceso cambia el comportamiento y no parece coincidir con lo que los argumentos implican que está ocurriendo, creemos que es lo correcto por motivos de compatibilidad con las aplicaciones existentes (aunque estamos abiertos a comentarios).
El mismo proceso se establece cuando la conexión de configuración se pierde u otras partes del SDK indican que la conexión de configuración está obsoleta (por ejemplo, una gran cantidad de operaciones fallidas).
Se ha añadido el registro a nivel INFO para que sea visible desde los registros qué enfoque de arranque se ha utilizado. Si las nuevas facilidades de gestión de conexiones funcionaron, se muestra este mensaje de registro:
De lo contrario, se puede encontrar esta salida de registro:
Dado que este cambio es un poco más grande dentro del SDK, por favor, patear los neumáticos en la vista previa de desarrollador (que es principalmente por qué optamos en hacer una vista previa en lugar de ir directamente a una versión final) y nos dan retroalimentación sobre diversos escenarios en su entorno. Nuestro equipo de pruebas también lo está probando.
Número total de registros en ViewResponse
Cada vista no reducida expone el número total de filas de la vista y esto se refleja ahora también en el SDK de Java. Esto es especialmente útil en escenarios de paginación y pruebas unitarias. He aquí un ejemplo (del conjunto de datos de la muestra de cerveza):
Vista vista = c.getView("cerveza", "cerveceria_cervezas");
Consulta consulta = nueva consulta();
query.setLimit(10);
ViewResponse response = c.query(view, query);
System.out.println("En este lote: " + response.size());
System.out.println("Total en esta vista: " + response.getTotalRows());
Esto imprime:
Total en esta vista: 7303
Se trata de una antigua petición de los usuarios que ahora se incluye en esta versión.
Capacidades de lectura de réplicas mejoradas
Otra petición de los usuarios -desde que añadimos las capacidades de lectura de réplicas- era que también hubiera una forma de recuperar el valor CAS del nodo réplica. Esto se parece básicamente al conocido comando "gets", pero esta vez para réplicas. Hemos añadido la capacidad a través de los comandos asyncGetsFromReplica y getsFromReplica. He aquí un ejemplo de cómo utilizar los nuevos métodos:
CASValor
Tenga en cuenta que la semántica es la misma que con "getFromReplica", por lo que el valor devuelto con CAS podría ser del nodo maestro o de uno de los nodos réplica, dependiendo de quién respondió primero. Este valor CAS puede utilizarse para comandos de escritura posteriores que necesiten incluir el valor CAS para el bloqueo optimista.
Códigos de estado seguros en OperationStatus
En el pasado, siempre ha sido un poco complicado tratar con cadenas de respuesta de estado de operaciones futuras. No había una buena manera de tratar con ellos aparte de la comprobación de cadenas. Esta versión menor trae StatusCodes a los objetos OperationStatus, lo que le permite simplemente comprobar contra un ENUM:
Ahora podemos utilizar el mismo método para comprobar si una respuesta de adición ha fallado porque la clave ya se ha establecido:
El StatusCode proporciona todos los posibles códigos de estado que pueden ser devueltos, y antes de la versión final también proporcionaremos la documentación adecuada cuando puedan ocurrir (para que sepa qué buscar al comprobar los códigos).
Próximos pasos
Hemos decidido realizar una vista previa para desarrolladores de esta versión menor porque queremos asegurarnos de que las nuevas funciones optimizadas de gestión de conexiones se prueban antes de la versión final. Por favor, compruébalo e infórmanos de cualquier problema que encuentres. en nuestro gestor de incidencias. Tan pronto como nuestro equipo de pruebas nos haya dado luz verde y si no hay preocupaciones por parte de los usuarios de DP, ¡lo lanzaremos como GA!
Hola Nitschinger,
Estamos recibiendo las siguientes excepciones al azar con couchbase 2.x y java cliente sdk 1.4.x
1. Cierre del cubo "Sample" en "ns_1@10.10.10.163" para el servidor shutdownns_memcached002ns_1@10.10.10.16322:33:48 - mar 11 ago 2015
2.com.couchbase.client.vbucket.ConfigurationException: Could not fetch a valid Bucket configuration.2015-08-06 00:37:37 STDIO [ERROR] at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.bootstrap(BucketConfigurationProvider.ja...:123)
2015-08-06 00:37:37 STDIO [ERROR]
¿Alguna idea de cómo podemos volver a producirlo y solucionarlo?
Hola Ravi,
Lo mejor es trasladar esta discusión a los foros, https://forums.couchbase.comdonde podremos seguir mejor la discusión y pedir más detalles (asegúrate de publicar en la categoría Java SDK, y da todo el contexto que puedas).
Gracias.