Problèmes connus pour les outils de développement

Détails

La version 2.81.0 du kit SDK Java OCI est incompatible avec Java 8. Si vous utilisez la version 2.81.0 avec Java 8, le message d'erreur suivant peut s'afficher lors de l'exécution :

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

Pour plus d'informations, reportez-vous au problème sur GitHub.

Solution de contournement

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, utilisez plutôt la version 2.82.0 ou une version plus récente.

Détails

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

Solution de contournement

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

Détails

Si vous utilisez des versions de kit SDK Java OCI de la version 3.31.0 à la version 3.38.0, une fuite de thread peut se produire dans IdleConnectionMonitor. Une augmentation de l'utilisation de la CPU ou de la mémoire peut se produire en raison de la prolifération de threads de type idle-connection-monitor-thread.

Solution de contournement

Ce problème a été résolu dans la version 3.39.0 et les versions ultérieures. Si vous utilisez l'une des versions précédentes concernées, nous vous recommandons d'effectuer une mise à niveau vers la version 3.39.1 ou ultérieure. Pour obtenir plus d'informations et d'autres solutions de contournement possibles, consultez le problème sur GitHub.

Détails

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

Solution de contournement

Ce problème est résolu dans les versions 3.31.1 et ultérieures. Si vous utilisez l'une des versions antérieures concernées, nous vous recommandons d'effectuer une mise à niveau vers la version 3.31.1 ou ultérieure. Pour obtenir plus d'informations et d'autres solutions de contournement possibles, consultez le problème sur GitHub.

Détails

Le message d'erreur suivant peut se produire après la mise à jour vers les versions 8u381, 11.0.20, 17.0.8 ou 21.0.0 du JDK :

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

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

Solution de contournement #1

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

-Djdk.jar.maxSignatureFileSize=16000000

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

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

Détails

Si vous utilisez un kit SDK Java OCI de la version 2.47.0 vers des versions antérieures à la version 2.51.2, vous risquez de rencontrer un bug dans CircuitBreaker qui génère une valeur NoSuchElementException. Pour plus d'informations, reportez-vous à https://github.com/oracle/oci-java-sdk/issues/491

Solution de contournement #1

Ce problème a été résolu dans le kit SDK Java OCI 2.51.2. Mettez à jour vers la version version 2.51.2 ou plus récente du kit SDK Java OCI.

Solution de contournement #2

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

Détails

Lors de la création répétée d'objets signataires/client avec l'authentification ID instance, principal de ressource et jeton de délégation, certains objets sous-jacents ne sont pas effacés de la mémoire, ce qui entraîne une perte de mémoire. D'après 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 client sont créés à plusieurs reprises à l'aide du kit SDK Python. Cela semble provenir d'une fuite de mémoire sous-jacente dans le package de demandes. Pour plus d'informations, reportez-vous à https://github.com/psf/requests/issues/4601.

Solution de contournement #1

Evitez de créer de nouveaux objets signataire/client 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 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 contournement #2

Utilisez le signataire de demande brut.

Détails : si vous utilisez l'un des clients synchrones du kit SDK Java OCI qui téléchargent des flux de données (par exemple, ObjectStorageClient ou DataSafeClient) et si vous ne définissez pas RetryConfiguration au niveau du client ou du niveau de demande, les données risquent d'être altérées sans invite.

Solution de contournement : nous travaillons activement à la résolution du problème. Pour avoir plus d'informations et obtenir les solutions de contournement possibles, consultez le problème sur GitHub.

Lien direct vers ce problème : Problème possible d'altération des données dans le kit SDK Java OCI avec le téléchargement des données binaires utilisant les tentatives par défaut

Détails : si vous utilisez la version 2.14.1 et les versions ultérieures du kit SDK OCI Java, vous risquez d'obtenir des régressions des performances lors de l'usage du kit SDK pour appeler les 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 kit SDK sur les services OCI.

Solution : pour avoir plus d'informations et obtenir des solutions de contournement possibles, consultez le problème sur GitHub.

Lien direct vers ce problème : Régression des performances dans les versions 2.14.1 du kit SDK Java OCI pour toutes les opérations d'API

Détails : à partir de la version 2.0.0, le kit SDK OCI pour Java prend en charge l'utilisation du fichier ApacheConnectorProvider de Jersey au lieu du fichier HttpUrlConnectorProvider par défaut de Jersey 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 de service Object Storage (reportez-vous à la page https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). Nous avons observé une régression des performances dans les mêmes opérations de service Object Storage.

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 performances avec le fournisseur du connecteur Apache dans Le kit SDK OCI pour Java

