Feature Request: Add option to handle binary response as text
In our particular scenario our server responds with binary frames, however when the response is treated as binary-encoded text then we can view the response in the view results tree.
Right now we have to add a BeanShell listener to each reponse in order to set the following command:
// Set the response data type as text to display in "View Results Tree"
sampleResult.setDataType( org.apache.jmeter.samplers.SampleResult.TEXT );
Please add this as an option to the WebSocket Single Read Sampler
Extra Bonus: As our server accepts json plain-text as the request, however responds with a binary response, I can never use the request-response sampler, as the sampler would assumes/awaits a text frame from the server when I choose to send my requests as plain-text.
Comments (8)
-
repo owner -
repo owner - changed status to wontfix
-
repo owner But i will add the binary renderer: https://bitbucket.org/pjtr/jmeter-websocket-samplers/branch/renderbinary
-
repo owner Support for rendering binary responses is included in release 0.8
-
@Anonymous
Where did you add
sampleResult.setDataType( org.apache.jmeter.samplers.SampleResult.TEXT );
I would like to have this feature too! ;)
-
repo owner Why??
-
Because of this problem:
-
repo owner You can simply view the binary data in the Results, see screenshot above.
Doing something as
setDataType(TEXT)
doesn't make sense, because (usually) the binary data won't be text (if it was, why use a binary frame?) and trying to interpret it as text will fail. - Log in to comment
Thanks for your feedback. It's good to know more people need binary websocket support and also want display support.
However, i think we should add this functionality where it belongs, and this is in JMeter. JMeter already has support for viewing response data in various formats, but unfortunately binary format is not one of them. Fortunately, adding a new renderer is not as difficult as i initially thought it was, as this screenshot of my first proof-of-concept shows:
(note the "Binary" label in the type selector!), so this is the way to go for displaying binary responses.
As for the "extra bonus": that would not come for free with this addition, because the request/response sampler expects a text-frame in return on sending a text-frame, so in your case, it would still throw an "unexpected frame type" exception.