JMeter Recording controller via Firefox on Ubuntu 18.04 - firefox

I'm using Firefox on Ubuntu 18.04 to record JMeter scenarios.
I can't access HTTPS pages : Firefox return the SSL_ERROR_RX_RECORD_TOO_LONG error.
In Firefox, I set up the temporary certificated generated by JMeter, listening to the 8080 port.
When I try to access a HTTPS page, I get this error in the jmeter.log file :
2019-05-02 16:36:22,461 ERROR o.a.j.p.h.p.Proxy:
javax.net.ssl.SSLProtocolException: Broken pipe (Write failed)
at sun.security.ssl.Alert.createSSLException(Alert.java:126) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:988) ~[?:?]
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:123) ~[?:?]
at java.io.FilterOutputStream.write(FilterOutputStream.java:108) ~[?:?]
at org.apache.jmeter.protocol.http.proxy.Proxy.writeToClient(Proxy.java:486) [ApacheJMeter_http.jar:5.1.1 r1855137]
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:244) [ApacheJMeter_http.jar:5.1.1 r1855137]
Caused by: java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method) ~[?:?]
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) ~[?:?]
at java.net.SocketOutputStream.write(SocketOutputStream.java:150) ~[?:?]
at sun.security.ssl.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:320) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:983) ~[?:?]
... 4 more
2019-05-02 16:36:22,463 ERROR o.a.j.p.h.p.Proxy: [52392] Exception when processing sample
javax.net.ssl.SSLProtocolException: Broken pipe (Write failed)
at sun.security.ssl.Alert.createSSLException(Alert.java:126) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:321) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:264) ~[?:?]
at sun.security.ssl.TransportContext.fatal(TransportContext.java:259) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:988) ~[?:?]
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:123) ~[?:?]
at java.io.FilterOutputStream.write(FilterOutputStream.java:108) ~[?:?]
at org.apache.jmeter.protocol.http.proxy.Proxy.writeToClient(Proxy.java:486) ~[ApacheJMeter_http.jar:5.1.1 r1855137]
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:244) [ApacheJMeter_http.jar:5.1.1 r1855137]
Caused by: java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method) ~[?:?]
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) ~[?:?]
at java.net.SocketOutputStream.write(SocketOutputStream.java:150) ~[?:?]
at sun.security.ssl.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:320) ~[?:?]
at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:983) ~[?:?]
... 4 more
2019-05-02 16:36:22,464 WARN o.a.j.p.h.p.Proxy: [52392] Exception while writing error
java.net.SocketException: Socket is closed
at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:916) ~[?:?]
at org.apache.jmeter.protocol.http.proxy.Proxy.writeErrorToClient(Proxy.java:561) [ApacheJMeter_http.jar:5.1.1 r1855137]
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:261) [ApacheJMeter_http.jar:5.1.1 r1855137]
Is there something I need to adapt in order to access HTTPS pages ?

Below is a link which has some methods that you can try:-
https://windowsreport.com/fix-ssl_error_rx_record_too_long-firefox-error/
But, if you have already tried this. Then, try to change the browser to some other like chrome.

You might come across several problems while recording scripts using Jmeter.
I would rather suggest to use Blazemeter Recording Extension to record your scenarios and then export in .jmx format and modify using jmeter.

Related

java.net.SocketException: Broken pipe (Write failed) in JMeter

