Re: Send request without User-Agent header
@Philippe - https://bz.apache.org/bugzilla/show_bug.cgi?id=62977 On Mon, 3 Dec 2018 at 09:47, Philippe Mouawad wrote: > Hello, > Please open an enhancement request here: > > - > > https://jmeter.apache.org/issues.html > > > For now I don’t think it’s possible > > > Regards > On Sunday, December 2, 2018, Antony Bowesman > wrote: > > > Using JMeter 3.3 > > > > > > > > How can I send an http request without a User-Agent header. > > > > > > > > I have a HeaderManager for the request, but if I don’t specify as UA > > header, it sends something like > > > > > > > > User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_102) > > > > > > > > whereas if I specify User-Agent as an empty value, it will send an empty > UA > > header. > > > > > > > > It seems like HttpProtocolParams will add the http.useragent default > > property, so will effectively mandate the UA header. > > > > > > > > Antony > > > > > -- > Cordialement. > Philippe Mouawad. >
Send request without User-Agent header
Using JMeter 3.3 How can I send an http request without a User-Agent header. I have a HeaderManager for the request, but if I don’t specify as UA header, it sends something like User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_102) whereas if I specify User-Agent as an empty value, it will send an empty UA header. It seems like HttpProtocolParams will add the http.useragent default property, so will effectively mandate the UA header. Antony
Send request without User-Agent header
Using JMeter 3.3 How can I send an http request without a User-Agent header. I have a HeaderManager for the request, but if I don't specify as UA header, it sends something like User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_102) whereas if I specify User-Agent as an empty value, it will send an empty UA header. It seems like HttpProtocolParams will add the http.useragent default property, so will effectively mandate the UA header. Antony
Sent request with no User-Agent header
Using JMeter 3.3 How can I send an http request without a User-Agent header. I have a HeaderManager for the request, but if I don't specify as UA header, it sends something like User-Agent: Apache-HttpClient/4.5.3 (Java/1.8.0_102) whereas if I specify User-Agent as an empty value, it will send an empty UA header. It seems like HttpProtocolParams will add the http.useragent default property, so will effectively mandate the UA header. Antony
RE: Cleaning up memory used by an HTTPSampleResult
I was unnecessarily hanging on to these SampleResult objects, so have cleaned that up, but the question on how to know that the thread has made its last iteration still stands - any ideas or is this something for dev? It's version 3.3 > -Original Message- > From: Antony Bowesman [mailto:antony.bowes...@williamhill.com.au] > Sent: Tuesday, 3 April 2018 2:04 PM > To: JMeter Users List <user@jmeter.apache.org> > Subject: Cleaning up memory used by an HTTPSampleResult > > I've been investigating a memory leak and it seems that under certain > circumstances when I get a redirect, I end up downloading a bunch of > embedded resources I don't need. In this case, these HTTPSampleResult > objects end up being part of my JavaSampler instance, which is added to the > TEAR_DOWN_SET in the JavaSampler jmeter class. > > In this particular test, the Java Sampler only executes once and so the > HTTPSampleResult objects only get cleaned up at the end of the test, when > my teardownTest() method is called. However, it also applies to samplers > that are called in a OnceOnlyController, which in my case happens to be > Login. > > I have a couple of solutions, i.e. I know I can prevent the follow redirects > to > stop the symptoms of this behaviour and I can also put in a hack that will > clean up the resources by other samplers in the same thread, but the bigger > picture of how to prevent the basic memory leak issue that appears to exist > for these hanging HTTPSampleResult objects. The main culprit is the > responseData byte[], which basically holds the entire response payload. > > There seems to be no message I can listen for > (LoopIterationListener/TestIterationListener) to indicate a thread has made > its last iteration. > > Is there any way to clean up a thread's resources when it is done with. I > can't > do the cleanup during the iteration as there may be listeners that want the > results. > > Thanks > Antony - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Cleaning up memory used by an HTTPSampleResult
I've been investigating a memory leak and it seems that under certain circumstances when I get a redirect, I end up downloading a bunch of embedded resources I don't need. In this case, these HTTPSampleResult objects end up being part of my JavaSampler instance, which is added to the TEAR_DOWN_SET in the JavaSampler jmeter class. In this particular test, the Java Sampler only executes once and so the HTTPSampleResult objects only get cleaned up at the end of the test, when my teardownTest() method is called. However, it also applies to samplers that are called in a OnceOnlyController, which in my case happens to be Login. I have a couple of solutions, i.e. I know I can prevent the follow redirects to stop the symptoms of this behaviour and I can also put in a hack that will clean up the resources by other samplers in the same thread, but the bigger picture of how to prevent the basic memory leak issue that appears to exist for these hanging HTTPSampleResult objects. The main culprit is the responseData byte[], which basically holds the entire response payload. There seems to be no message I can listen for (LoopIterationListener/TestIterationListener) to indicate a thread has made its last iteration. Is there any way to clean up a thread's resources when it is done with. I can't do the cleanup during the iteration as there may be listeners that want the results. Thanks Antony
RE: Feedback and question re Java memory/GC settings for Jmeter load generator CPU issue
Felix, I ran with G1. Results are very interesting. Shame I can't post images, but Using Parallel GC - Baseline CPU was smooth and low, reaching a normal rate of about 11% at the peak end of the test (~82,000 requests/min with 6,080 VU) - memory reached the max 12GB after 1 hour of the test, then did GC, causing spikes of CPU to about 60% and a break in requests of about 2.9 seconds - memory then dropped to just under 8GB Using G1 GC - Baseline CPU was very spiky, fluctuating between 15% and 30% at the same point in the test compared to ParallelGC - memory never reached max, it hit 6.6GB at 20 minutes, before dropping to 4GB and from then on until the test end, slowly saw-toothed up to 7.5GB, never getting close to the max - no break in request pattern GC log analyser says this (hope tables are not too stuffed up) Young Generation, allocated=4 gb, peak=1.01 gb Old Generation, allocated=8 gb, peak=6.1 gb Meta Space, allocated=1.02 gb, peak=22.44 mb Young + Old + Meta space, allocated=13.02 gb, peak=7.13 gb Avg Pause GC Time = 90 ms Max Pause GC Time = 190 ms Duration (secs) No. of GCs Percentage 0 - 0.1 837 78.151% 0.1 - 0.2 234 100.0% A substantial CPU cost to achieve that but I have plenty of capacity on those boxes. I did not run CMS Antony > -Original Message- > From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] > Sent: Tuesday, 20 March 2018 7:41 PM > To: JMeter Users List <user@jmeter.apache.org> > Subject: RE: Feedback and question re Java memory/GC settings for Jmeter > load generator CPU issue > > > > Am 19. März 2018 22:53:19 MEZ schrieb Antony Bowesman > <antony.bowes...@williamhill.com.au>: > >Mmm, I saw the images had gone too :( > > > >I have set up to do a gc log next time I run the test and will dig into > >it. I've been using the default Java8 GC, which is Parallel, so I am > >going to use CMS to see if that makes a difference. I gather it is > >supposed to favour shorter pauses, so I'll see what happens and post > >back results. > > As you have 12gb of heap, you could try to use g1, too. > > On the other hand side, this seems to be quite a lot of heap. What are you > doing in your test plan? > > And as a nice plus, you could tell us about the used versions for jvm, jmeter > and os. > > Regards, > Felix > > > > > > >Cheers > >Antony > > > > > >> -Original Message- > >> From: Kirk Pepperdine [mailto:kirk.pepperd...@gmail.com] > >> Sent: Monday, 19 March 2018 4:39 PM > >> To: JMeter Users List <user@jmeter.apache.org> > >> Subject: Re: Feedback and question re Java memory/GC settings for > >Jmeter > >> load generator CPU issue > >> > >> Hi, > >> > >> The images seem to have been filter out of my email at least. > >> > >> Can you collect and post a GC log. Most likely young gen is too small > >but a gc > >> log would confirm this. > >> > >> Kind regards, > >> Kirk > >> > >> > On Mar 19, 2018, at 3:37 AM, Antony Bowesman > >> <antony.bowes...@williamhill.com.au> wrote: > >> > > >> > Hi, > >> > > >> > I just thought I’d send in some info about a problem I’ve been > >looking at > >> recently – with a question of best GC settings > >> > > >> > I have a number of JMeter load generators (LG) and I have been > >seeing > >> CPU spikes on the boxes during a test. I am monitoring CPU and memory > >> from within a Java sampler, so have the following charts > >> > > >> > 1. First chart shows the request/sec rate (RHS axis) in blue > >and the CPU > >> max % in yellow (sampled every 5s). The blue vertical lines indicate > >a drop in > >> request rate (as recorded by the request finishing and therefore > >being > >> logged) an a corresponding spike to ‘catch up’. I note that the > >spikes always > >> correspond to a spike in CPU. > >> > 2. The second shows the spikes appearing to correlate with > >the increase > >> in committed memory > >> > 3. The third is after the JVM setting change. Note the > >behaviour still > >> occurs in CPU/request rate with a CPU spike in the green circle, but > >not until > >> the later stages. (NB: CPU scale is CPU% * 200 to fit on the graph) > >> > > >> > This behaviour is the same across all the LGs and happens > >regardless of the > >> way the target hosts are reached across the network, so I believe > >it’s a >
RE: Feedback and question re Java memory/GC settings for Jmeter load generator CPU issue
Felix, thanks for the g1 tip, I will try that. Using JMeter 3.3 on Amazon c4.2xlarge, running Linux 4.9.20-11.31.amzn1.x86_64 JVM openjdk version "1.8.0_131" OpenJDK Runtime Environment (build 1.8.0_131-b11) OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode) Each host runs 6080 VU and we run up to 15 hosts. All the samplers are Java samplers, about 12, with custom code that manages thousands of variables that tweak how the threads interact with the server and the 200+ endpoints hit. It's testing pure end-to-end, so is simulating the type of traffic seen on busy days. I've implemented a framework for the samplers that write out metric information for the running threads which goes direct to a Splunk instance, so we get real time reporting, so we just start our instances and load with an ansible playbook and don't have to use the distributed mechanism of JMeter. It's actually a port of some code that used to run on a tool called eggPlant, so it's not your typical JMeter test plan. I've done quite a bit of work to reduce the memory footprint, as eggplant only supported a 32bit JVM :( hence the port to JMeter. We run about 75K requests/min from each host Antony > -Original Message- > From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] > Sent: Tuesday, 20 March 2018 7:41 PM > To: JMeter Users List <user@jmeter.apache.org> > Subject: RE: Feedback and question re Java memory/GC settings for Jmeter > load generator CPU issue > > > > Am 19. März 2018 22:53:19 MEZ schrieb Antony Bowesman > <antony.bowes...@williamhill.com.au>: > >Mmm, I saw the images had gone too :( > > > >I have set up to do a gc log next time I run the test and will dig into > >it. I've been using the default Java8 GC, which is Parallel, so I am > >going to use CMS to see if that makes a difference. I gather it is > >supposed to favour shorter pauses, so I'll see what happens and post > >back results. > > As you have 12gb of heap, you could try to use g1, too. > > On the other hand side, this seems to be quite a lot of heap. What are you > doing in your test plan? > > And as a nice plus, you could tell us about the used versions for jvm, jmeter > and os. > > Regards, > Felix > > > > > > >Cheers > >Antony > > > > > >> -Original Message- > >> From: Kirk Pepperdine [mailto:kirk.pepperd...@gmail.com] > >> Sent: Monday, 19 March 2018 4:39 PM > >> To: JMeter Users List <user@jmeter.apache.org> > >> Subject: Re: Feedback and question re Java memory/GC settings for > >Jmeter > >> load generator CPU issue > >> > >> Hi, > >> > >> The images seem to have been filter out of my email at least. > >> > >> Can you collect and post a GC log. Most likely young gen is too small > >but a gc > >> log would confirm this. > >> > >> Kind regards, > >> Kirk > >> > >> > On Mar 19, 2018, at 3:37 AM, Antony Bowesman > >> <antony.bowes...@williamhill.com.au> wrote: > >> > > >> > Hi, > >> > > >> > I just thought I’d send in some info about a problem I’ve been > >looking at > >> recently – with a question of best GC settings > >> > > >> > I have a number of JMeter load generators (LG) and I have been > >seeing > >> CPU spikes on the boxes during a test. I am monitoring CPU and memory > >> from within a Java sampler, so have the following charts > >> > > >> > 1. First chart shows the request/sec rate (RHS axis) in blue > >and the CPU > >> max % in yellow (sampled every 5s). The blue vertical lines indicate > >a drop in > >> request rate (as recorded by the request finishing and therefore > >being > >> logged) an a corresponding spike to ‘catch up’. I note that the > >spikes always > >> correspond to a spike in CPU. > >> > 2. The second shows the spikes appearing to correlate with > >the increase > >> in committed memory > >> > 3. The third is after the JVM setting change. Note the > >behaviour still > >> occurs in CPU/request rate with a CPU spike in the green circle, but > >not until > >> the later stages. (NB: CPU scale is CPU% * 200 to fit on the graph) > >> > > >> > This behaviour is the same across all the LGs and happens > >regardless of the > >> way the target hosts are reached across the network, so I believe > >it’s a > >> JVM/host issue. > >> > > >> > The original memory settings were >
RE: Feedback and question re Java memory/GC settings for Jmeter load generator CPU issue
Mmm, I saw the images had gone too :( I have set up to do a gc log next time I run the test and will dig into it. I've been using the default Java8 GC, which is Parallel, so I am going to use CMS to see if that makes a difference. I gather it is supposed to favour shorter pauses, so I'll see what happens and post back results. Cheers Antony > -Original Message- > From: Kirk Pepperdine [mailto:kirk.pepperd...@gmail.com] > Sent: Monday, 19 March 2018 4:39 PM > To: JMeter Users List <user@jmeter.apache.org> > Subject: Re: Feedback and question re Java memory/GC settings for Jmeter > load generator CPU issue > > Hi, > > The images seem to have been filter out of my email at least. > > Can you collect and post a GC log. Most likely young gen is too small but a gc > log would confirm this. > > Kind regards, > Kirk > > > On Mar 19, 2018, at 3:37 AM, Antony Bowesman > <antony.bowes...@williamhill.com.au> wrote: > > > > Hi, > > > > I just thought I’d send in some info about a problem I’ve been looking at > recently – with a question of best GC settings > > > > I have a number of JMeter load generators (LG) and I have been seeing > CPU spikes on the boxes during a test. I am monitoring CPU and memory > from within a Java sampler, so have the following charts > > > > 1. First chart shows the request/sec rate (RHS axis) in blue and the > > CPU > max % in yellow (sampled every 5s). The blue vertical lines indicate a drop in > request rate (as recorded by the request finishing and therefore being > logged) an a corresponding spike to ‘catch up’. I note that the spikes always > correspond to a spike in CPU. > > 2. The second shows the spikes appearing to correlate with the > > increase > in committed memory > > 3. The third is after the JVM setting change. Note the behaviour still > occurs in CPU/request rate with a CPU spike in the green circle, but not until > the later stages. (NB: CPU scale is CPU% * 200 to fit on the graph) > > > > This behaviour is the same across all the LGs and happens regardless of the > way the target hosts are reached across the network, so I believe it’s a > JVM/host issue. > > > > The original memory settings were > > > > -Xms1G -Xmx12G -XX:NewSize=1024m -XX:MaxNewSize=4096m > > > > But I changed –Xms12G so that all memory is allocated initially and that > makes a huge change to the behaviour. > > > > However, I still see the CPU spike. Has anyone got some optimum GC > settings they have used that can avoid this? > > > > Thanks > > Antony > > > > > > > > > > > > > > - To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
Feedback and question re Java memory/GC settings for Jmeter load generator CPU issue
Hi, I just thought I'd send in some info about a problem I've been looking at recently - with a question of best GC settings I have a number of JMeter load generators (LG) and I have been seeing CPU spikes on the boxes during a test. I am monitoring CPU and memory from within a Java sampler, so have the following charts 1. First chart shows the request/sec rate (RHS axis) in blue and the CPU max % in yellow (sampled every 5s). The blue vertical lines indicate a drop in request rate (as recorded by the request finishing and therefore being logged) an a corresponding spike to 'catch up'. I note that the spikes always correspond to a spike in CPU. 2. The second shows the spikes appearing to correlate with the increase in committed memory 3. The third is after the JVM setting change. Note the behaviour still occurs in CPU/request rate with a CPU spike in the green circle, but not until the later stages. (NB: CPU scale is CPU% * 200 to fit on the graph) This behaviour is the same across all the LGs and happens regardless of the way the target hosts are reached across the network, so I believe it's a JVM/host issue. The original memory settings were -Xms1G -Xmx12G -XX:NewSize=1024m -XX:MaxNewSize=4096m But I changed -Xms12G so that all memory is allocated initially and that makes a huge change to the behaviour. However, I still see the CPU spike. Has anyone got some optimum GC settings they have used that can avoid this? Thanks Antony [cid:image005.jpg@01D3BF87.6FA2B260] [cid:image006.jpg@01D3BF87.6FA2B260] [cid:image009.jpg@01D3BF87.6FA2B260]
RE: How to diagnose NoHttpResponseException
Hi Phillippe, we have tried the 3.2 build and that has dramatically reduced the
errors, still have a small number, but I will do some digging into those and
I'll see if we can get the nightly build into our test.
Thanks
Antony
> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Monday, 7 August 2017 5:31 PM
> To: JMeter Users List
> Subject: Re: How to diagnose NoHttpResponseException
>
> Hello,
> Those settings are related to your server keep alive timeout.
>
> But there are fixes in both JMeter 3.2 and nightly build.
> Can you give nightly build a try:
> -
> https://apac01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjmet
> er.apache.org%2Fnightly.html=02%7C01%7CAntony.Bowesman%40wi
> lliamhill.com.au%7C9643cd0bfeab4966d99508d4dd66505a%7Cee4fd668f99f4
> f05a74b6405db44621a%7C0%7C0%7C636376878889185773=CD1iO23Q
> ySR3LVYYhUXNVhtg%2FM%2Forw4JAMuHJO6%2BQbk%3D=0
>
> Regards
>
> On Mon, Aug 7, 2017 at 8:43 AM, Antony Bowesman <
> antony.bowes...@williamhill.com.au> wrote:
>
> > I am using JMeter 3.1 and HttpClient4
> > I have the following httpclient settings in user.properties
> >
> > httpclient4.retrycount=3
> > httpclient4.validate_after_inactivity=2
> > httpclient4.time_to_live=180
> >
> > I have 5 load generators and each generator is running approx. 6,000
> > VU across a number of different samplers.
> >
> > We are migrating away from a commercial product, so in addition to
> > this load, I have 3 commercial product load generators running the
> > same profile and the effective server load is 75% JMeter and 25% other
> >
> > We do not have any problems with the commercial product, which we
> have
> > been using for 3 years.
> >
> > CPU and memory are fine on the Linux JMeter boxes, but I am seeing
> > frequent NoHttpResponseException errors
> >
> > I know that the retry logic is happening as in the test I can see
> > these messages appearing and there are far more of these than actual
> > errors and it's logging my retry count as 3
> >
> > 2017/08/07 14:36:09 INFO -
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$7:
> > I/O exception (java.net.SocketException) caught when processing
> > request to
> > {s}->https://host:443: Connection reset
> > 2017/08/07 14:36:09 INFO -
> org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$7:
> > Retrying request to {s}->https://host:443
> >
> > So, I've simplified the test down to a single machine and enabled
> > debug and run the test until I see the first error. I get this in the
> > log, but there is no retry logged
> >
> > 2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.control.CacheManager:
> > GET(OAH) https://host/experience/racing/upcomingracing null
> > 2017/08/07 16:06:32 DEBUG -
> jmeter.protocol.http.control.HC4CookieHandler:
> > Found 6 cookies for https:// host/experience/racing/upcomingracing
> > 2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.control.CacheManager:
> > inCache https:// host/experience/racing/upcomingracing null
> > 2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
> > IOException org.apache.http.NoHttpResponseException: host:443 failed
> > to respond
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(
> > DefaultHttpResponseParser.java:143)
> > at
> > org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(
> > DefaultHttpResponseParser.java:57)
> > at org.apache.http.impl.io.AbstractMessageParser.parse(
> > AbstractMessageParser.java:259)
> > at org.apache.http.impl.AbstractHttpClientConnection.
> > receiveResponseHeader(AbstractHttpClientConnection.java:281)
> > at org.apache.http.impl.conn.DefaultClientConnection.
> > receiveResponseHeader(DefaultClientConnection.java:259)
> > at org.apache.http.impl.conn.ManagedClientConnectionImpl.
> > receiveResponseHeader(ManagedClientConnectionImpl.java:209)
> > at org.apache.jmeter.protocol.http.sampler.
> >
> MeasuringConnectionManager$MeasuredConnection.receiveResponseHea
> der(
> > MeasuringConnectionManager.java:212)
> > at
> > org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(
> > HttpRequestExecutor.java:273)
> > at org.apache.http.protocol.HttpRequestExecutor.execute(
> > HttpRequestExecutor.java:125)
> > at
> > org.apache.http.impl.client.DefaultRequestDirector.tryExecute(
> > DefaultRequestDirector.java:686)
> > at o
How to diagnose NoHttpResponseException
I am using JMeter 3.1 and HttpClient4
I have the following httpclient settings in user.properties
httpclient4.retrycount=3
httpclient4.validate_after_inactivity=2
httpclient4.time_to_live=180
I have 5 load generators and each generator is running approx. 6,000 VU across
a number of different samplers.
We are migrating away from a commercial product, so in addition to this load, I
have 3 commercial product load generators running the same profile and the
effective server load is 75% JMeter and 25% other
We do not have any problems with the commercial product, which we have been
using for 3 years.
CPU and memory are fine on the Linux JMeter boxes, but I am seeing frequent
NoHttpResponseException errors
I know that the retry logic is happening as in the test I can see these
messages appearing and there are far more of these than actual errors and it's
logging my retry count as 3
2017/08/07 14:36:09 INFO -
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$7: I/O exception
(java.net.SocketException) caught when processing request to
{s}->https://host:443: Connection reset
2017/08/07 14:36:09 INFO -
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$7: Retrying request to
{s}->https://host:443
So, I've simplified the test down to a single machine and enabled debug and run
the test until I see the first error. I get this in the log, but there is no
retry logged
2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.control.CacheManager: GET(OAH)
https://host/experience/racing/upcomingracing null
2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.control.HC4CookieHandler:
Found 6 cookies for https:// host/experience/racing/upcomingracing
2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.control.CacheManager: inCache
https:// host/experience/racing/upcomingracing null
2017/08/07 16:06:32 DEBUG - jmeter.protocol.http.sampler.HTTPHC4Impl:
IOException org.apache.http.NoHttpResponseException: host:443 failed to respond
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281)
at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:259)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:209)
at
org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:212)
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:686)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:488)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:654)
at
org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:413)
at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at
org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1166)
at
au.com.williamhill.perftest.endpoint.Browser.sendRequest(Browser.java:202)
at
au.com.williamhill.perftest.jmeter.samplers.Command.sendRequest(Command.java:462)
at
au.com.williamhill.perftest.jmeter.samplers.Command.sendUrls(Command.java:531)
at
au.com.williamhill.perftest.jmeter.samplers.Command.postUrls(Command.java:271)
at
au.com.williamhill.perftest.jmeter.samplers.ViewRace.viewRace(ViewRace.java:162)
at
au.com.williamhill.perftest.jmeter.samplers.ViewRace.runTest(ViewRace.java:113)
at
org.apache.jmeter.protocol.java.sampler.JavaSampler.sample(JavaSampler.java:196)
at
org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:475)
at
org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:418)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:249)
at java.lang.Thread.run(Thread.java:748)
The request sequence is for the virtual user is
1. Request 1 starts at 16:06:07.982
2. Requests 2...17 all successful
RE: Sending cookies to non origin domains
I do this
cookieManager.setImplementation(HC4CookieHandler.class.getName());
cookieManager.setCookiePolicy("standard");
cookieManager.testStarted();
I see that I BasicDomainHandler.domainMatch() will support wildcarding, so I
have currently solved it by fooling the Cookie into thinking the domain was
specified
Cookie.setDomainSpecified(true)
And then trimming of the upper part of the domain.
> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Friday, 2 June 2017 3:10 PM
> To: JMeter Users List
> Subject: Re: Sending cookies to non origin domains
>
> Hello,
> What policy are you using for Cookie Manager ?
> Thanks
>
> On Friday, June 2, 2017, Antony Bowesman
> <antony.bowes...@williamhill.com.au>
> wrote:
>
> > All my samplers are Java samplers, so I am pretty much doing what you
> > suggest in my code, but I worked out that the BasicDomainHandler, used
> > by the CookieSpec handler, will allow the Cookie if I post process the
> > set-cookie and change the provided domain from api.xxx to just xxx and
> > set the domanSpecified to true
> >
> > c.setDomain("xxx");
> > c.setDomainSpecified(true);
> >
> > Thanks
> >
> >
> > > -Original Message-
> > > From: 易, [mailto:sc.yi...@gmail.com <javascript:;>]
> > > Sent: Friday, 2 June 2017 12:09 PM
> > > To: JMeter Users List
> > > Subject: Re: Sending cookies to non origin domains
> > >
> > > You can add "JSR223 PostProcessor" as the child of your sampler.
> > > Then put the following code in the script, now you can change the
> > > domain of all
> > your
> > > cookies to the new domain.
> > >
> > > import org.apache.jmeter.protocol.http.control.CookieManager;
> > > import org.apache.jmeter.protocol.http.control.Cookie;
> > >
> > > CookieManager manager = sampler.getCookieManager(); int count =
> > > manager.getCookieCount(); for(int i=0;i<count;i++){ Cookie cookie =
> > > manager.get(i); cookie.setDomain(vars.get("domain"));
> > > }
> > >
> > > 2017-06-02 6:57 GMT+08:00 Antony Bowesman <
> > > antony.bowes...@williamhill.com.au <javascript:;>>:
> > >
> > > > Hi,
> > > >
> > > > I am using JMeter 3.1, HttpClient4 and HC4CookieHandler and after
> > > > login am getting .ASPXAUTH cookies sent to me for domain
> > > >
> > > > api.xxx
> > > >
> > > > Our real clients are then sending those cookies back to
> > > >
> > > > services.xxx
> > > >
> > > > which then talks to api.xxx and of course forwards the cookies.
> > > >
> > > > However, jmeter is (correctly) not sending the cookie from api.xxx
> > > > back to services.xxx, so when the request goes internally to
> > > > api.xxx that thinks I am not logged in.
> > > >
> > > > Is there any way I can get JMeter to send those cookies back to
> > > > the non originating domain?
> > > >
> > > > Cheers
> > > > Antony
> > > >
> > > >
> > >
> > >
> > > --
> > > Best Regards
> > >
> > > Wei
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
RE: Sending cookies to non origin domains
standard
> -Original Message-
> From: Philippe Mouawad [mailto:philippe.moua...@gmail.com]
> Sent: Friday, 2 June 2017 3:10 PM
> To: JMeter Users List
> Subject: Re: Sending cookies to non origin domains
>
> Hello,
> What policy are you using for Cookie Manager ?
> Thanks
>
> On Friday, June 2, 2017, Antony Bowesman
> <antony.bowes...@williamhill.com.au>
> wrote:
>
> > All my samplers are Java samplers, so I am pretty much doing what you
> > suggest in my code, but I worked out that the BasicDomainHandler, used
> > by the CookieSpec handler, will allow the Cookie if I post process the
> > set-cookie and change the provided domain from api.xxx to just xxx and
> > set the domanSpecified to true
> >
> > c.setDomain("xxx");
> > c.setDomainSpecified(true);
> >
> > Thanks
> >
> >
> > > -Original Message-
> > > From: 易, [mailto:sc.yi...@gmail.com <javascript:;>]
> > > Sent: Friday, 2 June 2017 12:09 PM
> > > To: JMeter Users List
> > > Subject: Re: Sending cookies to non origin domains
> > >
> > > You can add "JSR223 PostProcessor" as the child of your sampler.
> > > Then put the following code in the script, now you can change the
> > > domain of all
> > your
> > > cookies to the new domain.
> > >
> > > import org.apache.jmeter.protocol.http.control.CookieManager;
> > > import org.apache.jmeter.protocol.http.control.Cookie;
> > >
> > > CookieManager manager = sampler.getCookieManager(); int count =
> > > manager.getCookieCount(); for(int i=0;i<count;i++){ Cookie cookie =
> > > manager.get(i); cookie.setDomain(vars.get("domain"));
> > > }
> > >
> > > 2017-06-02 6:57 GMT+08:00 Antony Bowesman <
> > > antony.bowes...@williamhill.com.au <javascript:;>>:
> > >
> > > > Hi,
> > > >
> > > > I am using JMeter 3.1, HttpClient4 and HC4CookieHandler and after
> > > > login am getting .ASPXAUTH cookies sent to me for domain
> > > >
> > > > api.xxx
> > > >
> > > > Our real clients are then sending those cookies back to
> > > >
> > > > services.xxx
> > > >
> > > > which then talks to api.xxx and of course forwards the cookies.
> > > >
> > > > However, jmeter is (correctly) not sending the cookie from api.xxx
> > > > back to services.xxx, so when the request goes internally to
> > > > api.xxx that thinks I am not logged in.
> > > >
> > > > Is there any way I can get JMeter to send those cookies back to
> > > > the non originating domain?
> > > >
> > > > Cheers
> > > > Antony
> > > >
> > > >
> > >
> > >
> > > --
> > > Best Regards
> > >
> > > Wei
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
-
To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
For additional commands, e-mail: user-h...@jmeter.apache.org
RE: Sending cookies to non origin domains
All my samplers are Java samplers, so I am pretty much doing what you suggest
in my code, but I worked out that the BasicDomainHandler, used by the
CookieSpec handler, will allow the Cookie if I post process the set-cookie and
change the provided domain from api.xxx to just xxx and set the domanSpecified
to true
c.setDomain("xxx");
c.setDomainSpecified(true);
Thanks
> -Original Message-
> From: 易, [mailto:sc.yi...@gmail.com]
> Sent: Friday, 2 June 2017 12:09 PM
> To: JMeter Users List
> Subject: Re: Sending cookies to non origin domains
>
> You can add "JSR223 PostProcessor" as the child of your sampler. Then put
> the following code in the script, now you can change the domain of all your
> cookies to the new domain.
>
> import org.apache.jmeter.protocol.http.control.CookieManager;
> import org.apache.jmeter.protocol.http.control.Cookie;
>
> CookieManager manager = sampler.getCookieManager(); int count =
> manager.getCookieCount(); for(int i=0;i<count;i++){ Cookie cookie =
> manager.get(i); cookie.setDomain(vars.get("domain"));
> }
>
> 2017-06-02 6:57 GMT+08:00 Antony Bowesman <
> antony.bowes...@williamhill.com.au>:
>
> > Hi,
> >
> > I am using JMeter 3.1, HttpClient4 and HC4CookieHandler and after
> > login am getting .ASPXAUTH cookies sent to me for domain
> >
> > api.xxx
> >
> > Our real clients are then sending those cookies back to
> >
> > services.xxx
> >
> > which then talks to api.xxx and of course forwards the cookies.
> >
> > However, jmeter is (correctly) not sending the cookie from api.xxx
> > back to services.xxx, so when the request goes internally to api.xxx
> > that thinks I am not logged in.
> >
> > Is there any way I can get JMeter to send those cookies back to the
> > non originating domain?
> >
> > Cheers
> > Antony
> >
> >
>
>
> --
> Best Regards
>
> Wei
HTTP requests and HeaderManager
Could be way off target here, as I'm a bit of a newbie. I have a custom java sampler that uses a HeaderManager to manage headers in multiple requests. My sampler makes a number of http requests in a single sample to form part of a dynamic 'transaction' and this means that different requests may need different headers, e.g. some could be GET, some POST, some require CSRF headers etc. I'm using an HTTPSamplerBase implementation and it appears there's no distinction between a default header and a request header that just applies to the request to be sent, could be wrong, but I can't see any way to separate the two in the API. My solution is to manage default and request headers is a wrapper class that will remove headers after the request is made, so they do not pollute subsequent requests. However, from my basic reading of the code, the header manager is using an ArrayList to store headers and to remove a header, it has to iterate that list. Is there any reason why it would not be more sensible to use a LinkedHashSet. Slightly additional overhead in storage, but much faster in removing elements. Cheers
Finding CookieManager from within test sampler
I have a test where I have a CookieManager assigned to a thread group. I have written a custom JavaSamplerClient where I am using the HTTPSamplerFactor to create a HTTPSamplerBase object within that java client - I use it to manage multiple requests, hence rolling my own. I can add a new CookieManager instance to that sampler and have that working fine, but what I want to do is to get the CM that has been assigned to the TG, but I can't find it. If I get the AbstractThreadGroup, I have traversed the TG and have the following test elements in a thread group Start:testElement=Ajax_1" Start:property=TestElement.gui_class(org.apache.jmeter.threads.gui.ThreadGroupGui)" Start:property=TestElement.test_class(org.apache.jmeter.threads.ThreadGroup)" Start:property=TestElement.name(Ajax_1)" Start:property=TestElement.enabled(true)" Start:property=ThreadGroup.on_sample_error(continue)" Start:property=ThreadGroup.main_controller(org.apache.jmeter.control.LoopController@27f9f8f5)" Start:testElement=Loop Controller" Start:property=LoopController.continue_forever(false)" Start:property=TestElement.gui_class(org.apache.jmeter.control.gui.LoopControlPanel)" Start:property=TestElement.test_class(org.apache.jmeter.control.LoopController)" Start:property=TestElement.name(Loop Controller)" Start:property=TestElement.enabled(true)" Start:property=LoopController.loops(2)" Start:property=ThreadGroup.num_threads(2)" Start:property=ThreadGroup.ramp_time(1)" Start:property=ThreadGroup.start_time(1482116187000)" Start:property=ThreadGroup.end_time(1482116187000)" Start:property=ThreadGroup.scheduler(false)" Start:property=ThreadGroup.duration()" Start:property=ThreadGroup.delay()" But I have a CM declared for the test and I can't seem to get hold of it from within my sampler. Anyone know how I can get hold of the instance? Antony
