Hi, This sounds like a bug report I filed previously, https://issues.apache.org/jira/browse/TS-935. When using TSContCall with TS_EVENT_IMMEDATE or TS_EVENT_TIMEOUT will cause an assertion to be thrown in INKContInternal::handle_event_count, this is a bug. Obvious quick fix is to not use those events with TSContCall.
Brian 2011/10/3 Uri Shachar <ushac...@hotmail.com> > > Hi, > > I'm not sure if this is a known behavior (and should just be better > documented), a bug or just bad practices on my part -- Flow goes like this: > > 1) In a global hook, create a continuation X and attach it to several > hookpoints in a transaction Y. > > 2) When called through one of the hookpoints, send an asynch request to an > external service that does URL categorization. > > 3) Return without reenabling (since we don't want to proceed before getting > the response). > > 4) A dedicated thread receives the response, and schedules continuation X. > (There's a mechanism that makes sure that cont X is still valid when the URL > categorization response arrives) > > 5) continuation X is called with an immediate event and calls TSHttpSsnArgGet > on transaction Y session. > > 6) If a client disconnects after we retrieve the session (and validate it), > but before we access the variables themselves... > Problem is when cont X is called due to the scheduled event, it does not lock > the HttpSM mutex, and a 'just-in-time' client disconnect can destroy the > ua_session. > > My solution to this was to create continuation X with the HttpSM mutex -- > Does this seem reasonable? > BTW -- I saw the TSHttpSchedule function that aims to solve a similar issue, > but it appears to cause transactions to hang occasionally since it overrides > the HttpSM default handler. > > Cheers, > Uri >
