The message processors have a default connection timeout of 3 seconds. I want to configure a connection timeout only for my MessageLogging policy, like we can do for ServiceCallout policies.
https://cloud.google.com/apigee/docs/api-platform/reference/endpoint-properties-reference
connect.timeout.millis does not work with ML policy.
Another similar question, which is not answered https://www.googlecloudcommunity.com/gc/Apigee/Apigee-Configuring-connect-timeout-millis-in-MessageLogging/m-p/750627
@dchiesa1 please help
2 Likes
Hey @shashank11p ,
You’re absolutely right - MessageLogging doesn’t care about errors like connection timeouts or even more dangerous stuff like an invalid TLS certificate! Apigee Trace (Debug) will still show a successful execution, even if the policy fails to send logs. This can be misleading, making it look like everything is fine when it’s not.
But actually, this behaviour is mentioned in the Apigee documentation, which notes:
Proxy calls succeed when logging fails. Because message logging is first written to buffer, the API proxy will continue successful execution even if message logging ultimately fails (for example, if there’s a connection failure to the destination).
To get around this, consider using a ServiceCallout for logging. It provides more control and error handling options, so you’ll know if something goes wrong.
I’ve covered this issue and other critical aspects of Apigee security in my latest post. Check it out here for more insights and tips on safeguarding your proxies!
Let me know if you have any more questions!
1 Like
Hi @nmarkevich ,
The issue with the 3 second timeout is that on higher load, even our proxy calls are taking 3 seconds to respond.
I assume that might be because of resource constraints when some threads are occupied for 3 seconds during logging.
I do not want our proxy calls to take 3 seconds when there’s a connection issue with the syslog server.
Have you tried moving the MessageLogging policy to the PostClientFlow? This way, it will log after the response has been sent to the client, so any connection issues with the syslog server won’t impact the response time of your proxy calls.
Yes, even then the client gets the response from apigee after 3 seconds. At apigee, it will return in just a few ms, whether I use in PostClientFlow or a normal Proxy Flow, as we know that the message is first written to a buffer.
I believe the request is waiting in some queue to be picked up for processing due to resource constraints. (where the threads are busy waiting for timeout)
Why does MessageLogging not have such a configuration? I think it should have a configuration for updating the connection timeout. That way, we can limit the time these threads might be stuck waiting. Because eventually at high load, my API calls start to get affected.