Bekannte Probleme bei Entwicklertools

Details

Version 2.81.0 des OCI-Java-SDK ist nicht mit Java 8 kompatibel. Wenn Sie Version 2.81.0 mit Java 8 verwenden, wird möglicherweise zur Laufzeit die folgende Fehlermeldung angezeigt:

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

Weitere Informationen finden Sie im Problem unter GitHub.

Workaround

Dieses Problem wurde in Version 2.82.0 behoben, die Kompatibilität mit Java 8 wiederherstellt. Alle Versionen vor 2.81.0 sind auch mit Java 8 kompatibel.

Wenn Sie Java 8 verwenden, verwenden Sie nicht Version 2.81.0, sondern Version 2.82.0 oder höher.

Details

Wenn Sie die OCI-Java-SDK-Version 2.66.0 verwenden, kann der Speicherverbrauch beim Hochladen von Streams aufgrund einer unnötigen Pufferung des gesamten Streams im Speicher erhöht werden.

Workaround

Dieses Problem wurde in Version 2.72.0 und höher behoben. Wenn Sie die betroffene Version verwenden, führen Sie ein Upgrade auf Version 2.72.0 oder höher durch. Weitere Informationen und mögliche Problemlösungen finden Sie unter GitHub.

Details

Wenn Sie eine oder mehrere OCI-Java-SDK-Versionen von 3.31.0 bis 3.38.0 verwenden, wird ein Threadleck in IdleConnectionMonitor angezeigt. Eine Erhöhung der CPU- oder Speicherauslastung kann aufgrund der zunehmenden Anzahl von Threads vom Typ idle-connection-monitor-thread auftreten.

Workaround

Dieses Problem wurde in Version 3.39.0 und höher behoben. Wenn Sie eine der betroffenen früheren Versionen verwenden, empfehlen wir ein Upgrade auf Version 3.39.1 oder höher. Weitere Informationen und mögliche Problemlösungen finden Sie unter GitHub.

Details

Wenn Sie einen der synchronen OCI-Java-SDK-Clients verwenden, die Datenstreams hochladen (wie ObjectStorageClient oder DataSafeClient), und Sie RetryConfiguration nicht auf Anforderungsebene definieren, werden Ihre Anforderungen nicht automatisch in den Versionen 3.0.0 bis 3.31.0 wiederholt. Es besteht keine Chance auf stille Datenbeschädigung.

Workaround

Dieses Problem wurde in Version 3.31.1 und höher behoben. Wenn Sie eine der betroffenen früheren Versionen verwenden, empfehlen wir Ihnen ein Upgrade auf Version 3.31.1 oder höher. Weitere Informationen und mögliche Problemlösungen finden Sie unter GitHub.

Details

Nach dem Aktualisieren auf JDK-Versionen 8u381, 11.0.20, 17.0.8 oder 21.0.0 ist möglicherweise die folgende Fehlermeldung aufgetreten:

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

Dieses Problem tritt auf, weil die aufgeführten Java-Versionen eine maximale Standardgröße für Signaturdateien aufweisen, die kleiner ist als einige Java-SDK-JARs. Der niedrige Standardwert in Java wird in kommenden kleineren Java-Versionsreleases behoben und behoben.

Workaround #1

Um dieses Problem zu beheben, können Sie Maven mit dem folgenden Parameter ausführen:

-Djdk.jar.maxSignatureFileSize=16000000

Wenn Sie mit javac kompilieren, können Sie den folgenden Befehl verwenden:

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

Details

Wenn Sie ein OCI-Java-SDK von Version 2.47.0 bis zu Versionen vor 2.51.2 verwenden, kann in der CircuitBreaker ein Bug auftreten, der eine NoSuchElementException auslöst. Weitere Informationen finden Sie unter https://github.com/oracle/oci-java-sdk/issues/491

Workaround #1

Dieses Problem wurde in OCI Java SDK 2.51.2 behoben. Update auf OCI Java SDK-Version Version 2.51.2 oder neuer.

Workaround #2

Wenn Sie kein Update auf Version 2.51.2 oder höher vornehmen können, können Sie die Java-SDK-Standardunterstützung für Circuit Breaker deaktivieren und deaktivieren für Serviceclients, die SDK-Standard-Circ Breaker aktiviert haben.

Details

