W-20072447-response-timeot

cloudhub-2/modules/ROOT/pages/ch2-limits.adoc

@@ -17,6 +17,15 @@ HTTP header length (`maxHeaderLength`):: 32K
 Maximum HTTP request size:: 1 GB
 
 Maximum HTTP request timeout:: 300 seconds
++
+This timeout applies to the time it takes for a client to send request data to the CloudHub 2.0 ingress load balancer (Edge). This value is not configurable and applies to both shared spaces and private spaces.
++
+If the client takes longer than 300 seconds to send the complete request (for example, when uploading large files), the connection is dropped. To handle large data transfers that exceed this limit, break up the request into smaller chunks or implement asynchronous processing.
++
+[NOTE]
+====
+Private spaces allow you to configure a separate read response timeout (the time Edge waits for the Mule application to send response data) up to 3600 seconds. For more information, see xref:ps-config-advanced.adoc#configure-http-requests-and-read-response-timeout[Configure HTTP Requests and Read-Response Timeout].
+====
 
 Maximum ingress URI size:: 4 KB
 

cloudhub-2/modules/ROOT/pages/ch2-networking-guide.adoc

@@ -52,9 +52,14 @@ The following example shows a Mule application configuration that exposes an HTT
 
 === Load Balancer Connections
 
-For each request a client makes through the CloudHub 2.0 load balancer `(<app>.<space-id>.<region>.cloudhub.io)`, the load balancer maintains two connections: one connection between the client and the load balancer, and another connection between the load balancer and the application. For each connection, the load balancer manages a default idle timeout of 300 seconds that is triggered when no data is sent over either connection. If no data is sent or received during this duration, the load balancer closes both connections.
+For each request a client makes through the CloudHub 2.0 load balancer `(<app>.<space-id>.<region>.cloudhub.io)`, the load balancer maintains two connections: one connection between the client and the load balancer (Edge), and another connection between the load balancer and the Mule application. For each connection, the load balancer manages a default idle timeout of 300 seconds that is triggered when no data is sent over either connection. If no data is sent or received during this duration, the load balancer closes both connections.
 
-For connections that take longer than 300 seconds to process from either side, handle the processing asynchronously. You can customize the idle timeout value in the *Advanced* tab of your xref:ps-config-advanced.adoc#configure-http-requests-and-read-response-timeout[private space settings] in Runtime Manager, or via the Mule application xref:mule-runtime::global-settings-configuration.adoc[global configurations] of the xref:mule-runtime::about-mule-configuration.adoc[Mule configuration file].
+CloudHub 2.0 also enforces separate timeouts for request and response data transfer:
+
+* *Read Request Timeout* (300 seconds, not configurable): The time Edge waits for the client to send the complete request data. This timeout applies to both shared spaces and private spaces. If the client takes longer than 300 seconds to send the request (for example, when uploading large files), the connection is dropped.
+* *Read Response Timeout* (300 seconds by default, configurable up to 3600 seconds in private spaces): The time Edge waits for the Mule application to send response data. If your Mule application requires more than 300 seconds to process a request and send the response, you can customize this value in the *Advanced* tab of your xref:ps-config-advanced.adoc#configure-http-requests-and-read-response-timeout[private space settings] in Runtime Manager, or via the Mule application xref:mule-runtime::global-settings-configuration.adoc[global configurations] of the xref:mule-runtime::about-mule-configuration.adoc[Mule configuration file].
+
+For long-running data transfers that take longer than 300 seconds to upload from the client to Edge, consider breaking up the request into smaller chunks or implementing asynchronous processing. For more information about timeout limits, see xref:ch2-limits.adoc[].
 
 == DNS Records
 

cloudhub-2/modules/ROOT/pages/ps-config-advanced.adoc

@@ -5,9 +5,9 @@ Use options on the *Advanced* tab to:
 * Configure how the ingress load balancer handles HTTP requests.
 * Specify the read-response timeout.
 +
-This value is the amount of time CloudHub 2.0 waits for a response from the Mule application.
-// If no data is sent or received in the specified time, CloudHub 2.0 closes the client and private space connections.
-If no data is sent or received in the specified time, CloudHub 2.0 drops the request with a 504 error.
+This value is the amount of time the CloudHub 2.0 ingress load balancer (Edge) waits for the Mule application to send response data back to Edge. If the Mule application does not send response data within the specified time, CloudHub 2.0 drops the request with a 504 error.
++
+This timeout applies to the Mule application processing time and sending the response, not to the time it takes for the client to send the request to Edge. For information about request timeouts, see xref:ch2-limits.adoc[].
 * Configure ingress load balancer logs levels and download logs.
 * Configure Amazon Web Services (AWS) service roles.
 
@@ -39,13 +39,19 @@ Silently drops HTTP requests.
 --
 . Specify the read response timeout value.
 +
-The default timeout is 300 seconds.
+The default timeout is 300 seconds. You can configure this value up to 3600 seconds (1 hour).
++
+This timeout controls how long Edge waits for the Mule application to send response data. If your Mule application requires more than 300 seconds to process a request before sending the response, increase this value accordingly.
 +
 . Click *Save Changes* or *Discard Changes*.
 
 [NOTE]
+====
 The maximum request size is 1 GB.
 
+If you are uploading large files (such as CSV files) that take longer than 300 seconds to transfer from the client to Edge, you might encounter a timeout even if you increase the read response timeout. This is because the read request timeout (the time Edge waits for the client to send the request) is hardcoded to 300 seconds and cannot be configured. For long-running data transfers, consider breaking up the request into smaller chunks or implementing asynchronous processing. For more information, see xref:ch2-limits.adoc[].
+===="
+
 [[configure-ingress-load-balancer-log-levels]]
 == Configure Default Ingress Load Balancer Log Levels