Currently, the start time is stored in ProxySession. How would adding `SSN_START` to the milestones work automatically? The value would still be stored in ProxySession and not in the milestones array. Would it be copied out at the start of every transaction to the HttpSM local milestone array? If not, then you need the special index check to handle `SSN_START` differently. It can't be store persistently in the milestones because those are cleared every transaction.
Again, there are already a number of API functions like this (see the PR, one thing it does is group these together). A few of them have overloads that work via the TXN object, but all of them are directly accessible via a session object. I really didn't think this would be controversial given that we already do this, just not for this particular session property. On Thu, Sep 19, 2019 at 2:20 PM Sudheer Vinukonda <sudheervinuko...@yahoo.com.invalid> wrote: > Hmm..TXN has access to the session it's associated with and I personally > don't feel it'd look ugly or bad to combine session related data to a TXN > milestone API (we already do that in Access logs). > The existing API (`sm->milestones[milestone]` ) should just work > automatically, if `SSN_START_TIME` is added to `TSMileStonesType`. May be > I'm missing something, but, I can't think of any special checks needed. > That said, while the advantage would be one less API to support and > consistency in terms of leveraging existing API, the major disadvantage > though would be that we'd always need to have a TXN to look at the Session > start time. > I don't know if there's any specific use case that needs to look at > Session Start time outside of a Txn, but, I won't be surprised if there is > and it does seem like a reasonable thing to support though. > I'm +0 on adding `TSHttpSsnStartTime`, but, would like to hear from others > too on what they think. > > On Thursday, September 19, 2019, 11:58:32 AM PDT, Alan Carroll > <solidwallofc...@verizonmedia.com.INVALID> wrote: > > It's not really associated with the Transaction, it's a session property. > It would be somewhat ugly to implement that way, as you would then need to > do special checks on the milestone enum to handle the session start time > differently, since it's in a completely different place. The code for this > function is effectively "return > reinterpret_cast<ProxySession*>(ssnp)->ssn_start_time;". > > It would also seem a bit odd to have things like the session VConn or ID > available via the milestone interface. > > On Thu, Sep 19, 2019 at 1:46 PM Sudheer Vinukonda > <sudheervinuko...@yahoo.com.invalid> wrote: > > > Hmm...Would it make sense to add this as a milestone and extend the > > existing API `TSHttpTxnMileStoneGet` (and `TSMilestonesType`) to support > > session start time and possibly other session level context associated to > > that Txn? > > Thoughts? > > > > > > On Thursday, September 19, 2019, 11:38:47 AM PDT, Alan Carroll > > <solidwallofc...@verizonmedia.com.INVALID> wrote: > > > > I'm playing with some session stuff and I'd like to add this, since the > > data is already stored in the session, it's trivial to access. > > >
