Release Notes for Content Gateway 5.3

New Features

With Swarm Storage 9.6 and the new direct POST method of replication available when defining replication feeds, Content Gateway now supports replication to a remote target cluster. Note: use of SCSP Proxy is no longer required to implement remote replication. (CLOUD-2618)

See Managing Feeds.

This release also includes these improvements:

  • Gateway has S3 protocol enhancements to track 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)

Upgrade Impacts

  • 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 "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)



© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.