Bug 49560 - wrong "size in bytes" when following redirections
Summary: wrong "size in bytes" when following redirections
Alias: None
Product: JMeter
Classification: Unclassified
Component: HTTP (show other bugs)
Version: 2.3.4
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
Depends on:
Reported: 2010-07-06 12:39 UTC by Dimitris Balaouras
Modified: 2010-07-08 11:41 UTC (History)
0 users

patch for correcting the parent's "size in bytes" when following redirections (1.16 KB, text/plain)
2010-07-06 12:39 UTC, Dimitris Balaouras

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitris Balaouras 2010-07-06 12:39:31 UTC
Created attachment 25715 [details]
patch for correcting the parent's "size in bytes" when following redirections

Using an HttpRequest Sampler on a url that redirects but also returns some body message next to the 30x headers, gives wrong size in bytes.

More precise, the "parent" http sample gets a value in "size in bytes" equal to 2x[initial request] + [size of the rest subrequests]

This issue has been addressed quite some time ago (http://www.mail-archive.com/jmeter-user@jakarta.apache.org/msg25592.html) by one of my colleagues (Mr. Pieter Ennes, WatchMouse.com) but it has not been fixed yet (checked in version 2.3.4).

We have located the root cause of this problem and it resides in the class src/core/org/apache/jmeter/samplers/SampleResult.java. The constructor "SampleResult(SampleResult res)", clones the initial result to a "Parent" result object and sets it as the child of the Parent.
During this cloning the following piece of code causes some trouble:

public SampleResult(SampleResult res) {
addSubResult(res); // this will add res.getTime() to getTime().

The invocation of addSubResult in the code above does this: setBytes(getBytes() + subResult.getBytes()); which sets the bytes of the parent to 2x[size of initial subresult].

Of course that is if the initial request has some body message and not just the headers with the 30x response. 
Although it's common that 30x response have no message body, it is not always the case. And I think JMeter should give fine figures at all times.

In the patch attached to this report, I have replaced this invocation with this code:

String tn = getThreadName();
if (tn.length()==0) {
    tn=Thread.currentThread().getName();//TODO do this more efficiently
if (subResults == null) {
    subResults = new ArrayList<SampleResult>();
// Extend the time to the end of the added sample
// Include the byte count for the added sample

which is the code of the function addSubResult but stripping out the "getBytes()" part.

This patch has been tested over several scripts and gave fine results.
Please give it a look as you might find it useful; if so, please add it in a next release.
Comment 1 Sebb 2010-07-07 11:11:52 UTC
There are two different usages for the constructor 
   SampleResult(SampleResult res)
- following redirects
- downloading page resources

I agree it seems wrong the way the sub-results are added currently, but I'm not yet sure of the best solution. Possibly the constructor should only create a clone of itself, and not add itself as a sub-result. The calling code would need to be changed accordingly, but would be easier to understand.

Other samplers that call addSubResult() do so directly; it only seems to be the HTTP samplers that use the copy constructor.

Is there a public URL that could be used to test against?
Comment 2 Sebb 2010-07-07 11:14:58 UTC
Just noticed - google's redirect response includes text, so that can be used for testing.
Comment 3 Sebb 2010-07-07 19:59:04 UTC
I've reworked the copy constructor to do a real copy and fixed the bytes problem (I hope!) In the process, the latency was also fixed for redirects.

URL: http://svn.apache.org/viewvc?rev=961539&view=rev
Bug 49560 - wrong "size in bytes" when following redirections


The code will be in nightlies after r961539 - if possible, please could you try one and report back?

Comment 4 Dimitris Balaouras 2010-07-08 02:06:15 UTC
Hi Sebb,

I've just svn up-ed my working copy to the HEAD revision and it looks nice!
Many thanks for this quick fix!

I have once more question though; I am wondering why did you set the latency of the parent to the latency of the first child? Shouldn't you count the overhead of the redirections in that figure?

I would think that the latency of the parent element is from START until the first byte of the FINAL (landing) page.

Thanks again!
Comment 5 Sebb 2010-07-08 05:09:59 UTC
In the case of "download embedded", latency should definitely only be time to first response of parent page, but then the parent page is the first to be downloaded anyway.

In the case of redirects, it's not so clear-cut, but I still think it makes sense to stick with the intial redirect latency, as that is how quickly the server has responded to the original request.
Comment 6 Dimitris Balaouras 2010-07-08 11:41:41 UTC
hmm..indeed it's not so clear in case of redirects..
Maybe an "overall_latency" figure would make sense here.

Anyways, thanks again for the fix!