Your response is really interesting. I already tried with log_level.jmeter.protocol.tcp=DEBUG setting and also looked into LengthPrefixedBinaryTCPClientImpl class. I too found that there were two writes. But not sure if the two writes correspond to two sends.
But the above setting I was unable to see the data length being sent as a separate request. Anyhow, I will set the settings you have specified and will analyse and share the log details. On Tue, Jun 17, 2014 at 12:49 PM, Jeff Ohrstrom <[email protected]> wrote: > 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] > >