Wenn wiederholt neue Signaturgeber/Clientobjekte mit Instanz-Principals, Resource Principal und Delegationstokenauthentifizierung erstellt werden, werden einige zugrunde liegende Objekte nicht aus dem Speicher gelöscht, was zu einem Speicherleck führt. Nach unseren Tests beträgt die Speicherzuwachsrate ~ 10 MiB/Stunde, wenn nur Client/Signer-Objekte in einer Endlosschleife erstellt werden. Cloud Shell ist von demselben Problem betroffen, wenn neue Clientobjekte wiederholt mit dem Python-SDK erstellt werden. Dies scheint von einem zugrunde liegenden Speicherleck im Anforderungspaket zu stammen. Weitere Informationen finden Sie unter https://github.com/psf/requests/issues/4601.

Workaround #1

Vermeiden Sie die Erstellung neuer Signaturgeber-/Clientobjekte und die Wiederverwendung vorhandener Objekte, wenn möglich. Wenn Sie die Delegierungstokenauthentifizierung verwenden und den Wert des Delegierungstokens aktualisieren müssen, zeigt das folgende Beispiel, wie Sie einen vorhandenen Signaturgeber aktualisieren, anstatt einen neuen Signaturgeber zu erstellen:

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" 

Workaround #2

Verwenden Sie den raw request signer.

Details: Wenn Sie einen synchronen OCI-Java-SDK-Client verwenden, der Datenstreams hochlädt (z.B. ObjectStorageClient oder DataSafeClient), und Sie RetryConfiguration nicht auf Clientebene oder Anforderungsebene definieren, können Sie von einer unbemerkten Datenbeschädigung betroffen sein.

Workaround: Wir arbeiten aktiv an der Behebung dieses Problems. Weitere Informationen und mögliche Workarounds finden Sie auf GitHub.

Direkter Link zu diesem Problem: Potenzielles Datenbeschädigungsproblem im OCI-Java-SDK mit Binärdatenuploads mit Standardwiederholungen

Details: Wenn Sie Version 2.14.1 und höher des OCI-Java-SDK verwenden, tritt möglicherweise eine Verschlechterung der Performance auf, wenn Sie mit dem SDK API-Vorgänge für eine der OCI-Services aufrufen. Die Verschlechterung führt zu einer Erhöhung der Latenz um 30 bis 60 % bei SDK-Vorgängen für einen OCI-Service.

Problemumgehung: Weitere Informationen und mögliche Problemumgehungen finden Sie unter GitHub.

Direkter Link zu diesem Problem: Verschlechterung der Leistung in OCI-Java-SDK-Versionen 2.14.1 und höher bei allen API-Vorgängen

Details: Ab Version 2.0.0 unterstützt das OCI-SDK für Java die Verwendung von "Jersey ApacheConnectorProvider" anstelle des Jersey-Standards HttpUrlConnectorProvider, damit Apache HttpClient OCI-Serviceaufrufe durchführen kann.

Der ApacheConnectorProvider unterstützt standardmäßig die Verwendung des Expect-Headers für einige Object Storage-Servicevorgänge (siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). Es wurde beobachtet, dass dies eine Verschlechterung der Performance bei denselben Object Storage-Servicevorgängen bewirkte.

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

Direkter Link zu diesem Problem: Verschlechterung der Leistung mit dem Apache Connector-Provider in OCI SDK für Java

Details: In der Version 2.0.0 bis 2.13.0 der OCI-Java-SDK-API geben einige Vorgänge, die einen Datenstream zurückgeben, aber in der Antwort nicht den Content-Length-Header zurückgeben, möglicherweise abgeschnittene Daten. Dies wird dadurch verursacht, dass das SDK den Stream vorzeitig schließt, bevor alle Daten gelesen wurden.

Workaround: Aktualisieren Sie den OCI-Java-SDK-Client auf Version 2.13.1 oder höher. Weitere Informationen zu diesem Problem und zu Workarounds finden Sie unter https://github.com/oracle/oci-java-sdk/issues/357.

Direkter Link zu diesem Problem: Abgeschnittene Antwort bei Vorgängen, die Binärdaten mit dem OCI-Java-SDK zurückgeben

Details: Aufgrund von Problemen mit einer Abhängigkeit funktioniert das Go-SDK-Feature, mit dem Kunden neue Realms automatisch verwenden können, die dem SDK unter Umständen nicht bekannt sind, nicht in der 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

