Problèmes connus pour les outils pour développeurs

Détails

La version 2.81.0 de la trousse SDK Java pour OCI est incompatible avec Java 8. Si vous utilisez la version 2.81.0 avec Java 8, vous pouvez obtenir le message d'erreur suivant lors de l'exécution :

java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;

Pour plus de renseignements, consultez la page GitHub.

Solution de rechange

Ce problème a été résolu dans la version 2.82.0, qui restaure la compatibilité avec Java 8. Toutes les versions antérieures à la version 2.81.0 sont également compatibles avec Java 8.

Si vous utilisez Java 8, n'utilisez pas la version 2.81.0, la version 2.82.0 ou une version plus récente.

Détails

Si vous utilisez la version 2.66.0 de la trousse SDK Java pour OCI, vous pouvez voir une consommation de mémoire accrue lors du chargement des flux en raison d'une mise en mémoire tampon inutile de l'ensemble du flux en mémoire.

Solution de rechange

Ce problème a été résolu dans la version 2.72.0 et versions ultérieures. Si vous utilisez la version touchée, effectuez une mise à niveau vers la version 2.72.0 ou ultérieure. Pour plus d'informations et d'autres solutions de rechange possibles, voir le problème sur GitHub.

Détails

Si vous utilisez des versions de trousse SDK Java pour OCI de la version 3.31.0 à la version 3.38.0, vous pouvez voir une fuite d'unité d'exécution dans IdleConnectionMonitor. Une augmentation de l'utilisation d'UC ou de mémoire peut survenir en raison de la prolifération d'unités d'exécution de type idle-connection-monitor-thread.

Solution de rechange

Ce problème a été résolu dans la version 3.39.0 et versions ultérieures. Si vous utilisez l'une des versions antérieures touchées, nous vous recommandons de passer à la version 3.39.1 ou ultérieure. Pour plus d'informations et d'autres solutions de rechange possibles, voir le problème sur GitHub.

Détails

Si vous utilisez l'un des clients synchrones de la trousse SDK Java pour OCI qui chargent des flux de données (tels que ObjectStorageClient ou DataSafeClient) et que vous ne définissez pas RetryConfiguration au niveau de demande, vos demandes ne seront pas relancées automatiquement dans les versions 3.0.0 à 3.31.0. Il n'y a aucune chance de corruption silencieuse des données.

Solution de rechange

Ce problème est résolu dans les versions 3.31.1 et ultérieures. Si vous utilisez l'une des versions antérieures touchées, nous vous recommandons de passer à la version 3.31.1 ou ultérieure. Pour plus d'informations et d'autres solutions de rechange possibles, voir le problème sur GitHub.

Détails

Le message d'erreur suivant peut être détecté après la mise à jour vers les versions JDK 8u381, 11.0.20, 17.0.8 ou 21.0.0 :

java.lang.ClassNotFoundException: com.oracle.bmc.auth.AbstractAuthenticationDetailsProvider

Ce problème se produit car les versions Java listées ont une taille de fichier de signature maximale par défaut inférieure à celle de certains fichiers JAR de trousse SDK Java. La faible valeur par défaut de Java sera traitée et résolue dans les prochaines versions mineures de Java.

Solution de rechange #1

Pour résoudre ce problème, vous pouvez exécuter Maven avec le paramètre suivant :

-Djdk.jar.maxSignatureFileSize=16000000

Si vous effectuez une compilation avec javac, vous pouvez utiliser la commande suivante :

javac -J-Djdk.jar.maxSignatureFileSize=16000000 example.java

Détails

Si vous utilisez une trousse SDK Java pour OCI de la version 2.47.0 à des versions antérieures à la version 2.51.2, vous pouvez rencontrer un bogue dans CircuitBreaker qui déclenche un NoSuchElementException. Pour plus d'informations, voir https://github.com/oracle/oci-java-sdk/issues/491

Solution de rechange #1

Ce problème a été résolu dans la trousse SDK Java pour OCI 2.51.2. Mettez à jour la version 2.51.2 ou plus récente de la trousse SDK Java pour OCI.

Solution de rechange #2

