Todos los productos
Search

Este producto

    E-MapReduce:Problemas conocidos en JindoData 4.x

    Centro de documentos

    E-MapReduce:Problemas conocidos en JindoData 4.x

    Última actualización: Sep 17, 2026

    JindoData 4.x presenta problemas conocidos que pueden afectar la estabilidad, el rendimiento o la integridad de los datos. Revise los problemas correspondientes a su versión y aplique las correcciones recomendadas.

    Versión 4.6.x

    Versión 4.6.2

    JindoSDK 4.6.0 y las versiones posteriores admiten la verificación de sumas de comprobación CRC64 para las rutas de escritura. De forma predeterminada, el parámetro fs.oss.checksum.crc64.enable está habilitado.

    Esta configuración reduce significativamente el rendimiento de escritura de OSS-HDFS. Si el rendimiento es una prioridad, deshabilítela. En la pestaña Configure del servicio Hadoop-Common dentro de EMR Configure, agregue un elemento de configuración en core-site.xml para establecer el parámetro fs.oss.checksum.crc64.enable en false. Para obtener más información sobre cómo agregar un elemento de configuración, consulte Manage configuration items.

    Versión 4.6.1

    • En JindoSDK 4.6.1, cuando se utiliza el acceso sin contraseña a OSS-HDFS en un clúster de EMR, algunos trabajos se interrumpen mientras esperan la actualización de un token.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.6.1, usar la herramienta JindoUtil con acceso sin contraseña en un clúster de EMR provoca un error de permiso.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • JindoSDK 4.6.0 y las versiones posteriores admiten la verificación de sumas de comprobación CRC64 para las rutas de escritura. De forma predeterminada, el parámetro fs.oss.checksum.crc64.enable está habilitado.

      Esta configuración reduce significativamente el rendimiento de escritura de OSS-HDFS. Si el rendimiento es una prioridad, deshabilítela. En la pestaña Configure del servicio Hadoop-Common dentro de EMR Configure, agregue un elemento de configuración en core-site.xml para establecer el parámetro fs.oss.checksum.crc64.enable en false. Para obtener más información sobre cómo agregar un elemento de configuración, consulte Manage configuration items.

    Versión 4.6.0

    • En JindoSDK 4.6.0, cuando se utiliza el acceso sin contraseña a OSS-HDFS en un clúster de EMR, algunos trabajos se quedan colgados mientras esperan la actualización de un token.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.6.0 y JindoFSx 4.6.0, establecer fs.oss.credentials.provider=com.aliyun.jindodata.oss.auth.RangerCredentialsProvider en un clúster de Kerberos provoca una fuga de memoria en el JindoFSx Namespace Service.

      Actualice tanto JindoFSx como JindoSDK a la versión 4.6.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster y Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.6.0, usar la herramienta JindoUtil con acceso sin contraseña en un clúster de EMR provoca un error de permiso.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • JindoSDK 4.6.0 y las versiones posteriores admiten la verificación de sumas de comprobación CRC64 para las rutas de escritura. De forma predeterminada, el parámetro fs.oss.checksum.crc64.enable está habilitado.

      Esta configuración reduce significativamente el rendimiento de escritura de OSS-HDFS. Si el rendimiento es una prioridad, deshabilítela. En la pestaña Configure del servicio Hadoop-Common dentro de EMR Configure, agregue un elemento de configuración en core-site.xml para establecer el parámetro fs.oss.checksum.crc64.enable en false. Para obtener más información sobre cómo agregar un elemento de configuración, consulte Manage configuration items.

    Versión 4.5.x

    Versión 4.5.2

    • En JindoSDK 4.5.2 y JindoFSx 4.5.2, establecer fs.oss.credentials.provider=com.aliyun.jindodata.oss.auth.RangerCredentialsProvider en un clúster de Kerberos provoca una fuga de memoria en el JindoFSx Namespace Service.

      Actualice tanto JindoFSx como JindoSDK a la versión 4.6.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster y Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.5.2, usar la herramienta JindoUtil con acceso sin contraseña en un clúster de EMR provoca un error de permiso.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    Versión 4.5.1

    • En JindoSDK 4.5.1 y JindoFSx 4.5.1, establecer fs.oss.credentials.provider=com.aliyun.jindodata.oss.auth.RangerCredentialsProvider en un clúster de Kerberos provoca una fuga de memoria en el JindoFSx Namespace Service.

      Actualice tanto JindoFSx como JindoSDK a la versión 4.6.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster y Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.5.1, usar la herramienta JindoUtil con acceso sin contraseña en un clúster de EMR provoca un error de permiso.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    Versión 4.5.0

    • En JindoSDK 4.5.0 y JindoFSx 4.5.0, establecer fs.oss.credentials.provider=com.aliyun.jindodata.oss.auth.RangerCredentialsProvider en un clúster de Kerberos provoca una fuga de memoria en el JindoFSx Namespace Service.

      Actualice tanto JindoFSx como JindoSDK a la versión 4.6.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster y Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.5.0, si falla un intento de acceso sin contraseña a OSS u OSS-HDFS en un clúster de EMR, el cliente no actualiza el token al reintentar la operación. Esto provoca que algunos trabajos se queden colgados.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.5.0, usar la herramienta JindoUtil con acceso sin contraseña en un clúster de EMR provoca un error de permiso.

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    Versión 4.4.x

    • En JindoSDK 4.4.0, 4.4.1 y 4.4.2, así como en JindoFSx 4.4.0, 4.4.1 y 4.4.2, establecer fs.oss.credentials.provider=com.aliyun.jindodata.oss.auth.RangerCredentialsProvider en un clúster de Kerberos provoca una fuga de memoria en el JindoFSx Namespace Service.

      Actualice tanto JindoFSx como JindoSDK a la versión 4.6.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster y Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.4.0, el acceso sin contraseña de alta concurrencia a OSS y OSS-HDFS en un clúster de EMR puede generar un volcado de memoria (core dump).

      Utilice un AccessKey fijo o actualice JindoSDK a la versión 4.6.2 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    Versión 4.3.x

    • En JindoSDK 4.3.0 (en clústeres EMR-3.40.0 o EMR-5.6.0), mostrar las marcas de tiempo de los directorios degrada el rendimiento del comando ls. Por este motivo, dichas marcas de tiempo no se muestran.

      Para mostrar las marcas de tiempo, actualice JindoSDK a la versión 4.3.1 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • En JindoSDK 4.3.0 (en clústeres EMR-3.40.0 o EMR-5.6.0), MagicCommitter puede desencadenar llamadas frecuentes a uploadPart. Esto genera el error "Part number must be an integer between 1 and 10000".

      Para resolver este problema, actualice JindoSDK a la versión 4.3.1 o posterior. Para consultar las instrucciones de actualización, vea Upgrade and roll back JindoSDK for an EMR cluster (X86).

    • JindoFSx 4.3.0 gestiona incorrectamente los errores al leer datos almacenados en caché desde ciertas rutas. El servidor no devuelve los errores al cliente, por lo que este recibe datos incorrectos.

      Para resolver este problema, actualice JindoFSx a la versión 4.3.1 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster.

    • JindoFSx 4.3.0 procesa de manera incorrecta los comandos de precarga de la caché de memoria. Esto puede dañar los datos almacenados en caché y provocar que las lecturas posteriores devuelvan resultados erróneos.

      Para resolver este problema, actualice JindoFSx a la versión 4.3.1 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster.

    • JindoFSx 4.3.0 y 4.3.1 presentan fugas de controladores de archivos. Con el tiempo, el proceso puede alcanzar el límite de controladores de archivos del sistema operativo. Cuando esto ocurre, el servicio no puede abrir nuevos controladores y deja de estar disponible.

      Para resolver este problema, actualice JindoFSx a la versión 4.3.2 o posterior. Para obtener más información, consulte Upgrade JindoData for an EMR cluster.

    Versión 4.2.x

    En JindoSDK 4.2.0, la operación SEEK en archivos grandes puede causar un desbordamiento de enteros. Como consecuencia, los trabajos basados en SEEK que leen archivos grandes desde OSS podrían fallar.

    Versión 4.1.x

    En JindoSDK 4.1.0, la operación SEEK en archivos grandes puede causar un desbordamiento de enteros. Como consecuencia, los trabajos basados en SEEK que leen archivos grandes desde OSS podrían fallar.

    Versión 4.0.x

    En JindoSDK 4.0.0 (en clústeres EMR-3.39.0 o EMR-5.5.0), la operación SEEK en archivos grandes puede causar un desbordamiento de enteros. Como consecuencia, los trabajos basados en SEEK que leen archivos grandes desde OSS podrían fallar.

    Limitaciones

    • JindoSDK no admite la escritura de archivos mayores a 80 GB en OSS.

    • JindoSDK no admite la escritura en OSS mediante el modo de anexión (append).

    • JindoSDK no es compatible con el cifrado del lado del cliente para OSS.

    • JindoSDK no admite las versiones anteriores de JindoFS en modo bloque ni en modo caché.

    • El servicio Alibaba Cloud OSS-HDFS (el servicio JindoFS) no admite actualizaciones desde versiones anteriores de JindoFS que se ejecutan en modo bloque.

      Puede utilizar la herramienta JindoDistCp para migrar los datos del sistema antiguo al nuevo servicio.