Workaround: Um dieses Problem zu beheben, aktivieren Sie die Auflösung von Regionen mit dem Instanzmetadatenservice für die Go-SDK. Weitere Informationen finden Sie unter Regionen hinzufügen.

Details: Bei Vorgängen, die mit den SDKs, Terraform, Ansible und der CLI an einigen OCI-Services durchgeführt wurden, kann die Latenz erhöht sein. Es wurde bestätigt, dass sich dieses Problem auf den OCI Streaming-Service und wahrscheinlich auch auf die Services Email Delivery, Health Checks, NoSQL Database Cloud, Registry, Generic Artifacts sowie Web Application Acceleration and Security auswirkt. Diese Liste ist nicht vollständig, und es ist möglich, dass Sie auch bei anderen OCI-Services auf dieses Problem stoßen. Es wurde bestätigt, dass das Problem sich NICHT auf die OCI-Services Object Storage und Functions auswirkt.

Die folgenden SDKs und Tools sind betroffen:

Workarounds und weitere Informationen: Wir arbeiten aktiv an der Behebung dieses Problems. Weitere Informationen und mögliche Workarounds finden Sie unter:

Direkter Link zu diesem Problem: Erhöhte Latenzprobleme in Vorgängen für einige OCI-Services mit SDKS und anderen Tools

Details: Die Compositevorgänge copy_boot_volume_backup_and_wait_for_state und copy_volume_backup_and_wait_for_state aus den Compositevorgängen BlockStorage Client lösen die Fehlermeldung 404/NotAuthorizedOrNotFound aus, wenn ein Backup aus einer Region in die andere kopiert werden soll. Weitere Informationen finden Sie unter: https://github.com/oracle/oci-python-sdk/issues/344.

Workaround: Anstatt die Composite-Vorgänge zu verwenden, verwenden Sie zwei verschiedene Clients für diesen Vorgang: einen Client in die Quellregion, der die Anforderung zum Kopieren des Backups von Region A in die Region B sendet, und einen zweiten Client in die Zielregion, die darauf wartet, das Backup verfügbar zu machen. Siehe Beispiel hier: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

Direkter Link zu diesem Problem: Python-SDK-Compositevorgänge lösen einen Fehler 404 NotAuthorizedOrNotFound aus, obwohl der Vorgang erfolgreich ist

Details: Das OCI-SDK für TypeScript und JavaScript gibt ein bekanntes Problem mit Zahlen an, die größer als Number.MAX_SAFE_INTEGER von JavaScript sind. Alle Zahlen, die größer sind als Number.MAX_SAFE_INTEGER führen zu einem Problem bei der Rundung.

Problemumgehung: Wir wissen um das Problem, bei dem eine API-Antwort eine Zahl zurücksendet, die größer als die Number.MAX_SAFE_INTERGER von JavaScript ist. Derzeit hat das Problem der Zahlenrundung keine Auswirkung auf den Aufruf von APIs.

Direkter Link zu diesem Problem: Potenzielles Problem bei der Rundung großer Zahlen mit OCI SDK für TypeScript und JavaScript

Details: Wenn Sie Version 1.25.1 oder älter der OCI-Java-SDK-Clients nutzen, die Datenströme entweder synchron und asynchron hochladen (z.B. ObjectStorageClient oder FunctionsInvokeClient), und Sie einen RefreshableOnNotAuthenticatedProvider verwenden (z.B. für Ressourcen-Principals oder Instanz-Principals), kann es zu unbemerkten Datenbeschädigungen kommen.

Workaround: Aktualisieren Sie den OCI-Java-SDK-Client auf Version 1.25.2 oder höher. Weitere Informationen zu diesem Problem sowie Workarounds finden Sie unter Potenzielles Datenbeschädigungsproblem für OCI-Java-SDK bei Binärdatenuploads mit RefreshableOnNotAuthenticatedProvider.

Direkter Link zu diesem Problem: Potenzielles Problem einer Datenbeschädigung mit OCI Java SDK beim Hochladen von Binärdaten mit RefreshableOnNotAuthenticatedProvider

Details: Wenn Sie Version 3.2.1.1 oder älter der OCI HDFS-Connector-Clients verwenden und eine RefreshableOnNotAuthenticatedProvider (z.B. InstancePrincipalsCustomAuthenticator oder allgemein für Ressourcen-Principals oder Instanz-Principals) verwenden, können Sie von einer unbemerkten Datenbeschädigung betroffen sein.

