You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There's a Timeout option in ghz config file which expects uint as a value. The value is interpreted as a number of seconds. It means that we can't specify a timeout which is less than a second or is not an integer (f.e. 1500 ms or 0.5). The same also applies to DialTimeout and KeepaliveTime parameters.
The ability to specify precise timeout is extremely important. Imagine you have an SLA for the response time of your service, f.e. 100 ms. In production, the request will be cancelled on the client side if the server fails to answer in time. Now it's possible to emulate this behavior using ghz only with 1-second precision.
Describe the solution you'd like
It would be great if Timeout (as well as other time options) will accept duration string like 500ms. This will also make all time-related options behave in the same predictable way. To support backward compatibility we can interpret the value without unit as seconds (maybe it already works like this?)
Describe alternatives you've considered
We could treat the uint as the number of milliseconds but this would be a breaking change.
Additional context
I also found a little bug related to this issue in UnmarshalJSON function from config.go.
If X option is specified but Z is not, the X one will be ignored because of the error check. It'd be better to check if the value is specified before trying to parse it, and if it's specified but invalid throw the error.
The text was updated successfully, but these errors were encountered:
Thank you for reporting this. I understand the issue and I agree this could be improved. Just wanted to say I will try and take a deeper look at the solution and address this soon when I get some more free time.
Hello this should be working now in 0.40.0. All duration values originally configured as ints have been changed to the duration type. If there are any problems please create a new issue.
Hello,
Is your feature request related to a problem? Please describe.
There's a
Timeout
option in ghz config file which expectsuint
as a value. The value is interpreted as a number of seconds. It means that we can't specify a timeout which is less than a second or is not an integer (f.e.1500 ms
or0.5
). The same also applies toDialTimeout
andKeepaliveTime
parameters.The ability to specify precise timeout is extremely important. Imagine you have an SLA for the response time of your service, f.e. 100 ms. In production, the request will be cancelled on the client side if the server fails to answer in time. Now it's possible to emulate this behavior using ghz only with 1-second precision.
Describe the solution you'd like
It would be great if
Timeout
(as well as other time options) will accept duration string like500ms
. This will also make all time-related options behave in the same predictable way. To support backward compatibility we can interpret the value without unit as seconds (maybe it already works like this?)Describe alternatives you've considered
We could treat the uint as the number of milliseconds but this would be a breaking change.
Additional context
I also found a little bug related to this issue in UnmarshalJSON function from config.go.
If
X
option is specified butZ
is not, theX
one will be ignored because of the error check. It'd be better to check if the value is specified before trying to parse it, and if it's specified but invalid throw the error.The text was updated successfully, but these errors were encountered: