[Starlingx-discuss] Analysis of patch 2e4ca00 for StarlingX Upstreaming

Legacy, Allain Allain.Legacy at windriver.com
Wed Nov 7 12:14:22 UTC 2018


Adding a config option for "max_rpc_response_timeout" is acceptable, but I would continue to use the existing values for multiplier (10) and rpc_response_timeout (60).    Anyone needing to use a different maximum can override the configuration option but everyone else will continue to use the existing maximum timeout.

Regards,
Allain


Allain Legacy, Software Developer, Wind River
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5


[WIND]<http://www.windriver.com/>

From: Xu, Chenjie [mailto:chenjie.xu at intel.com]
Sent: Wednesday, November 07, 2018 12:25 AM
To: Legacy, Allain
Cc: starlingx-discuss at lists.starlingx.io; Peters, Matt
Subject: RE: [Starlingx-discuss] Analysis of patch 2e4ca00 for StarlingX Upstreaming

Hi Allain,
Thanks for your reply! I agree with your opinions. About configuration option, I think we can propose to add max_rpc_response_timeout or multipler into the config file. The function get_max_timeout() should return max_rpc_response_timeout or multipler*rpc_response_timeout. The default value for max_rpc_response_timeout can be 300s and for multipler can be 5. Coud you please help review and comment?

Best Regards,
Xu, Chenjie

From: Legacy, Allain [mailto:Allain.Legacy at windriver.com]
Sent: Tuesday, November 6, 2018 8:30 PM
To: Xu, Chenjie <chenjie.xu at intel.com<mailto:chenjie.xu at intel.com>>; Peters, Matt <Matt.Peters at windriver.com<mailto:Matt.Peters at windriver.com>>
Cc: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: RE: [Starlingx-discuss] Analysis of patch 2e4ca00 for StarlingX Upstreaming

The issue with changing the configuration value from 60 to 6 is that provides the default value for _METHOD_TIMEOUTS which means now each RPC request will timeout after 6 seconds rather than 60 seconds.  In a heavily loaded system that timeout will get hit frequently thus leading to repeated RPC requests and an increased load on the server.

We need a way to control the maximum timeout without reducing the timeout of each individual RPC timeout so much as to increase the load on the server.

I think it is unlikely that upstream will accept the current change in its current form.  Perhaps we need to propose a configuration option that can be controlled via config file but still leaves the default as it is today.

Regards,
Allain


Allain Legacy, Software Developer, Wind River
direct 613.270.2279  fax 613.492.7870 skype allain.legacy
350 Terry Fox Drive, Suite 200, Ottawa, Ontario, K2K 2W5


[WIND]<http://www.windriver.com/>

From: Xu, Chenjie [mailto:chenjie.xu at intel.com]
Sent: Tuesday, November 06, 2018 2:35 AM
To: Peters, Matt
Cc: starlingx-discuss at lists.starlingx.io<mailto:starlingx-discuss at lists.starlingx.io>
Subject: [Starlingx-discuss] Analysis of patch 2e4ca00 for StarlingX Upstreaming

Hi Matt,
The patch 2e4ca00 changes function get_max_timeout() by changing the multiplication factor of 10 to 1 to avoid wait for 60*10 seconds(The default value for rpc_response_timeout is 60). This can be done by changing the default value from 60 to 6. Then will wait 6*10 seconds. This patch may be just a configuration problem to neutron upstream. Do you think we should upstream this patch or not?

Best Regards,
Xu, Chenjie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181107/26d67de7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1807 bytes
Desc: image001.png
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181107/26d67de7/attachment.png>


More information about the Starlingx-discuss mailing list