Does JMeter 3.2 support HTTP2 ?
HTTP2 is not supported by Core JMeter as of version 4.0
But there is a plugin that implements it.
This plugin can be installed by JMeter-Plugins Manager.
Regarding HTTP Client, since version 5.0 released on 18 January 2018, Http/2 is supported:
https://hc.apache.org/httpcomponents-client-5.0.x/index.html
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201801.mbox/%3C1516280327.10018.3.camel%40apache.org%3E
To sample HTTP/2 requests, you can use a plugin for jmeter, such as this one: https://github.com/syucream/jmeter-http2-plugin
From the readme file:
Build Netty 5 (Alpha3+) and netty-tcnative for your platform
Copy HTTP2Sampler.jar, netty-all.jar, netty-tcnative.jar and
hpack.jar to lib/ext of jmeter directory
If you use gzip encoding, you must prepare jzlib.jar too.
Run JMeter
Write your test scenario with HTTP2Sampler
From HTTPClient 4.5 official docs:
Standards based, pure Java, implementation of HTTP versions 1.0 and
1.1
SO, you need to wait till HTTP/2 is implemented in HTTPClient libraries and Jmeter implements HTTP2 using the library and create a sampler for the same.
Related
I would like to know information about HTTP v3 support in okhttp.
Someone knows when or if it will support the new HTTP version?
I see it would use injestors for this, but I haven't found anything updated about that.
Thanks.
You can use a bridging interceptor like https://github.com/google/cronet-transport-for-okhttp/blob/master/README.md
There are no plans for HTTP/3 support implemented in Kotlin inside of OkHttp. See https://github.com/square/okhttp/issues/907
Every time I run JMeter I received multiple bouncycastle errors. I have checked I have the latest jar.
Any help would be appreciated.
By default JMeter doesn't contain the "bouncycastle" .jar file, as per Readme:
Some jars are not included with JMeter. If required, these should be downloaded and placed in the lib directory
JDBC - available from the database supplier
JMS - available from the JMS provider
Bouncy Castle - only needed for SMIME Assertion
Looking into gradle.properties
bouncycastle.version=1.67
So if you're using Bouncy Castle API somewhere i.e. in the SMIME Assertion (check out How to Use JMeter Assertions in Three Easy Steps for more details if needed) - make sure to have only one set of BC .jar files and preferably stick to version of 1.67 so JMeter implementation would match the API in .jars
If you don't use Bouncy Castle API just download and install the latest stable version of JMeter, it will not give you this error.
I wrote a Maven application that I want to use in my Jmeter BeanShell script.
The Maven application is using Google Guice 4.2.2 for dependecy injection and it is calling an API at the end (Code needs to perform some other operations before calling the API and that's why I am not using the JMeter Plugin). I am creating the uber JAR (Fat JAR) with maven-shade-plugin. When I run the Jar from the command line the application run successfully!
However, When I load the JAR in my Jmeter test plan and call my application main method in the Jmeter BeanShell I am getting the following error:
java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument(ZLjava/lang/String;Ljava/lang/Object;)V
at com.google.inject.Key.ensureRetainedAtRuntime(Key.java:341) ~[load-testing.jar:?]
.
.
.
Now lots of other threads mentioned that this can be because of older Google Guava version (20.x older) but from the dependency tree I see the Guava version is 25.1-android and I can run my JAR successfully from the command line!!
Also, I list the classes in the Uber JAR by running jar -tf command and I can see that the com.google.common.base.Preconditions class is there.
I would appreciate it if someone can shed some light on this matter and help me to resolve this?
It seems that your fat-jar contains multiple versions of Guava (which may be caused by the shade-plugin).
Make sure to lock it to single version by using Mavens dependency management in each maven module. (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Management)
The Beanshell itself might be a problem, since JMeter 3.1 it's recommended to use JSR223 Test Elements and Groovy language for scripting, the reasons are in:
Groovy is more "modern" language which supports all modern Java features while with Beanshell you're stuck at Java 1.5 language level (no lambdas, no generics, no multi-catch etc.)
Groovy performance is much better comparing to Beanshell cause Grooovy engine implements Compilable interface and is capable of caching compiled scripts providing performance very close to native Java code
Groovy provides a lot of enhancements on top of standard Java SDK
Check out Apache Groovy - Why and How You Should Use It article for more details.
I have finally cofirmed my comment. The problem was my JAR Guava version was conflicting with Jmeter Guava version (which is 17.0) and Jmeter for some reason is picking up its own Guava version, after downgrading Guice version to 3.0 which does not depend on guava, I successfully ran my JAR through Jmeter.
There is still a mystery on why Jmeter is overriding my JAR Guava version with its own. I will create a ticket with Jmeter in order to find more about this mystery but this change solved my problem
We are using below list of Spring Framework jar files in the application and we are not using Spring’s websocket or any other form of websocket dependencies in the application and no code references of enabling STOMP support.
Could someone please confirm if we are still vulnerable to CVE-2018-1270?
spring-security-web-4.2.3.RELEASE.jar
spring-security-core-4.2.3.RELEASE.jar
spring-security-config-4.2.3.RELEASE.jar
spring-aspects-4.3.12.RELEASE.jar
spring-web-4.3.12.RELEASE.jar
spring-tx-4.3.12.RELEASE.jar
spring-orm-4.3.12.RELEASE.jar
spring-jdbc-4.3.12.RELEASE.jar
spring-expression-4.3.12.RELEASE.jar
spring-core-4.3.12.RELEASE.jar
spring-context-support-4.3.12.RELEASE.jar
spring-context-4.3.12.RELEASE.jar
spring-beans-4.3.12.RELEASE.jar
spring-jms-4.3.12.RELEASE.jar
spring-messaging-4.3.12.RELEASE.jar
spring-aop-4.3.12.RELEASE.jar
All versions of the 4.3 branch (up to 4.3.15) are affected, you should upgrade to 4.3.16 as recommended. Further information here: https://pivotal.io/security/cve-2018-1270
This only affects you if you use STOMP over WebSockets, otherwise you are not affected.
I am having problems trying to upload a file in JMeter 3.1.
In the HTTP Request, I have a POST request with the "User multipart/form-data for POST" option checked. Then I have File Path, Parameter Name and MIME type set, no problems there.
The issue is that the script is working on JMeter 2.13, but it keeps failing when running either on 3.0 or 3.1. The response code is 200, but it fails on the expected text "File successfully uploaded".
The only difference between 2.13 and 3.1 is that 3.1 adds the charset value on the Conent-Type Request Header (please find attached screenshots).
JMeter 2.13
Jmeter 3.1
Thanks in advance!
My expectation is that you have different HTTP Client Implementations
HTTP Request
this has an implementation drop-down box, which selects the HTTP protocol implementation to be used:
Java
uses the HTTP implementation provided by the JVM. This has some limitations in comparison with the HttpClient implementations - see below.
HTTPClient3.1
(DEPRECATED SINCE 3.0) uses Apache Commons HttpClient 3.1. This is no longer being developed, and support for this will be dropped in a future JMeter release.
HTTPClient4
uses Apache HttpComponents HttpClient 4.x.
Blank Value
does not set implementation on HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.properties
Make sure you are using the same for both JMeter versions and you will get the same behaviour. If the value is blank you can check jmeter.httpsampler property value in jmeter.properties and/or user.properties files.
You can quickly change the implementation for all the samplers using HTTP Request Defaults.