Si vous ne pouvez pas effectuer la mise à jour vers la version 2.51.2 ou une version plus récente, vous pouvez désactiver et refuser la prise en charge par défaut de la trousse SDK Java pour les disjoncteurs pour les clients de service qui ont activé les disjoncteurs de trousse SDK par défaut.

Détails

Lors de la création répétée de nouveaux signataires/objets clients avec Instance Principals, Resource Principal et l'authentification par jeton de délégation, certains objets sous-jacents ne sont pas effacés de la mémoire, ce qui entraîne une fuite de mémoire. À partir de nos tests, le taux de croissance de la mémoire est d'environ 10 Mio / heure lorsque seuls les objets client / signataire sont créés dans une boucle infinie. Cloud Shell est affecté par le même problème lorsque de nouveaux objets clients sont créés à plusieurs reprises à l'aide de la trousse SDK Python. Cela semble provenir d'une fuite de mémoire sous-jacente dans le paquet de demandes. Pour plus de renseignements, consultez la page https://github.com/psf/requests/issues/4601.

Solution de rechange #1

Évitez de créer de nouveaux objets signataires/clients et réutilisez les objets existants si possible. Si vous utilisez l'authentification par jeton de délégation et que vous devez mettre à jour la valeur du jeton de délégation, l'exemple suivant montre comment mettre à jour un signataire existant au lieu de créer un nouveau signataire :

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" 

Solution de rechange #2

Utilisez le signataire de demande brute.

Détails : Si vous utilisez l'un des clients synchrones de la trousse SDK Java pour OCI qui chargent des flux de données (par exemple ObjectStorageClient ou DataSafeClient) et que vous ne définissez pas RetryConfiguration au niveau du client ou au niveau de la demande, une corruption silencieuse des données peut se produire.

Sondage : Nous travaillons activement à la résolution de ce problème. Pour plus d'informations et les solutions de rechange possibles, consultez le problème sur GitHub.

Lien direct vers ce problème : Problème potentiel de corruption de données dans la trousse SDK Java pour OCI lors du chargement de données binaires à l'aide de la recherche par défaut

Détails : Si vous utilisez les versions 2.14.1 et ultérieures de la trousse SDK Java pour OCI, vous pouvez rencontrer des régressions de performance lors de l'utilisation de la trousse SDK pour appeler des opérations d'API sur l'un des services OCI. La régression entraîne une augmentation de 30 à 60 % de la latence des opérations de trousse SDK sur l'un des services OCI.

Solution de rechange : Pour plus d'informations et les solutions de rechange possibles, voir le problème sur GitHub.

Lien direct vers ce problème : Régression de la performance des versions 2.14.1 et ultérieures de la trousse SDK Java pour OCI pour toutes les opérations d'API

Détails : À partir de la version 2.0.0, la trousse SDK OCI pour Java prend en charge l'utilisation du connecteur Jersey ApacheConnectorProvider au lieu du connecteur Jersey HttpUrlConnectorProvider par défaut pour permettre à Apache HttpClient d'effectuer des appels de service OCI.

ApacheConnectorProvider prend en charge l'utilisation de l'en-tête Expect par défaut pour certaines opérations du service de stockage d'objets (voir https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). Il a été observé que cela entraînait une régression de la performance des mêmes opérations du service de stockage d'objets.

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);

Lien direct vers ce problème : Régression de la performance avec le fournisseur de connecteur Apache dans la trousse SDK d'OCI pour Java

Détails : Dans les versions 2.0.0 à 2.13.0 de l'API de la trousse SDK Java d'OCI, certaines opérations qui retournent un flux de données mais qui ne retournent pas l'en-tête de longueur de contenu dans la réponse, peuvent retourner des données tronquées. Cela est dû à la fermeture prématurée du flux par la trousse SDK avant que toutes les données aient été lues.

Solution de rechange : Mettez à jour le client de trousse SDK Java OCI vers la version 2.13.1 ou ultérieure. Pour plus d'informations sur ce problème et ses solutions, voir https://github.com/oracle/oci-java-sdk/issues/357

Lien direct vers ce problème : Réponse tronquée pour les opérations qui retournent des données binaires avec la trousse SDK Java d'OCI

