Jmeter Tests work at the console, but not with the JMeter Jenkins(Performance) plugin - maven

I'm working with Maven(3.3.9), JMeter (3.0) and the Jenkis Performance plugin.
When I run my JMeter test with Mvn on my Computer, everything works fine, but when I try to make a build #Jenkins, the JMeter tests always fail(100%).
Has anybody an idea what could be the cause for my problem?
My JMeter tests use an assertion, which checks for "viewExpired", because I'm using JSF, and a second assertion, which skips all the other tests as soon as the first test fails.
Here is my log (i changed it a bit, server-adress,etc.)
https://gist.github.com/anonymous/801ef819233468246eb9e42893366b56

Tom -
From your logs, it looks to me that your TLS connections are failing from the Jenkins machine to the target test server (test.at.com). If your Jenkins machine has an Xterm interface, can you install JMeter there and launch it in the GUI mode to validate? Your test plan should run without issues. The logs also indicate that it is using an empty key store. Do you have the test.at.com certificate added to the default java key store on your Jenkins machine? By default, JMeter uses the java key store present under /lib/security. You can override it with your own trust store by using the property
You can edit the JMeter system.properties to use a custom Keystore by editing the below lines
\# Keystore properties (client certificates)
\# Location
\#javax.net.ssl.keyStore=H:\\cert\\client_keystore.jks
\#
\#The password to your keystore
\#javax.net.ssl.keyStorePassword=changeit
\#
\#javax.net.ssl.keyStoreProvider
\#javax.net.ssl.keyStoreType [default = KeyStore.getDefaultType()]
I would also suggest enabling the SSL debug options if you want to know the actual root cause. You can turn it on in the system.properties
\#javax.net.debug=ssl
Having said all the above, please can you check if the connectivity is there between your Jenkins machine and the actual target host
**telnet test.at.com 443**
2017/01/23 15:50:17 DEBUG - org.apache.jmeter.protocol.http.sampler.JMeterClientConnectionOperator$JMeterDefaultClientConnection: Connection 0.0.0.0:33542<->62.116.177.251:443 closed
2017/01/23 15:50:17 DEBUG - org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$7: Closing the connection.
2017/01/23 15:50:17 DEBUG - org.apache.jmeter.protocol.http.sampler.JMeterClientConnectionOperator$JMeterDefaultClientConnection: Connection 0.0.0.0:33542<->62.116.177.251:443 closed
2017/01/23 15:50:17 DEBUG - org.apache.jmeter.protocol.http.sampler.JMeterClientConnectionOperator$JMeterDefaultClientConnection: Connection 0.0.0.0:33542<->62.116.177.251:443 shut down
2017/01/23 15:50:17 DEBUG - org.apache.jmeter.protocol.http.sampler.JMeterClientConnectionOperator$JMeterDefaultClientConnection: Connection 0.0.0.0:33542<->62.116.177.251:443 closed

Related

I can't get 'create-rmi-keystore.bat' to run on windows, is there a solution to this?

I am new to Jmeter 5.1.1 however I am in the process of setting up a remote testing with it.
One step I'm having trouble with is running 'create-rmi-keystore.bat' when I double click it nothing happens. I have tried to open it using the command line and get the following message.
'keytool' is not recognized as an internal or external command,
operable program or batch file.
"Copy the generated rmi_keystore.jks to jmeter/bin folder or reference it in property 'server.rmi.ssl.keystore.file'"
I don't seem to have a rmi-keystore.jks .
Has anyone managed to solve this issue?
You don't have keytool utility in your Windows PATH, all you need to do is to ensure that it's there.
Solution using Windows Command Prompt would be:
set PATH="path\to\bin\folder\of\your\JDK\or\JRE\installation";%PATH%
In general if you don't need the secure RMI communication between JMeter master and slave machines (and 99% of people don't need this as it doesn't add any value and only creates overhead in terms of CPU and RAM) you can just disable this functionality by adding the next line to user.properties file:
server.rmi.ssl.disable=true
References:
Remote hosts and RMI configuration
Apache JMeter Properties Customization Guide
If you do this on JMeter master and all the slaves you will not have to worry about the RMI keystore, but I would still recommend having the keytool in the PATH otherwise you will not be able to use HTTP(S) Test Script Recorder for recording secure traffic.

JMeter LDAP tests using GSSAPI/kerberos credentials

