While it does not appear to be the root of the issue reported, the bug report has revealed a possible room for improvement in the relationship between the real server and the relay server with regards to the inactivity_probe configuration.
The inactivity_probe is normally adjusted on the backend server to avoid situations where the backend server is too busy to service the inactivity probe in a timely manner and as a consequence erroneously drops the connection.
Having the inactivity_probe configuration out of sync between the real server and the relay could possibly lead to more of these situations, and it would increase complexity of configuration if we leave it to the human operator to keep these things in sync. Perhaps we should teach the backend server and relay to communicate this setting between each other?
While it does not appear to be the root of the issue reported, the bug report has revealed a possible room for improvement in the relationship between the real server and the relay server with regards to the inactivity_probe configuration.
The inactivity_probe is normally adjusted on the backend server to avoid situations where the backend server is too busy to service the inactivity probe in a timely manner and as a consequence erroneously drops the connection.
Having the inactivity_probe configuration out of sync between the real server and the relay could possibly lead to more of these situations, and it would increase complexity of configuration if we leave it to the human operator to keep these things in sync. Perhaps we should teach the backend server and relay to communicate this setting between each other?