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.
>