Détails : dans les versions 2.0.0 à 2.13.0 de l'API du kit SDK Java OCI, certaines opérations qui renvoient un flux de données mais pas l'en-tête content-length dans la réponse peuvent renvoyer des données tronquées. Cela est dû à la fermeture prématurée du flux par le kit SDK avant la lecture de toutes les données.

solution de contournement : mettez à jour le client SDK Java OCI vers la version 2.13.1 ou ultérieure. Pour plus d'informations sur ce problème et ses solutions de contournement, reportez-vous à la page https://github.com/oracle/oci-java-sdk/issues/357.

Lien direct vers ce problème : Réponse tronquée pour les opérations qui renvoient les données binaires avec le kit SDK Java OCI

Détails : en raison du problème lié à l'une de ses dépendances, la fonctionnalité du kit SDK Go qui permet aux clients d'utiliser automatiquement de nouveaux domaines pouvant être inconnus du kit SDK ne fonctionne pas à partir de 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 contournement : pour résoudre ce problème, activez l'activation de la résolution de régions à l'aide du service des métadonnées d'instance pour Le kit SDK Go. Pour plus d'informations, reportez-vous à: Ajout de régions

Détails : vous pouvez rencontrer une augmentation de la latence pour les opérations effectuées sur certains services OCI à l'aide des SDK, de Terraform, d'Ansible et de l'interface de ligne de commande. Ce problème a une incidence démontrée sur le service OCI Streaming, et probablement sur les services Email Delivery, Health Checks, NoSQL Database Cloud, Registry, Generic Artifacts et Web Application Acceleration and Security. Cette liste n'est pas complète. Il est possible que vous rencontriez le problème avec d'autres services OCI également. Le problème n'a pas d'incidence sur les services OCI Object Storage et Functions.

Les kits SDK et outils suivants sont concernés :

Solutions de contournement et informations complémentaires : nous travaillons activement à la résolution de ce problème. Pour avoir plus d'informations et obtenir les solutions de contournement possibles, consultez les références suivantes :

Lien direct vers ce problème : Problèmes de latence accrue dans les opérations pour certains services OCI lors de l'utilisation de kits SDKS et d'autres outils

Détails : les opérations composites copy_boot_volume_backup_and_wait_for_state et copy_volume_backup_and_wait_for_state du client BlockStorage génèrent une erreur de type 404/NotAuthorizedOrNotFound lorsque vous copiez une sauvegarde d'une région vers une autre. Pour plus d'informations, reportez-vous à https://github.com/oracle/oci-python-sdk/issues/344.

Solution de contournement : au lieu d'utiliser les opérations composites, utilisez deux clients différents pour cette opération ; un client dans La région source pour envoyer la demande d'envoi de la sauvegarde de la Région A vers la Région B et l'autre client dans La région de destination pour attendre que la sauvegarde soit disponible. Reportez-vous à l'exemple suivant : 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 kit SDK Python génèrent une erreur 404 NotAuthorizedOrNotFound même si l'opération réussit

Détails : le kit SDK OCI pour TypeScript et JavaScript présente un problème connu avec les grands nombres supérieurs à Number.MAX_SAFE_INTEGER de JavaScript. Tous les nombres supérieurs à Number.MAX_SAFE_INTEGER auront un problème d'arrondi.

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

Lien direct vers ce problème : Problème d'arrondi des données pour les grands nombres avec le kit SDK OCI pour TypeScript et JavaScript

