My http query
http://testemu.foo.com:5050/reportGroup?customerId=4&token=18817614-b662-41f1-b9e7-99a5afcf312d&searchKey={"brandId":1,"sourceType":"E-Commerce","startDate":"01/01/2017","endDate":"31/12/2017"}
Jmeter is throwing error
java.net.URISyntaxException: Illegal character in query at index 109
As per RFC 1738
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
So you need to wrap your query into __urlEncode() function like:
${__urlencode(reportGroup?customerId=4&token=18817614-b662-41f1-b9e7-99a5afcf312d&searchKey={"brandId":1,"sourceType":"E-Commerce","startDate":"01/01/2017","endDate":"31/12/2017"})}
See Apache JMeter Functions - An Introduction to get familiarized with JMeter Functions concept.
This error is presented by the java version with which Jmeter is being used, the latest versions have this problem. It works for me with the java version "1.8.0_201" - Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Related
while generating html report through jmeter getting following error message.
note[using jmeter version 5.4.1]
Generating report
An error occurred: Data exporter "html" is unable to export data.
The Data exporter "html" is unable to export data message unfortunately doesn't contain either root cause of the issue or at least a clue.
You need to take a look at jmeter.log file, it should contain way more information regarding the failure.
The most common reasons are:
Lack of JVM Heap space
Impossibility to write to the destination folder (lack of permissions, disk full, etc.)
Issues with .jtl results file (i.e. you ran your test on another JMeter instance having different Results File Configuration)
Also be informed that according to JMeter Best Practices you should always be using the latest version of JMeter so consider upgrading to JMeter 5.5 (or whatever is the latest version available at JMeter Downloads page) on next available opportunity.
When I execute ApacheJmeter then UI is coming blank.Please help me how I can get user interface of jmeter.I also installed java development kit v 17.0.3.
Check jmeter.log file for any suspicious entries. If it doesn't contain anything meaningful - increase JMeter logging verbosity to DEBUG level
Try earlier version of Java, the minimum you can run JMeter 5.4.3 with is Java 8
Try nightly build of JMeter
Try another look and feel, i.e. run JMeter as:
jmeter -Jjmeter.laf=CrossPlatform
While running the script in non-gui mode for jmeter tests, test gets completed but it does shows min: 0, max: 0...
note:
JMeter 5.4 is installed without any 3rd party plugin.
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
Please help
It means that none of Samplers were executed and the reasons could be in:
The number of threads in Thread Group is 0
The test contains CSV Data Set Config and the .csv file is not there
The test relies on a JMeter Plugin which is not installed
etc.
The reason should be in jmeter.log file, check it and I believe you will find either the cause or at least a clue there.
Also be aware that according to 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article you should always be using the latest version of JMeter so consider upgrading to JMeter 5.4.1 (or whatever is the latest stable version available at JMeter Downloads page) on next available opportunity
I guess you probably found the answer - but maybe this response will be useful to someone.
I've been battling a similar issue -> locally all was working fine (in GUI and non-GUI mode), but as soon as I tried to run the jmx on the server I could see it would start threads, all logs seemed normal (standard info logs within jmeter.log at start) but still no requests were actually made (confirmed by observing logs from the target server). I tried running trace logs but still nothing out of the ordinary - I could see proper HTTP config, threads were as if normal... But the generated jtl file only contained a header and no requests actually were made.
After some hair pulling I finally found my issue - I'm using variables for threads, rampup and loop which I invoke using ${__P(threads,)} syntax and when running the non-GUI load test I pass those with -J to the command line (f.ex. jmeter -Jthreads=50 ...)
I didn't pass the loop parameter since I figured it would just default to 1 (and that is also the impression I get when looking at the logs where I see all thread started ... entries) - turns out for some reason it will log, but won't execute anything actually till I pass a value for that loop.
So if you run a test plan and notice it only simulates doing something but you get no results in the target log file -> confirm you're setting ALL variables used for thread groups including those you suspect to default
The issue is reproducible when running a JMeter test under specific machine. The number of users is 1. The JMeter test uses regex to exclude certain domains ^((?!somerealdomain\.com).)*$. The thread is closed almost immediately and the error in the jmeter log is:
2018-09-03 15:53:12,596 ERROR o.a.j.JMeter: Uncaught exception:
java.lang.StackOverflowError: null
at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) ~[oro-2.0.8.jar:?]
at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) ~[oro-2.0.8.jar:?]
at org.apache.oro.text.regex.Perl5Matcher.__match(Unknown Source) ~[oro-2.0.8.jar:?]
The Perl5Matcher error is present approximately 1000 times.
As the issue is reproducible only on one from our 3 performance agents, I am not sure what is causing it.
The heap is 1GB on all machines:
HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m
Java version is the 1.8.0_181 an all three agents.
Do you have ideas where to look?
Try settings Xss to same value everywhere:
-Xss256k
Also please show all the jmeter.log of:
jmeter.log
jmeter-server.log
If only one machine is affected it means that it is not the same as other machines therefore it can produce not the same load as you expect so I would start with identifying the differences.
Double check that your load generators are running the same OS
Double check that your load generators use the same JVM version (preferably from Oracle, preferably server JRE or JDK) vendor, architecture, build, etc.
Double check that your load generators use the same (preferably latest) JMeter version
Double check that your load generators have the same configuration, the best way is setting up one node according to JMeter Best Practices and copy the installation over to all slave machines
Save response data for failing request and verify that it is the same for all slaves, you can do this by adding the next 2 lines to user.properties file:
jmeter.save.saveservice.output_format=xml
meter.save.saveservice.response_data=true
Try amending your regular expression to exclude the domain to something like:
^((?!somerealdomain).)*$
or
^((?!somerealdomain.com).)*$
I found the solution. I added to the start of the PATH C:\Program Files\Java\jre1.8.0_181\bin; and then restarted the computer as explained here.
What lead me to this was that after I have installed latest Java JRE 64-bit version and I run java -version, the message was "Java is not recognized as an internal or external command". It was strange that the JMeter test has even started its execution on this machine.
There was no need to do this on the other two agents. Thank you all for your kind suggestions.
I am inserting a record in aerospike. Everything is working fine on my local environment. However, on the staging environment, UTF-8 characters are not being stored correctly.
aql> select msg from test.msges
LIST('["{"message_id":"kxwFZHVBKj","title":"คำถามได้รับà¸à¸²à¸£à¸•à¸à¸šà¸à¸¥à¸±à¸šà¹à¸¥à¹‰à¸§!","actions":
|
+----------------------------------------------------------------------------------------------------------+ 1 row in set (0.038 secs)
Also, this is being done using a golang clinet which is pretty UTF-8 safe i.e. no problems of byte-to-string or string-to-byte conversions and this works fine on local, hence
I am assuming this has something to do with aerospike configuration or version. The aerospike version on my local is 3.14.1.1 and on staging is 3.9.1.1.
One more thing I noticed based on the c-client comments coming on this post is that on my local machine I get the following aql version:
Aerospike Query Client Version 3.13.0.1 C Client Version 4.1.6
But on the remote I have the following:
Aerospike Query Client Version 3.9.1.2
The C-client version is missing !
Anyone can help what configuration (or whatever) am I missing here ?
aql is a tool written in c-client. In c-client, the application is expected to handle utf-8 encoding as there is no "string" datatype similar to newer generation languages that support multibyte utf-8 characters. The application reading data should have prior knowledge that the data is indeed written with utf-8 encoding to handle that. aql cannot determine that as it is a generic tool. So, it ends up printing each byte as a character.