While running a stress test against an HTTP server which has an authentication process (401+challenge,200) I get the JMeter (v2.11) log full of these:
2015/02/17 13:52:48 ERROR - jmeter.protocol.http.sampler.HTTPJavaImpl: readResponse: java.io.IOException: Server returned HTTP response code: 401 for URL: http://w1-load1:8080/perftest/login
2015/02/17 13:53:04 ERROR - jmeter.protocol.http.sampler.HTTPJavaImpl: Cause: java.io.IOException: Server returned HTTP response code: 401 for URL: http://w1-load1:8080/perftest/login
2015/02/17 13:53:08 INFO - jmeter.protocol.http.sampler.HTTPJavaImpl: Error Response Code: 401
I don't mind the HTTP 401 , I handle those in the next request (by design)
in the BeanShell post processor I read these 401 and "make" them ok (using prev.setResponseOK() ).
setting the response code in the BeanShell doesn't prevent the initial IOException.
The problem occur also when not using BeanShell at all.
However, under stress,with many threads, these errors cost me 10% of JMeter output rate (tested against a service which doesn't return 401).
I saw that the rate of error in the JMeter log is approximately 20 lines/sec.
tested also with JMeter remote agents.
can some one explain how to avoid those log lines or how I can remove them ?
if I fail to write the BeanShell directive the log gets even larger exception:
and the request is considered a failure.
The Log Messages format is probably
#log_format=%{time:yyyy/MM/dd HH:mm:ss} %5.5{priority} - %{category}: %{message} %{throwable}
In this case the logging is not from BeanShell but jmeter.protocol.http.sampler.HTTPJavaImpl.
You can control this logging in the JMeter properties file or user properties file.
The logging configuration file is well documented in the source of the jmeter.properties file.
You can turn down logging by controlling at the package or class level.
Anything that is below this package name will only log on FATAL_ERROR
log_level.jmeter.protocol.http=FATAL_ERROR
Or at that class level, only impacting the HTTPJavaImpl
log_level.jmeter.protocol.http.sampler.HTTPJavaImpl=FATAL_ERROR
I tested the following using this load test and JMX just changing the Implementation to see the different log statements.
Finally in your case your are using HTTPJavaImpl, if you were to use HTTPClient4 the logging is a bit different and does not seem to log 401 return values or treat them as exceptions.
jmeter.properties: you can change the Sampler implementation:
jmeter.httpsampler=HTTPSampler2
Related
I tried to run a POST method for API testing in JMeter, I have sent the parameters as needed in body using a csv file. It works with https url(domain url) but not working in localhost. In localhost, requested body is showing blank. Please help me to resolve this issue.
There should be no any difference between local and non-local URLs so most probably you made a configuration mistake somewhere. We cannot state where exactly without seeing the test plan so I would suggest:
Inspect request and response details using View Results Tree listener
Ensure that the variables originating from the CSV Data Set Config really exist and have their respective values by adding a Debug Sampler and seeing what variables are there.
Check jmeter.log file for any suspicious entries. If it doesn't say anything meaningful you can try increasing logging verbosity to DEBUG level.
Recorded Blazemeter scripts are not working in JMeter, getting following error message.
Response code: Non HTTP response code: java.net.SocketException
Response message: Non HTTP response message: Software caused connection abort: recv failed
The error indicates that JMeter fails to receive the response most probably due to network error (connection has been terminated or timed out)
In order to get more information you should increase JMeter Logging verbosity for Apache HttpComponents by adding the next line to log4j2.xml file
<Logger name="org.apache.http" level="debug" />
it would also be a good idea to enable network debugging on Java level, it can be done by adding the next line to system.properties file:
javax.net.debug=all
and you should get way more information in jmeter.log file and STDOUT, this way you will get the error reason and would be able to handle it.
It worth also checking:
that your application is not overloaded as it might be the case the application cannot handle the load delivered by JMeter hence fails to respond properly
if you're absolutely sure that the application works normally and the problem is at JMeter end you can follow workarounds from JMeterSocketClosed wiki page
Using:
JMeter version 5.4.1
Browsers:
MS Edge 94.0
Google Chrome: 94.0
FireFox: 92.0.1
Using JMeter to record .Net application. 90% of the recording was perfectly fine. no page crashed and received the response correctly. Except, when I made any requests that related to permission.aspx or permission.asp page I got error message have shown below or wrong response content displayed on the page.
I did try to change the record type from httpclient4 to Java but it didn't help.
Also Error log from JMeter log showed: Cause: java.io.IOExeption: Server returned HTTP response code: 500 for URL: https://xxxx.xx.xx.com/
USERID:
ASP.Net EXCEPTION:
StatusCode:
200
Error Message:
Exception of type 'System.Web.HttpUnhandledException' was thrown.
Inner Exception:
System.NullReferenceException: Object reference not set to an instance of an object.
Your question provide sufficient level of details so I doubt you will get a comprehensive answer, it looks like JMeter isn't capable of handling some specific setup of your application.
In order to get more information you could:
Increase logging level verbosity for JMeter's HTTP(S) Test Script Recorder by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.proxy" level="debug" />
then inspect jmeter.log file for any suspicious entries
Check your application logs as HTTP 5xx errors are server-side errors so most probably the reason can be found there
You might also want to try out an alternative way of recording a JMeter test: JMeter Chrome Extension which is kind of less "invasive" and "alien" to the browser than JMeter's proxy server.
While execution of negative TC (login with Invalid user), i need to login with invalid data, but not get marked the execution as failed in 'View Results Tree', coz this is expected behavior by the system.
I try changing parameters in .jmx file, but without any result.
Is this possible to be done, so my 'http request' wont be marked as Failed?
If the failure is being caused by receiving HTTP Response Code >= 400 you can add a Response Assertion as a child of the request which is not supposed to fail and tick Ignore Status box
Check out Response Assertions in JMeter 3.2 - New and Improved article for more information on defining custom pass/fail criteria with Response Assertion
If your request fails for any other reason - please clarify it so we could come up with the optimal solution. Be aware that you can mark the request as passed using JSR223 Listener and the following Groovy code:
prev.setSuccessful(true)
Well, you can use a single Response Assertion with only 'ignore status' option checked.
See below screenshot
Go through the below link for more details on this.
https://funwithjmeter.blogspot.com/2018/12/jmeter-pass-http-failed-request.html
JMeter - Parameterization(using CSV data),
JMeter - In My local UAT Server same URL request not hitting second time(Error- 500)
In My local UAT Server same URL request is not hitting second time it's displaying a Response code like - 500.
I generate script by using blazemeter chrome addons V.1.5.184.
Kindly give any solution for this.
It is not possible to suggest anything without seeing request details, response message, response body, your CSV Data Set Config details and partial CSV file.
Most likely your parameterization doesn't work as expected, I would recommend comparing what's is being sent in 1st and 2nd request using View Results Tree listener and double check variables coming from CSV using Debug Sampler. See How to Debug your Apache JMeter Script article for more details on JMeter tests troubleshooting.