-
Notifications
You must be signed in to change notification settings - Fork 528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve caller context in TcpAcceptor #1087
Preserve caller context in TcpAcceptor #1087
Conversation
Before this fix, acceptOne() was losing FTP DATA TcpAcceptor context by unconditionally resetting the context to a nil listenPort_. Also, TcpAcceptor methods should not (be expected to) explicitly set their job code context. Instead, the job should be created in the right code context, allowing job-created async calls to auto-manage code context. The updated port-iterating clientHttpConnectionsOpen() and Ftp::StartListening() loops now set the right code context when creating async calls that result in TcpAcceptor job creation.
for (AnyP::PortCfgPointer s = HttpPortList; s != nullptr; s = s->next) { | ||
CodeContext::Reset(s); | ||
if (s->listenConn != nullptr) { | ||
debugs(1, Important(14), "Closing HTTP(S) port " << s->listenConn->local); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and similar debugs() will now report the port twice, but we are already polishing how the listening ports are reported (including these messages) in #835, so I think it is best to merge this (much simpler) PR first and address the double-reporting concern in #835, where we have much better tools to do so. That is why I am approving this PR despite this (hopefully very temporary) flaw.
Before this fix, acceptOne() was losing FTP DATA TcpAcceptor context by unconditionally resetting the context to a nil listenPort_. Also, TcpAcceptor methods should not (be expected to) explicitly set their job code context. Instead, the job should be created in the right code context, allowing job-created async calls to auto-manage code context. The updated port-iterating clientHttpConnectionsOpen() and Ftp::StartListening() loops now set the right code context when creating async calls that result in TcpAcceptor job creation.
Before this fix, acceptOne() was losing FTP DATA TcpAcceptor context by unconditionally resetting the context to a nil listenPort_. Also, TcpAcceptor methods should not (be expected to) explicitly set their job code context. Instead, the job should be created in the right code context, allowing job-created async calls to auto-manage code context. The updated port-iterating clientHttpConnectionsOpen() and Ftp::StartListening() loops now set the right code context when creating async calls that result in TcpAcceptor job creation.
Before this fix, acceptOne() was losing FTP DATA TcpAcceptor context by unconditionally resetting the context to a nil listenPort_. Also, TcpAcceptor methods should not (be expected to) explicitly set their job code context. Instead, the job should be created in the right code context, allowing job-created async calls to auto-manage code context. The updated port-iterating clientHttpConnectionsOpen() and Ftp::StartListening() loops now set the right code context when creating async calls that result in TcpAcceptor job creation.
Before this fix, acceptOne() was losing FTP DATA TcpAcceptor context
by unconditionally resetting the context to a nil listenPort_.
Also, TcpAcceptor methods should not (be expected to) explicitly set
their job code context. Instead, the job should be created in the
right code context, allowing job-created async calls to auto-manage code
context. The updated port-iterating clientHttpConnectionsOpen() and
Ftp::StartListening() loops now set the right code context when creating
async calls that result in TcpAcceptor job creation.