{"id":5432,"date":"2018-06-29T01:23:36","date_gmt":"2018-06-29T08:23:36","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=5432"},"modified":"2018-06-29T01:23:36","modified_gmt":"2018-06-29T08:23:36","slug":"inside-the-java-sdk-connection-management","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/inside-the-java-sdk-connection-management\/","title":{"rendered":"Dentro del SDK de Java: Gesti\u00f3n de conexiones"},"content":{"rendered":"

En esta segunda entrega de \"Inside the Java SDK\" vamos a ver en profundidad c\u00f3mo el SDK gestiona y agrupa los sockets a los distintos nodos y servicios. Aunque en \u00faltima instancia no es necesario seguir, te recomiendo que eches un vistazo al primer post sobre arranque\u00a0<\/a>tambi\u00e9n.<\/p>\n

Tenga en cuenta que este post fue escrito con las versiones Java SDK 2.5.9 \/ 2.6.0 en mente. Las cosas podr\u00edan cambiar con el tiempo, pero el enfoque general deber\u00eda seguir siendo el mismo.<\/p>\n

Siguiendo el esp\u00edritu de los modelos OSI y TCP, propongo un modelo de tres capas que represente la pila de conexiones del SDK:<\/p>\n

+-----------------+\r\n| Service Layer   |\r\n+-----------------+\r\n| Endpoint Layer  |\r\n+-----------------+\r\n| Channel Layer   |\r\n+-----------------+<\/pre>\n
Los niveles superiores se superponen a los inferiores, por lo que empezaremos por la capa Canal e iremos subiendo por la pila.<\/p>\n
La capa de canales<\/h2>\n
La capa de canal es el nivel m\u00e1s bajo en el que el SDK se ocupa de las redes y est\u00e1 construida sobre la excelente biblioteca IO totalmente as\u00edncrona llamada Netty<\/a>\u00a0Hemos sido usuarios extensivos de Netty durante a\u00f1os y tambi\u00e9n hemos contribuido con parches as\u00ed como con el c\u00f3dec memcache<\/a> al proyecto.<\/p>\n
Cada Netty Canal<\/a> corresponde a un socket y se multiplexa sobre bucles de eventos. Cubriremos el modelo de hilos en una entrada posterior del blog, pero por ahora es importante saber que en lugar del modelo de \"un hilo por socket\" del IO de bloqueo tradicional, Netty toma todos los sockets abiertos y los distribuye a trav\u00e9s de un pu\u00f1ado de bucles de eventos. Hace esto de una manera muy eficiente, por lo que no es de extra\u00f1ar que Netty se utiliza en todo el sector<\/a>\u00a0para componentes de red de alto rendimiento y baja latencia.<\/p>\n
Dado que un canal s\u00f3lo se ocupa de los bytes que entran y salen, necesitamos una forma de codificar y decodificar las solicitudes a nivel de aplicaci\u00f3n (como una consulta N1QL o una solicitud de obtenci\u00f3n de clave\/valor) en su representaci\u00f3n binaria adecuada. En Netty esto se hace agregando manipuladores<\/a> a la canalizaci\u00f3n<\/a>. Todas las operaciones de escritura de la red bajan por la tuber\u00eda y las respuestas del servidor vuelven a subir por la tuber\u00eda (tambi\u00e9n llamadas de entrada y salida en la terminolog\u00eda de Netty).<\/p>\n
Algunos manejadores se a\u00f1aden independientemente del servicio utilizado (como el registro o el cifrado) y otros dependen del tipo de servicio (por ejemplo, para una respuesta N1QL tenemos analizadores de flujo JSON personalizados para la estructura de la respuesta).<\/p>\n
Si alguna vez te has preguntado c\u00f3mo obtener una salida de registro a nivel de paquetes durante el desarrollo o depuraci\u00f3n (para producci\u00f3n usa tcpdump, wireshark o similar), todo lo que necesitas hacer es activar el nivel de registro TRACE en tu biblioteca de registro favorita y ver\u00e1s una salida como esta:<\/p>\n
[cb-io-1-1] 2018-06-28 14:03:34 TRACE LoggingHandler:94 - [id: 0x41407638, L:\/127.0.0.1:60923 - R:localhost\/127.0.0.1:11210] WRITE: 243B\r\n+-------------------------------------------------+\r\n| 0 1 2 3 4 5 6 7 8 9 a b c d e f |\r\n+--------+-------------------------------------------------+----------------+\r\n|00000000| 80 1f 00 db 00 00 00 00 00 00 00 e5 00 00 00 00 |................|\r\n|00000010| 00 00 00 00 00 00 00 00 7b 22 61 22 3a 22 63 6f |........{\"a\":\"co|\r\n|00000020| 75 63 68 62 61 73 65 2d 6a 61 76 61 2d 63 6c 69 |uchbase-java-cli|\r\n|00000030| 65 6e 74 2f 32 2e 36 2e 30 2d 53 4e 41 50 53 48 |ent\/2.6.0-SNAPSH|\r\n|00000040| 4f 54 20 28 67 69 74 3a 20 32 2e 36 2e 30 2d 62 |OT (git: 2.6.0-b|\r\n|00000050| 65 74 61 2d 31 36 2d 67 35 63 65 30 38 62 30 2c |eta-16-g5ce08b0,|\r\n|00000060| 20 63 6f 72 65 3a 20 31 2e 36 2e 30 2d 62 65 74 | core: 1.6.0-bet|\r\n|00000070| 61 2d 33 33 2d 67 31 62 33 65 36 66 62 29 20 28 |a-33-g1b3e6fb) (|\r\n|00000080| 4d 61 63 20 4f 53 20 58 2f 31 30 2e 31 33 2e 34 |Mac OS X\/10.13.4|\r\n|00000090| 20 78 38 36 5f 36 34 3b 20 4a 61 76 61 20 48 6f | x86_64; Java Ho|\r\n|000000a0| 74 53 70 6f 74 28 54 4d 29 20 36 34 2d 42 69 74 |tSpot(TM) 64-Bit|\r\n|000000b0| 20 53 65 72 76 65 72 20 56 4d 20 31 2e 38 2e 30 | Server VM 1.8.0|\r\n|000000c0| 5f 31 30 31 2d 62 31 33 29 22 2c 22 69 22 3a 22 |_101-b13)\",\"i\":\"|\r\n|000000d0| 30 43 34 37 35 41 43 41 35 46 33 38 30 41 32 31 |0C475ACA5F380A21|\r\n|000000e0| 2f 30 30 30 30 30 30 30 30 34 31 34 30 37 36 33 |\/000000004140763|\r\n|000000f0| 38 22 7d |8\"} |\r\n+--------+-------------------------------------------------+----------------+<\/pre>\n
Observe el peque\u00f1o LoggingHandler<\/span>\u00a0 ah\u00ed arriba? Esto se debe a que s\u00f3lo a\u00f1adimos el controlador de registro si el rastreo est\u00e1 habilitado para la tuber\u00eda, por lo que no est\u00e1 pagando la sobrecarga si no lo est\u00e1 utilizando (que es la mayor parte del tiempo):<\/p>\n
bootstrap = new BootstrapAdapter(new Bootstrap()\r\n  \/\/ *snip*\r\n  .option(ChannelOption.ALLOCATOR, allocator)\r\n  .option(ChannelOption.TCP_NODELAY, tcpNodelay)\r\n  .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, env.socketConnectTimeout())\r\n  .handler(new ChannelInitializer<Channel>() {\r\n    @Override\r\n    protected void initChannel(Channel channel) throws Exception {\r\n      ChannelPipeline pipeline = channel.pipeline();\r\n      if (env.sslEnabled()) {\r\n        pipeline.addLast(new SslHandler(sslEngineFactory.get()));\r\n      }\r\n      if (LOGGER.isTraceEnabled()) {\r\n        pipeline.addLast(LOGGING_HANDLER_INSTANCE);\r\n      }\r\n    customEndpointHandlers(pipeline);\r\n  }\r\n}));<\/pre>\n
Tambi\u00e9n puedes ver que dependiendo de la configuraci\u00f3n del entorno hacemos otros ajustes como a\u00f1adir un handler SSL\/TLS al pipeline o configurar el nodelay TCP y los timeouts de los sockets.<\/p>\n
En customEndpointHandlers<\/span>\u00a0 se sobrescribe para cada servicio, aqu\u00ed est\u00e1 la tuber\u00eda para la capa KV (ligeramente simplificada):<\/p>\n
if (environment().keepAliveInterval() > 0) {\r\n    pipeline.addLast(new IdleStateHandler(environment().keepAliveInterval(), 0, 0, TimeUnit.MILLISECONDS));\r\n}\r\n\r\npipeline\r\n    .addLast(new BinaryMemcacheClientCodec())\r\n    .addLast(new BinaryMemcacheObjectAggregator(Integer.MAX_VALUE));\r\n\r\npipeline\r\n    .addLast(new KeyValueFeatureHandler(context()))\r\n    .addLast(new KeyValueErrorMapHandler());\r\n\r\nif (!environment().certAuthEnabled()) {\r\n    pipeline.addLast(new KeyValueAuthHandler(username(), password(), environment().forceSaslPlain()));\r\n}\r\n\r\npipeline\r\n    .addLast(new KeyValueSelectBucketHandler(bucket()))\r\n    .addLast(new KeyValueHandler(this, responseBuffer(), false, true));<\/pre>\n
Aqu\u00ed pasan muchas cosas. Vayamos por partes:<\/p>\n