I have an application that has a license for a set number of cpus and I want to be able to set the number of cpus that java runs in to 1 before the check is done. I am running Solaris and have looked at pbind but thought that if I started the application and then used pbind it would have checked the license before it had set the number of CPUs that java could use.
Does anyone know a way of starting an application with a set number of CPUs on Solaris?
It is a workaround, but using Solaris 10 you could set up a zone with a single CPU available and then run the application inside that zone.
If you want to do testing without running the full application, this bit of Java is most likely what they are using to get the number of CPU's:
Runtime runtime = Runtime.getRuntime();
int nrOfProcessors = runtime.availableProcessors();
A full example here.
This isn't a complete solution, but might be enough to develop into one. There's definitely a point at which the java process exists (and thus can be controlled by pbind) and at which point it hasn't yet run the code to do the processor check. If you could pause the launch of the application itself until pbind had done its work, this should be OK (assuming that the pbind idea will work from the CPU-checking point of view).
One way to do this that should definitely pause the JVM at an appropriate place is the socket attach for remote debuggers and starting with suspend mode. If you pass the following arguments to the java invocation:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,suspend=y,server=y
then the JVM will pause after starting the java process but before executing the main class, until a debugger/agent is attached to port 8000.
So perhaps it would be possible to use a wrapper script to start the program in the background with these parameters, sleep for a second or so, use pbind to set the number of processors to one for the java process, then attach and detach some agent to port 8000 (which will be enough to get Java to proceed with execution).
Flaws or potential hiccoughs in this idea would be whether running in debug mode would notably affect performance of your app (it doesn't seem to have a big impact in general), whether you can control some kind of no-op JDWP agent from the command line, and whether you're able to open ports on the machine. It's not something I've tried to automate before (though I've used something broadly similar in a manual way to increase the niceness of a Java process before letting it loose), so there might be other issues I've overlooked.
I think the most direct answer to your question is to use pbind to bind the running shell process, and then start Java from that shell. According to the man page the effects of pbind are inherited by processes that are created from a bound process. Try this:
% pbind -b 0 $$
% java ...
Googling over, I found that you are right, pbind binds processes to processors.
More info and examples at: http://docs.sun.com/app/docs/doc/816-5166/pbind-1m?a=view
Related
I have situation where I start JDK18 jvm from c++ code to produce vst plugin goal being to implement audio signal algorithms in java side with added value of full java GUI api. My framework works very smoothly apart from the repeatable state where my audio streaming crashes after 14 hours. So I thought this is good place to start learning JFR. My jvm starting parameters are in xml file and relevant part is:
<param>
-XX:StartFlightRecording,dumponexit=true,filename=c:/out/blackbox.jfr
</param>
Even when application exits that named file keeps empty. So what is the idea of filename parameter if it stays empty and how to use it?
The recording is dumped in a Java shutdown hook. If you terminate the C++ application with exit(status), the Java hook never gets a chance to run.
Not sure how to best run the shutdown hooks, but you could perhaps invoke System.exit(status) from native using CallStaticVoidMethod?
My solution with JDK 18 and flight recorder is not to use JVM startup options at all but instead use jcmd's JFR commands. This is due to incompatible JVM options at startup and lacking documentation. Available documentation is clearly for some older versions of JVM. Here is the available documentation:https://docs.oracle.com/javacomponents/jmc-5-5/jfr-command-reference/toc.htm which proposes use of -XX:+UnlockCommercialFeatures which has been long gone. What is current state of command line options is not achieveable for average programmer.
But "jcmd JFR.start" is example of things that work. I got things working observing with "jcmd PID JFR.check" . It is obvious that JFR api is also little bit broken and needs to addressed in a certain way to get the wanted results. There must have been very hurry when implementing it because the order of parameters is very crucial. And there is a nag that "name" must not be a number even it uses it as number. Now I know it is sensitive. So the way I want it to function is to sample and dump periodic chunks so that differences reveal them selves. Now I have the solution to that but it needs another question with no stupid complaints. Baseline is that jcmd with JFR parameter must be used as it comes out of the box in the way which is not obvious.
Situation:
I have a Java1.7 process running in CentOS6 with multiple threads. The process currently halts (i.e., stuck in some kind of loop or waiting function). Due to the complexity nature of the program, it is difficult to do a routine debug in, for instance, Eclipse (more explanation in the background section below). Therefore, I'd like to debug the code by tracing the current running stack.
Question:
Is there a Linux command that would allow me to print the stack to identify the thread/method that is currently running such that I can find which method is causing the halt?
Background:
The reasons for not being able to debug in Eclipse:
It is a MapReduce program typically run on multiple computers.
Even if I use run on one computer, it still involves multiple threads running simultaneously.
Most importantly, the "halting bug" occurs randomly (i.e., not being able to reproduce). So my best shot is to identify the current running method that caused the bug.
P.S. My approach may be completely wrong, so feel free to correct me and point me in the right direction.
Thanks for your help.
You can use JStack to get the current thread dump. It should give you currently running threads and their stack traces.
It will even do more for you - should there be any deadlocks present it will tell you about them.
Apart from that you can also use JVisualVM to monitor your application in real time (you can check threads in real time there and take thread dumps from it).
From RedHat:
Following are methods for generating a Java thread dump on Unix:
1) Note the process ID number of the Java process (e.g. using top, a
grep on ps -axw, etc.) and send a QUIT signal to the process with the
kill -QUIT or kill -3 command. For example:
kill -3 JAVA_PID
I want to modify the default jvm setting, like gc policy and Xmx.
Because of some reason, I can't modify the starting command of java program to add these setting.
Is there any ways to do that?
Thanks.
[updated]
Sorry I didn't describe it clearly.
It is something like server side job program which is started from another server program. Because of the default Xmx is too big(on 64 bit server), minor GC time is too long, almost 1 second. So I want to change the default GC policy to test.
And for now, the server program can't be modified.
You can have the Java program relaunch itself. You can have a bootstrap main which is called first. It then does a Runtime.exec(...) with the command line option you require running a different Class.main() which is the actual program.
Short answer: with your requirements you can't do this.
Theoretically you have 2 possibilities:
Provide settings via comand line options:
I can't modify the starting command of java program to add these setting
Change settings at run time:
But it's impossible
I am running a java app as daemon on a linux machine using a customized shell script.
Since I am new to java and linux, I want to know is it possible that the app itself resurrects itself(just like restart) and recovers from cases like app crashing, unhandled exceptions or out of memory etc.
thanks in advance
Ashish Sharma
The JVM is designed to die when there is an unrecoverable error. The ones you described fall in this category.
You could, however, easily write a shell script or a Python script that checks if the process is alive, and if it is dead, waits a few seconds and revive it. As a hint to doing this, the Unix command "pgrep" is your friend, as you can check for the exact command line used to fire a JVM (and thus including the starting class file). This way, you can determine if that specific JVM instance is running, and restart it.
All that being said, you may want to add some reporting or logging capability and check if often, because it is too easy to assume that things are ok when in fact the daemon is dying every few minutes. Make sure you've done what you could to prevent it from dying before resurrecting it.
There are Wrappers that can handle that, like Java Service Wrapper (Be aware, that the Community Edition ist under GPL) and some alternatives, mentioned here
To be honest, relaunching the daemon without any question after a crash is probably not a good idea; well it depends greatly on the type of processing achieved by your daemon, but if for example it processes files from a given directory, or requests coming from a queue manager, and the file / message contains some unexpected data causing the crash, relaunching the daemon would make it crash again immediately (excepting when the file / message is removed no matter it has been correctly processed or not, but as well it seems not to be a good idea).
In short, it's probably better to track down the possible crash reasons and fix them when possible (or at least log the the problem and go ahead, provided that the log message would ever be scanned to warn at last a human being, so some action can be engaged upon such "failures").
Anyway if you have very good reasons to do such, a solution even simpler than "checking that the process is alive" (as it would probably in some way involve some "ps -blahblah" stuff), you could just put the java program launching in a shell "while true" loop as follows :
while true
do
# launch the java program here, no background
# when crashing, the shell will be given hand back
java -classpath blahblah...
echo "program crashed, relaunching it..."
done
On unix based systems, you may use "inittab" to specify the program. If process dies, it is re-started by OS.(respawn)
I am not sure if the app itself can handle such crashes. You could write a shell script in linux which could be running as a cron job itself to manage the app, checking if the java app is running on scheduled intervals and if not, it will restart it automatically.
We've developed a Java standalone program. We've configured in our Linux (RedHat ES 4) cron
schedule to execute this Java standalone every 10 minutes. Each standalone
may sometime take more than 1 hour to complete, or sometime it may complete
even within 5 minutes.
My problem/solution I'm looking for is, the number of Java standalones executing
at any time should not exceed, for example, 5 process. So, for example,
before even a Java standalone/process starts, if there are already 5 processes running,
then this process should not be started; otherwise this would indirectly start
creating OutOfMemoryError problems. How do I control this? I would also like to make this 5 process limit configurable.
Other Information:
I've also configured -Xms and -Xmx heap size settings.
Is there any tool/mechanism by which we can control this?
I also heard about Java Service Wrapper. What is this all about?
You can create 5 empty files (with names "1.lock",...,"5.lock") and make the app to lock one of them to execute (or exit if all files are already locked).
First, I am assuming you are using the words "thread" and "process" interchangably. Two ideas:
Have the cron job be a script that will check the currently running processes and count them. If less than threshold spawn new process, otherwise exit, here threshold can be defined in your script.
Have the main method in your executing java file check some external resource (a file, database table, etc) for a count of running processes, if it is below threshold increment and start process, otherwise exit (this is assuming the simple main method will not be enough to cause your OOME problem). You may also need to use an appropriate locking mechanism on the external resource (though if your job is every 10 minutes, this may be overkill), here you could defin threshold in a .properties, or some other configuration file for your program.
Java Service Wrapper helps you set up a java program as a Windows service or a *nix daemon. It doesn't really deal with the concurrency issue you are looking at--the closest thing is a config setting that disallows concurrent instances if its a Windows service.