開発ツールの既知の問題

詳細

If you are using any OCI Java SDK version(s) from 3.31.0 to 3.38.0 then you could see a thread leak in IdleConnectionMonitor. An increase in CPU or memory usage might occur due to the proliferation of threads of type idle-connection-monitor-thread.

回避方法

この問題はバージョン3.39.0以降で修正されました。影響を受ける以前のバージョンを使用している場合は、バージョン3.39.1以降にアップグレードすることをお薦めします。詳細およびその他の考えられる回避策については、GitHubの問題を参照してください。

詳細

データのストリームをアップロードするOCI Java SDK同期クライアント(ObjectStorageClientやDataSafeClientなど)のいずれかを使用していて、RetryConfigurationをリクエスト・レベルで定義しない場合、リクエストはバージョン3.0.0から3.31.0で自動的に再試行されません。サイレント・データ破損の可能性はありません。

回避策

この問題はバージョン3.31.1以降で修正されています。影響を受ける以前のバージョンを使用している場合は、バージョン3.31.1以上にアップグレードすることをお薦めします。詳細およびその他の考えられる回避策については、GitHubの問題を参照してください。

詳細

JDKバージョン8u381、11.0.20、17.0.8または21.0.0への更新後に、次のエラー・メッセージが表示される場合があります。

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

この問題は、リストされているJavaバージョンのデフォルトの署名ファイル・サイズが一部のJava SDK JARよりも小さいために発生します。Javaの低デフォルト値は、今後のマイナーJavaバージョン・リリースで対処および解決されます。

回避策#1

この問題を解決するには、次のパラメータを使用してMavenを実行します。

-Djdk.jar.maxSignatureFileSize=16000000

javacを使用してコンパイルする場合は、次のコマンドを使用できます。

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

詳細

バージョン2.47.0から2.51.2より前のバージョンまでOCI Java SDKを使用している場合は、CircuitBreakerにNoSuchElementExceptionが発生する可能性があります。詳細は、https://github.com/oracle/oci-java-sdk/issues/491を参照してください

回避策#1

この問題はOCI Java SDK 2.51.2で解決されました。OCI Java SDKバージョンバージョン2.51.2またはより新しいに更新します。

回避策#2

バージョン2.51.2以降に更新できない場合は、デフォルトのSDKサーキット・ブレーカが有効になっているサービス・クライアントについて、Java SDKのサーキット・ブレーカのデフォルト・サポートを無効化およびオプトアウトできます。

詳細

Instance Principals、リソース・プリンシパルおよび委任トークン認証を使用して新しい署名者/クライアント・オブジェクトを繰り返し作成すると、基礎となるオブジェクトの一部がメモリーからクリアされないため、メモリー・リークが発生します。このテストでは、無限ループでクライアント/シグナ・オブジェクトのみが作成される場合、メモリー増加率は10MiB/時です。Cloud Shellは、Python SDKを使用して新しいクライアント・オブジェクトが繰り返し作成されるときと同じ問題の影響を受けます。これは、requestsパッケージ内の基礎となるメモリーリークから発生しているようです。詳細は、https://github.com/psf/requests/issues/4601を参照してください。

回避策#1

新しい署名者/クライアント・オブジェクトを作成することは避け、可能な場合は既存のオブジェクトを再利用してください。委任トークン認証を使用していて、委任トークンの値を更新する必要がある場合、次の例では、新しい署名者を作成するのではなく、既存の署名者を更新する方法を示します。

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" 

回避策#2

rawリクエスト署名者を使用します。

詳細: データのストリームをアップロードするOCI Java SDK同期クライアント(ObjectStorageClientやDataSafeClientなど)のいずれかを使用していて、クライアント・レベルでもリクエスト・レベルでもRetryConfigurationを定義していない場合、サイレント・データ破損の影響を受ける可能性があります。

回避策: この問題の修正に積極的に取り組んでいます。詳細および考えられる回避策については、GitHubで問題を参照してください。

この問題への直接リンク: デフォルトの再試行を使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータ破損の問題

詳細: OCI Java SDKのバージョン2.14.1以降を使用している場合は、SDKを使用して任意のOCIサービスでAPI操作をコールするときにパフォーマンスの低下が発生する可能性があります。この低下により、任意のOCIサービスでSDK操作におけるレイテンシが30%から60%増加します。