Détails : lors de l'utilisation de la version 1.25.1 ou d'une version antérieure des clients de kit SDK Java OCI qui téléchargent des flux de données (par exemple, ObjectStorageClient ou FunctionsInvokeClient), de manière synchrone et asynchrone, et si vous utilisez RefreshableOnNotAuthenticatedProvider (par exemple, pour les principales de ressource ou les principaux d'instance), vous pourrez être concerné par une altération automatique des données.

Solution : mettez à jour le client du kit SDK Java OCI vers la version 1.25.2 ou ultérieure. Pour plus d'informations sur ce problème et les solutions de contournement, reportez-vous à Potentiel problème d'altération des données pour le kit SDK Java OCI lors du téléchargement de données binaires avec RefreshableOnNotAuthenticatedProvider.

Lien direct vers ce problème : Potentiel problème d'altération des données avec le kit SDK Java OCI lors du téléchargement de données binaires avec RefreshableOnNotAuthenticatedProvider

Détails : si vous utilisez les versions 3.2.1.1 ou antérieures des clients du connecteur HDFS OCI et si vous utilisez RefreshableOnNotAuthenticatedProvider (par exemple, InstancePrincipalsCustomAuthenticator, ou généralement pour les principales de ressource ou les principaux d'instance), vous êtes susceptible d'être concerné par unealtération silencieuse des données.

Solution de contournement : mettez à jour le client du connecteur HDFS OCI vers la version 3.2.1.3 ou ultérieure. Pour plus d'informations sur ce problème et les solutions de contournement, reportez-vous à Potentiel problème d'altération des données pour le connecteur HDFS OCI avec RefreshableOnNotAuthenticatedProvider.

Lien direct vers ce problème : Potentiel problème d'altération des données avec le connecteur OCI HDFS lors du téléchargement de données binaires avec RefreshableOnNotAuthenticatedProvider

Détails : lors de l'utilisation du kit SDK pour Python afin d'effectuer des opérations d'import de fichiers binaires, vous risquez de rencontrer un problème d'altération des données si des nouvelles tentatives sont activées ou si vous utilisez UploadManager.upload_file.

Solution de contournement : nous travaillons à une résolution. Pour plus d'informations sur ce problème et les solutions de contournement, reportez-vous à Problème d'altération potentielle des données pour les nouvelles tentatives du kit SDK Python lors du téléchargement des données binaires.

Lien direct vers ce problème : Altération potentielle des données avec le kit SDK pour Python lors du téléchargement de fichiers binaires

Mise à jour : la cause principale du problème de l'altération des données a été corrigée avec la version 2.54.0. Utilisez oci version 2.54.0 ou ultérieure pour éviter toute altération des données. Le comportement des anciennes versions du kit SDK OCI pour Python par rapport à ce problème a été expliqué ci-dessous.

Détails : les clients qui utilisent le kit SDK OCI pour Python et oci.object_storage.UploadManager.upload_stream en mode FIPS peuvent être vulnérables à l'altération automatique de données. Si les circonstances dans lesquelles le problème est généré sont réunies pour votre environnement, le kit SDK signale la réussite de l'opération de téléchargement, mais un objet de longueur nulle est téléchargé.

La résolution varie en fonction de l'état de votre environnement :

1. Utilisation de UploadManager.upload_stream() dans un environnement qui utilise une version OpenSSL conforme aux normes FIPS, dans laquelle le kit SDK pour Python ne fonctionne pas en mode FIPS, comme décrit dans la rubrique Utilisation de bibliothèques validées FIPS.

   Pour déterminer si vous relevez de ce scénario, procédez comme suit :

   • Vérifiez que vous utilisez une version d'OpenSSL conforme aux normes FIPS en exécutant la commande openssl version. Si "FIPS" fait partie du nom de la version et que vous n'exécutez pas le kit SDK en mode FIPS, vous relévez de ce scénario.

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

   Solution de contournement : mettez à niveau le kit SDK OCI pour Python vers la version 2.53.1 ou supérieure et utilisez le kit SDK pour Python en mode FIPS comme décrit dans Utilisation de bibliothèques validées FIPS.

   Important
   
   Si vous n'exécutez pas le kit SDK en mode FIPS alors que vous utilisez une version d'OpenSSL conforme aux normes FIPS, les données seront toujours altérées lors de l'utilisation de UploadManager.upload_stream().
2. Utilisation de UploadManager.upload_stream() lorsque le kit SDK pour Python est fonctionnant en mode FIPS comme décrit dans Utilisation de bibliothèques validées FIPS et que le kit SDK pour Python est version 2.53.0 ou inférieure.

   Si oci.fips.is_fips_mode() renvoie True, le kit SDK fonctionne en mode FIPS.

   Résolution : mettez à niveau le kit SDK OCI pour Python vers la version 2.53.1 ou ultérieure.

Afin d'obtenir plus d'informations sur ce problème, reportez-vous à Potentiel problème d'altération des données pour le téléchargement de flux multipart concernant le kit SDK OCI pour Python sur GitHub.

Lien direct vers ce problème : Potentiel problème d'altération des données avec le kit SDK pour Python et les flux de téléchargement

Pour connaître les problèmes connus relatifs à WebLogic Management, reportez-vous à Problèmes connus.