This behavior should be better documented (Would have saved me a huge headache)
-- What's the flow to updating the docs?
Should I open an issue or just submit a patch for INKContSched.html?
Cheers,
Uri
----------------------------------------
> Date: Fri, 7 Oct 2011 14:00:12 -0700
> Subject: Re: TSContSched on continuations that are called by HttpSM hooks can
> lead to crashes/odd behavior
> From: jplev...@acm.org
> To: dev@trafficserver.apache.org
>
> Personally, I like your solution. Generally, fewer mutexes are safer, and a
> single mutex should be shared over as much of the connection as possible as
> acquiring it gives access to all state that it covers. Normally plenty of
> parallelism to go around.
>
> john
>
> 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
> >
> >