回避方法:詳細および考えられる回避策については、GitHubの問題を参照してください。

この問題への直接リンク: すべてのAPI操作におけるOCI Java SDKバージョン2.14.1以降でのパフォーマンス低下

詳細: バージョン2.0.0以降、OCI SDK for Javaでは、Apache HttpClientがOCIサービス・コールを行うことができるように、JerseyのデフォルトHttpUrlConnectorProviderではなくJersey ApacheConnectorProviderの使用をサポートしています。

ApacheConnectorProviderでは、一部のオブジェクト・ストレージ・サービス操作に対してデフォルトでExpectヘッダーを使用することがサポートされています(https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100を参照)。これによって、同じオブジェクト・ストレージ・サービス操作でパフォーマンスの低下が発生することが観測されています。

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

この問題への直接リンク: OCI SDK for JavaのApache Connector Providerでのパフォーマンスの低下

詳細: OCI Java SDK APIのバージョン2.0.0から2.13.0では、レスポンスでデータのストリームは返すがコンテンツ長ヘッダーは返さない一部の操作が、切り捨てられたデータを返す場合があります。これは、SDKがすべてのデータを読み取る前にストリームを途中で閉じることが原因です。

回避策: OCI Java SDKクライアントをバージョン2.13.1以降に更新します。この問題および回避策の詳細は、https://github.com/oracle/oci-java-sdk/issues/357を参照してください

この問題への直接リンク: OCI Java SDKでバイナリ・データを返す操作のレスポンスが切り捨てられる

詳細: 依存関係の1つに問題があるため、SDKに認識されない可能性のある新しいレルムを顧客が自動的に使用できるようにするGo SDK機能が、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

回避策: この問題を解決するには、Go SDKのインスタンス・メタデータ・サービスを使用したリージョンの解決を有効にします。詳細は、リージョンの追加を参照してください。

詳細: SDK、Terraform、AnsibleおよびCLIを使用して一部のOCIサービスに対して行う操作で、レイテンシが増加する場合があります。この問題はOCIストリーミング・サービスに影響を及ぼすことが確認されており、また、電子メール配信、ヘルス・チェック、NoSQL Database Cloud、レジストリ、汎用アーティファクト、Webアプリケーション・アクセラレーションおよびセキュリティのサービスにも影響を及ぼす可能性があります。このリストがすべてを網羅しているわけではなく、他のOCIサービスでも問題が発生する可能性があります。この問題はOCIのオブジェクト・ストレージ・サービスおよびファンクション・サービスには影響を及ぼさないことが確認されています。

次のSDKおよびツールは影響を受けます:

回避策と詳細情報: この問題の修正に積極的に取り組んでいます。詳細および考えられる回避策については、次を参照してください:

この問題への直接リンク: SDKSや他のツールを使用した一部のOCIサービスの操作でレイテンシが増加する問題

詳細: BlockStorageクライアント・コンポジット操作からのcopy_boot_volume_backup_and_wait_for_stateおよびcopy_volume_backup_and_wait_for_stateは、あるリージョンから別のリージョンにバックアップをコピーするときに404/NotAuthorizedOrNotFoundをスローします。詳細は、https://github.com/oracle/oci-python-sdk/issues/344を参照してください。

回避策: コンポジット操作を使用するかわりに、この操作には2つの異なるクライアントを使用します。つまり、ソース・リージョンの一方のクライアントがリージョンAからリージョンBへのバックアップのコピーのリクエストを送信し、宛先リージョンの2番目のクライアントはバックアップが使用可能になるまで待機します。次の例を参照してください: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py

この問題への直接リンク: Python SDKコンポジット操作で、操作が成功した場合でも404 NotAuthorizedOrNotFoundエラーがスローされる

詳細: OCI SDK for TypeScriptおよびJavaScriptでは、JavaScriptのNumber.MAX_SAFE_INTEGERを超える大きな数に関連する既知の問題があります。Number.MAX_SAFE_INTEGERを超える数値があると、丸めの問題が発生します。

回避策: APIレスポンスでJavaScriptのNumber.MAX_SAFE_INTERGERを超える数が返される問題があることを認識しています。現時点では、数値丸めの問題がAPIのコールに影響を与えることはありません。

