https://issues.apache.org/bugzilla/show_bug.cgi?id=52072
Bug #: 52072
Summary: LengthPrefixedBinaryTcpClientImpl may end a sample
prematurely and report wrong response time
Product: JMeter
Version: 2.5.1
Platform: PC
Status: NEW
Severity: normal
Priority: P2
Component: Main
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
LengthPrefixedBinaryTcpClientImpl may end a sample prematurely in a network
environment with small MSS or client with shortage of TCP buffer.
In LengthPrefixedBinaryTcpClientImp.java, the sampler does a single read on the
inputstream after the length of the message is determined:
/**
* {@inheritDoc}
*/
public String read(InputStream is) {
byte[] msg = new byte[0];
int msgLen = 0;
try {
byte[] lengthBuffer = new byte[lengthPrefixLen];
if (is.read(lengthBuffer, 0, lengthPrefixLen) == lengthPrefixLen) {
msgLen = byteArrayToInt(lengthBuffer);
msg = new byte[msgLen];
int bytes = is.read(msg);
if (bytes < msgLen){
log.warn("Incomplete message read, expected: "+msgLen+"
got: "+bytes);
}
}
} catch (SocketTimeoutException e) {
// drop out to handle buffer
} catch (InterruptedIOException e) {
// drop out to handle buffer
} catch (IOException e) {
log.warn("Read error:" + e);
}
String buffer = JOrphanUtils.baToHexString(msg);
log.debug("Read: " + msgLen + "\n" + buffer);
return buffer;
}
In a network with small MSS or a client with shortage of buffer (e.g. during a
stress test), the response message may not be returned completely in just one
call to is.read(msg). When this occurs, the sampler mistakenly assumes that the
response is complete and leads to the following problems. Let's call the first
sample S1, the next one S2 etc.
1. It reports a wrong response time shorter than the actual one for S1
2. In case "Re-use connection" is set to true, the remaining bytes of the
response message of S1 in the TCP stream confuses the sampler in the next
sample, S2. The sampler thinks that these bytes are the initial part of the
response of S2 and therefore reports another wrong and unrealistically short
response time for S2. Worse, it now sends yet another new sample S3 because it
thinks that S2 has completed. This may cause problem to the server side if the
server side assumes the stop-and-wait nature of the connection in order to
function correctly.
In other words, this bug may render the stress test ineffective in these
circumstances because of the wrong response times and problems triggered on the
server side.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
