Of course, by automatic, I don't mean out of thin air :) - you just need to
initialize it in the TXN milestones just like you'd do the rest of the TXN
milestones. for e.g in HttpSM::init().
milestones[SSN_START] = Thread::get_hrtime();
The API doesn't need to do anything different, you just need the wiring to fill
the data in the SM. Again like I said, I'm not fully opposed to the new API,
just saying it seems something that's relevant/related to existing milestones
as well and seemed like a natural fit.
On Thursday, September 19, 2019, 02:07:29 PM PDT, Alan Carroll
<solidwallofc...@verizonmedia.com.INVALID> wrote:
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.
> >
>
