First you cannot catch errors in another sampler (or post-processor) because the error has already occurred, so that won't really help you. You can retroactively make the sample successful, but by then so much time will have passed (because the connection timed out) it will severely throw off your results.
It seems you have 2 options. The first (and much easier if it applies to you) is to use the LengthPrefixedBinaryTCPClientImpl. If this applies to you, that is, if your responses are always the same fixed sizes, you can simply set the tcp.binarylength.prefix.length property and go about your business. If that is not the case, then your other option is to extend org.apache.jmeter.protocol.tcp.sampler.TCPClient. It may help to get in touch with the client team of this proprietary protocol, because after all, they have implemented something that works. You'll probably have to extend it to look something like LengthPrefixedBinaryTCPClientImpl only instead of being fixed it's able to read the header information and read N bytes. Although, this runs the risks of reading too many or too few bytes. If your application server ever miscalculates the size of it's output, you suffer the consequences by getting another timeout or leaving extra bytes in the buffer and reading them on the next iteration (and then cascading errors). http://jmeter.apache.org/usermanual/component_reference.html#TCP_Sampler I know this is quite long, but I hope some of it helps. On Tue, 2014-06-24 at 11:55 +0200, Andreas Mailing wrote: > Hi all, > > I have to test an application which is listening on a tcp port speaking a > proprietary protocol. > I set up a test using tcp sampler. Jmeter is showing the correct response, > but it is waiting till given response timeout. Then the following exception > is thrown: > > 2014/06/24 10:47:42 ERROR - jmeter.protocol.tcp.sampler.TCPSampler: > org.apache.jmeter.protocol.tcp.sampler.ReadException: > at > org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl.read(BinaryTCPClientImpl.java:140) > at > org.apache.jmeter.protocol.tcp.sampler.TCPSampler.sample(TCPSampler.java:414) > at > org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257) > at java.lang.Thread.run(Unknown Source) > Caused by: java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(Unknown Source) > at java.net.SocketInputStream.read(Unknown Source) > at java.net.SocketInputStream.read(Unknown Source) > at > org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl.read(BinaryTCPClientImpl.java:126) > > Thats nearly acceptable for qualitative testing, but a no go for load testing. > > The protocol is divided into header and data. In the header the header's > lentgh and length of data is defined. > Unfortunately there is no fix byte / character which is marking the end of > the response such as \n or \r. > > Because the protocol is given as is I need a way to calculate the eol > dynamically and give set the value in jmeter for each packet. > > I need to do the following: > > 1. extracting the bytes for header length and data length out of each response > 2. add them to get the given length of response > 3. set the result in jmeter as response length for current response > 4. -> jmeter will only read the current packet, and goes on to response > assertions, etc. -> no error is thrown > > Please give any advise how to do this. > > Biggest question: How can I define the end of line / message dynamically in > jmeter. I do not have any idea. > Additional question: Is a post processor or an assertion the correct position > to calculate the end of the packet? > > Many thanks in advance, > Andreas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
