You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by bu...@apache.org on 2004/08/10 18:00:00 UTC
DO NOT REPLY [Bug 30563] New: -
Thread Group should have a restart loop option on Sample Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30563>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30563
Thread Group should have a restart loop option on Sample Error
Summary: Thread Group should have a restart loop option on Sample
Error
Product: JMeter
Version: 2.0.1
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Main
AssignedTo: jmeter-dev@jakarta.apache.org
ReportedBy: jmeter@binarytwo.com
In 2.0.1 new Thread Group options were introduced that gave us more options on
what to do when a thread encounters a Sample Error.
Currently the options are to Continue, Stop Thread, or Stop Test.
I think it would be very useful to have a Next Loop option available here as well.
The reason for this is that say I'm running a load test, but only want to the
initial point where errors are encountered, and error caused by a previous
action that didn't work properly.
The current options don't allow me to do this as 'Continue' results in a
possibly large number of cascaded errors, 'Stop Thread' will slowly kill the
load test and 'Stop Test' just isn't what I want to do.
Having a Next Loop option on the Thread Group would allow me to run a test of a
constant load of 50 users for a scheduled duration and observe where the initial
errors are encountered.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: gzip, deflate support
Posted by joelsherriff <jo...@comcast.net>.
I think I've found the fix; had to add "new Inflater(true)" as a 2nd
argument to InflaterInputStream...not sure why yet...
in = new BufferedInputStream(new
InflaterInputStream(conn.getInputStream()), new Inflater(true));
----- Original Message -----
From: "joelsherriff" <jo...@comcast.net>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Tuesday, August 10, 2004 5:01 PM
Subject: gzip, deflate support
> I've been hacking to see why this isn't working. I found that
> "Accept-Encoding: gzip, deflate" wasn't being inserted into
> the request, so I added it in setConnectionHeaders() (not sure if there's
a
> better place), since it seems to be ignoring it even if I insert it in the
> "Browser-derived headers" page. So now it's working as long as I get it
> back as "Content-Encoding: gzip". But, if it comes back as
> "Content-Encoding: deflate" (like www.amazon.com does), then it breaks.
> After a little investigating, I see that we should be calling
> InflaterInputStream() instead of GZIPInputStream() to inflate the stream
if
> it's encoded with "deflate" (right now we expect "gzip" or nothing). But,
> that's not working for me. If I do that, I get an "unknown compression
> method" exception from InflaterInputStream(). If I use, ZipInputStream()
> instead (as some stuff I've read recommends), then the html parser gets a
> parse exception and it loops over and over again adding child after child
to
> the view results tree. Looks like ZipInputStream is failing in the same
> way, but with no exception. Here's the code snippet:
>
> if ("gzip".equals(conn.getContentEncoding()))// works OK even if
CE
> is null
> {
> in = new BufferedInputStream( new
> GZIPInputStream(conn.getInputStream()));
> }
> else if ("deflate".equals(conn.getContentEncoding()))
> {
> in = new BufferedInputStream(new
> InflaterInputStream(conn.getInputStream()));
> // in = new BufferedInputStream(new
> ZipInputStream(conn.getInputStream()));
> }
> else
> {
> in= new BufferedInputStream(conn.getInputStream());
> }
>
> Anybody ever deal with InflaterInputStream()? I'm not seeing any
complaints
> about it not working as advertised so I wonder what could be going wrong
> here.
>
> J
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
gzip, deflate support
Posted by joelsherriff <jo...@comcast.net>.
I've been hacking to see why this isn't working. I found that
"Accept-Encoding: gzip, deflate" wasn't being inserted into
the request, so I added it in setConnectionHeaders() (not sure if there's a
better place), since it seems to be ignoring it even if I insert it in the
"Browser-derived headers" page. So now it's working as long as I get it
back as "Content-Encoding: gzip". But, if it comes back as
"Content-Encoding: deflate" (like www.amazon.com does), then it breaks.
After a little investigating, I see that we should be calling
InflaterInputStream() instead of GZIPInputStream() to inflate the stream if
it's encoded with "deflate" (right now we expect "gzip" or nothing). But,
that's not working for me. If I do that, I get an "unknown compression
method" exception from InflaterInputStream(). If I use, ZipInputStream()
instead (as some stuff I've read recommends), then the html parser gets a
parse exception and it loops over and over again adding child after child to
the view results tree. Looks like ZipInputStream is failing in the same
way, but with no exception. Here's the code snippet:
if ("gzip".equals(conn.getContentEncoding()))// works OK even if CE
is null
{
in = new BufferedInputStream( new
GZIPInputStream(conn.getInputStream()));
}
else if ("deflate".equals(conn.getContentEncoding()))
{
in = new BufferedInputStream(new
InflaterInputStream(conn.getInputStream()));
// in = new BufferedInputStream(new
ZipInputStream(conn.getInputStream()));
}
else
{
in= new BufferedInputStream(conn.getInputStream());
}
Anybody ever deal with InflaterInputStream()? I'm not seeing any complaints
about it not working as advertised so I wonder what could be going wrong
here.
J
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org