UDA timeout not working properly

[DorisBDR]

We had cases where we bumped into the timeout (default 10mn) whereas there were activities between server and client….a lot of requests….
So we have a feeling that there is a bug in the timeout implementation, could you please tell us how the timeout was thought? I would have expect idle activity between server and client (i.e. no requests…)

E.g.
127.0.0.1 - codac [Wed Dec 13 15:04:13 2023] [1000 getMeta(path=/ITER/BUIL-B38-DW:MP0001-PT-STATE/severity_labels, startTime=18446744073709551615, arg1=modeStatusSeverity:epicsb) 0 -1
UDA UDA ] 0 8504 [] 26.936 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:04:13 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/val_full, retType=native, tsFormat=absolute, startTime=0, endTime=1687824000000000000
%2, decSamples=4267628, ddContinueFrom=0, ddSamples=10000) 0 -1 UDA UDA ] 0 170696 [] 25149.6 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:04:38 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/status_id_full, retType=native, tsFormat=none, startTime=0, endTime=16878240000000000
00%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=0, ddSamples=10000) 0 -1 UDA UDA ] 0 50712 [] 1030.1 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:04:39 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/severity_id_full, retType=native, tsFormat=none, startTime=0, endTime=168782400000000
0000%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=0, ddSamples=10000) 0 -1 UDA UDA ] 0 50712 [] 1921.73 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:04:40 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/val_full, retType=native, tsFormat=absolute, startTime=0, endTime=1687824000000000000
%2, decSamples=4267628, ddContinueFrom=10000, ddSamples=10000) 0 -1 UDA UDA ] 0 170696 [] 1034.47 8 8 [485818 2008909] []
…

27.0.0.1 - codac [Wed Dec 13 15:13:47 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/val_full, retType=native, tsFormat=absolute, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, ddContinueFrom=340000, ddSamples=10000) 0 -1 UDA UDA ] 0 170696 [] 10808 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:13:57 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/status_id_full, retType=native, tsFormat=none, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=340000, ddSamples=10000) 0 -1 UDA UDA ] 0 50712 [] 9475.68 8 8 [485818 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:14:06 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/severity_id_full, retType=native, tsFormat=none, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=340000, ddSamples=10000) 0 -1 UDA UDA ] 0 50712 [] 10472.9 8 8 [485818 2008909] []
127.0.0.1 - [Wed Dec 13 15:14:06 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/severity_id_full, retType=native, tsFormat=none, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=340000, ddSamples=10000) 0 -1 UDA UDA ] 20 0 [Protocol 10 Error (Receiving Client Block)] 10491.1 0 8 [2008909 2008909] []
127.0.0.1 - codac [Wed Dec 13 15:14:16 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/val_full, retType=native, tsFormat=absolute, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, ddContinueFrom=350000, ddSamples=10000) 0 -1 UDA UDA ] 0 170696 [] 1269.43 8 8 [485818 2009068] []
127.0.0.1 - [Wed Dec 13 15:14:16 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/val_full, retType=native, tsFormat=absolute, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, ddContinueFrom=350000, ddSamples=10000) 0 -1 UDA UDA ] 20 0 [Protocol 10 Error (Receiving Client Block)] 1272.64 0 8 [2009068 2009068] []
127.0.0.1 - codac [Wed Dec 13 15:14:17 2023] [1000 getData(variable=/ITER/BUIL-B38-DW:MP0001-PT-STATE/status_id_full, retType=native, tsFormat=none, startTime=0, endTime=1687824000000000000%2, decSamples=4267628, arg1=modeStatusSeverity:epicsb, ddContinueFrom=350000, ddSamples=10000) 0 -1 UDA UDA ] 0 50712 [] 1942.65 8 8 [485818 2009080] []

[DorisBDR]

ok so with 2.8.0 we observed that session cannot last more than 10 minutes they are getting ended. Is there any reason why we are terminating them after 10 mn? even though the session is active. Typical use case i have a visualization or an analysis code which is making a lot of requests : why do we end up after 10 mn? what's the rational?
we would like to propose a behavioral change and to only kill in case of a query being stuck...so a long query.
comments, feedback appreciated?

[stephen-dixon]

you're right. I think current behaviour is that a connection is reset after a total lifetime of the server_timeout variable. The default value of 10 minutes is probably from the old MAST use-case where data volumes were very small - the rationale (i believe) is that this just forces a fresh server periodically (between multiple small data requests) to avoid issues with long-running servers probably having memory leaks.

Short term: This is a variable that can be changed in the client to set a much longer value than the default 600 seconds to support your use-case without unnecessary interruptions.

c++:

udaSetProperty("timeout=3600");

python:

client.set_property("timeout", 3600)

I'd personally support adding a feature that kills connections after some period of inactivity (rather than total lifetime). Though not sure if we want to keep the option to specify a total-lifetime too. @jholloc any thoughts?