When I run a distributed test with JMeter, I get the following error on some slave clients. For this reason, for example, if I send 10000 requests, only 5000 requests go.
2023-02-07 17:35:55,125 ERROR o.a.j.s.BatchSampleSender: sampleOccurred
java.rmi.MarshalException: error marshalling arguments; nested exception is:
java.net.SocketException: Broken pipe (Write failed)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160) ~[?:?]
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:217) ~[?:?]
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162) ~[?:?]
at com.sun.proxy.$Proxy19.processBatch(Unknown Source) ~[?:?]
at org.apache.jmeter.samplers.BatchSampleSender.sampleOccurred(BatchSampleSender.java:182) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.samplers.DataStrippingSampleSender.sampleOccurred(DataStrippingSampleSender.java:106) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.samplers.RemoteListenerWrapper.sampleOccurred(RemoteListenerWrapper.java:94) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.ListenerNotifier.notifyListeners(ListenerNotifier.java:58) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.notifyListeners(JMeterThread.java:1037) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:591) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:501) ~[ApacheJMeter_core.jar:5.5]
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:268) ~[ApacheJMeter_core.jar:5.5]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.net.SocketException: Broken pipe (Write failed)
at java.net.SocketOutputStream.socketWrite0(Native Method) ~[?:?]
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) ~[?:?]
at java.net.SocketOutputStream.write(SocketOutputStream.java:150) ~[?:?]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) ~[?:?]
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:127) ~[?:?]
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1883) ~[?:?]
at java.io.ObjectOutputStream$BlockDataOutputStream.writeByte(ObjectOutputStream.java:1921) ~[?:?]
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1582) ~[?:?]
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:352) ~[?:?]
at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:293) ~[?:?]
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:155) ~[?:?]
... 12 more
I looked in the etc/ssh/ssh_config settings but it doesn't seem to be because of it.
It looks like JMeter slaves cannot report results back to master due to networking issues. If you're using SSH tunnels for establishing the connectivity you might want to check SSH server logs for any suspicious entries.
From JMeter perspective you can check the following:
RMI ports which are used for bi-directional communication should be open and accessible
You can also play with batching properties like num_sample_threshold and asynch.batch.queue.size and try to setting it to lower value so sending results would occur more often and the size of the chunk would be less.
More information:
Configuring JMeter
Apache JMeter Properties Customization Guide

ERROR: Failed to determine the health of the cluster when i cearte a token for Kibana

I installed elastic and Kibana 8.4.0 in the same ubuntu server VM and when I try to connect them with creating a token I find this error what's the cause of this error and what's the solution?
elastic#elastic:/usr/share/elasticsearch/bin$ sudo ./elasticsearch-create-enrollment-token -s kibana
08:48:22.547 [main] WARN org.elasticsearch.common.ssl.DiagnosticTrustManager - failed to establish trust with server at [192.168.43.147]; the server provided a certificate with subject name [CN=elastic], fingerprint [c15aa3d1e42222febed51b84f266dde2453738a9], no keyUsage and extendedKeyUsage [serverAuth]; the session uses cipher suite [TLS_AES_256_GCM_SHA384] and protocol [TLSv1.3]; the certificate has subject alternative names [DNS:localhost,IP:0:0:0:0:0:0:0:1,IP:127.0.0.1,IP:192.168.1.14,IP:fe80:0:0:0:20c:29ff:fe48:9b3e,DNS:elastic]; the certificate is issued by [CN=Elasticsearch security auto-configuration HTTP CA]; the certificate is signed by (subject [CN=Elasticsearch security auto-configuration HTTP CA] fingerprint [68ececcb9f792679272e9d8c6e2b0f5a1cca667e] {trusted issuer}) which is self-issued; the [CN=Elasticsearch security auto-configuration HTTP CA] certificate is trusted in this ssl context ([xpack.security.http.ssl (with trust configuration: Composite-Trust{JDK-trusted-certs,StoreTrustConfig{path=certs/http.p12, password=<non-empty>, type=PKCS12, algorithm=PKIX}})])
java.security.cert.CertificateException: No subject alternative names matching IP address 192.168.43.147 found
at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:165) ~[?:?]
at sun.security.util.HostnameChecker.match(HostnameChecker.java:101) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:452) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:426) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:238) ~[?:?]
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:132) ~[?:?]
at org.elasticsearch.common.ssl.DiagnosticTrustManager.checkServerTrusted(DiagnosticTrustManager.java:82) ~[?:?]
at sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1335) ~[?:?]
at sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1226) ~[?:?]
at sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1169) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:396) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:480) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:458) ~[?:?]
at sun.security.ssl.TransportContext.dispatch(TransportContext.java:201) ~[?:?]
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:172) ~[?:?]
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505) ~[?:?]
at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420) ~[?:?]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455) ~[?:?]
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426) ~[?:?]
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:578) ~[?:?]
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:183) ~[?:?]
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:142) ~[?:?]
at org.elasticsearch.xpack.core.common.socket.SocketAccess.lambda$doPrivileged$0(SocketAccess.java:42) ~[?:?]
at java.security.AccessController.doPrivileged(AccessController.java:569) ~[?:?]
at org.elasticsearch.xpack.core.common.socket.SocketAccess.doPrivileged(SocketAccess.java:41) ~[?:?]
at org.elasticsearch.xpack.core.security.CommandLineHttpClient.execute(CommandLineHttpClient.java:178) ~[?:?]
at org.elasticsearch.xpack.core.security.CommandLineHttpClient.execute(CommandLineHttpClient.java:112) ~[?:?]
at org.elasticsearch.xpack.security.tool.BaseRunAsSuperuserCommand.checkClusterHealthWithRetries(BaseRunAsSuperuserCommand.java:214) ~[?:?]
at org.elasticsearch.xpack.security.tool.BaseRunAsSuperuserCommand.execute(BaseRunAsSuperuserCommand.java:127) ~[?:?]
at org.elasticsearch.common.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:54) ~[elasticsearch-8.4.1.jar:8.4.1]
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:85) ~[elasticsearch-cli-8.4.1.jar:8.4.1]
at org.elasticsearch.cli.Command.main(Command.java:50) ~[elasticsearch-cli-8.4.1.jar:8.4.1]
at org.elasticsearch.launcher.CliToolLauncher.main(CliToolLauncher.java:64) ~[cli-launcher-8.4.1.jar:8.4.1]
ERROR: Failed to determine the health of the cluster.

