Never mind, I figured out the issue. Please ignore... thanks.
On Mon, Oct 9, 2017 at 5:13 PM, Dk Jack <dnj0...@gmail.com> wrote: > Alan, > I've been working on the issues we discussed. I have most of it working. > I've added two things: > > - Allow plugins to add user data to conn. > bool TSVConnSetUserData(TSVConn connp, const char* name, void* data); > void* TSVConnGetUserData(TSVConn connp, const char* name); > > Did not bother with reserving since user can get the data using name. > > - Added close hook for SSLNetVConnection. I couldn't add it to lower levels > because, the lower levels (vconn, netvconn) are called after the ssl > data-structures > are cleaned up and I wanted the plugin callback to be synchronously so > that user > data can be cleaned up. > > Things are working for the most part. I am getting a crash on the second > ssl request. I suspect > I am missing something. Would appreciate it if you or someone more > familiar with the > code can let me know what I am doing wrong. > > I've attached the diff (the diff is based on 6.2.1 code base). > > Thanks, > Dk > > PS: Stack trace... > > 0 0x00000000004afd82 crash_logger_invoke(int, siginfo_t*, void*) + 0x82 > 1 0x00002afa38eec390 __restore_rt + (nil) > 2 0x00002afa39bd2428 gsignal + 0x38 > 3 0x00002afa39bd402a abort + 0x16a > 4 0x00002afa37ba0adf ink_fatal_va(char const*, __va_list_tag*) + 0x9f > 5 0x00002afa37ba0b79 ink_fatal(char const*, ...) + 0x99 > 6 0x00002afa37b9ec35 _ink_assert + 0x15 > 7 0x00000000004ca26d INKContInternal::handle_event(int, void*) + 0x13d > 8 0x0000000000780b27 SSLNetVConnection::do_io_close(int) + 0x147 > 9 0x00000000005a7636 Http1ClientSession::do_io_close(int) + 0x116 > 10 0x00000000005ab86f Http1ClientSession::state_keep_alive(int, void*) > + 0x3f > 11 0x00000000007adbb0 UnixNetVConnection::readSignalDone(int, > NetHandler*) + 0x50 > 12 0x00000000007891e8 SSLNetVConnection::net_read_io(NetHandler*, > EThread*) + 0x898 > 13 0x0000000000798654 NetHandler::mainNetEvent(int, Event*) + 0x214 > 14 0x00000000007e0f12 EThread::process_event(Event*, int) + 0x92 > 15 0x00000000007e1bc9 EThread::execute() + 0x639 > 16 0x00000000007e0995 spawn_thread_internal(void*) + 0x55 > 17 0x00002afa38ee26ba start_thread + 0xca > 18 0x00002afa39ca43dd clone + 0x6d > 19 0x0000000000000000 0x0 + 0x6d > > > On Wed, Sep 27, 2017 at 6:19 PM, Alan Carroll <solidwallofc...@oath.com. > invalid> wrote: > >> I don't think I'd do it for TLS_CLOSE, but VCONN_CLOSE would likely be >> worth it. There's an issue on that, linked from the issue I mentioned >> above. It's about the same thing - plugin wants to attach data during TLS >> handshake for later retrieval at the HTTP level that can be cleaned up if >> something goes wrong. >> >> On Wed, Sep 27, 2017 at 4:29 PM, Dk Jack <dnj0...@gmail.com> wrote: >> >> > Yeah, I was thinking along similar lines... >> > >> > Do you think, it'd be a worth while effort to add a ssl-close event >> hook? >> > >> > On Wed, Sep 27, 2017 at 1:31 PM, Alan Carroll < >> > solidwallofc...@oath.com.invalid> wrote: >> > >> > > I'd probably put a time stamp in and update it during the hook >> > processing. >> > > If you waited 5 minutes or so before clearing, that should be enough. >> If >> > > it's been 5 minutes since the last activity the connection should be >> > dead, >> > > unless you're shipping big files. >> > > >> > > Or, alternatively, in READ_REQUEST_HDR_HOOK pull the data out and >> attach >> > it >> > > to the txn, cleaning it up in TXN_CLOSE. Set a time stamp on entry in >> the >> > > table and if that's been 5 minutes, the connection has definitely >> timed >> > > out. >> > > >> > >> > >
