[ 
https://issues.apache.org/jira/browse/HTTPCORE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Zhang Guilin updated HTTPCORE-230:
----------------------------------

    Description: 
I found this issue HTTPCORE-181 raised before.
I got the similar requirement that we want to measure all kinds of time-related 
data to get the performance report such as:
1. DNS parsing time
2. Connection setup time
2. header parsing time
3. body transfer time
...
I found that there are a lot of "private" fields which have no setter method in 
this component, this makes us hard to extend the functionality.
For example in org.apache.http.impl.io.AbstractSessionInputBuffer#init() 
method, it would be better to change "this.metrics = new 
HttpTransportMetricsImpl();" to "this.metrics = createMetrics()" (a protected 
method) which subclasses can easily override this if they want to get an 
extended HttpTransportMetricsImpl instance.

Can some one look at this feature?

  was:
I found this issue <a 
href="https://issues.apache.org/jira/browse/HTTPCORE-181";>HTTPCORE-181</a> 
raised before.
I got the similar requirement that we want to measure all kinds of time-related 
data to get the performance report such as:
1. DNS parsing time
2. Connection setup time
2. header parsing time
3. body transfer time
...
I found that there are a lot of "private" fields which have no setter method in 
this component, this makes us hard to extend the functionality.
For example in org.apache.http.impl.io.AbstractSessionInputBuffer#init() 
method, it would be better to change "this.metrics = new 
HttpTransportMetricsImpl();" to "this.metrics = createMetrics()" (a protected 
method) which subclasses can easily override this if they want to get an 
extended HttpTransportMetricsImpl instance.

Can some one look at this feature?


Generally speaking, I think it would be better if we have more protected fields 
or methods rather than private ones. So that we can easily extend some concrete 
classes to meet our application's requirement.
To be more specific, here is an example:
In org.apache.http.impl.io.HttpResponseParser class, #parseHead(), "int i = 
sessionBuffer.readLine(this.lineBuf);" indicates that header transfer has been 
started and first line is received, it would be better to add a hook method or 
raise an event(might be more complicated) to do something. For example, add a 
protected method "headerTransferStarted" and append it behind "int i = 
sessionBuffer.readLine(this.lineBuf);" would be good.
So in our application, we might want to record the header transfer start time, 
we can just do something like this:
protected void headerTransferStarted() {
          headerStartTime = System.nanoTime();
}

> Need time related metrics data
> ------------------------------
>
>                 Key: HTTPCORE-230
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-230
>             Project: HttpComponents HttpCore
>          Issue Type: New Feature
>          Components: HttpCore
>            Reporter: Zhang Guilin
>             Fix For: 4.1
>
>
> I found this issue HTTPCORE-181 raised before.
> I got the similar requirement that we want to measure all kinds of 
> time-related data to get the performance report such as:
> 1. DNS parsing time
> 2. Connection setup time
> 2. header parsing time
> 3. body transfer time
> ...
> I found that there are a lot of "private" fields which have no setter method 
> in this component, this makes us hard to extend the functionality.
> For example in org.apache.http.impl.io.AbstractSessionInputBuffer#init() 
> method, it would be better to change "this.metrics = new 
> HttpTransportMetricsImpl();" to "this.metrics = createMetrics()" (a protected 
> method) which subclasses can easily override this if they want to get an 
> extended HttpTransportMetricsImpl instance.
> Can some one look at this feature?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to