Problemas conocidos de las herramientas de desarrollador

En esta sección se muestran las incidencias conocidas que se han identificado para las herramientas de desarrollador y los SDK.

Aumento del consumo de memoria al cargar flujos en el SDK de Java de OCI versión 2.66.0

Detalles

Si utiliza la versión 2.66.0 del SDK de Java de OCI, podría ver un mayor consumo de memoria al cargar flujos debido a un almacenamiento en buffer innecesario de todo el flujo en memoria.

Solución Alternativa

Este problema se ha solucionado en la versión 2.72.0 y posteriores. Si utiliza la versión afectada, actualice a la versión 2.72.0 o posterior. Para obtener más información y otras posibles soluciones alternativas, consulte el problema en GitHub.

Fuga de threads en IdleConnectionMonitor en las versiones 3.31.0 a 3.38.0 del SDK de Java de OCI

Detalles
Si utiliza cualquier versión de SDK de Java de OCI de 3.31.0 a 3.38.0, podría ver una pérdida de thread en IdleConnectionMonitor. Es posible que se produzca un aumento en el uso de CPU o memoria debido a la proliferación de threads de tipo idle-connection-monitor-thread.
Solución Alternativa

Este problema se ha solucionado en la versión 3.39.0 y posteriores. Si utiliza cualquiera de las versiones anteriores afectadas, recomendamos actualizar a la versión 3.39.1 o posterior. Para obtener más información y otras posibles soluciones alternativas, consulte el problema en GitHub.

Los reintentos de operaciones que cargan datos binarios sin reintentos de nivel de solicitud fallan en las versiones 3.0.0 a 3.31.0 del SDK de Java de OCI

Detalles
Si utiliza cualquiera de los clientes síncronos del SDK de Java de OCI que cargan flujos de datos (como ObjectStorageClient o DataSafeClient) y no define RetryConfiguration en el nivel de solicitud, las solicitudes no se volverán a intentar automáticamente en las versiones 3.0.0 a 3.31.0. No hay posibilidad de corrupción de datos silenciosa.
Solución Alternativa

Este problema se ha solucionado en la versión 3.31.1 y posteriores. Si utiliza alguna de las versiones anteriores afectadas, le recomendamos que actualice a la versión 3.31.1 o posterior. Para obtener más información y otras posibles soluciones alternativas, consulte el problema en GitHub.

Errores al utilizar el SDK de Java después de actualizar a las versiones de JDK 8u381, 11.0.20, 17.0.8 o 21.0.0

Detalles
Es posible que se encuentre el siguiente mensaje de error después de actualizar a las versiones 8u381, 11.0.20, 17.0.8 o 21.0.0 de JDK:
java.lang.ClassNotFoundException: com.oracle.bmc.auth.AbstractAuthenticationDetailsProvider

Este problema se produce porque las versiones de Java mostradas tienen un tamaño de archivo de firma máximo por defecto menor que algunos JAR de SDK de Java. El valor por defecto bajo en Java se abordará y resolverá en las próximas versiones secundarias de la versión de Java.

Solución alternativa #1
Para resolver este problema, puede ejecutar Maven con el siguiente parámetro:
-Djdk.jar.maxSignatureFileSize=16000000
Si va a compilar con javac, puede utilizar el siguiente comando:
javac -J-Djdk.jar.maxSignatureFileSize=16000000 example.java

Condición de raza del SDK de Java en CircuitBreaker que lleva a NoSuchElementException en el SDK de Java de OCI

Detalles
Si utiliza un SDK de Java de OCI de la versión 2.47.0 a versiones anteriores a la 2.51.2, puede que encuentre un bug en CircuitBreaker que emita un NoSuchElementException. Para obtener más información, consulte https://github.com/oracle/oci-java-sdk/issues/491.
Solución alternativa #1

Este problema se resolvió en el SDK Java de OCI 2.51.2. Actualice a la versión versión 2.51.2 o más reciente del SDK de Java de OCI.

Solución alternativa #2

Si no puede actualizar a la versión 2.51.2 o posterior, puede desactivar y excluirse del soporte por defecto del SDK de Java para disyuntores para clientes de servicio que han activado disyuntores del SDK por defecto.

Posible problema de pérdida de memoria del SDK de Python al crear nuevos firmantes/clientes repetidamente

