> On Jul 7, 2016, at 9:55 AM, Shrihari Kalkar <[email protected]> > wrote: > > Guys, > I understand that in code, if a stat is registered under 'proxy.process' it > is owned by traffic_server.
That is by convention. In the code RECT_PROCESS metrics are owned by traffic_server. Ownership of metrics is not a particularly strong concept though :-/ > Also, if a stat is registered under stats.config.xml or metrics.config, the > 'destination' is owned by traffic_manager. > > Since proxy.process.ssl.total_success_handshake_count is listed in > stats.config.xml and metrics.config, do you think that this is a conflict of > ownership? Grovelling through the git history will probably clear this up for you. IIRC total_success_handshake_count was moved to the derived metrics for compatibility when total_success_handshake_count_in and total_success_handshake_count_out were introduced. Maybe it makes sense now to make total_success_handshake_count the sum of in and out? > I see that on my instance, traffic_manager keeps sending an 'RECG_SET' event > for this stat to traffic_server even when nothing is happening. As a result, > I am seeing an issue where traffic_server blocks for a very long time for > initializing. Hmm. I'm not sure that slow initialization would be related to this. One common cause of initialization lag is setting proxy.config.http.wait_for_cache. I think you need to debug this one further :) > I wanted to know if my understanding of ownership is correct. And if it is, > can I open a new bug to track the definition of this stat? Yes, it sounds like it is worth revisiting SSL stats to make sure they still make sense. Last time I looked at these, there were a few problems. J
