"Orphan" files in /tmp/haproxy when Site xxx does not exist increasing memory consumption

[luiz-neto-umbler]

Hello team, we have some servers running the haproxytech/haproxy-alpine Docker image version 3.0.1 (we also tested with version 3.0.2 with Data Plane API version 2.9.4) and we noticed that the memory consumption of the servers was only increasing, with the same number of registered sites, when analyzing the container we noticed that there were several "orphan" transactions in /tmp/haproxy that are created when we remove a site that does not exist ({"code":404,"message":"missing object: Site TestServer does not exists"}), after deleting these "orphaned" files from the container and restarting, memory consumption dropped drastically.

As a test, we created a new container and ran the API creating 1000 new sites with the example command below:

curl -X POST -u ubadmin:123456 -H "Content-Type: application/json" -d '{"farms":[{"balance":{"algorithm":"roundrobin"},"mode":"tcp","name":"TestServer","servers":[{"address":"192.168.100.1","name":"TestServer","port":45397,"check":"disabled"}],"use_as":"default"}],"name":"TestServer","service":{"listeners":[{"address":"*","name":"TestServer","port":45397}],"mode":"tcp"}}' "http://127.0.0.1:5555/v2/services/haproxy/sites?version=1"

Then we delete the site and no "orphan" file is created in /tmp/haproxy:

curl -X DELETE -u ubadmin:123456 -H "Content-Type: application/json" "http://127.0.0.1:5555/v2/services/haproxy/sites/TestServer?version=2"

But if we run the same command above, the error message that the Site does not exist is returned, the "orphan" transaction file is created in /tmp/haproxy and memory consumption increases:

curl -X DELETE -u ubadmin:123456 -H "Content-Type: application/json" "http://127.0.0.1:5555/v2/services/haproxy/sites/TestServer?version=3"
{"code":404,"message":"missing object: Site TestServer does not exist"}

With each execution of the above command on a non-existent site, the container's memory consumption increases by approximately 40MB.

Thanks in advance.

[mjuraga]

Thank you for the report, we are looking to deprecate Sites API as it's not proved to be really useful. Do you find it useful for your use-case? If we find enough votes for it maybe we can keep it.

[luiz-neto-umbler]

Thank you for the report, we are looking to deprecate Sites API as it's not proved to be really useful. Do you find it useful for your use-case? If we find enough votes for it maybe we can keep it.

Hi @mjuraga, thanks for your response!
Yes, this feature is useful for our use case, as we avoid editing the sites configuration files via sed or awk for example, without this API we sometimes had problems with 2 processes editing the files at the same time, which generated duplicate entries or inconsistencies in the configuration files.

[mjuraga]

You could use frontend and backend resources for the changes you need under one transaction instead of using site resource.