Detalles
Al crear repetidamente nuevos objetos de firmantes/clientes con autenticación de principales de instancia, entidad de recurso y token de delegación, algunos objetos subyacentes no se borran de la memoria, lo que provoca una pérdida de memoria. A partir de nuestras pruebas, la tasa de crecimiento de la memoria es de ~10 MiB/hora cuando solo se crean objetos cliente/firmante en un bucle infinito. Cloud Shell se ve afectado por el mismo problema cuando se crean nuevos objetos de cliente repetidamente mediante el SDK de Python. Esto parece provenir de una pérdida de memoria subyacente en el paquete de solicitudes. Para obtener más información, consulte https://github.com/psf/requests/issues/4601.
Solución alternativa #1
Evite crear nuevos objetos de firmante/cliente y reutilice los objetos existentes si es posible. Si utiliza la autenticación de token de delegación y necesita actualizar el valor del token de delegación, en el siguiente ejemplo se muestra cómo actualizar un firmante existente en lugar de crear un firmante nuevo:
from oci.auth.signers import InstancePrincipalsDelegationTokenSigner
from oci.object_storage import ObjectStorageClient    

# Create signer and client
delegation_token_signer = InstancePrincipalsDelegationTokenSigner(delegation_token="delegation_token_value")
client = ObjectStorageClient(config={}, signer=delegation_token_signer)    

# Update the delegation token on the client
client.base_client.signer.delegation_token="new_delegation_token_value" 
Solución alternativa #2
Utilice el firmante de solicitud raw.

Posible problema de corrupción de datos en el SDK de Java de OCI con carga de datos binarios mediante reintentos por defecto

Detalles: Si está utilizando cualquiera de los clientes síncronos del SDK de Java de OCI que cargan flujos de datos (por ejemplo, ObjectStorageClient o DataSafeClient) y no define RetryConfiguration en el nivel de cliente o nivel de solicitud, puede que se vea afectado por daños de datos silenciosos.

Solución alternativa: estamos trabajando activamente para solucionar esta incidencia. Para obtener más información y posibles soluciones alternativas, consulte el problema en GitHub.

Enlace directo a esta incidencia: Posible problema de corrupción de datos en el SDK de Java de OCI con carga de datos binarios mediante reintentos por defecto

Regresión del rendimiento en las versiones 2.14.1 y posteriores de OCI Java SDK para todas las operaciones de API

Detalles: si está utilizando las versiones 2.14.1 y posteriores del SDK de Java de OCI, puede que detecte regresiones del rendimiento al utilizar el SDK para llamar a operaciones de API en cualquiera de los servicios de OCI. La regresión provoca un aumento de entre el 30% y el 60% en la latencia en las operaciones de SDK en cualquiera de los servicios de OCI.

Solución alternativa: para obtener más información y posibles soluciones alternativas, consulte el problema en GitHub.

Enlace directo a este problema: Regresión del rendimiento en las versiones 2.14.1 y posteriores del SDK de Java de OCI para todas las operaciones de API

Regresión del rendimiento con el proveedor del conector Apache en el SDK de OCI para Java

Detalles: a partir de la versión 2.0.0, el SDK de OCI para Java soporta el uso de ApacheConnectorProvider de Jersey en lugar del valor por defecto HttpUrlConnectorProvider de Jersey para permitir que Apache HttpClient realice llamadas de servicio de OCI.

ApacheConnectorProvider soporta el uso de la cabecera Expect por defecto para algunas operaciones del servicio Object Storage (consulte https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). Se ha observado que esto provoca una regresión del rendimiento en las mismas operaciones del servicio Object Storage.

