I downloaded the pre-build ".tar" version of Open-daylight Oxygen release. When I try to install the dlux feature using feature:install command, I get the following error.
dluxapps-topology error:
Error executing command: Exception in org.opendaylight.controller.config.manager.impl.osgi.ConfigManagerActivator.stop() of bundle org.opendaylight.controller.config-manager.
dluxapps-application error:
19:32:19.530 [Refresh Thread: Equinox Container: d3f0af16-e328-4ecd-927f-ddb53597d0d5] ERROR org.opendaylight.controller.config.manager.impl.osgi.ConfigManagerActivator - Error starting config manager
java.lang.IllegalStateException: BundleContext is no longer valid
at org.eclipse.osgi.internal.framework.BundleContextImpl.checkValid(BundleContextImpl.java:984) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:463) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:482) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.registerService(BundleContextImpl.java:999) [?:?]
at org.opendaylight.controller.config.manager.impl.osgi.mapping.RefreshingSCPModuleInfoRegistry.<init>(RefreshingSCPModuleInfoRegistry.java:47) [112:org.opendaylight.controller.config-manager:0.8.0]
at org.opendaylight.controller.config.manager.impl.osgi.ConfigManagerActivator.start(ConfigManagerActivator.java:61) [112:org.opendaylight.controller.config-manager:0.8.0]
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:774) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1) [?:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:767) [?:?]
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:724) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:932) [?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:309) [?:?]
at org.eclipse.osgi.container.Module.doStart(Module.java:581) [?:?]
at org.eclipse.osgi.container.Module.start(Module.java:449) [?:?]
at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:470) [?:?]
at org.eclipse.osgi.container.ModuleContainer.start(ModuleContainer.java:736) [?:?]
at org.eclipse.osgi.container.ModuleContainer.applyDelta(ModuleContainer.java:727) [?:?]
at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:497) [?:?]
at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:443) [?:?]
at org.eclipse.osgi.container.ModuleContainer.refresh(ModuleContainer.java:987) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1368) [?:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerWiring.dispatchEvent(ModuleContainer.java:1) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
19:32:19.580 [Blueprint Extender: 1] ERROR io.netty.util.ResourceLeakDetector - LEAK: HashedWheelTimer.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetection.level=advanced' or call ResourceLeakDetector.setLevel() See http://netty.io/wiki/reference-counted-objects.html for more information.
The DLUX subproject in ODL currently is no longer actively maintained by anyone. It was therefore actually removed in the current dev release cycle (current master, upcoming Fluorine). It's not suprising to see that it actually was already broken in Oxygen. If you / your organization has an active interest in DLUX, you would most probably be very welcome to step as the new active maintainer to fix it and keep it up to date... ;-)
Related
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)
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.
Note: Even though there are errors in the log, script gets executed as inteded. I am trying to understand how to remove these errors which are flooding logs
I am using JMeter 5.3 and setting up a Concurrency thread group with Throughput Shaping Timer.
Now the Throughput Shaping Timer works as intended however when I use Variable names in the Configuration, logs get flooded with jexl3 errors. Below are the details of the Configuration that I am using:
Thread Group:
When I use the variable names in the ramp up period, I consistently get following error in the logs
2021-05-17 19:13:49,454 ERROR o.a.j.f.Jexl3Function: An error occurred while evaluating the expression "${RampUpPeriod}/60"
org.apache.commons.jexl3.JexlException$Ambiguous: 60#1:17 ambiguous statement error in '${RampUpPeriod}/60'
at org.apache.commons.jexl3.parser.JexlParser.throwParsingException(JexlParser.java:270) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.parser.JexlParser.jjtreeCloseNodeScope(JexlParser.java:207) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.parser.Parser.ExpressionStatement(Parser.java:505) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.parser.Parser.Statement(Parser.java:350) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.parser.Parser.JexlScript(Parser.java:93) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.parser.Parser.parse(Parser.java:25) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.internal.Engine.parse(Engine.java:594) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:261) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.internal.Engine.createScript(Engine.java:58) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:316) ~[commons-jexl3-3.1.jar:3.1]
at org.apache.jmeter.functions.Jexl3Function.execute(Jexl3Function.java:96) ~[ApacheJMeter_functions.jar:5.3]
at org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:135) ~[ApacheJMeter_core.jar:5.3]
at org.apache.jmeter.engine.util.CompoundVariable.execute(CompoundVariable.java:110) ~[ApacheJMeter_core.jar:5.3]
at kg.apc.jmeter.JMeterVariableEvaluator.evaluate(JMeterVariableEvaluator.java:9) ~[jmeter-plugins-cmn-jmeter-0.6.jar:?]
at com.blazemeter.jmeter.threads.LoadParamsFieldsPanel.UItoModel(LoadParamsFieldsPanel.java:45) ~[jmeter-plugins-casutg-2.9.jar:?]
at com.blazemeter.jmeter.threads.AbstractDynamicThreadGroupGui.updateUI(AbstractDynamicThreadGroupGui.java:139) ~[jmeter-plugins-casutg-2.9.jar:?]
at com.blazemeter.jmeter.threads.AbstractDynamicThreadGroupGui.run(AbstractDynamicThreadGroupGui.java:113) ~[jmeter-plugins-casutg-2.9.jar:?]
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 sounds like a bug in the plugin, you can try reaching out to JMeter Plugins developers and maintainers via JMeter Plugins Support Forum. If you're a BlazeMeter customer you can open a BlazeMeter support ticket
In the meantime you can work it around by adding another User Defined Variables configuration element below your original one and put your calculation logic there:
once done you can replace the __jexl3() functions in the Concurrency Thread Group with the calculated variables:
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.
I have a Spring-Boot application that calls to elastic-search cluster. I want to add prometheous monitoring to it. I have just add only
following dependencies,
As soon as i run the application i get java.util.concurrent.TimeoutException
<!-- Spring boot actuator to expose metrics endpoint -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<!-- Micormeter core dependecy -->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-core</artifactId>
</dependency>
<!-- Micrometer Prometheus registry -->
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
My error log is as follows
org.elasticsearch.ElasticsearchTimeoutException: java.util.concurrent.TimeoutException: Timeout waiting for task.
at org.elasticsearch.common.util.concurrent.FutureUtils.get(FutureUtils.java:72) ~[elasticsearch-6.4.3.jar:6.4.3]
at org.elasticsearch.action.support.AdapterActionFuture.actionGet(AdapterActionFuture.java:54) ~[elasticsearch-6.4.3.jar:6.4.3]
at org.elasticsearch.action.support.AdapterActionFuture.actionGet(AdapterActionFuture.java:44) ~[elasticsearch-6.4.3.jar:6.4.3]
at org.springframework.boot.actuate.elasticsearch.ElasticsearchHealthIndicator.doHealthCheck(ElasticsearchHealthIndicator.java:80) ~[spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.health.AbstractHealthIndicator.health(AbstractHealthIndicator.java:84) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.health.CompositeHealthIndicator.health(CompositeHealthIndicator.java:98) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.health.HealthEndpoint.health(HealthEndpoint.java:50) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:246) [spring-core-5.1.3.RELEASE.jar:5.1.3.RELEASE]
at org.springframework.boot.actuate.endpoint.invoke.reflect.ReflectiveOperationInvoker.invoke(ReflectiveOperationInvoker.java:76) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.endpoint.annotation.AbstractDiscoveredOperation.invoke(AbstractDiscoveredOperation.java:61) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.endpoint.jmx.EndpointMBean.invoke(EndpointMBean.java:126) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at org.springframework.boot.actuate.endpoint.jmx.EndpointMBean.invoke(EndpointMBean.java:99) [spring-boot-actuator-2.1.1.RELEASE.jar:2.1.1.RELEASE]
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:809) [?:?]
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) [?:?]
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1466) [?:?]
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1307) [?:?]
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1399) [?:?]
at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827) [?:?]
at jdk.internal.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359) [?:?]
at sun.rmi.transport.Transport$1.run(Transport.java:200) [?:?]
at sun.rmi.transport.Transport$1.run(Transport.java:197) [?:?]
at java.security.AccessController.doPrivileged(Native Method) [?:?]
at sun.rmi.transport.Transport.serviceCall(Transport.java:196) [?:?]
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562) [?:?]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796) [?:?]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677) [?:?]
at java.security.AccessController.doPrivileged(Native Method) [?:?]
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.util.concurrent.TimeoutException: Timeout waiting for task.
at org.elasticsearch.common.util.concurrent.BaseFuture$Sync.get(BaseFuture.java:235) ~[elasticsearch-6.4.3.jar:6.4.3]
at org.elasticsearch.common.util.concurrent.BaseFuture.get(BaseFuture.java:69) ~[elasticsearch-6.4.3.jar:6.4.3]
at org.elasticsearch.common.util.concurrent.FutureUtils.get(FutureUtils.java:70) ~[elasticsearch-6.4.3.jar:6.4.3]
... 37 more
The stacktrace seems to indicate that the ElasticsearchHealthIndicator.doHealthCheck task Timeout waiting for task.. This often occurs if no connection could be established. You mentioned the elastic search service is running on an external server. Could you check if the program has access to the Elasticsearch port on the server?
Elasticsearch is restricted to localhost by default, because if this no external programs can access it.
After I connect elastic-search running in local problem was solved. As I guess the reason to issue is bad connectivity. And nothing relate to micrometer