Known Issues for Developer Tools

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.

Details

The following error message might be encountered after updating to JDK versions 8u381, 11.0.20, 17.0.8, or 21.0.0 :

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

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:

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

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.

Workaround #2

If you cannot update to version 2.51.2 or newer, you can disable and opt out of the Java SDK default support for circuit breakers for service clients that have enabled default SDK circuit breakers.

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" 

Workaround #2

Use the raw request signer.

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.

Direct link to this issue: Potential data corruption issue in OCI Java SDK with binary data upload using default retries

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.

Workaround: For more information and possible workarounds, see the issue on GitHub.

Direct link to this issue: Performance regression in OCI Java SDK versions 2.14.1 and later for all API operations

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.

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

Direct link to this issue: Performance regression with the Apache Connector Provider in OCI SDK for Java

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.

Workaround:Update the OCI Java SDK client to version 2.13.1 or later. For more information about this issue and workarounds, see https://github.com/oracle/oci-java-sdk/issues/357

Direct link to this issue: Truncated response for operations that return binary data with the OCI Java SDK

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.

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

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:

Workarounds and more information: We are actively working on fixing this issue. For more information and possible workarounds, please see the following:

Direct link to this issue: Increased latency issues in operations for some OCI services using the SDKS and other tools

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

Direct link to this issue: Python SDK composite operations throw a 404 NotAuthorizedOrNotFound error even though operation is a success

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.

Direct link to this issue: Potential data rounding issue for big numbers with OCI SDK for TypeScript and JavaScript

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.

Workaround: Update the OCI Java SDK client to version 1.25.2 or later. For more information about this issue and workarounds, see Potential data corruption issue for OCI Java SDK on binary data upload with RefreshableOnNotAuthenticatedProvider.

Direct link to this issue: Potential data corruption issue with OCI Java SDK 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.

Workaround: Update the OCI HDFS Connector client to version 3.2.1.3 or later. For more information about this issue and workarounds, see Potential data corruption issue for OCI HDFS Connector with RefreshableOnNotAuthenticatedProvider.

Direct link to this issue: Potential data corruption issue with OCI HDFS Connector on binary data upload with RefreshableOnNotAuthenticatedProvider

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.

Workaround: We're working on a resolution. For more information about this issue and workarounds, see Potential data corruption issue for PythonSDK retry on binary data upload.

Direct link to this issue: Potential data corruption with SDK for Python on binary upload

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:

1. 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().
2. Using UploadManager.upload_stream() when the SDK for Python is operating in FIPS mode as described in Using FIPS validated libraries and 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.

For more information about this issue, see Potential data corruption issue for multipart stream upload for OCI Python SDK on GitHub.

Direct link to this issue: Potential data corruption issue with SDK for Python and upload streams