--- schema_version: "1" id: c96244946e8580e4d2f015b7185d640f5e7446d9163556302c6aa59987c9470a title: Configuring Advanced Private Space Settings collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/cloudhub-2/ps-config-advanced.md canonical_url: https://docs.mulesoft.com/cloudhub-2/ps-config-advanced source_site: docs.mulesoft.com content_type: documentation content_hash: d3652aae310ed101c402ac506c03fe592484ab6c68887cb841a43a5cd8943c27 description: MuleSoft Documentation Site latest: true --- --- product: CloudHub 2.0 --- # Configuring Advanced Private Space Settings > For the full documentation index, see: https://docs.mulesoft.com/llms.txt 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 the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after forwarding the request. If your application takes longer than the configured time to process the request and start sending the response, CloudHub 2.0 drops the connection with a 504 error. > [!IMPORTANT] This timeout setting is separate from the read-request timeout, which controls how > long the CloudHub 2.0 ingress controller waits to receive the full request from the client. The > read-request timeout is hardcoded to 300 seconds and isn’t configurable. If your client takes > longer than 300 seconds to send the complete request, for example, when uploading large files, > CloudHub 2.0 drops the connection even if you configure a longer read-response timeout. > > For data transfers that exceed 300 seconds, consider breaking the request into smaller chunks or > implementing asynchronous processing patterns. - Configure ingress load balancer logs levels and download logs. - Configure Amazon Web Services (AWS) service roles. ## Configure HTTP Requests and Read-Response Timeout When you modify HTTP requests, applications may not be reachable for up to 5 seconds. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Configure how the private accepts inbound traffic: CloudHub 2.0 doesn’t allow you to accept only insecure HTTP requests. From the **HTTP Requests** list, select one of the following: - **Redirect to HTTPS** Redirects HTTP requests to the same URL using the HTTPS protocol. - **Accept HTTP** Accepts the inbound request on the default SSL endpoint using the HTTP protocol. - **Drop HTTP** Silently drops HTTP requests. 5. Specify the read response timeout value. The default read-response timeout is 300 seconds. You can configure this value up to 3600 seconds (1 hour). 6. Click **Save Changes** or **Discard Changes**. > [!NOTE] The maximum request size is 1 GB. ## Understanding Timeout Behavior CloudHub 2.0 uses multiple timeout settings to manage different phases of request handling: Read Request Timeout (hardcoded at 300 seconds) The time the CloudHub 2.0 ingress controller waits to receive the complete request from the client. If the client takes longer than 300 seconds to send the entire request payload (for example, uploading a large CSV file), CloudHub 2.0 drops the connection. This timeout is not user-configurable and applies to both shared and private spaces. Read Response Timeout (user-configurable) The time the CloudHub 2.0 ingress controller waits to receive a response from your Mule application after the request has been forwarded. Configure this timeout in the **Advanced** tab of your private space settings. This setting controls how long your Mule application takes to process the request and begin sending a response. Connection Idle Timeout (hardcoded at 15 seconds) The time the CloudHub 2.0 ingress controller waits before closing an idle connection when no data is being transferred. For long-running operations that exceed these timeout limits, consider implementing one of the following approaches: - Break large requests into smaller chunks - Use asynchronous processing patterns where the client receives an immediate acknowledgment and polls for results - Implement keep-alive mechanisms to prevent idle timeout during processing ## Configure Default Ingress Load Balancer Log Levels CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for all apps deployed to the private space. > [!IMPORTANT] More verbose log levels affect performance. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Select the default [log level](#ingress-load-balancer-log-levels) from the drop-down list. 5. Click **Save Changes** or **Discard Changes**. ## Configure Custom Ingress Load Balancer Log Levels CloudHub 2.0 enables you to specify the default severity level of messages that are written to the log file for specific IP addresses, for example, for troubleshooting. > [!IMPORTANT] More verbose log levels affect performance. 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Configure custom log levels: 1. Enter the IP address and select the [log level](#ingress-load-balancer-log-levels) from the drop-down list. 2. Click **Add IP Address** to enter additional custom log levels. 3. To remove a custom log level, click the trash can icon (**Delete**) for the entry. 5. Click **Save Changes** or **Discard changes**. ## Ingress Load Balancer Log Levels The default log level for IP address filtering is `DEBUG`.
Table 1. Ingress Load Balancer Log Levels
LevelDescription

Error (Recommended)

Only error messages, such as when an exception occurs

Debug

Debugging messages

Trace

Tracks application metadata such as path, headers, state, and timeline between Ingress and APIs to facilitate collaboration

Info

Informative messages

### Download Ingress Load Balancer Logs To download ingress load balancer logs: 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Click **Download Logs**. ## Configure AWS Service Role If you have identity and access management (IAM) roles configured in AWS, associate the role with your private space. The private space receives the permissions from the IAM role in AWS and accesses AWS resources. To configure this feature in AWS: - Use the unique AWS IAM role name that Anypoint Platform generates. - Use the organization ID for the organization in which the private space was configured. - Allow outbound traffic on port 443 to use this feature. For more information, see [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html). 1. From Anypoint Platform, select **Runtime Manager** > **Private Spaces**. 2. Click the name of the private space to manage. 3. Click the **Advanced** tab. 4. Click **Enable AWS Service Role**. 5. Click **Save Changes** or **Discard changes**. A unique service role name is generated. Use this role to configure identity and access management for AWS. Role generation takes a few minutes. If the role name doesn’t appear, refresh the page. > [!NOTE] Each private space supports only one AWS service role. ### IAM Roles and AWS S3 Connector: STS Endpoint Behavior When you enable the AWS service role for a private space, the cluster injects environment variables such as `AWS_STS_REGIONAL_ENDPOINTS=regional`. The AWS SDK credential provider that this setup uses ignores custom STS endpoint settings in your Mule application and always uses the public regional STS endpoint, such as `sts.{region}.amazonaws.com`. > [!IMPORTANT] If your private-space firewall doesn’t allow outbound traffic to that STS endpoint, > connectivity tests for the AWS S3 Connector and other AWS SDK-based connectors fail, and > applications stop responding. Allow outbound HTTPS on port 443 to the regional STS endpoint for > the region where your private space runs. Configure this outbound access in > [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules). > > Don’t use application-level egress rules for the STS domain. Those rules don’t support this > endpoint and can cause intermittent connection failures. See > [ps-config-app-level-egress.adoc#limitations](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress#limitations). If you can’t open outbound access to the public regional STS endpoint, set the AWS\_ENDPOINT\_URL environment variable for your application to the STS endpoint URL so that the SDK uses that URL instead. To apply this workaround: 1. In Runtime Manager, open your application, and then go to **Settings** > **Properties**. 2. Add an application property or environment variable that sets `AWS_ENDPOINT_URL` to your STS endpoint URL, for example `[https://sts.{region}.amazonaws.com](https://sts.{region}.amazonaws.com)` or your custom endpoint. 3. To have the runtime use the new value, apply the changes, and then redeploy or restart the application. For more information about setting environment variables, see [Example: Using Properties to Set Environment Variables](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props#example-using-properties-to-set-environment-variables). ## See Also - [Configuring Firewall Rules to Manage Traffic to and from a Private Space](https://docs.mulesoft.com/cloudhub-2/ps-config-fw-rules) - [Configuring Application-Level Egress Rules](https://docs.mulesoft.com/cloudhub-2/ps-config-app-level-egress) - [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) in the AWS documentation