この問題への直接リンク: OCI SDK for TypeScriptとJavaScriptでの大きな数値に関するデータ丸めの問題

詳細: データのストリームを同期的または非同期的にアップロードするバージョン1.25.1またはそれ以前のOCI Java SDKクライアント(ObjectStorageClientやFunctionsInvokeClientなど)を使用している場合、(リソース・プリンシパルやインスタンス・プリンシパルなどに対して) RefreshableOnNotAuthenticatedProviderを使用すると、サイレント・データ破損が発生する可能性があります。

回避策: OCI Java SDKクライアントをバージョン1.25.2以降に更新します。この問題および回避策の詳細は、RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータ破損の問題を参照してください。

この問題への直接リンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータ破損の問題

詳細: バージョン3.2.1.1またはそれ以前のOCI HDFSコネクタ・クライアントを使用しており、RefreshableOnNotAuthenticatedProvider (例: InstancePrincipalsCustomAuthenticator、または一般にリソース・プリンシパルまたはインスタンス・プリンシパルに対して)を使用している場合は、サイレント・データ破損が発生する可能性があります。

回避策: OCI HDFSコネクタ・クライアントをバージョン3.2.1.3以降に更新します。この問題および回避策の詳細は、RefreshableOnNotAuthenticatedProviderを使用したOCI HDFSコネクタに関する潜在的なデータ破損の問題を参照してください。

この問題への直接リンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI HDFSコネクタに関する潜在的なデータ破損の問題

詳細: 再試行が有効になっているか、UploadManager.upload_fileを使用している場合、SDK for Pythonを使用してバイナリ・アップロード操作を実行する際にデータの破損の問題が発生することがあります。

回避策: 解決に向けて取り組んでいます。この問題および回避策の詳細は、バイナリ・データのアップロードでのPythonSDKの再試行に関する潜在的なデータ破損の問題を参照してください。

この問題への直接リンク: バイナリ・アップロードでのSDK for Pythonによる潜在的なデータ破損

更新: データ破損の原因となっていた問題の根本原因は、v2.54.0のリリースで修正されました。データの破損を回避するには、oci v2.54.0以上を使用してください。この問題に関するOCI Python SDKの古いバージョンの動作について、次に説明しています。

詳細: 顧客がFIPSモードでOCI SDK for Pythonおよびoci.object_storage.UploadManager.upload_streamを使用している場合、サイレント・データ破損が発生しやすくなる可能性があります。問題を生成する状況が環境に存在する場合、SDKによってアップロード操作の成功が報告されますが、長さ0のオブジェクトがアップロードされます。

解決方法は、環境の状態によって異なります:

1. FIPS準拠のOpenSSLバージョンを使用している環境で、SDK for PythonがFIPSモードで動作していない場合(FIPS検証済ライブラリの使用を参照)に、UploadManager.upload_stream()を使用する。

   このシナリオに該当するかどうかを判断するには:

   • コマンドopenssl versionを実行して、FIPS準拠のOpenSSLバージョンを使用していることを確認します。バージョン名に"fips"が含まれ、SDKをFIPSモードで操作していない場合は、このシナリオに該当します。

   • oci.fips.is_fips_mode()がTrueを返さない場合、SDKはFIPSモードで動作していません。

   回避策: OCI SDK for Pythonをバージョン2.53.1以上にアップグレードし、SDK for PythonをFIPSモードで操作します(FIPS検証済ライブラリの使用)。

   重要
   
   FIPS準拠のOpenSSLバージョンを使用しているのにSDKをFIPSモードで操作していない場合も、UploadManager.upload_stream()の使用中にデータが破損します。
2. SDK for PythonがFIPSモードで動作していて(FIPS検証済ライブラリの使用を参照)、かつSDK for Pythonがv2.53.0以下の場合に、UploadManager.upload_stream()を使用する。

   oci.fips.is_fips_mode()がTrueを返す場合、SDKはFIPSモードで動作しています。

   解決策: OCI SDK for Pythonをバージョン2.53.1以上にアップグレードします。

この問題の詳細は、GitHubのOCI Python SDKのマルチパート・ストリーム・アップロードに関する潜在的なデータ破損の問題を参照してください。

この問題への直接リンク: SDK for Pythonおよびアップロード・ストリームでの潜在的なデータ破損の問題