couldnt save my jmeter testplan the following error is displaying

2021-06-22 11:08:20,824 ERROR o.a.j.JMeter: Uncaught exception in thread Thread[AWT-EventQueue-0,6,main]
java.lang.IllegalAccessError: class com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge$DetailsTableModel (in unnamed module #0x2b546384) cannot access class sun.awt.shell.ShellFolder (in module java.desktop) because module java.desktop does not export sun.awt.shell to unnamed module #0x2b546384
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge$DetailsTableModel.updateColumnInfo(DarkFilePaneUIBridge.java:1158) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge$DetailsTableModel.<init>(DarkFilePaneUIBridge.java:1145) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge.getDetailsTableModel(DarkFilePaneUIBridge.java:586) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge$SortableListModel.<init>(DarkFilePaneUIBridge.java:1109) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePane.createList(DarkFilePane.java:129) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFileChooserUIBridge.createList(DarkFileChooserUIBridge.java:608) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFileChooserUIBridge$MetalFileChooserUIAccessor.createList(DarkFileChooserUIBridge.java:780) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge.setViewType(DarkFilePaneUIBridge.java:384) ~[darklaf-core-2.1.1.jar:2.1.1]
at com.github.weisj.darklaf.ui.filechooser.DarkFilePaneUIBridge.propertyChange(DarkFilePaneUIBridge.java:918) ~[darklaf-core-2.1.1.jar:2.1.1]
at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:342) ~[?:?]
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:334) ~[?:?]
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:267) ~[?:?]
at java.awt.Component.firePropertyChange(Component.java:8713) ~[?:?]
at javax.swing.JComponent.setUI(JComponent.java:688) ~[?:?]
at javax.swing.JFileChooser.updateUI(JFileChooser.java:1838) ~[?:?]
at javax.swing.JFileChooser.setup(JFileChooser.java:395) ~[?:?]
at javax.swing.JFileChooser.<init>(JFileChooser.java:361) ~[?:?]
at javax.swing.JFileChooser.<init>(JFileChooser.java:308) ~[?:?]
at org.apache.jmeter.gui.util.FileDialoger.<clinit>(FileDialoger.java:42) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.gui.action.Save.computeFileName(Save.java:202) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.gui.action.Save.doAction(Save.java:164) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:87) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.gui.action.ActionRouter.lambda$actionPerformed$0(ActionRouter.java:69) ~[ApacheJMeter_core.jar:5.3]
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:316) ~[?:?]
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770) ~[?:?]
at java.awt.EventQueue$4.run(EventQueue.java:721) ~[?:?]
at java.awt.EventQueue$4.run(EventQueue.java:715) ~[?:?]
at java.security.AccessController.doPrivileged(AccessController.java:391) ~[?:?]
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) ~[?:?]
at java.awt.EventQueue.dispatchEvent(EventQueue.java:740) ~[?:?]
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) [?:?]
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) [?:?]
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) [?:?]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) [?:?]
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) [?:?]
at java.awt.EventDispatchThread.run(EventDispatchThread.java:90) [?:?]
It's described in JMeter Bug 65300, the options are in:
Downgrade to Java 8
Upgrade to a nightly build of JMeter
Change line 112 of jmeter.bat script to look like
set JAVA9_OPTS=--add-opens java.desktop/sun.awt=ALL-UNNAMED --add-opens java.desktop/sun.swing=ALL-UNNAMED --add-opens java.desktop/javax.swing.text.html=ALL-UNNAMED --add-opens java.desktop/java.awt=ALL-UNNAMED --add-opens java.desktop/java.awt.font=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/sun.awt.shell=ALL-UNNAMED
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 if you're not going for the Nightly Build consider upgrading to the latest stable version of JMeter available at JMeter Downloads page (it's JMeter 5.4.1 as of now)

