Bug 56422 - Configurable processing timeouts
Configurable processing timeouts
Status: NEW
Product: Components
Classification: Unclassified
Component: udm-rest-api-client
unspecified
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2023-08-11 16:28 CEST by Timo Hollwedel
Modified: 2023-08-28 13:34 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timo Hollwedel univentionstaff 2023-08-11 16:28:53 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.
Comment 1 Daniel Tröder univentionstaff 2023-08-14 08:57:06 CEST
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.
Comment 2 Florian Best univentionstaff 2023-08-28 09:40:22 CEST
But for now as we don't support pagination we could make that configurable in the Python UDM REST API (OpenAPI) Client?!
Comment 3 Daniel Tröder univentionstaff 2023-08-28 13:34:54 CEST
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