Basically I want to use a jsp web page, so in Java, to run(manager) different background process (could be anything that runs) on a linux server.
They need to be run as different user than the web itself.
I wonder what options do I have?
I just found out that
Runtime rt = Runtime.getRuntime();
Process proc = rt.exec("linux command");
may work.
But I don't know whether the (child?) process just started will be completely detached from the java servlet process? And is it possible to run it under different account?
Using Runtime in a supposedly lifelong running Java EE web application is a bad idea.
First and foremost, a new process created by Runtime will by design allocate as many new heap memory as the currently running Java environment. This may not necessarily harm inside a simple Java application which uses by default 64MB or something, but in a Java EE web application which ususually allocates memory in terms of gigabytes, this is going to be a complete memory waste.
Second, you just don't want so spawn unmanaged processes/threads inside a Java EE web application. What if the process/thread stalls and/or runs forever which can cause unability to shutdown/restart the Java EE web application when necessary (you'd need to kill it altogether first)? What if the process crashes and takes down your whole Java EE runtime along it?
Last, you cannot change the user running the process. It will always be the same user who has executed the currently running Java runtime.
You have basically 2 options:
Don't use Java for this at all. For example, just do the job using platform provided background job manager, such as Cron in Unix based platforms and Task Scheduler in Windows based platforms.
Do it in 100% Java. Perform the same goal using pure Java, without the need to spawn a process. You can if necessary manage background jobs using ExecutorService API or a 3rd party library like Quartz. Note that even those jobs have still to run 100% pure Java code.
Related
I have a Java application that needs to run several times. Every time it runs, it checks if there's data to process and if so, it processes the data.
I'm trying to figure out what's the best approach (performance, resource consumption, etc.) to do this:
1.- Launch it once, and if there's nothing to process make it sleep (All Java).
2.- Using a bash script to launch the Java app, and when it finishes, sleep (the script) and then relaunch the java app.
I was wondering if it is best to keep the Java app alive (sleeping) or relaunching every time.
It's hard to answer your question without the specific context. On the face of it, your questions sounds like it could be a premature optimization.
Generally, I suggest you do what's easier for you to do (and to maintain), unless you have good reasons not to. Here are some possible good reasons, pick the ones appropriate to your situation:
For sleeping in Java:
The check of whether there's new data is easier in Java
Starting the Java program takes time or other resources, for example if on startup, your program needs to load a bunch of data
Starting the Java process from bash is complex for some reason - maybe it requires you to fiddle with a bunch of environment variables, files or something else.
For re-launching the Java program from bash:
The check of whether there's new data is easier in bash
Getting the Java process to sleep is complex - maybe your Java process is a complex multi-threaded beast, and stopping, and then re-starting the various threads is complicated.
You need the memory in between Java jobs - killing the Java process entirely would free all of its memory.
I would not keep it alive.
Instead of it you can use some Job which runs at defined intervals you can use jenkins or you can use Windows scheduler and configure it to run every 5 minutes (as you wish).
Run a batch file with Windows task scheduler
And from your batch file you can do following:
javac JavaFileName.java // To Compile
java JavaFileName // to execute file
See here how to execute java file from cmd :
How do I run a Java program from the command line on Windows?
I personally would determine it, by the place where the application is working.
if it would be my personal computer, I would use second option with bash script (as resources on my local machine might change a lot, due to extensive use of some other programs and it can happen that at some point I might be running out of memory for example)
if it goes to cloud (amazon, google, whatever) I know exactly what kind of processes are running there (it should not change so dynamically comparing to my local PC) and long running java with some scheduler would be fine for me
Is the same JVM used by all Java applications running or, does 'one JVM per Java application' apply? (say the applications are IntelliJ IDEA, a server and NetBeans for example)
Further, is there any connection between JVMs assigned and processes used by each Java application?
Generally speaking, each application will get its own JVM instance and its own OS-level process and each JVM instance is independent of each other.
There are some implementation details such as Class Data Sharing, where multiple JVM instances might share some data/memory but those have no user-visible effect to the applications (except for improved startup time, hopefully).
A common scenario however is a single application server (or "web server") such as Glassfish or Tomcat running multiple web applications. In this case, multiple web applications can share a JVM.
There's one JVM per Java application. There shouldn't be any connection between them unless you establish one, e.g. with networking. If you're working inside of an IDE, the code you write generally runs in a separate JVM. The IDE will typically connect the separate JVM for debugging. If you're dealing with multiple web applications they could share the same JVM if they're deployed to the same web container.
In theory you can run multiple applications in a JVM. In practice, they can interfere with each other in various ways. For example:
The JVM has one set of System.in/out/err, one default encoding, one default locale, one set of system properties, and so on.
If one application changes these, it affects all applications.
Any application that calls System.exit() kills all applications.
If one application thread goes wild, and consumes too much CPU or memory it will affect the other applications too.
Short answer: often, yes, you'll get one application per JVM.
Long answer: the JVM can be used that way, and that may be the best option, but it doesn't have to be.
It all depends on what you consider to be an 'application'. An IDE is a good example of an application which is presented to its end users (i.e. us) as a single entity but which is actually comprised of multiple underlying applications (compilers, test runners, static analysis tools, packagers, package managers, project / dependency management tools, etc). In that case there are a variety of tricks which the IDE uses to ensure that the user experiences an integrated experience while also being shielded (to some extent) from the individual vagaries of the underlying tools. One such trick is to do some things in a separate JVM, communicating either via text files or via the application-level debugging facilities.
Application servers (Wildfly, Glassfish, Websphere, Weblogic, etc) are applications whose raison d'etre is to act as containers for other applications to run in. In that case, from one perspective, there's a single JVM per application (i.e. one JVM is used to run the entire application server) but there are actually multiple applications contained within that JVM in their own right, each logically separated from each other in their own classloader (reducing the possibility of accidental in-process crosstalk).
So, it all really depends on what you consider an application to be. If you're purely talking about "the thing which runs when 'main()' is called", then you're looking at one application per JVM - when the OS starts the JVM, the JVM runs a single class's public static void main() method.
But once your applications start getting more complicated your boundaries become more blurred. An IDE such as Intellij or Eclipse will reuse much of the same stuff as 'javac', either in the same JVM or a different one, as well as doing different work (such as repainting the screen). And users of a web application on a (shared JVM) application server may actually be using much the same 'core' application as could be used locally via the command line.
Number of JVMs running is the number of executables invoked.
Each such application invokes its own java executable (java.exe/ javaw.exe etx for windows) which means each is running in a separate JVM.
Any application which has shared libraries will share the same copy of those libraries. Java has a fair amount of shared libraries. However, you won't notice the difference except for some memory saved.
Little late here however this info may be useful for somebody. In a Linux system, if you want to know how many JVMs are running you can try this command
$ ps -ef | grep "[j]ava" | wc -l
ps to list process, grep to search process containing "java" and wc to count lines returned
Actually this is one question that can have very confusing answers. To keep it real short:
Yes per java process, per JVM.
Runtime and ProcessBuilder follow this rule.
Loading jars using reflection and then executing the main won't spawn new JVM.
We Have a Multi-threaded Application in JAVA which has multiple threads running in parallel. Now we want to run all these threads on a single core. Currently application is running on a system having more then one Cores.
We know there is a technique available ProcesAffinity in .Net Framework to set process affinity.
But we don't want to depend on .Net Framework, because our application is build in java.
Do we set Process affinity using Bat file and run our application executable jar file through Bat file?
Currently our application is running on Window XP. So we need a solution that should be working fine on XP platform.
EDIT:
It's possible: See Java thread affinity
Pure Java doesn't support running a thread on specific processor. Check the SO question linked above.
Personally, I don't think that the fact that this cannot be set in pure Java is a bad thing, as to me, how an app is run does very much depend on the OS, so therefore a OS-specific solution isn't a bad thing.
You can use the MS psexec utility to set the affinity:
psexec -a 1 java -jar myapplication.jar
Would instruct that all of the threads created by java would be run on the lowest CPU.
And this line would be your .BAT file...
You cannot do it in pure Java. But on some versions of Windows, you can do it via operating system utilities; see https://superuser.com/questions/309617/how-to-limit-a-process-to-a-single-cpu-core ... and you might be able to do this by calling native libraries via JNI.
I have a Java program running on a linux system, which I would like to give a higher IO Scheduler priority. Is there a library JNI/JNA based that would allow me to do that from within my code?
You could spawn and external command and call ionice on your process.
You can get the PID of the Java Process by using the Java Management API, at least when using the Sun JVM. Have a look at the actual implementations of the management objects, one returns the pid (don't know which for the moment).
Then I would use jnative to call the linux function, so you don't have to rely on ionice to be installed.
I've written a Java file, using Jsp,servlets, that I would like to perform run-time tests on. I've never done this before and was just curious on how to go about it.
What I'm interested in knowing, besides the actual timings, is how to find cpu,memory and io utilization when running the application.Your thoughts are appreciated.
Typically you wouldn't measure these from within the application, but by running another tool on the same host.
If you just want to see the impact on the host operating system, you can use a program like top (on *nix boxes), or good old Task Manager on Windows, to see the CPU/memory/IO utilisation of your Java process (typically the servlet container such as Tomcat).
If you want more detailed information on the actual Java process itself, you can connect JConsole or jvisualvm to get VM information (including memory and CPU) for the process itself. (With Java 6 you should be able to do this from the local machine without passing any parameters to the Java process at startup; for Java 5, or remote connections, you'll need to pass command-line arguments to the Java process to allow (remote) JMX connections.)
Finally, if you want really in-depth details of the resource usage, down to the performance of various methods (which it sounds like you're after), you'll need to use a profiler. There are several of these for Java - with YourKit and JProfiler being the biggest commercial ones (in my unqualified opinion). I believe that the NetBeans IDE also has a decent profiler built-in. The process for connecting these to your application would vary depending on the app itself, but these will all typically allow you to "drill down" into the CPU time to see which classes/methods took the most cycles to execute, and likewise to drill down into memory use to see which classes are taking up the most memory.
The standard way to monitor running Java applications these days is sing JMX through the JConcole
If your a using a commercial application server like Weblogic or WebSphere these have custom and powerful management consoles that provide the monitoring information you are looking for. The technology at the heart of these consoles is still JMX so these can also be monitored and managed using the standard JConsole. This article shows how to do this for Weblogic.
I guess you need this info in the client side (browser). So it's not Java based question.
If so, here is my answer:
I prefer using FireBug and ySlow extensions. They give performance information, memory information and much more.
I combine it with using regular task-manager to view more information about the browser.
BR