Jmeter 5.4.1: Distributed mode : "Connection refused to host: nested exception is: java.net.ConnectException: Connection timed out: connect"

I am setting up distributed test with jmeter 5.4.1 in two windows VMs.
Started the jmeter server in slave machine. with below change in jmeter.properties file(both master and slave)
server.rmi.ssl.disable=true
Added slave machine ip in master and running the test from GUI mode. getting connection refused error:
ERROR o.a.j.e.DistributedRunner: Failed to create engine at
192.168.xxx.xx java.rmi.ConnectException: Connection refused to host: 192.168.xxx.xx; nested exception is: java.net.ConnectException: Connection timed out: connect at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:623)
~[?:?] at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:209)
~[?:?] at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:196)
~[?:?] at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:343)
~[?:?] at
sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:116)
~[?:?] at
org.apache.jmeter.engine.ClientJMeterEngine.getEngine(ClientJMeterEngine.java:71)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.engine.ClientJMeterEngine.(ClientJMeterEngine.java:84)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.engine.DistributedRunner.createEngine(DistributedRunner.java:243)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.engine.DistributedRunner.getClientEngine(DistributedRunner.java:220)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.engine.DistributedRunner.init(DistributedRunner.java:92)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.gui.action.RemoteStart.doAction(RemoteStart.java:79)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:87)
~[ApacheJMeter_core.jar:5.4.1] at
org.apache.jmeter.gui.action.ActionRouter.lambda$actionPerformed$0(ActionRouter.java:69)
~[ApacheJMeter_core.jar:5.4.1] at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:316)
~[?:?] at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
~[?:?] at java.awt.EventQueue$4.run(EventQueue.java:721) ~[?:?] at
java.awt.EventQueue$4.run(EventQueue.java:715) ~[?:?] at
java.security.AccessController.doPrivileged(AccessController.java:391)
[?:?] at
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
[?:?] at java.awt.EventQueue.dispatchEvent(EventQueue.java:740) [?:?]
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
[?:?] at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
[?:?] at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
[?:?] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
[?:?] at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
[?:?] at
java.awt.EventDispatchThread.run(EventDispatchThread.java:90) [?:?]
Caused by: java.net.ConnectException: Connection timed out: connect
at sun.nio.ch.Net.connect0(Native Method) ~[?:?] at
sun.nio.ch.Net.connect(Net.java:576) ~[?:?] at
sun.nio.ch.Net.connect(Net.java:565) ~[?:?] at
sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:588) ~[?:?] at
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:333) ~[?:?] at
java.net.Socket.connect(Socket.java:645) ~[?:?] at
java.net.Socket.connect(Socket.java:595) ~[?:?] at
java.net.Socket.(Socket.java:519) ~[?:?] at
java.net.Socket.(Socket.java:293) ~[?:?] at
sun.rmi.transport.tcp.TCPDirectSocketFactory.createSocket(TCPDirectSocketFactory.java:40)
~[?:?] at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:617)
~[?:?]
First of all, your "architecture" of one master and one slave doesn't have any sense as you have only one load generator, if there are no plans to scale it further - you can just run your JMeter test in command-line non-GUI mode and that would be it.
However if going forward you want to add more slaves, make sure that
The machines are in the same subnet and can reach one another (or alternatively the appropriate routing is set up)
The following ports are open in Windows Firewall :
Port 1099 (or whatever is the SERVER_PORT)
The port you define as server.rmi.localport
The port(s) you define as client.rmi.localport
You started the slave via jmeter-server.bat command
More information:
Remote hosts and RMI configuration
How to Perform Distributed Testing in JMeter
Apache JMeter Distributed Testing Step-by-step
Make sure master and slaves use the same rmi keystore file (rmi_keystore.jks). I created it on the master and scp it to the slaves.