I would like to use JMeter to run some load testing against our OpenLDAP service authenticating using GSSAPI (i.e., Kerberos). How do I get JMeter to use a keytab with Kerberos credentials to do this? (Note: I tried following the directions here but they did not work for me: https://community.hortonworks.com/articles/141035/jmeter-kerberos-setup-for-hive-load-testing.html)
UPDATE
The command I use to start JMeter is
java.exe -XX:+HeapDumpOnOutOfMemoryError -Xms1g -Xmx1g
-XX:MaxMetaspaceSize=256m -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:G1ReservePercent=20 -Djava.security.egd=file:/dev/urandom
-Duser.language="en" -Duser.region="EN"
-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext
-jar "D:\JMeter\bin\ApacheJMeter.jar"
-Dsun.security.krb5.debug=true
-Djava.security.krb5.conf="D:\JMeter\bin\krb5.conf"
-Djava.security.auth.login.config="D:\JMeter\bin\jaas.conf"
-Djavax.security.auth.useSubjectCredsOnly=false
The contents of D:\JMeter\bin\jaas.conf:
JMeter {
com.sun.security.auth.module.Krb5LoginModule required
doNotPrompt=true
useTicketCache=false
useKeyTab=true
keyTab="D:\JMeter\bin\ldap.keytab"
principal="service/testing-prod#example.com"
debug=true;
};
I have a single LDAP Request sampler. For that sampler I entered the LDAP server, port, and search base and filter. I run the test which "succeeds" but no information comes back.
I see no log messages in jmeter.log concerning the success or failure of authentication.
Unfortunately your didn't work statement tells nothing to us. With regards to the referenced guide - it is fine for HortonWorks Docs, however it might be not applicable for your application setup as Kerberos has many faces, to wit:
Your REALM will be different
Your SPN will be different (it may or may not be present)
Your keytab configuration will be different (again, Kerberos may or may not use keytabs for authentication)
Your KDC will be different
Your keytab generation algorithms may be different
So I would recommend the following:
Reach out to your network administrators / developers / devops / whoever can have the knowledge about your Kerberos setup and collect as much information as you can
Enable debug logging for JMeter HTTP Authorization Manager by adding the next line to log4j2.xml file:
<Logger name="org.apache.jmeter.protocol.http.control" level="debug" />
Enable debug logging for Java Kerberos implementation by adding the next line to system.properties file:
sun.security.krb5.debug=true
Restart JMeter to pick up the changes
Re-run your test and look for underlying error cause in jmeter.log file and in STDOUT
Fix the issue
Repeat step 5 until you're happy with the result
There are hundreds of different reasons, it might be the case your setup is 100% fine, however your login doesn't succeed because you have different time on KDC and your JMeter machine and it needs syncing.

How do I start a Liberty server in debug mode in the background with the liberty-maven-plugin?

Use Case
The liberty-maven-plugin has a debug goal which allows you to start the server in debug mode, but in the foreground.
Often when wanting to attach the debugger, this is all you'd need. You can execute tests separately somehow or via other goals launched from another shell.
But the debug goal, like the run goal, runs in the foreground and blocks until the server process completes.
If I want to continue to the next phase of my build, e.g. on to run integration tests, it could help to configure a start goal to start the server in debug mode, in the background, and continue on.
Use: src/test/resources/jvm.options
In src/test/resources/jvm.options, for example:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=7777
This is the default value for the <jvmOptionsFile> configuration parameter (described here), so of course you could configure a different location if desired.
Note:
Though an alternative might appear to be to use the <jvmOptions> configuration, it does not work well with the commas (',') embedded in this value.
Warning:
You may be expecting a message from the starting JVM:
Listening for transport dt_socket at address: 7777
However you will not see this from your Maven execution log, it actually appears in the console.log file of the configured server. So the Maven execution will just pause at the point of logging message:
[INFO] Starting server defaultServer.
If you fail to connect in time you'll see:
[INFO] Server defaultServer start failed. Check server logs for details.

Jmeter- how to include external .p12 SSL certificate

exception Jmeter throws-
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.ibm.jsse2.qc.a(qc.java:422)
at com.ibm.jsse2.qc.h(qc.java:714)
at com.ibm.jsse2.qc.a(qc.java:831)
at com.ibm.jsse2.qc.startHandshake(qc.java:828)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:553)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
at org.apache.jmeter.protocol.http.sampler.LazySchemeSocketFactory.connectSocket(LazySchemeSocketFactory.java:97)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:114)
Is there any specific Java version need to be used?
Jmeter version is - 3.1
Just add the next lines to system.properties file (located in the "bin" folder of your JMeter installation)
javax.net.ssl.keyStoreType=pkcs12
javax.net.ssl.keyStore=/path/to/your/certificate.p12
javax.net.ssl.keyStorePassword=your_certificate_password_here
Another option is providing the aforementioned properties via -D command-line argument like:
jmeter -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=/path/to/your/certificate.p12 -Djavax.net.ssl.keyStorePassword=your_certificate_password_here
This is more convenient for unattended executions, i.e. using Continuous Integration servers
Restart JMeter to pick the properties up
Now JMeter will be using your client certificate for requests encryption
See How to Set Your JMeter Load Test to Use Client Side Certificates for more details.
Alternatively you can use SSL Manager, however personally I consider using system properties more convenient.

Running remote JBoss in debug mode, Bootup Time Issue

I am trying to run remote jboss in debug mode to debug my application and i have set
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y %JAVA_OPTS%
in run.bat file, and am trying to start the jboss server using ant jboss.start but it is taking some time and then timing out, am not sure why this is happening, is there a way out?
Also as jboss is timing out, I would like to increase bootup time for the server, how can i do it from the command line?
Side note, server.log file does not show any messages which jboss is trying to bootup in debug mode (not sure if this would help but thought so sharing this info.)
Any clue or suggestions?
You should set:
suspend=n
in debugger startup settings.
suspend - True if the target VM is to be suspended immediately before the main class is loaded; false otherwise.
Your JBoss waits infinitely for debugger connection, this is useful when you want to troubleshoot startup issues, otherwise do not suspend your VM and let the debugger be connected any time you want.
I was frustated to get jboss started in debug mode through command line
Finally following seemed to work
1.Below should be the last line in /bin/run.conf.bat
rem # Sample JPDA settings for remote socket debugging
set JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n %JAVA_OPTS%
If there is anything below this, delete it.
2.Also when you are running jboss from command prompt please check whether -Xdebug is at the start of JAVA_OPTS.
Then it should display following message
Listening for transport dt_socket at address: 8787
3.In eclipse use 127.0.0.1 instaed of localhost.
I don't know the reason behind it...but when I changed localhost to 127.0.0.1 it worked
(Make sure you replace localhost with 127.0.0.1 at 2 locations 1.Eclipse remote debug and 2.URL while running your application in browser)
Also check project name.
Sometimes we need to change the port number.
I never had such issues with tomcat.

Resources