[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jmeter-user
Subject:    Re: Head scratcher - test hanging
From:       "joelsherriff" <joelsherriff () comcast ! net>
Date:       2004-07-25 20:00:12
Message-ID: 019401c47282$00efb180$6501a8c0 () akumac
[Download RAW message or body]

Peter,
    Thanks - it turns out that the only really wierd stuff it's doing is the
mangling of "Connection:" in the response headers.  I got my tracing code to
work, so now I know that the mangling of "Connection:" in the replies isn't
something that JMeter is doing, that's coming right from amazon.  Anyway, I
found the source of the main problem, but not sure I "fixed" it in the right
place.  The "Host:" field in the request isn't being updated correctly.
It's not set to the hostname in the URI being requested, but is still set to
the hostname from the original URI (Referrer: of the new URI).  Looks like
it's just borrowing the original headers.  What I did was to add

   if(n.equalsIgnoreCase("Host")) {
    v = u.getHost();
   }

before the

    conn.setRequestProperty(n,v);
    hdrs.append(n);
    hdrs.append(": ");
    hdrs.append(v);
    hdrs.append("\n");

inside setConnectionHeaders() in HTTPSampler.java.  That fixes the problem,
but since I'm still getting used to the architecture, I'm not sure if
there's a better place.  Of course, the other problem (that caused the
infinite loop) is the lack of cache emulation.  In this case, I'm glad
JMeter didn't have cache emulation, otherwise I might not have noticed this
problem.  If I get the contract I'm evaluating JMeter for, I'll try to help
add some kind of cache emulation, it's really pretty easy.  I'm seeing
another problem re gzip support, but I'll post a separate msg about that.

Thanks again.

J

----- Original Message ----- 
From: "Peter Lin" <woolfel@gmail.com>
To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
Sent: Friday, July 23, 2004 9:28 PM
Subject: Re: Head scratcher - test hanging


> wow, that sounds like amazon does some weird stuff. hmm, the standard
> URLConnection is suppose to give up after a couple tries.
> HttpSamplerBase probably is the place to look.
>
> peter
>
>
> On Fri, 23 Jul 2004 19:56:46 -0400, joelsherriff
> <joelsherriff@comcast.net> wrote:
> > Goofy s**t going on here.  Debugging has found that at least one of the
> > subrequests generated as a result of enabling "Retrieve All..." is for a
> > ..gif which gets a 200 response - yet the content-type is "image/text"
and
> > the response data is html for a 404 Not Found error.  So, the parser
parses
> > the (large) response which self-references the original url, causing
jmeter
> > to loop infinitely (or at least until it gets tired of eating the
memory).
> > I need to get under the hood for this one and since I don't feel like
> > cracking java.net. code, does anyone know of a winsock tracing tool that
> > will trace java.exe calls (free or shareware)?  None of my tools is
working.
> > Not sure what to suspect at this point, since the url is most definitely
not
> > Not Found.
> >
> > J
> >
> >
> >
> >
> > ----- Original Message -----
> > From: "joelsherriff" <joelsherriff@comcast.net>
> > To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
> > Sent: Thursday, July 22, 2004 3:52 PM
> > Subject: Re: Head scratcher - test hanging
> >
> > > Further testing has narrowed it down a little more, but is still not
much
> > > help.  It's not the 301 response code though.
> > > The 301 redirects to:
> > > http://www.amazon.com/exec/obidos/subst/home/home.html
> > > which is then redirected by a 302 to
> > > http://www.amazon.com/exec/obidos/subst/home/home.html/{someuniqueid}
> > > It appears that enabling Retrieve All Embedded Resources from HTML
Files
> > > contributes to the problem.  If I change my test so that the path in
the
> > > request is /exec/obidos/subst/home/home.html (to skip the 301 response
> > > entirely), enable Follow Redirects and Retrieve All..., it hangs.  If
I
> > > disable Retrieve All..., it doesn't hang.  I'm now going to dig into
the
> > > code to see if I can figure out what's going on - maybe the html
parser is
> > > choking on the response.  I did notice that the response headers are
> > mangled
> > > in the Sampler result tab (for the case where Retrieve All... is
> > disabled) -
> > > "Connection:  close" is written either as "nnCoection:  close" or
> > > "Cneonction:  close", depending on whether I'm looking at the
home.html
> > > response or the home.html/{someuniqueid} response.  But that could be
a
> > red
> > > herring.
> > >
> > > Anyone with a suspicion where to look, chime in...
> > >
> > > J
> > > ----- Original Message -----
> > > From: "joelsherriff" <joelsherriff@comcast.net>
> > > To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
> > > Sent: Wednesday, July 21, 2004 1:59 PM
> > > Subject: Head scratcher - test hanging
> > >
> > >
> > > > Just capturing and playing back odds and ends and I have a case here
> > that
> > > > just hangs when playing back an http request.  Maybe someone can see
> > > > something silly I'm doing?  I have only 1 thread group which
contains
> > only
> > > 1
> > > > request - to www.amazon.com, path "/".  Redirect Automatically,
Follow
> > > > Redirects, and Use KeepAlive are enabled.  Thread properties is Stop
> > Test,
> > > > 1, 1, and 1.
> > > > This should execute quickly, yet when I hit Start, it runs until I
stop
> > it
> > > > but the request never completes.  The only thing of interest I can
see
> > is
> > > > that the request gets a 301 (moved permanently) response, as opposed
to
> > > the
> > > > more common 302.  That is, it gets it "normally", I have no way of
> > knowing
> > > > what's happening during the test.
> > > >
> > > > Any ideas?  I've attached the test plan in case anyone want's to
view
> > it.
> > > >
> > > > J
> > > >
> > > >
> > >
> > >
> >
> --------------------------------------------------------------------------
> > --
> > > ----
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]