Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Replaced 'CAStor Error' with 'Swarm Storage Error'
Table of Contents
maxLevel2

...

  • Gateway has S3 protocol enhancements to track with Amazon S3 changes.

  • Gateway has more support for Swarm Platform Server and third-party clients.

  • Gateway has better handling for requests to domains that are marked as belonging to an unknown tenant. These requests are handled as if they are from the "System Tenant" and troubleshooting guidance is recorded in the application logs. (CLOUD-2714)

...

  • Swarm Storage Requirements — Gateway 5.3 requires a minimum back-end storage cluster version of 9.5.3 and a recommended version of 9.6. The storage cluster must be upgraded prior to installing this version of Gateway.

    • Releases of Gateway 5.1.3 and earlier are not compatible with Storage versions 9.2 or higher. For historic compatibility details, refer to the releases included with those distributions.

  • RHEL/CentOS 6 Deprecation — Support for RHEL/CentOS 6 is removed in the near future. Customers are encouraged to complete the transition to RHEL/CentOS 7 to guarantee a smooth upgrade path to future Gateway versions.

  • Automatic service start must be re-enabled — The service may not automatically start after a system reboot after the upgrade. Run the following to re-enable the service:
    "chkconfig --add cloudgateway" for RHEL/CentOS 6, or
    "systemctl enable cloudgateway" for RHEL/CentOS 7. (CLOUD-2819)

  • ExpanDrive — ExpanDrive users must upgrade to ExpanDrive 6.1.0 with this version of Gateway; earlier versions report 403 Signature errors when creating a folder or uploading a large object. (CLOUD-2746)

Additional Changes

  • Fixed: DEBUG logs in Gateway 5.3.2 are missing some logging related to auth and multipart handling. (5.3.3: CLOUD-3004)

  • Fixed: During S3 multipart "complete" operations, whitespace ticks (meant to keep the connection alive) are not being sent, which causes some clients and load balancers to time out for the large number of parts. (5.3.3: CLOUD-3000)

  • Fixed: During S3 multipart "complete" operations, an error condition can cause future uploads to report "java.lang.IllegalStateException: Timer already cancelled", although the object usually did complete in Swarm. (5.3.3: CLOUD-2985)

  • Fixed: S3 multipart listings returned the incorrect error "part-number-marker must be an integer between 0 and 10000". (5.3.3: CLOUD-2971)

  • Fixed: The cloudgateway_server.log had invalid SCSP warnings reporting 'Failed requests will not be retried' and 'Failed querying cluster for name and version'. (5.3.3: CLOUD-2663)

  • Fixed: Long S3 multipart "complete" requests can lead to failed client retries. (5.3.2: CLOUD-2736)

  • Fixed: S3 multipart listings returned the incorrect error "part-number-marker must be an integer between 0 and 10000". (5.3.1: CLOUD-2937)

  • Fixed: 405 errors occurred with CatDV and the Java AWS SDK TransferManager. (CLOUD-2921)

  • Fixed: Cyberduck operations like "Edit with" and uploads that "Overwrite?" can fail with a 400 "CAStor Swarm Storage Error" / "Content-MD5 did not match" because Content-MD5 was included in GET/HEAD responses, which caused problems with specific clients that failed to strip it from subsequent writes. (CLOUD-2914)

  • Fixed: Multipart/form-data MIME POST uploads that spanned several days of sustained load can result in an OutOfMemoryError. (CLOUD-2732)

  • Fixed: Buckets did not always inherit versioning status correctly. (CLOUD-2577)

  • Fixed: The Date header was missing from the responses for S3 Upload Part operations. (CLOUD-2570)

...