> On Jan 16, 2015, at 10:04 AM, Nick Kew <n...@apache.org> wrote: > > On Thu, 15 Jan 2015 11:01:43 -0600 > Susan Hinrichs <shinr...@network-geographics.com> wrote: > >> I've dug into Lev's observation on the Transaction Start hook and blind >> tunnels some more. I'd like to pursue two issues so I'm dividing his >> note into two. >> >> As the code currently stands, both TS_HTTP_TXN_START_HOOK and >> TS_HTTP_SSN_START_HOOK get called at the start of the session. >> TS_HTTP_SSN_START_HOOK gets involved explicitly from >> HttpClientSession::new_connection(). TS_HTTP_TXN_START_HOOK gets called >> from HttpSM::state_add_to_list. The TS_HTTP_TXN_START_HOOK gets called >> before any attempt is made to read the client header (at least for the >> first transaction). > > Heh. I've long been aware of some anomalies, but I hadn't realised > TXN_START would get called in the absence of an HTTP request line. > I think this calls for some more customised testing on my part. > > If what you're saying is that the creation of a txn, and with it the > calling of any TXN_START continuations, should be contingent on > detecting an HTTP request line, then +1.
Yeh +1 from me on not firing TXN_START unless it's really HTTP. Though, maybe the right approach is to keep the current event timing, but only fire TXN_START on HTTP ports? >> At the end TS_HTTP_TXN_CLOSE_HOOK and TS_SSN_CLOSE_HOOK both get called >> (though in the wrong order in my opinion, but Alan says that this is a >> known issue). > > I've seen both orders. I agree it would be much easier if we could > rely on seeing TXN_CLOSE first, but it can be worked around. Both orders? Yuck! IMHO, we should guarantee TXN_CLOSE precedes SSN_CLOSE. J
