Need to check that. Just to be a little more clear, my requirements for the http server are pretty basic and if it can serve just one request at a time, it would serve my requirement. With this requirement, if io_context object can be stopped and post that if we clear the ssl related stuff and then start io_context again to serve the next request, would it help in clearing the memory being held? Any thoughts?
The io_context is a separate, orthogonal concern to the ssl::context.
The io_context represents your program's io loop. Normally there would be only one per program.
The ssl::context represents a common set of parameters for negotiating SSL sessions and acts as a container for those sessions. Note that these SSL sessions are not necessarily associated with any particular TCP connection - they merely represent the state of an encrypted tunnel over some transport. You would normally have one ssl::context per domain in your program. For example, a server that accepted inbound connections from the internet but then made outbound connections to a specific set of servers guarded by private keys, might use two ssl::context objects - one for all inbound connections and one for all outbound.
Destroying the ssl::context and recreating is possible but I don't think it gains you anything. It might be that the context simply keeps hold of allocated memory in anticipation of re-using it. In this case, allowing it to cache memory is harmless. If the memory use grows during the lifetime of the program, then this might be more serious. But I have never experienced this.
Destroying and recreating the io_context serves no purpose whatsoever. It simply means that cached services will be destroyed and re-created each time you service a request.
Yes this is too early. I would expect these functions ti be called in the destructor of your ssl stream object
Can you confirm that this is actually destroyed?
Maybe put a breakpoint in the destructor of asio::ssl::stream ?
My bad. I probably spoke too soon. It is resulting in invalid write.
I have added some code in on_shutdown to get the session object and free it explicitly. The same stack is not observed in the valgrind report anymore.
Is this fine? any comments?
void
on_shutdown(beast::error_code ec)
{
if(ec)
return fail(ec, "shutdown");
std::cout<<"Shutting down"<<std::endl;
SSL *ssl = stream_.native_handle();
SSL_SESSION *session_object = SSL_get_session(ssl);
SSL_SESSION_free(session_object);
// At this point the connection is closed gracefully
}
Hi,
I tried the async program as suggested and I still see one of the stacks where the "still reachable" memory keeps increasing with duration. I have attached the relevant stack and the program. Sorry I had to resend this email multiple times due to size limitations. Hopefully this will go through.
It's entirely possible that OpenSSL caches memory, which would be beyond the responsibility of Beast or Asio.
Thanks a lot. I will give it a try.
On Thu, Feb 3, 2022 at 9:41 AM Sandeep Bhardwaj via Boost-users
<boost-users@lists.boost.org> wrote:
> http_server_sync_ssl.cpp
Oh, right. Synchronous APIs have no way to time out. So if the remote
host does not close gracefully (i.e. just slams the connection shut)
then you will be left with a connection object which either has no way
to be destroyed, or has to wait what could be a very long time (up to
2 hours) for the operating system to time out the synchronous read.
Please try the asynchronous example, http_server_async_ssl.cpp and
determine if the problem persists.
Thanks
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Richard Hodges
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users