Tomcat NioEndpoint - Error running socket processor

In a Spring Boot production app, the following exception is occasionally thrown:
o.a.t.u.n.NioEndpoint : Error running socket processor
java.util.NoSuchElementException: No value present
at java.util.Optional.get(Optional.java:148) ~[?:?]
at sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:547) ~[?:?]
at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) ~[?:?]
at sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) ~[?:?]
at sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) ~[?:?]
at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) ~[?:?]
at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995) ~[?:?]
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:443) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:507) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1616) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at java.lang.Thread.run(Thread.java:834) [?:?]
It is hard to tell what causes the exception, as there are no logs before or after by the same thread. Looking at the stack-trace, it might occur before any custom request pre-processing code is reached, during the SSL handshake, which might be the reason there are no logs before. (Production application is currently logging on level TRACE.)
What could be the cause and how to fix it?
Spring Boot version: 2.2.5.RELEASE
EDIT:
I recently encountered a very similar case, but the stacktrace is quite different:
o.a.t.u.n.NioEndpoint : Error running socket processor
java.lang.NullPointerException: null
at sun.security.ssl.HKDF.extract(HKDF.java:93) ~[?:?]
at sun.security.ssl.HKDF.extract(HKDF.java:119) ~[?:?]
at sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1167) ~[?:?]
at sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:545) ~[?:?]
at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436) ~[?:?]
at sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234) ~[?:?]
at sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170) ~[?:?]
at sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852) ~[?:?]
at sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813) ~[?:?]
at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) ~[?:?]
at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048) ~[?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995) ~[?:?]
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:443) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:507) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238) ~[tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1616) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.31.jar!/:9.0.31]
at java.lang.Thread.run(Thread.java:834) [?:?]
This seems to be caused by a JRE issue:
http://hg.openjdk.java.net/jdk/jdk/rev/01d8eae542ff
https://bugs.openjdk.java.net/browse/JDK-8218889
It was fixed with
11.0.8 b01
11.0.7 b04
8u261 b05
Are you using an affected JRE version?
As for the second issue you mentioned:
https://bugs.openjdk.java.net/browse/JDK-8241248
This is an option issue (but mentions a workaround).
Please look into both issues, try to update for addressing the first issue and see if your can apply the workaround as long as no fix is available for the second issue.

Resources