I could be mistaken, but it would appear that in the code it calls
OutputStream.write twice and this could be causing your issue, although
flushing on the second time, the JVM could have decided to flush after
the first write call. I list the debug settings here, but a tcp dump may
be necessary to see if there are 1 or 2 packets being written out on the
wire (Java tends to abstract that). Could it be that 2 packets means to
'recv' calls (and 1 packet is 1 recv call)?
I would add the debug lines to see what they say it's doing:
log_level.org.apache.jmeter.protocol.tcp.sampler.LengthPrefixedBinaryTCPClientImpl=DEBUG
log_level.org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl=DEBUG
>From LengthPrefixedBinaryTCPClientImpl.java:
@Override
public void write(OutputStream os, String s) throws IOException{
os.write(intToByteArray(s.length()/2,lengthPrefixLen)); //first write
if(log.isDebugEnabled()) {
log.debug("Wrote: " + s.length()/2 + " bytes");
}
this.tcpClient.write(os, s); //second write
}
On Mon, 2014-06-16 at 20:06 +0530, Vinoth raj wrote:
> Thanks for the response.
> I indeed send hex-encoded string only.
> The length of the message is something the Jmeter calcultates based on the
> text in put in Text to Send field. So, I guess I need not worry about that.
>
> So, when I send the hex encoded data, on the server side I get first
> message as the message length and the second message the actual data. So
> one request on Jmeter side leads to two "recv" calls on server side.
>
> Could you explain how to receive the complete request in one single recv
> call?
>
>
>
>
> On Sat, Jun 14, 2014 at 6:14 PM, 黄吉浩 <[email protected]> wrote:
>
> > I think I understand you, and I try to clarify this problem by example:
> > when using "LengthPrefixedBinaryTCPClientImpl" as the "TcpClient
> > classname", the input in "Text to send" should be hex-encoded string.
> > i.e. if you want to send 1-byte message of 'A' to server, so the "Text to
> > send" should be "41" (hex-representation of 'A')
> > and what Jmeter do is:
> > 1, caculate the actual length of contents in "Text to send", that is 2/2 =
> > 1 ('A' occupys 1 byte, but representation "41" occupys 2 byte, so 2/2)
> > 2, populate the value of lengh(here is 1) in 2 bytes and send to your
> > server (supposed u r using default, that is,
> > tcp.binarylength.prefix.length=2 in jmeter.properties)
> > 3, send the 1-byte message body to ur server
> > that's all.
> >
> >
> >
> >
> > At 2014-06-13 00:14:26, "-Vinoth raj" <[email protected]> wrote:
> > >Hi All,
> > >
> > >I am trying to send a message to my server application developed in C++
> > >using LengthPrefixedBinaryTCPClientImpl class.
> > >
> > >On the server side I get the length and data in two recv (socket function)
> > >calls.
> > >I presume that normally this is not the case as the first two bytes of the
> > >data itself should contain the data length.
> > >
> > >EXAMPLE:
> > >For example, if I send 131 bytes data Jmeter should send 133 bytes with
> > the
> > >first two bytes containing the data length.
> > >On enabling debug mode for the TCP sampler I found that the actual data
> > >sent is logged as 131.
> > >
> > >Also, strangely if I run both Jmeter and the server application on same
> > >machine I see the expected behaviour. I actually get 133 bytes in a single
> > >recv call.
> > >
> > >I would appreciate if anyone can shed light on the actual behaviour of the
> > >Jmeter.
> > >
> > >Vinoth
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