Détails : En raison de problèmes liés à l'une de ses dépendances, la fonction de la trousse SDK Go qui permet aux clients d'utiliser automatiquement de nouveaux domaines qui peuvent être inconnus de la trousse SDK ne fonctionne pas dans Cloud Shell.

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

Solution de rechange : Pour résoudre ce problème, activez la résolution des régions à l'aide du service de métadonnées d'instance pour la trousse SDK Go. Pour plus d'informations, voir Ajout de régions.

Détails : Vous pouvez subir une augmentation de la latence des opérations exécutées dans certains services OCI à l'aide des trousses SDK, de Terraform, d'Ansible et de l'interface de ligne de commande. Ce problème concerne le service de diffusion en continu OCI et il a probablement une incidence sur les services de transmission de messages, de vérifications d'état, NoSQL Database Cloud, de registre, d'artefacts génériques et d'accélération et de sécurité des applications Web. Cette liste n'est pas exhaustive et il est possible que vous rencontriez également le problème avec d'autres services OCI. Il a été confirmé que ce problème ne concernait pas les services OCI de stockage d'objets et de fonctions.

Les trousses SDK et les outils suivants sont concernés :

Solutions de rechange et informations supplémentaires : Nous travaillons activement à la résolution de ce problème. Pour obtenir des informations supplémentaires et connaître les éventuelles solutions de rechange, consultez les ressources suivantes :

Lien direct vers ce problème : Problèmes de latence accrue des opérations effectuées dans certains services OCI à l'aide des trousses SDK et d'autres outils

Détails : Les opérations composites de client copy_boot_volume_backup_and_wait_for_state et copy_volume_backup_and_wait_for_state BlockStorage génèrent une erreur 404/NotAuthorizedOrNotFound lors de la copie d'une sauvegarde d'une région à une autre. Pour plus d'informations, voir : https://github.com/oracle/oci-python-sdk/issues/344.

Solution de rechange : Au lieu d'utiliser les opérations composites, utilisez deux clients différents pour cette opération : un client de la région source qui envoie la demande de copie de la région A vers la région B, et un client de la région de destination qui attend que la sauvegarde soit disponible. Voir un exemple ici : https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

Lien direct vers ce problème : Les opérations composites de la trousse SDK Python lancent une erreur 404 NotAuthorizedOrNotFound même si l'opération réussit

Détails : La trousse SDK OCI pour TypeScript et JavaScript présente un problème connu lié aux grands nombres supérieurs à JavaScript Number.MAX_SAFE_INTEGER. Tout nombre supérieur à Number.MAX_SAFE_INTEGER entraîne un problème d'arrondissement.

Solution de rechange : Nous sommes conscients du fait qu'une réponse d'API peut renvoyer un nombre supérieur à Number.MAX_SAFE_INTERGER dans JavaScript. Pour le moment, le problème d'arrondissement des nombres n'a aucune incidence sur l'appel des API.

Lien direct vers ce problème : Problème potentiel d'arrondissement de données pour les grands nombres avec la trousse SDK OCI pour TypeScript et JavaScript

