[3.2] http-max-bytes-in-flight-mb fixes #59
Conversation
allow http-max-bytes-in-flight-mb bigger than 4GB; make -1 indicate unlimited; add range check
| @@ -217,7 +217,7 @@ class http_plugin_impl : public std::enable_shared_from_this<http_plugin_impl> { | |||
| std::optional<eosio::chain::named_thread_pool> thread_pool; | |||
| std::atomic<size_t> bytes_in_flight{0}; | |||
| std::atomic<int32_t> requests_in_flight{0}; | |||
| size_t max_bytes_in_flight = 0; | |||
| uint64_t max_bytes_in_flight = 0; | |||
There was a problem hiding this comment.
This is later compared with a size_t, I think it is clearer as a size_t.
There was a problem hiding this comment.
Thanks. I will change back to size_t (was thinking make it explicitly 64 bits)
| @@ -776,7 +776,16 @@ class http_plugin_impl : public std::enable_shared_from_this<http_plugin_impl> { | |||
| EOS_ASSERT( my->thread_pool_size > 0, chain::plugin_config_exception, | |||
| "http-threads ${num} must be greater than 0", ("num", my->thread_pool_size)); | |||
|
|
|||
| my->max_bytes_in_flight = options.at( "http-max-bytes-in-flight-mb" ).as<uint32_t>() * 1024 * 1024; | |||
| // http-max-bytes-in-flight-mb is allowed to be -1, | |||
| // that's why int64_t is used | |||
There was a problem hiding this comment.
Would not mention this except I have the other comment. This could be on the same line or even just remove the second line of the comment.
| EOS_ASSERT( max_bytes_mb == -1 || (max_bytes_mb >= 0 && max_bytes_mb < std::numeric_limits<int64_t>::max() / (1024 * 1024)), chain::plugin_config_exception, | ||
| "http-max-bytes-in-flight-mb ${max_bytes_mb} must be equal to or greater than 0 and less than ${max}, or -1", ("max_bytes_mb", max_bytes_mb) ("max", std::numeric_limits<int64_t>::max() / (1024 * 1024)) ); | ||
| if ( max_bytes_mb == -1 ) { | ||
| my->max_bytes_in_flight = std::numeric_limits<uint64_t>::max(); |
There was a problem hiding this comment.
This should change to size_t as well.
|
This arguably could be a 3.1 candidate. |
|
If we do this for 3.1, should I close this PR, do 3.1 first, and then merge 3.1 to main? |
|
I'm on the fence about it. #48 does make it sound like it could be treated as a defect since setting it to a high value silently ends up breaking HTTP by not behaving as expected. I'm merely suggesting it could be considered for 3.1 I'm not sure I have a strong feeling either way. |
|
Since it is not a big effort and prevents a potentially broken HTTP, I will do a 3.1 and then main. |
Resolve #48