Workaround: Aktualisieren Sie den OCI HDFS-Connector-Client auf Version 3.2.1.3 oder höher. Weitere Informationen zu diesem Problem und Workarounds finden Sie unter Potenzielles Datenbeschädigungsproblem für OCI-HDFS-Connector mit RefreshableOnNotAuthenticatedProvider.

Direkter Link zu diesem Problem: Potenzielles Datenbeschädigungsproblem mit OCI HDFS-Connector beim Hochladen von Binärdaten mit RefreshableOnNotAuthenticatedProvider

Details: Wenn Sie mit dem SDK für Python Binärdaten hochladen, kann ein Problem mit Datenbeschädigung auftreten, wenn Wiederholungen aktiviert sind oder wenn Sie UploadManager.upload_file verwenden.

Workaround: Wir arbeiten an einer Lösung. Weitere Informationen zu diesem Problem sowie Workarounds finden Sie unter Potenzielles Datenbeschädigungsproblem bei Wiederholungen von Binärdatenuploads mit Python-SDK.

Direkter Link zu diesem Problem: Potenzielle Datenbeschädigung mit SDK für Python bei Binärdatenuploads

Aktualisierung: Die Ursache des Problems, das eine Datenbeschädigung verursacht, wurde mit dem Release v2.54.0 behoben. Verwenden Sie OCI 2.54.0 oder höher, um Datenbeschädigung zu vermeiden. Das Verhalten älterer Versionen des OCI-Python-SDK in Bezug auf dieses Problem wird weiter unten erläutert.

Details: Für Kunden, die das OCI-SDK für Python und oci.object_storage.UploadManager.upload_stream im FIPS-Modus verwenden, ist möglicherweise ein Risiko unbemerkte Datenbeschädigungen. Wenn die Umstände, unter denen das Problem entsteht, für Ihre Umgebung zutreffen, meldet das SDK einen erfolgreichen Uploadvorgang, aber ein Objekt mit einer Länge von 0 wird hochgeladen.

Die Lösung unterscheidet sich je nach Status Ihrer Umgebung:

1. Verwendung von UploadManager.upload_stream() in einer Umgebung, in welcher eine FIPS-konforme OpenSSL-Version verwendet wird, in welcher das SDK für Python nicht im FIPS-Modus ausgeführt werden, wie in FIPS-validierte Librarys verwenden beschrieben.

   So ermitteln Sie, ob dieses Szenario für Sie zutrifft:

   • Prüfen Sie, ob Sie eine FIPS-konforme OpenSSL-Version verwenden, indem Sie den Befehl openssl version ausführen. Wenn "FIPS" Teil des Versionsnamens ist und Sie nicht das SDK im FIPS-Modus betreiben, trifft dieses Szenario zu.

   • Wenn oci.fips.is_fips_mode() nicht "True" zurückgibt, wird das SDK nicht im FIPS-Modus verwendet.

   Workaround: Upgraden Sie das OCI-SDK für Python auf Version 2.53.1 oder höher, und betreiben Sie das SDK für Python im FIPS-Modus, wie in FIPS-validierte Librarys verwenden beschrieben.

   Wichtig
   
   Wenn Sie das SDK nicht im FIPS-Modus ausführen, aber eine FIPS-konforme OpenSSL-Version verwenden, führt dies weiterhin zu einer Datenbeschädigung bei Verwendung von UploadManager.upload_stream().
2. Verwenden Sie die UploadManager.upload_stream(), wenn das SDK für Python im FIPS-Modus ausgeführt werden, wie unter FIPS-validierte Librarys verwenden und das SDK für Python v2.53.0 oder niedriger ist.

   Wenn oci.fips.is_fips_mode() "True" zurückgibt, wird das SDK im FIPS-Modus ausgeführt.

   Lösung: Aktualisieren Sie das OCI-SDK für Python auf Version 2.53.1 oder höher.

Weitere Informationen zu diesem Problem finden Sie unter Potenzieller Datenbeschädigung bei Multipart-Streamupload für OCI-Python-SDK auf GitHub.

Direkter Link zu diesem Problem: Potenzielle Datenbeschädigung mit SDK für Python und Uploadstreams

Bekannte Probleme mit der Verwaltung von WebLogic finden Sie unter Bekannte Probleme.