IPv6 support #1203
IPv6 support #1203
Conversation
# Conflicts: # plugins/state_history_plugin/state_history_plugin.cpp
| @@ -98,7 +96,7 @@ class beast_http_session : public detail::abstract_conn, | |||
| // HTTP response object | |||
| std::optional<http::response<http::string_body>> res_; | |||
|
|
|||
| std::shared_ptr<http_plugin_state> plugin_state_; | |||
| http_plugin_state* plugin_state_; | |||
There was a problem hiding this comment.
Is there any way to refactor this to not store a naked pointer?
| } else if (ec == boost::system::errc::too_many_files_open) { | ||
| // retry accept() after timeout to avoid cpu loop on accept | ||
| auto timeout_ms = static_cast<T*>(this)->accept_timeout_ms; | ||
| fc_elog(state_->get_logger(), "accept: too many files open - waiting ${timeout}ms", ("timeout", timeout_ms)); |
There was a problem hiding this comment.
Maybe consider elaborating on this message a little more as I'm not sure everyone understands files == connections in this context. "open file limit reached: not accepting new connections for next Xms" or something like that
I'd like to figure out a way to suggest the action for user to take but I can't think of a concise way to put it.. "open file limit reached: not accepting new connections for next Xms, consider increasing 'ulimit -n'" .. but someone using docker, etc, would adjust this knob differently so don't really like that
| inline auto make_http_response_handler(std::shared_ptr<http_plugin_state> plugin_state, detail::abstract_conn_ptr session_ptr, http_content_type content_type) { | ||
| return [plugin_state{std::move(plugin_state)}, | ||
| inline auto make_http_response_handler(http_plugin_state* plugin_state, detail::abstract_conn_ptr session_ptr, http_content_type content_type) { | ||
| return [plugin_state = plugin_state, |
There was a problem hiding this comment.
Is it dangerous to use a regular pointer to http_plugin_state in a response_handler, instead of a shared_ptr that extends its lifetime if necessary?
There was a problem hiding this comment.
The handlers can't be executed after the plugin shutdown, and the state will only be deleted by the destructor of the plugin, so it's safe to do so.
There was a problem hiding this comment.
Please change to http_plugin_state& then.
This PR refactors net_plugin, http_plugin, and state_history_plugin to support IPv6.
Resolves #622