Univention Bugzilla – Bug 56422
Configurable processing timeouts
Last modified: 2023-08-28 13:34:54 CEST
A partner maintaining a customer environment with about 60k users is asking if possible to make the timeout-time for processing between REST service and client configurable. This is the issue they are currently running into as described by them: With the amount of users we have a processing time of about 5 minutes to query all users. So we run into an asyncio.exceptions.TimeoutError, although the REST API returns the response correctly (at least according to the log). Is there any way to increase the processing timeouts in the UDM REST client? Namely, we run into a timeout every now and then due to the amount of data (details attached). According to my analysis, the timeout can't really be adjusted anywhere. Right now it looks like the API is just about ready "in time", but then client-side processing is still taking place.... "You should" ideally be able to configure both, I think. 12:28:13 ERROR edubsimport.tasks.base Task read_data.ucs.read_persons failed after 0:05:00.476676; details: Traceback (most recent call last): File "/src/edubsimport/tasks/base.py", line 151, in async_wait_and_run await self._async_run_processor(config) File "/src/edubsimport/tasks/base.py", line 337, in _async_run_processor return await asyncio.ensure_future(processor()) File "/src/edubsimport/tasks/read_data/ucs/read_persons.py", line 28, in read_persons async for user in users_user.search("uid=*"): File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/udm_rest_client/base_http.py", line 1133, in search api_model_objs, _, _ = await self.session.call_openapi( File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/udm_rest_client/base_http.py", line 432, in call_openapi api_model_obj, status, header = await meth(**kwargs) File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/openapi_client_udm/api_client.py", line 185, in __call_api response_data = await self.request( File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/openapi_client_udm/rest.py", line 182, in GET return (await self.request("GET", url, File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/openapi_client_udm/rest.py", line 166, in request r = await self.pool_manager.request(**args) File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/aiohttp/client.py", line 560, in _request await resp.start(conn) File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 914, in start self._continue = None File "/root/.cache/pypoetry/virtualenvs/edubs-ucs5-import-VsnhxLU2-py3.9/lib/python3.9/site-packages/aiohttp/helpers.py", line 721, in __exit__ raise asyncio.TimeoutError from None asyncio.exceptions.TimeoutError In the meantime the following was suggested to the partner to address the current behaviour: Regarding the timeout for the client. This is not very well documented, but when you instantiate the UDM class (your client main object), you can pass any kwargs that you want: https://github.com/univention/python-udm-rest-api-client/blame/0cad0c545200907d11eaa1d0171bc8d4d1893981/udm_rest_client/udm.py#L104 All kwargs not consumed by the init function itself, are passed on to the init function of the Session, which in turn passes it to the openapi configuration. As there is not any documentation on what is accepted there, something like timeout=5 in seconds would be worth a try.
This is a general problem that cannot be fixed on the client side. The more objects exist in the domain, the longer the response times will be. What if there are 100k or 500k or 2mio? The only way to handle this correctly is by using pagination.
But for now as we don't support pagination we could make that configurable in the Python UDM REST API (OpenAPI) Client?!
Technically the timeout could be set per request, but an interface for that does currently not exist in the UDM REST client. Workaround: I don't have time to test this, but one of the following two lines should set the timeout of an already opened session to 300 sec: session._client.rest_client.pool_manager._timeout = 300 session._session._timeout = 300