Hello,
I found the logs like below in my App Engine service A:
…The connection observed an error, the request cannot be retried as the headers/body were sent\nio.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer
Service A is an application implemented with spring boot, and I expected it to be a netty connector-related problem.
To check why the log is occurring, the test was performed by configuring the environment below:
Service A is the same source code, but the environment running was tested differently. As a result of several tests, the ‘Connection reset by peer’ log occurred 610 or 620 seconds after the last LB domain call only in TEST CASE A.
I searched references and I can confirmed that the issue is resolved if I use a provider that specifies the value of the maxIdleTime, evictInBackground options when I create a HttpClient or WebClient object. But I did not understand why the ‘Connection reset’ logs only occurs with the service deployed in the App Engine environment. If Service A’s logic is implemented in python, TEST CASE A, B, C, and D all operate normally without the occurrence of “Connetion reset” logs.
Test code is simple like below:
import reactor.netty.http.client.HttpClient;
...
HttpClient client = HttpClient.create();
return client.get()
.uri("https://lb.bespinlab.kr/api/main/ext?from=demo-provider-none")
.responseContent()
.aggregate()
.asString()
.block();
The “lb.bespinlab.kr” is attached domain to LB static IP.
The “/api/main/ext” API is serving in the App Engine service B.
I understand that the timeout of the HTTPS Load Balancer of GCP is 600 seconds and this cannot be changed. Therefore, I understand that the client that calls LB should set the timeout. But, I think it is strange that the same source works normally when deployed in a local or Cloud Run environment, and only occurs when deployed in an App Engine environment. I looked for any limits related to the connection to the App Engine environment, but I could not find any docs reference.
Of course, the problem can be solved by setting up the provider with options. But to avoid similar phenomena from occurring, is there any idea or approach to find the cause?
any suggestion?
