Author: sebb
Date: Fri Sep 23 19:00:10 2011
New Revision: 1174955
URL: http://svn.apache.org/viewvc?rev=1174955&view=rev
Log:
Synch docs
Modified:
jakarta/jmeter/trunk/docs/changes.html
jakarta/jmeter/trunk/docs/usermanual/component_reference.html
jakarta/jmeter/trunk/docs/usermanual/remote-test.html
Modified: jakarta/jmeter/trunk/docs/changes.html
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/changes.html?rev=1174955&r1=1174954&r2=1174955&view=diff
==============================================================================
--- jakarta/jmeter/trunk/docs/changes.html (original)
+++ jakarta/jmeter/trunk/docs/changes.html Fri Sep 23 19:00:10 2011
@@ -223,13 +223,17 @@ Incompatible changes
</h2>
<p>
-The HttpClient4 sampler as implemented in version 2.5 used a retry count of 3.
-As this can hide server errors, JMeter now sets the retry count to 0 to
prevent any automatic retries.
-This can be overridden by setting the JMeter property
-<b>
-httpclient4.retrycount
-</b>
-.
+The HttpClient4 and Commons HttpClient 3.1 samplers previously used a retry
count of 3.
+This has been changed to default to 1, to be compatible with the Java
implementation.
+The retry count can be overridden by setting the relevant JMeter property, for
example:
+
+<pre>
+
+httpclient4.retrycount=3
+httpclient3.retrycount=3
+
+</pre>
+
</p>
<h2>
@@ -257,11 +261,6 @@ Bug 51750 - Retrieve all embedded resour
<li>
-Change the default so the HttpClient 4 sampler does not retry
-</li>
-
-
-<li>
Bug 51752 - HTTP Cache is broken when using "Retrieve all embedded resources"
with concurrent pool
</li>
@@ -425,6 +424,11 @@ Bug 51855 - Parent samples may have slig
</li>
+<li>
+Bug 51880 - The shutdown command is not working if I invoke it before all the
thread are started
+</li>
+
+
</ul>
<h2>
Improvements
@@ -440,6 +444,16 @@ Bug 51380 - Control reuse of cached SSL
</li>
+<li>
+Bug 51882 - HTTPHC3Client uses a default retry count of 3, make it
configurable; default is now 1
+</li>
+
+
+<li>
+Change the default HttpClient 4 sampler retry count to 1
+</li>
+
+
</ul>
<h3>
Other samplers
@@ -493,6 +507,11 @@ Timers, Assertions, Config, Pre- & Post-
<ul>
+<li>
+Bug 51885 - Allow a JMeter Variable as input to XPathExtractor
+</li>
+
+
</ul>
<h3>
Functions
@@ -519,6 +538,11 @@ Bug 51822 - (part 1) save 1 invocation o
</li>
+<li>
+Added AsynchSampleSender which sends samples from server to client
asynchronously.
+</li>
+
+
</ul>
<h2>
Non-functional changes
Modified: jakarta/jmeter/trunk/docs/usermanual/component_reference.html
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/usermanual/component_reference.html?rev=1174955&r1=1174954&r2=1174955&view=diff
==============================================================================
--- jakarta/jmeter/trunk/docs/usermanual/component_reference.html (original)
+++ jakarta/jmeter/trunk/docs/usermanual/component_reference.html Fri Sep 23
19:00:10 2011
@@ -1331,13 +1331,17 @@ Retry handling
<br>
</br>
-In version 2.5 of JMeter, the HttpClient4 sampler used the default retry
count, which was 3.
-As this can hide server errors, JMeter now sets the retry count to 0 to
prevent any automatic retries.
-This can be overridden by setting the JMeter property
-<b>
-httpclient4.retrycount
-</b>
-.
+In version 2.5 of JMeter, the HttpClient4 and Commons HttpClient 3.1 samplers
used the default retry count, which was 3.
+In later versions, the retry count has been set to 1, which is what the Java
implementation appears to do.
+The retry count can be overridden by setting the relevant JMeter property, for
example:
+
+<pre>
+
+httpclient4.retrycount=3
+httpclient3.retrycount=3
+
+</pre>
+
</p>
<p><b>See Also:</b>
@@ -14741,7 +14745,7 @@ This test element allows the user to ext
query language.
<p><b>Control Panel</b></p>
-<div align="center"><img width='612' height='318'
src="../images/screenshots/xpath_extractor.png"></div>
+<div align="center"><img width='729' height='317'
src="../images/screenshots/xpath_extractor.png"></div>
<p>
<b>Parameters</b>
<a name="XPath_Extractor_parms"/>
@@ -14779,6 +14783,11 @@ Main sample and sub-samples - applies to
</li>
+<li>
+JMeter Variable - assertion is to be applied to the contents of the named
variable
+</li>
+
+
</ul>
XPath matching is applied to all qualifying samples in turn, and all
the matching results will be returned.
Modified: jakarta/jmeter/trunk/docs/usermanual/remote-test.html
URL:
http://svn.apache.org/viewvc/jakarta/jmeter/trunk/docs/usermanual/remote-test.html?rev=1174955&r1=1174954&r2=1174955&view=diff
==============================================================================
--- jakarta/jmeter/trunk/docs/usermanual/remote-test.html (original)
+++ jakarta/jmeter/trunk/docs/usermanual/remote-test.html Fri Sep 23 19:00:10
2011
@@ -540,15 +540,17 @@ The chosen port will be logged in the se
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#828DA6">
<font color="#ffffff" face="arial,helvetica,sanserif">
-<a name="batchmode"><strong>15.4 Using sample batching</strong></a>
-<a class="sectionlink" href="#batchmode" title="Link to here">¶</a></font>
+<a name="sendermode"><strong>15.4 Using a different sample sender</strong></a>
+<a class="sectionlink" href="#sendermode" title="Link to
here">¶</a></font>
</td></tr>
<tr><td>
<blockquote>
<p>
Listeners in the test plan send their results back to the client JMeter which
writes the results to the specified files
-By default, samples are sent back as they are generated. This can place a
large load on the network and the JMeter client.
+By default, samples are sent back synchronously as they are generated.
+This can affect the maximum throughput of the server test; the sample result
has to be sent back before the thread can
+continue.
There are some JMeter properties that can be set to alter this behaviour.
</p>
@@ -556,7 +558,7 @@ There are some JMeter properties that ca
<li>
-mode - sample sending mode - default is Standard
+mode - sample sending mode - default is Standard. This should be set on the
client node.
</li>
@@ -564,7 +566,7 @@ mode - sample sending mode - default is
<li>
-Standard - send samples as soon as they are generated
+Standard - send samples synchronously as soon as they are generated
</li>
@@ -574,7 +576,8 @@ Hold - hold samples in an array until th
<li>
-Batch - send saved samples when either the count or time exceeds a threshold
+Batch - send saved samples when either the count or time exceeds a threshold,
+ at which point the samples are sent synchronously. See also the Asynch
mode, described below.
</li>
@@ -629,6 +632,24 @@ StrippedBatch - remove responseData from
<li>
+Asynch - samples are temporarily stored in a local queue. A separate worker
thread sends the samples.
+ This allows the test thread to continue without waiting for the result
to be sent back to the client.
+ However, if samples are being created faster than they can be sent,
the queue will eventually fill up,
+ and the sampler thread will block until some samples can be drained
from the queue.
+ This mode is useful for smoothing out peaks in sample generation.
+ The queue size can be adjusted by setting the JMeter property
+
+<b>
+<code>
+asynch.batch.queue.size
+</code>
+</b>
+ (default 20) on the client node.
+
+</li>
+
+
+<li>
Custom implementation : set the mode parameter to your custom sample sender
class name.
This must implement the interface SampleSender and have a constructor
which takes a single
parameter of type RemoteSampleListener.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
