This section lists the known issues that have been identified for Developer Tools and
SDKs.
Increased memory consumption when uploading streams in OCI Java SDK version
2.66.0
Details
If you are using OCI Java SDK version 2.66.0, then you could see increased memory consumption when
uploading streams due to unnecessary buffering of the entire stream in memory.
Workaround
This issue has been fixed in version 2.72.0 and later. If you are using the impacted version,
upgrade to version 2.72.0 or later. For more information and other possible workarounds,
see the issue on GitHub.
Thread leak in IdleConnectionMonitor in OCI Java SDK versions 3.31.0 to
3.38.0 🔗
Details
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.
Workaround
This issue has been fixed in version 3.39.0 and later. If you are using any of the
impacted earlier versions, we recommend upgrading to version 3.39.1 or later. For more
information and other possible workarounds, see the issue on GitHub.
Retries for operations that upload binary data without request-level retries fail in OCI
Java SDK versions 3.0.0 to 3.31.0 🔗
Details
If you are using any of the OCI Java SDK synchronous clients that upload streams of data
(such as ObjectStorageClient or DataSafeClient) and you
do not define the RetryConfiguration at request level, your requests will not be
automatically retried in versions 3.0.0 to 3.31.0. There is no chance of silent data
corruption.
Workaround
This problem is fixed in version 3.31.1 and later. If you are using any of the impacted
earlier versions, we recommend that you upgrade to version 3.31.1 or later. For more
information and other possible workarounds, see the issue on GitHub.
Errors while using the Java SDK after updating to JDK versions 8u381, 11.0.20, 17.0.8,
or 21.0.0 🔗
Details
The following error message might be encountered after updating to JDK versions 8u381,
11.0.20, 17.0.8, or 21.0.0
:
This issue occurs because the listed Java versions have a default maximum signature
file size smaller than some Java SDK JARs. The low default value in Java will be
addressed and resolved in upcoming minor Java version releases.
Workaround #1
To resolve this problem, you can run Maven with the following
parameter:
-Djdk.jar.maxSignatureFileSize=16000000
If you're compiling with javac, you can use the following
command:
Java SDK race condition in CircuitBreaker leading to NoSuchElementException in OCI Java
SDK 🔗
Details
If you are using an OCI Java SDK from version 2.47.0 to versions prior to 2.51.2, you
may encounter a bug in the CircuitBreaker that raises a NoSuchElementException. For more
information, see https://github.com/oracle/oci-java-sdk/issues/491
Workaround #1
This issue was resolved in OCI Java SDK 2.51.2. Update to OCI Java SDK version version 2.51.2 or newer.
Python SDK potential memory leak issue when repeatedly creating new
signers/clients 🔗
Details
When repeatedly creating new signers/client objects with Instance Principals, Resource
Principal, and Delegation token authentication, some underlying objects are not cleared from
memory, causing a memory leak. From our tests, the rate of memory growth is ~10 MiB/hour when
only client/signer objects are created in an infinite loop. Cloud Shell is affected by the
same issue when new client objects are created repeatedly using the Python SDK. This seems to
be coming from an underlying memory leak in the requests package. For more information, see
https://github.com/psf/requests/issues/4601.
Workaround #1
Avoid creating new signer/client objects, and reuse existing objects if possible. If you
are using delegation token authentication, and need to update the value of the delegation
token, the following example shows how to update an existing signer instead of creating a
new
signer:
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"
Potential data corruption issue in OCI Java SDK with binary data upload using default
retries 🔗
Details: If you are using any of the OCI Java SDK synchronous clients that upload
streams of data (for example ObjectStorageClient or DataSafeClient) and you do not
define the RetryConfiguration at the client level or request level, you may be affected by silent
data corruption.
Workaround: We are actively working on fixing this issue. For more information
and possible workarounds, see the issue on GitHub.
Performance regression in OCI Java SDK versions 2.14.1 and later for all API
operations 🔗
Details: If you're using versions 2.14.1 and later of the OCI Java SDK, you may
encounter performance regressions when using the SDK to call API operations on any of
the OCI services. The regression causes a 30% to 60% increase in latency in SDK
operations on any of the OCI services.
Performance regression with the Apache Connector Provider in OCI SDK for Java 🔗
Details: Starting with version 2.0.0, the OCI SDK for Java supports using the
Jersey ApacheConnectorProvider instead of the Jersey default
HttpUrlConnectorProvider to allow the Apache HttpClient to make OCI
service calls.
The ApacheConnectorProvider supports the use of Expect
header by default for some Object Storage service operations (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100). This has been observed to cause performance regression in the
same Object Storage service operations.
Workaround:You can disable the use of the Expect header by
switching back to Jersey Default Connector (see https://docs.oracle.com/iaas/Content/API/SDKDocs/javasdkconfig.htm), or if
you're already using the ApacheConnectorProvider, you can disable the
Expect header with the ApacheConnectorProvider by
doing the following when initializing the client
:
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);
Truncated response for operations that return binary data with the OCI Java SDK 🔗
Details: In versions 2.0.0 to 2.13.0 of the OCI Java SDK API, some operations that
return a stream of data but don't return the content-length header in the response might
return truncated data. This is caused by the SDK prematurely closing the stream before
reading all the data.
Go SDK cannot automatically find some regions while running in Cloud Shell 🔗
Details: Due to some issues with one of its dependencies, the Go SDK feature which
allows customers to automatically use new realms which might be unknown to the SDK is
not functioning from within Cloud Shell.
Attempting to run code in Cloud Shell that uses this feature will result in the following
error
message:
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: To resolve this issue, enable resolving regions using the instance
metadata service for Go SDK. For more information, see: Adding Regions
Increased latency issues in operations for some OCI services using the SDKS and other
tools 🔗
Details: You may encounter an increase in latency for operations made to some OCI
services using the SDKs, Terraform, Ansible, and the CLI. This issue has been confirmed
to impact the OCI Streaming service, and likely impacts the Email Delivery, Health
Checks, NoSQL Database Cloud, Registry, Generic Artifacts, and Web Application
Acceleration and Security services as well. This list is not comprehensive, and it is
possible you may encounter the issue against other OCI services as well. The issue has
been confirmed to NOT affect the OCI Object Storage and Functions services.
The following SDKs and tools are impacted:
Go SDK (version 41.2.0 and later)
.NET SDK (version 14.2.0 and later)
Java SDK (version 2.0.0 and later)
Python SDK (version 2.38.4 and later)
CLI (version 2.25.0 and later)
PowerShell Modules (version 9.2.0 and later)
Ansible Modules (version 2.23.0 and later)
Terraform Provider (version 4.30.0 and
later)
Workarounds and more information: We are actively working on fixing this issue.
For more information and possible workarounds, please see the following:
Python SDK composite operations throw a 404 NotAuthorizedOrNotFound error even though
operation is a success 🔗
Details: The copy_boot_volume_backup_and_wait_for_state and
copy_volume_backup_and_wait_for_state from the BlockStorage Client Composite operations
throw a 404/NotAuthorizedOrNotFound when copying a backup from one region to another.
For more information see: https://github.com/oracle/oci-python-sdk/issues/344.
Workaround: Instead of using the composite operations, use two different clients
for this operation; one client in the Source Region to send the request for copying the
backup from Region A to Region B, and a second client in Destination region to wait for
the backup to become available. See example here: https://github.com/oracle/oci-python-sdk/blob/master/examples/copy_volume_backup_example.py
Potential data rounding issue for big numbers with OCI SDK for TypeScript and
JavaScript 🔗
Details: The OCI SDK for TypeScript and JavaScript have a known issue with big
numbers greater than JavaScript's Number.MAX_SAFE_INTEGER. Any Numbers greater than
Number.MAX_SAFE_INTEGER will result in rounding issue.
Workaround: We are aware of the issue where an API response may send back a number
greater than JavaScript's Number.MAX_SAFE_INTERGER. At the moment the number rounding
issue is not an impact to calling any APIs.
Potential data corruption issue with OCI Java SDK on binary data upload with
RefreshableOnNotAuthenticatedProvider 🔗
Details: When using version 1.25.1 or earlier of the OCI Java SDK clients that
upload streams of data (for example ObjectStorageClient or
FunctionsInvokeClient), either synchronously and asynchronously,
and you use a RefreshableOnNotAuthenticatedProvider (for example, for
Resource Principals or Instance Principals) you may be affected by silent data
corruption.
Potential data corruption issue with OCI HDFS Connector on binary data upload with
RefreshableOnNotAuthenticatedProvider 🔗
Details: If you are using version 3.2.1.1 or earlier of the OCI HDFS Connector
clients and you use a RefreshableOnNotAuthenticatedProvider (e.g.
InstancePrincipalsCustomAuthenticator, or generally for Resource Principals or Instance
Principals) you may be affected by silent data corruption.
Potential data corruption with SDK for Python on binary upload 🔗
Details: When using the SDK for Python to perform binary upload operations you may encounter an issue with data corruption if retries are enabled or if you are using UploadManager.upload_file.
Potential data corruption issue with SDK for Python and upload streams 🔗
Update: The root cause of the issue causing data corruption has been fixed with
the release of v2.54.0. Please use oci v2.54.0 or above to avoid data corruption. The
behavior of older versions of the OCI Python SDK regarding this issue has been explained
below.
Details: Customers using the OCI SDK for Python and
oci.object_storage.UploadManager.upload_stream in FIPS mode might
be vulnerable to silent data corruption. If the circumstances to produce the issue are
true for your environment, the SDK reports success for the upload operation, but a
0-length object is uploaded.
The resolution differs depending on the state of your environment:
Using UploadManager.upload_stream() in an environment which uses a
FIPS-compliant OpenSSL version where the SDK for Python is not operating in
FIPS mode as described in Using FIPS validated libraries.
To
determine if you fall under this scenario:
Verify that you are using a FIPS-compliant OpenSSL version by running the command openssl version . If "fips" is part of the version name, and you are not operating the SDK in FIPS mode, then you would fall under this scenario.
If oci.fips.is_fips_mode() does not return True, then
the SDK is not operating in FIPS mode.
Workaround: Upgrade the OCI SDK for Python to version 2.53.1 or
greater and operate the SDK for Python in FIPS mode as described in Using FIPS validated libraries.
Important
Not operating the SDK in FIPS mode while using a
FIPS-compliant OpenSSL version will still result in data corruption while
using UploadManager.upload_stream().
Using UploadManager.upload_stream() when the SDK for Python
is operating in FIPS mode as described in Using FIPS validated librariesand the SDK for Python is v2.53.0 or lower.
If
oci.fips.is_fips_mode() returns True, then the SDK is
operating in FIPS mode.
Resolution: Upgrade the OCI SDK for Python
to version 2.53.1 or greater.