> On July 27, 2016, 8:33 p.m., Joris Van Remoortere wrote: > > 3rdparty/libprocess/src/libevent_ssl_socket.cpp, line 508 > > <https://reviews.apache.org/r/50477/diff/1/?file=1454471#file1454471line508> > > > > why `s` vs `get()`?
I didn't think of using get() at the time. Looking at it now, `s` seems a bit clearer vs a free-standing `get()`, and I notice `s` is already used in another location this file (whereas get() is not used). So I'll stick with `s` for now. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50477/#review143805 ----------------------------------------------------------- On July 27, 2016, 2:03 a.m., Benjamin Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50477/ > ----------------------------------------------------------- > > (Updated July 27, 2016, 2:03 a.m.) > > > Review request for mesos, Joris Van Remoortere and Joseph Wu. > > > Bugs: MESOS-5913 > https://issues.apache.org/jira/browse/MESOS-5913 > > > Repository: mesos > > > Description > ------- > > The deferred call to SSL_shutdown within ~LibeventSSLSocketImpl > can occur after the socket fd has been closed by Socket::~Impl. > > This can lead to a TLS Alert message being sent on any fd if > it the fd is re-used between the close and the SSL_shutdown! > > Thanks to Jan-Philip Gehrcke for reporting the issue. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/socket.hpp > 881b44b987e5894cac838dae046ab7dbad20b000 > 3rdparty/libprocess/src/libevent_ssl_socket.hpp > 4d376d8b7c1b29105de69bed2e4077f8c94fed0b > 3rdparty/libprocess/src/libevent_ssl_socket.cpp > f4c0b0b97960400b0282837979bf0ed17f56a068 > > Diff: https://reviews.apache.org/r/50477/diff/ > > > Testing > ------- > > make check > > Ran my repro steps (issue HTTP requests while hammering the master with HTTPS > requests). Issue disappears after this fix. > > > Thanks, > > Benjamin Mahler > >