Solución alternativa: puede desactivar el uso de la cabecera Expect volviendo al conector por defecto de Jersey (consulte https://docs.oracle.com/iaas/Content/API/SDKDocs/javasdkconfig.htm) o, si ya está utilizando ApacheConnectorProvider, puede desactivar la cabecera Expect con ApacheConnectorProvider haciendo lo siguiente al inicializar el cliente:
final ApacheConnectorProperties apacheConnectorProperties =
        ApacheConnectorProperties.builder()
                .expectContinue(false) // disable the Expect header
                .build();

final ApacheConfigurator configurator =
        new ApacheConfigurator.NonBuffering(apacheConnectorProperties);
        
ObjectStorageClient objectStorageClient =
        ObjectStorageClient.builder()
                .clientConfigurator(configurator)
                .build(provider);

Enlace directo a esta incidencia: Regresión del rendimiento con el proveedor del conector Apache en el SDK de OCI para Java

Respuesta truncada para las operaciones que devuelven datos binarios con el SDK de Java de OCI

Detalles: en las versiones 2.0.0 a 2.13.0 de la API del SDK de Java de OCI, algunas operaciones que devuelven un flujo de datos pero no devuelven la cabecera content-length en la respuesta podrían devolver datos truncados. Esto se debe al cierre prematuro del flujo por parte del SDK antes de leer todos los datos.

Solución alternativa: actualice el cliente de SDK de Java de OCI a la versión 2.13.1 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte https://github.com/oracle/oci-java-sdk/issues/357.

Enlace directo a esta incidencia: Respuesta truncada para las operaciones que devuelven datos binarios con el SDK de Java de OCI

El SDK de Go no puede encontrar automáticamente algunas regiones mientras se ejecuta en Cloud Shell

Detalles: debido a algunas incidencias con una de sus dependencias, la función SDK de Go, que permite a los clientes utilizar automáticamente nuevos dominios que podrían ser desconocidos para el SDK, no funciona desde Cloud Shell.

Si intenta ejecutar código en Cloud Shell que utilice esta función, aparecerá el siguiente mensaje de error:
can not create client, bad configuration: failed to get security token: failed to renew security token: failed to get security token: failed to call: Post "https://<endpoint>/v1/x509": dial tcp: lookup <endpoint> on 127.0.0.11:53: server misbehaving
panicked while retrying operation. Panic was: runtime error: invalid memory address or nil pointer dereference

Solución alternativa: para resolver esta incidencia, active la resolución de regiones mediante el servicio de metadatos de instancia para el SDK de Go. Para obtener más información, consulte: Adición de Regiones

Aumento de las incidencias de latencia en operaciones realizadas para algunos servicios de OCI mediante los SDK y otras herramientas.

Detalles: puede que observe un aumento de la latencia en operaciones realizadas en algunos servicios de OCI mediante los SDK, Terraform, Ansible y la CLI. Se ha confirmado que esta incidencia afecta al servicio OCI Streaming, y que puede afectar también a los servicios Email Delivery, Health Checks, NoSQL Database Cloud, Registry, los artefactos genéricos y Web Application Acceleration and Security. Esta lista no es exhaustiva, por lo que es posible que también detecte esta incidencia en otros servicios de OCI. Se ha confirmado que esta incidencia NO afecta a los servicios Object Storage y Functions de OCI.

Los siguientes SDK y herramientas se ven afectados:

  • SDK de Go (versión 41.2.0 y posterior)
  • SDK de .NET (versión 14.2.0 y posterior)
  • SDK de Java (versión 2.0.0 y posterior)
  • SDK de Python (versión 2.38.4 y posterior)
  • CLI (versión 2.25.0 y posterior)
  • Módulos de PowerShell (versión 9.2.0 y posterior)
  • Módulos de Ansible (versión 2.23.0 y posterior)
  • Proveedor de Terraform (versión 4.30.0 y posterior)

Soluciones alternativas y más información: Estamos trabajando activamente para solucionar esta incidencia. Para obtener más información y posibles soluciones alternativas, consulte lo siguiente:

Enlace directo a esta incidencia: Aumento de las incidencias de latencia en operaciones realizadas para algunos servicios de OCI mediante los SDK y otras herramientas

Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

Detalles: las operaciones copy_boot_volume_backup_and_wait_for_state y copy_volume_backup_and_wait_for_state del compuesto de cliente BlockStorage devuelven 404/NotAuthorizedOrNotFound cuando se copia una copia de seguridad de una región a otra. Para obtener más información, consulte: https://github.com/oracle/oci-python-sdk/issues/344.

Solución alternativa: en lugar de utilizar las operaciones de compuesto, utilice dos clientes diferentes para esta operación; un cliente en la región de origen para enviar la solicitud de duplicado de la copia de seguridad de la región A a la región B, y un segundo cliente en la región de destino para esperar a que la copia de seguridad esté disponible. Consulte el ejemplo aquí: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

Enlace directo a esta incidencia: Las operaciones de compuesto del SDK de Python devuelven el error 404 NotAuthorizedOrNotFound a pesar de que la operación es correcta

Posible incidencia de redondeo de datos para números grandes con el SDK de OCI para TypeScript y JavaScript

Detalles: el SDK de OCI para TypeScript y JavaScript tiene una incidencia conocida con números grandes mayores que Number.MAX_SAFE_INTEGER de JavaScript. Cualquier número mayor que Number.MAX_SAFE_INTEGER generará una incidencia de redondeo.

Solución alternativa: Tenemos constancia de la incidencia por la que una respuesta de API puede devolver un número mayor que Number.MAX_SAFE_INTERGER de JavaScript. En este momento, la incidencia de redondeo de números no afecta a la llamada a ninguna API.

Enlace directo a esta incidencia: Posible incidencia de redondeo de datos para números grandes con el SDK de OCI para TypeScript y JavaScript

Posible incidencia de datos en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Detalles: si está utilizando la versión 1.25.1 o anterior de los clientes de SDK de Java de OCI que cargan flujos de datos (por ejemplo, ObjectStorageClient o FunctionsInvokeClient), de forma síncrona y asíncrona, y utiliza RefreshableOnNotAuthenticatedProvider (por ejemplo, para los principales de recursos o los principales de instancia), puede verse afectado por daños silenciosos en los datos.

Solución alternativa: actualice el cliente de SDK de Java de OCI a la versión 1.25.2 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte Posible incidencia de daños en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el SDK de Java de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Posible incidencia de daños en los datos con el conector HDFS de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Detalles: si utiliza la versión 3.2.1.1 o anterior de los clientes del conector HDFS de OCI y usa RefreshableOnNotAuthenticatedProvider (por ejemplo, InstancePrincipalsCustomAuthenticator o, generalmente, para principales de recurso o principales de instancia), puede que se vea afectado por daños silenciosos en los datos.

Solución alternativa: actualice el cliente del conector HDFS de OCI a la versión 3.2.1.3 o una versión posterior. Para obtener más información sobre esta incidencia y soluciones alternativas, consulte Posible incidencia de daños en los datos para el conector HDFS de OCI con RefreshableOnNotAuthenticatedProvider.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el conector HDFS de OCI en la carga de datos binarios con RefreshableOnNotAuthenticatedProvider

Posibles daños de los datos con el SDK para Python en la carga binaria

Detalles: al utilizar el SDK para Python para realizar operaciones de carga binaria, puede que aparezca un problema relacionado con daños de los datos si los reintentos están activados o si está utilizando UploadManager.upload_file.

Solución alternativa: estamos intentando solucionar este problema. Para obtener más información sobre este problema y las soluciones alternativas, consulte Posible problema de daños de los datos para el reintento del SDK de Python en la carga de datos binarios.

Enlace directo a este problema: Posibles daños de los datos con el SDK para Python en la carga binaria

Posible incidencia de daños en los datos con el SDK para Python y flujos de carga

Actualización: la causa raíz de la incidencia que causa daños en los datos se ha corregido con la versión v2.54.0. Utilice oci v2.54.0 o una versión superior para evitar daños en los datos. A continuación se explica el comportamiento de las versiones anteriores del SDK de Python de OCI con respecto a esta incidencia.

Detalles: los clientes que utilizan el SDK de OCI para Python y oci.object_storage.UploadManager.upload_stream en modo FIPS pueden ser vulnerables a daños silenciosos en los datos. Si las circunstancias para producir la incidencia son verdaderas para su entorno, el SDK informa que la operación de carga se ha realizado correctamente, pero se carga un objeto de longitud 0.

La resolución varía en función del estado del entorno:

  1. El uso de UploadManager.upload_stream() en un entorno que utiliza una versión de OpenSSL compatible con FIPS en la que el SDK para Python no está funcionando en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS.

    Para determinar si entra dentro de este escenario:

    • Verifique que está utilizando una versión de OpenSSL compatible con FIPS mediante la ejecución del comando openssl version. Si "fips" forma parte del nombre de la versión y no está utilizando el SDK en modo FIPS, entonces entraría dentro de este escenario.

    • Si oci.fips.is_fips_mode() no devuelve True, quiere decir que el SDK no está funcionando en modo FIPS.

    Solución alternativa: actualice el SDK de OCI para Python a la versión 2.53.1 o posterior y utilice el SDK para Python en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS.
    Importante

    Si no usa el SDK en modo FIPS mientras utiliza una versión de OpenSSL compatible con FIPS, los datos se dañarán al utilizar UploadManager.upload_stream().
  2. El uso de UploadManager.upload_stream() cuando el SDK para Python está funcionando en modo FIPS, como se describe en Uso de bibliotecas validadas por FIPS, y la versión del SDK para Python es v2.53.0 o inferior.

    Si oci.fips.is_fips_mode() devuelve True, quiere decir que el SDK está funcionando en modo FIPS.

    Resolución: actualice el SDK de OCI para Python a la versión 2.53.1 o posterior.

Para obtener más información sobre esta incidencia, consulte la sección sobre la posible incidencia de corrupción de datos para la carga de flujos de varias partes para el SDK de Python de OCI en GitHub.

Enlace directo a esta incidencia: Posible incidencia de daños en los datos con el SDK para Python y flujos de carga