Limitaciones de JSOR (solo Linux)

El número de clientes paralelos de larga ejecución entre dos puntos finales RDMA es limitado

Este comportamiento se asocia a tarjetas Mellanox antiguas y sus controladores. El límite no provoca el modo en que el controlador de interfaz subyacente asigna y rehace los pares de colas (colas de envío y recepción enlazadas). Los pares de colas son la base para realizar solicitudes de envío o recepción entre puntos finales RDMA.

Por ejemplo, la tarjeta Mellanox MT25208 de primera generación limita el número de conexiones abiertas simultáneas a aproximadamente 300, mientras que la tarjeta Mellanox MT26428 de segunda generación limita el número a aproximadamente 30.

El algoritmo de asignación de pares de colas se ha mejorado con el firmware más reciente de Mellanox, de modo que no debería tener esta limitación con controladores posteriores. Para obtener más información, consulte el siguiente artículo de Mellanox, que detalla cómo se puede optimizar el asignador de mapa de bits: Cambiar el asignador de mapas de bits para que funcione en modo round-robin

Las aplicaciones Java habilitadas para RDMA no se cierran inmediatamente después de la ejecución

El entorno de ejecución RDMA asigna y gestiona muchos objetos de recursos como parte del establecimiento de cada conexión. Cuando se cierra una conexión, estos recursos se desasignan. El entorno de ejecución RDMA espera aproximadamente un segundo a que los procesos de la conexión simultánea puedan completarse antes de liberar los recursos. Este tiempo de espera se refleja en el cierre de una aplicación Java habilitada para RDMA.

Las conexiones RDMA tardan más tiempo que las conexiones TCP

El proceso de establecimiento de conexión es más complejo en RDMA que en TCP. El establecimiento de las conexiones RDMA implica crear y gestionar objetos de recursos específicos de RDMA y un control de sucesos bidireccional. Este incremento de tiempo es un conocido efecto secundario del uso de RDMA.

Si el servidor RDMA elige el puerto de servicio dinámicamente, el punto final correspondiente no está habilitado para RDMA

La implementación de JSOR no admite puertos efímeros. Por tanto, el punto final de servicio debe fijarse con antelación en su archivo de configuración.

Propiedades de habilitación de JSOR

Se da soporte a las características NET y NIO mediante propiedades de habilitación independientes: com.ibm.net.rdma.conf y com.ibm.nio.rdma.conf.

Un cliente RDMA se conecta utilizando TCP cuando la opción de migración tras anomalía TCP no está establecida en el servidor RDMA

El este caso poco habitual, un cliente RDMA enumerado en las reglas de un servidor habilitado para RDMA que se ejecuta sin migración tras anomalía TCP intenta conectarse utilizando TCP.

Un servidor RDMA espera un tiempo indefinido para intentar aceptar la conexión utilizando RDMA, a menos que establezca un tiempo de espera de aceptación. De forma predeterminada, cada punto final RDMA tiene dos partes, una para TCP y otra para RDMA. Cuando se establece una conexión entre un servidor RDMA y un cliente RDMA, implícitamente se abre una conexión TCP en segundo plano. La parte TCP se utiliza para esperar solicitudes de conexión entrantes.

Cuando un cliente RDMA intenta conectarse utilizando TCP a un servidor habilitado para RDMA que se ejecuta sin migración tras anomalía TCP habilitada, la parte de la conexión TCP se traslada al cliente. Sin embargo, el servidor sigue esperando el progreso de la parte RDMA de este punto final. Para evitar este comportamiento, establezca un tiempo de espera de aceptación. En lugar de esperar, el servidor RDMA cancela, generando una excepción SocketTimeoutException con el mensajeRDMA Accept timed out.

El número de clientes simultáneos para aplicaciones de canal NIO de JSOR está limitado con el selector Poll predeterminado

El número de clientes simultáneos soportados en las pruebas de cliente y servidor Java está limitado a 200. A partir de este límite, los clientes pueden experimentar excepciones de errores de conexión. Sin embargo, puede utilizar el -Dcom.ibm.nio.rdma.EPollSelectorProvider (Linux solamente) para aumentar este límite a 1000 clientes.Para obtener información sobre las limitaciones actuales de esta opción, consulte Problemas encontrados con Apache Spark en modo JSOR cuando se utiliza el selector EPoll y Problemas encontrados con aplicaciones multihilo en modo JSOR cuando se utiliza el selector EPoll.

No puede especificar selectores de sondeo RDMA utilizando la propiedad del sistema java.nio.channels.spi.SelectorProvider

La especificación de selectores de sondeo RDMA sólo se puede lograr utilizando la propiedad de habilitación de RDMA com.ibm.nio.rdma.conf=<configuration_file> en la línea de mandatos Java. No se da soporte a la especificación de selectores de sondeo de RDMA utilizando la propiedad del sistema java.nio.channels.spi.SelectorProvider. Por ejemplo, utilizando el método provider() en la clase Java java.nio.channels.spi.SelectorProvider.

Problemas de infraestructura de entrada/salida de Netty

Para aplicaciones de socket de flujo NIO, se encuentran problemas en el Netty IO framework, https://netty.io/.

Problema encontrados con Apache Spark en modalidad de JSOR cuando se utiliza el selector EPoll

Problemas encontrados con aplicaciones de varias hebras en modalidad JSOR cuando se utiliza el selector EPoll

Se observan excepciones no controladas mientras se ejecutan aplicaciones cliente/servidor Java NIO multihilo en modo Java Sockets over Remote Direct Memory Access (JSOR), cuando el -Dcom.ibm.nio.rdma.EPollSelectorProvider (Linux) se establece en true.

También se observan excepciones no controladas cuando la conexión del lado del cliente finaliza antes de que se puedan recibir todos los datos del servidor.