ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

BM: java.io.IOException when Running in BlazeMeter

book

Article ID: 188088

calendar_today

Updated On:

Products

BlazeMeter

Issue/Introduction

We have a JMeter UI script that runs fine in JMeter but when running in BlazeMeter we are getting java.io.IOException for some ajax calls within the script.

java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.1 407 Proxy Authentication Required" 

Client implementation within the script needs to be set to “Java” for these calls.  We get parse errors when using -HttpClinet4 or Empty.

    1. Getting parse error with Client implementation as Empty or HttpClient4.

                                                              i.      The URL has special characters like open/close flower braces and commas etc.

                                                            ii.      Tried encoding the complete request through Base 64 /UTF-8

                                                          iii.      Tried providing the request part in Body data & few other options , but no luck.

 

We have also tried uploading properties files from JMeter to BlazeMeter.  BlazeMeter seems to use the system and user property files but not the jmeter.properties. 

 

We have also tried adding some of the jmeter.properties through the GUI but have not had any luck.

Cause

I noticed from looking at the error and looking at the JMeter script. The error is the result of the '09_NetworkAddRemoveProvider' Thread Group -> 'UC9_Add Providers_079_TINSearch' Transaction Controller -> 'added ajax call-JAVA' HTTP Request. The error is informing us that while executing this HTTP Request, and attempting to establish a tunnel through the proxy, the proxy host returned "HTTP/1.1 407 Proxy Authentication Required" and refusing the connection.

Looking through the jmeter-1.log I see you are running java.version=1.8.0_242.

Environment

Release :

Component : BLOCKMASTER

Resolution

Researching this Java error it looks like this is a known issue for Java8. As of Java 8 update 111, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. This authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line. See https://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html

Disable Basic authentication for HTTPS tunneling
In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the 
jdk.http.auth.tunneling.disabledSchemes networking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line.

Additionally, the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively.
JDK-8160838 (not public)


There is an option to change the Java version used in JMeter. You can see the option in the following screenshot:


It's on our roadmap to deprecate Java 7 and 9, but we will have one version of Java 8 and one version of Java 11. You're welcome to move to Java 11 to avoid this issue, but this is something that you need to work out with your network team, as we can do little about this with the current version of Java 8 we use (and we can't revert due to security constraints). This is not an issue we can do much about.