Cloudhub 2.0 Ingress Timeout when forwarding Logs

Question

We have a mule application and we are trying to load test the application with 8K records. It's a simple application that gets the request, sends its to GCP to fetch a value and then provide that value as a response.

Everything was working fine, since then we have introduced socket appenders in our log4j file to forward all the logs to Alloy off Grafana. When we performed a re-test with the log4j changes, we saw a lot of timeouts in our ingress.

2025年09月16日T10:27:05.120Z ERROR EdgeEgress [EdgeRuntime] [event: 1454f89b-2e87-49f5-8b81-f91ecd4f6014]: HTTP_Client(1000089dab).EdgeReqtor(10000e4844): Can't get response for request(ingress=<<url>>, method=PUT, uri=<<endpoint>>) from upstream application( <<host>>.<<uuid>>.svc.cluster.local:8081) within receive timeout(300 seconds), will close connection

Plus the transaction was completed as we see the end logger in our logs but soon after that an error is also printed which is of MULE:SOURCE_RESPONSE_SEND with description as Client connection was closed.

Here is the log4j that we have configured.

<?xml version="1.0" encoding="utf-8"?>
<Configuration>
 <!--These are some of the loggers you can enable. There are several more
 you can find in the documentation. Besides this log4j configuration, you
 can also use Java VM environment variables to enable other logs like network
 (-Djavax.net.debug=ssl or all) and Garbage Collector (-XX:+PrintGC). These
 will be append to the console, so you will see them in the mule_ee.log file. -->
 <Properties>
 <Property name="alloyHost">${sys:alloy.host}</Property>
 <Property name="alloyUrl">${alloyHost}.<<host-redacted>></Property>
 </Properties>
 <Appenders>
 <RollingFile name="file"
 fileName="${sys:mule.home}${sys:file.separator}logs${sys:file.separator}${artifactId}.log"
 filePattern="${sys:mule.home}${sys:file.separator}logs${sys:file.separator}${artifactId}-%i.log">
 <PatternLayout pattern="%-5p %d [%t] [%MDC] %c: %m%n" />
 <SizeBasedTriggeringPolicy size="10 MB" />
 <DefaultRolloverStrategy max="10" />
 </RollingFile>
 <Console name="console" target="SYSTEM_OUT">
 <PatternLayout pattern="%-5p %d [%t] [%MDC] %c: %m%n" />
 </Console>
 <Socket name="alloySocket" host="${alloyUrl}" port="7070" protocol="TCP">
 <JsonLayout compact="true" eventEol="true" properties="true"/>
 </Socket>
 </Appenders>
 <Loggers>
 <AsyncLogger name="org.mule.service.http" level="WARN" />
 <AsyncLogger name="org.mule.extension.http" level="WARN" />
 <!-- Mule logger -->
 <AsyncLogger
 name="org.mule.runtime.core.internal.processor.LoggerMessageProcessor"
 level="INFO" />
 <AsyncRoot level="INFO">
 <AppenderRef ref="alloySocket" />
 <AppenderRef ref="file" />
 <AppenderRef ref="console" />
 </AsyncRoot>
 </Loggers>
</Configuration>

We have changed the log4j to forward logs using a socket appender to Grafana using Alloy.

• aled: There is not enough information to help. The error MULE:SOURCE_RESPONSE_SEND has details that you haven't shared. Is <<host>>.<<uuid>> related to the logger socket or something else? What is the application doing? Can you create a minimal reproducible example? Probably a full thread dump analysis is required. Try starting there.
• Hrithik Naha: The application calls GCP and fetches a value based off the payload. <<host>> contains the application name <<uuid>> contains the pod's id. Either of them is related to the Kubernetes pod that is used in Ch2.0. I can get you the thread dump, getting the complete error message would be difficult as the application can't be tested locally.
• aled: You should find if there is a relationship between the errors and the change in log4j2. The errors are in application operations that are not directly related to logging. Maybe the socket appender is introducing delays or causing resources issues that impact the application. If the application was working previous to this change shows that it doesn't seem to be a programming issue but networking, infrastructure, or whatever is receiving the logs. This question is probably not a good match for Stack Overflow. See stackoverflow.com/help/on-topic for details on which questions are appropriate.