開発者ツールの既知の問題
この項では、開発者ツールおよびSDKで識別された既知の問題を示します。
OCI Java SDKバージョン2.81.0はJava 8と互換性がありません
- 詳細
-
OCI Java SDKのバージョン2.81.0は、Java 8と互換性がありません。Java 8でバージョン2.81.0を使用している場合、実行時に次のエラー・メッセージが表示されることがあります。
java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer;
詳細は、GitHubで問題を参照してください。
- 回避方法
-
この問題は、Java 8との互換性をリストアするバージョン2.82.0で修正されています。2.81.0 より前のバージョンはすべて、Java 8とも互換性があります。
Java 8を使用している場合は、バージョン2.81.0を使用せず、かわりにバージョン2.82.0以降を使用してください。
OCI Java SDKバージョン2.66.0でストリームをアップロードする際のメモリー消費の増加 🔗
- 詳細
-
OCI Java SDKバージョン2.66.0を使用している場合、メモリー内のストリーム全体の不要なバッファリングが原因で、ストリームのアップロード時にメモリー消費量が増加する可能性があります。
- 回避方法
-
この問題は、バージョン2.72.0以降で修正されています。影響を受けるバージョンを使用している場合は、バージョン2.72.0以降にアップグレードします。詳細および考えられる回避策については、GitHubで問題を参照してください。
OCI Java SDKバージョン3.31.0から3.38.0のIdleConnectionMonitorのスレッド・リーク 🔗
- 詳細
- 3.31.0 から3.38.0までのOCI Java SDKバージョンを使用している場合は、
IdleConnectionMonitor
にスレッド・リークが表示されます。idle-connection-monitor-thread
型のスレッドが急増したため、CPUまたはメモリー使用率が増加する可能性があります。
- 回避方法
-
この問題はバージョン3.39.0以降で修正されています。影響を受ける以前のバージョンのいずれかを使用している場合は、バージョン3.39.1以降にアップグレードすることをお薦めします。詳細および考えられる回避策については、GitHubで問題を参照してください。
OCI Java SDKバージョン3.0.0から3.31.0では、リクエスト・レベルの再試行なしでバイナリ・データをアップロードする操作の再試行が失敗します 🔗
- 詳細
- データ・ストリーム(
ObjectStorageClient
やDataSafeClient
など)をアップロードするOCI Java SDK同期クライアントのいずれかを使用していて、リクエスト・レベルで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 SDKの使用中にエラーが発生しました 🔗
- 詳細
-
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
CircuitBreakerのJava SDK競合条件で、OCI Java SDKでNoSuchElementExceptionが発生 🔗
- 詳細
- バージョン2.47.0からバージョン2.51.2より前のOCI Java SDKを使用している場合、NoSuchElementExceptionを発生させるCircuitBreakerにバグが発生する可能性があります。詳細については、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の回路遮断器のデフォルト・サポートを無効にしてオプトアウトできます。
新しい署名者/クライアントを繰り返し作成する場合のPython SDK潜在的なメモリー・リークの問題 🔗
- 詳細
- Instance Principals、Resource PrincipalおよびDelegationトークン認証を使用して新しい署名者/クライアント・オブジェクトを繰り返し作成する場合、基礎となるオブジェクトの一部がメモリーからクリアされないため、メモリー・リークが発生します。テストでは、クライアント/シグナ・オブジェクトのみが無限ループで作成されるとき、メモリーの増加率は最大10MiB/時間です。クラウド・シェルは、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に関する潜在的なデータ破損の問題 🔗
詳細:データ・ストリームをアップロードするOCI Java SDK同期クライアント(ObjectStorageClientやDataSafeClientなど)のいずれかを使用していて、クライアント・レベルでもリクエスト・レベルでもRetryConfigurationを定義していない場合、サイレント・データ破損の影響を受ける可能性があります。
回避方法:この問題の修正に積極的に取り組んでいます。詳細および考えられる回避策については、GitHubで問題を参照してください。
この問題への直接リンク: デフォルトの再試行を使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータ破損の問題
すべてのAPI操作におけるOCI Java SDKバージョン2.14.1以降でのパフォーマンス低下 🔗
詳細: OCI Java SDKのバージョン2.14.1以降を使用している場合は、SDKを使用して任意のOCIサービスでAPI操作をコールするときにパフォーマンスの低下が発生する可能性があります。この低下により、任意のOCIサービスでSDK操作におけるレイテンシが30%から60%増加します。
回避策:詳細および考えられる回避策については、GitHubで問題を参照してください。
この問題への直接リンク: すべてのAPI操作におけるOCI Java SDKバージョン2.14.1以降におけるパフォーマンス低下
OCI SDK for JavaのApache Connector Providerでのパフォーマンスの低下 🔗
詳細:バージョン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を参照)。これによって、同じオブジェクト・ストレージ・サービス操作でパフォーマンスの低下が発生することが観測されています。
Expect
ヘッダーの使用を無効にできます(https://docs.oracle.com/iaas/Content/API/SDKDocs/javasdkconfig.htmを参照)。あるいは、ApacheConnectorProvider
をすでに使用している場合は、クライアントの初期化時に次を実行して、ApacheConnectorProvider
でExpect
ヘッダーを無効にすることもできます: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でバイナリ・データを返す操作のレスポンスが切り捨てられる 🔗
詳細: 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でバイナリ・データを返す操作のレスポンスを切り捨てられる
Cloud Shellで実行中のGo 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のインスタンス・メタデータ・サービスを使用したリージョン解決を有効にします。詳細は、リージョンの追加を参照してください。
SDKSや他のツールを使用した一部のOCIサービスの操作でレイテンシが増加する問題 🔗
詳細: SDK、Terraform、AnsibleおよびCLIを使用して一部のOCIサービスに対して行われた操作のレイテンシが増加する場合があります。この問題はOCIストリーミング・サービスに影響を及ぼすことが確認されており、また、電子メール配信、ヘルス・チェック、NoSQL Database Cloud、レジストリ、汎用アーティファクト、Webアプリケーション・アクセラレーションおよびセキュリティのサービスにも影響を及ぼす可能性があります。このリストがすべてを網羅しているわけではなく、他のOCIサービスでも問題が発生する可能性があります。この問題はOCIのオブジェクト・ストレージ・サービスおよびファンクション・サービスには影響を及ぼさないことが確認されています。
次のSDKおよびツールは影響を受けます:
- Go SDK (バージョン41.2.0以降)
- .NET SDK (バージョン14.2.0以降)
- Java SDK (バージョン2.0.0以降)
- Python SDK (バージョン2.38.4以降)
- CLI (バージョン2.25.0以降)
- PowerShellモジュール(バージョン9.2.0以降)
- Ansibleモジュール(バージョン2.23.0以降)
- Terraformプロバイダ(バージョン4.30.0以降)
回避策と詳細情報: この問題の修正に積極的に取り組んでいます。詳細および考えられる回避策については、次を参照してください:
この問題への直接リンク: SDKSや他のツールを使用した一部のOCIサービスの操作でレイテンシが増加する問題
Python SDKコンポジット操作で、操作が成功の場合でも404 NotAuthorizedOrNotFoundエラーがスローされる 🔗
詳細: 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での大きな数値についてデータ丸めの問題 🔗
詳細: 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での大きな数値についてデータ丸めの問題
RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータの破損の問題 🔗
詳細: データのストリームをアップロードするOCI Java SDKクライアント(ObjectStorageClient
やFunctionsInvokeClient
など)のバージョン1.25.1以前を使用する場合、同期的にも非同期的にも、RefreshableOnNotAuthenticatedProvider
(リソース・プリンシパルやInstance Principalsなど)を使用すると、サイレント・データ破損の影響を受ける可能性があります。
回避方法: OCI Java SDKクライアントをバージョン1.25.2以降に更新します。この問題および回避策の詳細は、RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードでのOCI Java SDKに関する潜在的なデータ破損の問題を参照してください。
この問題への直接リンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データのアップロードにおけるOCI Java SDKに関する潜在的なデータの破損の問題
RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI HDFS Connectorに関する潜在的なデータ破損の問題 🔗
詳細: OCI HDFS Connectorクライアントのバージョン3.2.1.1以前を使用しており、RefreshableOnNotAuthenticatedProvider (InstancePrincipalsCustomAuthenticatorなど、または通常はリソース・プリンシパルまたはInstance Principals用)を使用している場合、サイレント・データ破損の影響を受ける可能性があります。
回避策: OCI HDFS Connectorクライアントをバージョン3.2.1.3以降に更新します。この問題および回避策の詳細は、RefreshableOnNotAuthenticatedProviderを使用したOCI HDFSコネクタに関する潜在的なデータ破損の問題を参照してください。
この問題への直接リンク: RefreshableOnNotAuthenticatedProviderを使用したバイナリ・データ・アップロードでのOCI HDFS Connectorでの潜在的なデータ破損の問題
バイナリ・アップロードでのSDK for Pythonによる潜在的なデータ破損 🔗
詳細: 再試行が有効になっているか、SDK for Pythonを使用している場合、再試行が有効になっているか、UploadManager.upload_file
を使用してバイナリ・アップロード操作を実行する際にデータの破損の問題が発生することがあります。
回避方法: 解決に向けて取り組んでいます。この問題および回避策の詳細は、バイナリ・データのアップロードでのPythonSDKの再試行に関する潜在的なデータ破損の問題を参照してください。
この問題への直接リンク: バイナリ・アップロードでのSDK for Pythonによる潜在的なデータ破損
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のオブジェクトがアップロードされます。
解決方法は、環境の状態によって異なります:
- FIPS準拠のOpenSSLバージョンを使用している環境で、SDK for PythonがFIPモードで動作しない場合(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()
の使用中にデータが破損します。 -
- 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およびアップロード・ストリームでの潜在的なデータ破損の問題
WebLogic管理 🔗
WebLogic管理に関する既知の問題は、既知の問題を参照してください。