Develop Reference

Java Jar starts from command line , but not from intellij idea

I am able to start the server with the command line 'java -jar jarname.jar
But , while running main method of the spring boot application , server start fails ,saying that a class from an imported dependency project does not exists
Caused by: java.lang.NoClassDefFoundError: Lcom/jj/db/repositories/KKRepository;
Also there is a warning message in the console :
2021-11-15 11:04:47 WARN WebappClassLoaderBase:173 - - The web application [MM] appears to have started a thread named [RxIoScheduler-1 (Evictor)] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
Can anyone please help ?

Instead of a multi-module project, make it as a single module project or specify appropriately in the manifest.

NoSuchMethodError when running Spark streaming example with kafka [duplicate]

This question already has answers here:
Exception in thread "main" java.lang.NoSuchMethodError: scala.Product.$init$(Lscala/Product;)
(3 answers)
Closed 3 years ago.
I'm using spark-2.4.4-bin-without-hadoop, and I wanna test the self-contained example JavaDirectKafkaWordCountexample.
From the official document, it mentioned the application should include spark-streaming-kafka-0-10_2.12 this dependency. So I download the spark-streaming-kafka-0-10_2.12-2.4.0.jar to jars directory.
However, When I run run-example streaming.JavaDirectKafkaWordCount device1:9092 group_id topic, it manifests
NoSuchMethodError:
20/01/13 11:51:12 INFO handler.ContextHandler: Started o.s.j.s.ServletContextHandler#1549bba7{/metrics/json,null,AVAILABLE,#Spark}
Exception in thread "main" java.lang.NoSuchMethodError: scala.Product.$init$(Lscala/Product;)V
at org.apache.spark.streaming.kafka010.PreferConsistent$.<init>(LocationStrategy.scala:42)
at org.apache.spark.streaming.kafka010.PreferConsistent$.<clinit>(LocationStrategy.scala)
at org.apache.spark.streaming.kafka010.LocationStrategies$.PreferConsistent(LocationStrategy.scala:66)
at org.apache.spark.streaming.kafka010.LocationStrategies.PreferConsistent(LocationStrategy.scala)
at org.apache.spark.examples.streaming.JavaDirectKafkaWordCount.main(JavaDirectKafkaWordCount.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.spark.deploy.JavaMainApplication.start(SparkApplication.scala:52)
at org.apache.spark.deploy.SparkSubmit.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:845)
at org.apache.spark.deploy.SparkSubmit.doRunMain$1(SparkSubmit.scala:161)
at org.apache.spark.deploy.SparkSubmit.submit(SparkSubmit.scala:184)
at org.apache.spark.deploy.SparkSubmit.doSubmit(SparkSubmit.scala:86)
at org.apache.spark.deploy.SparkSubmit$$anon$2.doSubmit(SparkSubmit.scala:920)
at org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:929)
at org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)
20/01/13 11:51:12 INFO spark.SparkContext: Invoking stop() from shutdown hook

As per the documentation -
You have to compile your streaming application into a JAR. If you are using spark-submit to start the application, then you will not need to provide Spark and Spark Streaming in the JAR. However, if your application uses advanced sources (e.g. Kafka, Flume), then you will have to package the extra artifact they link to, along with their dependencies, in the JAR that is used to deploy the application. For example, an application using KafkaUtils will have to include spark-streaming-kafka-0-10_2.12 and all its transitive dependencies in the application JAR.
Alternatively, you can use like "--packages org.apache.spark:spark-sql-kafka-0-10_2.12:2.4.0" with spark submit command.

Any idea how to fix this? Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError

My application uses javafx 11.0.1 and is shipped bundled with a jlinked version of openjdk 11. It runs fine for the vast majority of the users but few of them are getting this stack:
Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: <init>
at com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at com.sun.glass.ui.Screen.initScreens(Screen.java:412)
at com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Unknown Source)
Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
at com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
at com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
at com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Unknown Source)
I found some discussion related to the same exception but regarding Maven+Eclipse, here and here. The issue is very similar, user reporting it, do have other java installations and uninstalling them solves the issue, so basically leaving my bundled openjdk as the only option the application starts, but if there is another Java installed on the system, the wrong .dll is picked up and the application crashes with the above stacktrace.
I tried the suggested java.library.path workaround but users are saying it doesn't solve. Unfortunately I cannot reproduce it myself, any idea on how to solve it or what to ask the users reporting it?
EDIT: we fixed the exe generated by lauch4j here and the bash script here. The idea is basically to restrict/change the PATH env variable to avoid the wrong dll being picked up.

We fixed the exe generated by lauch4j here and the bash script here. The idea is basically to restrict/change the PATH env variable to avoid the wrong dll being picked up.

Solaris - Why is java.lang.UNIXProcess.forkAndExec(Native Method) hanging

I have a java application running on Solaris. This application regularily launches external processes using Runtime.exec. It seems that after a while, having successfully launched such processes many time over, a launching of a process will hang. A thread dump taken at this point (and several minutes later) reveals that java.lang.UNIXProcess.forkAndExec is "stuck". Following is the top of the relevant stack trace taken from the thread dump:
"Thread-85305" prio=3 tid=0x0000000102aae800 nid=0x21499 runnable [0x7fffffff2a3fe000]
java.lang.Thread.State: RUNNABLE
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
at java.lang.ProcessBuilder.start(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
at java.lang.Runtime.exec(Unknown Source)
I have read through some forums where others have experienced forAndExec throwing an IOException due to not enough space or not enough memory, but I'm not getting this error here. I'm now waiting to get the results of pstack in the hope that it will reveal more information.
Does anyone have any idea on how to resolve this issue?
thanks,
Mike

Installing the Sun Alert Patch Cluster will do the trick.

As the thread live as long as your executable is running, maybe it's only your external executable which is hanging.
You should try to find the parameters passed to your executable and try to launch it manually.

Is stdout and stderr from the process being consumed? You might be looking at the results of a full buffer.
You can test this by adding output redirection to a tempfile for the command that is spawned.

Unable to get thread dump? Any ideas why my app blocks?

I have a basic java server app that has 100 worker threads that do simple HEAD requests on urls. I'm using HttpClient 4.x for this.
A few minutes into the run my program just freezes for a couple minutes and I cannot figure out why. Check out the screen shot of what visual vm monitor reports. You can see it flatline. During this time I'm unable to get a good thread dump and visual vm just freezes until it's unblocked. Does anyone have any ideas on what I can do to try and start debugging this guy?
Visual VM: http://tinypic.com/view.php?pic=2i915bs&s=7
Here is the output when I tried to take a jstack dump while it was frozen:
jstack -F 4325
Attaching to process ID 4325, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 16.3-b01
Deadlock Detection:
No deadlocks found.
Thread 4557: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:466)
at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65)
at sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(LinuxAMD64JavaThreadPDAccess.java:92)
at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:256)
at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:218)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:76)
at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.tools.jstack.JStack.runJStackTool(JStack.java:118)
at sun.tools.jstack.JStack.main(JStack.java:84)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:51)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:460)
at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:127)

I've seen several bug reports about jstack on Linux with a similar trace:
JVM Bug Id: 6494722 (is supposed to be fixed)
Ubuntu Bug #597098 (this one is not)
Do you get the same result with a kill -3 <pid>?

Very likley due to too much memory usage causing GC. Add the params to java:
-verbosegc -XX:+PrintGCDetails
And see if you notice anything obvious in the output/logs

What worked for me was running jstack as the process owner without -F.