Détails : Lorsque vous utilisez la version 1.25.1 ou une version antérieure des clients de trousse SDK Java OCI qui chargent des flux de données (par exemple ObjectStorageClient ou FunctionsInvokeClient), de manière synchrone et asynchrone, et que vous utilisez RefreshableOnNotAuthenticatedProvider (par exemple, pour les principaux de ressource ou les principaux d'instance) vous pouvez être affecté par une corruption silencieuse des données.

Solution de rechange : Mettez à jour le client de trousse SDK Java OCI vers la version 1.25.2 ou ultérieure. Pour plus d'informations sur ce problème et les solutions de rechange associées, voir Problème potentiel de corruption de données avec la trousse SDK Java OCI lors du chargement de données binaires avec RefreshableOnNotAuthenticatedProvider.

Lien direct vers ce problème : Problème potentiel de corruption de données avec la trousse SDK Java OCI lors du chargement de données binaires avec RefreshableOnNotAuthenticatedProvider

Détails : Si vous utilisez la version 3.2.1.1 ou une version antérieure des clients de connecteur HDFS OCI et que vous utilisez RefreshableOnNotAuthenticatedProvider (par exemple, InstancePrincipalsCustomAuthenticator, ou généralement pour les principaux de ressource ou les principaux d'instance), vous risquez d'être affecté par une corruption silencieuse des données.

Solution de rechange : Mettez à jour le client de connecteur OCI HDFS vers la version 3.2.1.3 ou ultérieure. Pour plus d'informations sur ce problème et les solutions de rechange associées, voir Problème potentiel de corruption de données avec le connecteur HDFS OCI avec RefreshableOnNotAuthenticatedProvider.

Lien direct vers ce problème : Problème de corruption de données potentielle avec le connecteur HDFS OCI sur le chargement de données binaires avec RefreshableOnNotAuthenticatedProvider

Détails : Lorsque vous utilisez la trousse SDK Python pour effectuer des opérations de chargement de données binaires, vous pouvez rencontrer un problème de corruption de données si les nouvelles tentatives sont activées ou si vous utilisez UploadManager.upload_file.

Solution de rechange : Nous travaillons à une résolution. Pour plus d'informations sur ce problème et les solutions de rechange associées, voir Problème de corruption de données potentielle en cas de nouvelle tentative avec la trousse SDK Python lors du chargement de données binaires.

Lien direct vers ce problème : Corruption de données potentielle avec la trousse SDK Python lors du chargement de données binaires

Mise à jour : La cause fondamentale du problème entraînant la corruption de données a été corrigée avec la version 2.54.0. Utilisez OCI v2.54.0 ou supérieure pour éviter la corruption de données. Le comportement des anciennes versions de la trousse SDK Python d'OCI par rapport à ce problème est décrit ci-dessous.

Détails : Les clients qui utilisent la trousse SDK pour Python d'OCI et oci.object_storage.UploadManager.upload_stream en mode FIPS peuvent être vulnérables à la corruption silencieuse des données. Si les circonstances de survenue du problème sont vraies pour votre environnement, la trousse SDK signale la réussite de l'opération de chargement, mais un objet de longueur 0 est chargé.

La résolution diffère selon l'état de votre environnement :

1. Utilisation de UploadManager.upload_stream() dans un environnement qui utilise une version OpenSSL conforme à FIPS où la trousse SDK pour Python ne fonctionne pas en mode FIPS, comme décrit sous Utilisation des bibliothèques validées pour FIPS.

   Pour déterminer si ce scénario vous concerne :

   • Vérifiez que vous utilisez une version d'OpenSSL conforme à FIPS en exécutant la commande openssl version. Si "FIPS" fait partie du nom de la version et que vous n'utilisez pas la trousse SDK en mode FIPS, ce scénario vous concerne.

   • Si oci.fips.is_fips_mode() ne renvoie pas la valeur True, la trousse SDK ne fonctionne pas en mode FIPS.

   Solution de rechange : Mettez à niveau la trousse SDK pour Python d'OCI vers la version 2.53.1 ou supérieure et utilisez la trousse SDK pour Python en mode FIPS, comme décrit sous Utilisation des bibliothèques validées pour FIPS.

   Important
   
   Le fait de ne pas utiliser la trousse SDK en mode FIPS lors de l'utilisation d'une version d'OpenSSL conforme à FIPS entraîne toujours une corruption des données lors de l'utilisation de UploadManager.upload_stream().
2. Utilisation de UploadManager.upload_stream() lorsque la trousse SDK pour Python fonctionne en mode FIPS, comme décrit dans Utilisation des bibliothèques validées pour FIPS, et que la trousse SDK pour Python est version 2.53.0 ou inférieure.

   Si oci.fips.is_fips_mode() retourne la valeur True, la trousse SDK fonctionne en mode FIPS.

   Résolution : Passez à la version 2.53.1 ou supérieure de la trousse SDK pour Python d'OCI.

Pour plus d'informations sur ce problème, voir Problème potentiel de corruption de données pour le chargement de flux en plusieurs parties avec la trousse SDK pour Python d'OCI sur GitHub.

Lien direct vers ce problème : Problème potentiel de corruption de données avec la trousse SDK pour Python et les flux de chargement

Pour plus d'informations sur les problèmes connus liés au service de gestion WebLogic, voir Problèmes connus.