The idea behind this is that I have a main class that acts as an agent, constantly running and waiting for instructions. Then, the agent gets instructed to launch n instances of another class which plays a monitoring role.
Since each instance of the monitoring class is going to be doing heavy printing (plus the fact that the agent class also prints a little bit), I would like for each instance to have its own command window to do all its printing to.
Is this possible? If not, I welcome suggestions on how to get a similar effect.
Thank you.
EDIT: I feel like some clarification is in order. I want to start a new command/terminal window per monitoring instance and regularly write to that window.
I would obviously love to be able to run this on any machine, but at least I'd like to it to be able to work on Windows.
I know that there are some GUI libraries available (AWT, Swing) but I want the application to be as lightweight as possible, so that I can maximize the number of monitors that I can have on each computer. I will use a GUI library only if I have no other option.
First of all, if an instance is running for a long time and you may require multiple of those running at the same time, you will need to implement multi-threading. In particular, look into concurrency: http://docs.oracle.com/javase/tutorial/essential/concurrency/
Next, once you figure out how to run each instance in a separate thread, you simply access Runtime:
Runtime RT = Runtime.getRuntime();
RT.exec("cmd.exe /c start command", null, new File(newDir)); // for example
There are plenty of GUI libraries that can do what you want. AWT is one see AWTConsoleWindow. Or this one.
Related
i want to create a applet which paints a running ball while a process a running in the Java application . I have no idea how to synch the process time with the applet life . Help please ??
Applets run in a browser controlled JVM, that is completely separate from the JVM executing your program, but can do anything a normal Java application can do.
Therefore the problem here is actually, how you can have one JVM ask another JVM for information and you have several options depending on your need and skills.
I would suggest you look into JMX which is usually used for these kind of things, and if inapplicable then the EndPoint class which provide a tiny web server to your application.
I am running a Java program that acts as a server for my program using CreateProcess with no window (using the settings shown here). I have an object which runs the process in its constructor, saves the process handle, and uses it in the destructor in a call to TerminateProcess to kill it.
My problem is that when my window is closed with the X in the corner, this destructor is never called and the process keeps running in the background, the handle is lost, and I have no indication that it is still running or a way to kill it (other the Task Manager). How can I make sure it is killed.
Larger picture
Here is what I need to do. If you can suggest a better way altogether to accomplish this, that is fine too.
I need a new instance of this java server for every run of my program (sometimes even multiple times in the program). I would like to run it without any visible indication (window etc.) but this is not a requirement. I do need to be able to either make sure that no matter what happens the server I opened is killed when I am done with it, or a way to make sure there is no running instance of it and if so, kill it before I start a new one. (Or better yet, both.) Using the process name is no good, since it is just java, and I don't want to kill all Java instances on the computer. I can (if I knew how) check if a program is listening on the port this server uses, and if so close it.
EDIT
I forgot to mention (if it makes a difference) that the GUI is C# and I have no control over it or over the Java program itself. I am writing a library in c++ that get called from the C# GUI and needs to use the Java server.
Create a new background process called "watchdog". This process obtains a handle to your main GUI and also to the background Java server, and then calls WaitForSingleObject on your GUI's process handle. When this call returns, you terminate the Java server.
Modify your DllMain entrypoint to handle DLL_PROCESS_DETACH. Its response should be to perform whatever desired cleanup you have.
I have a .bat file in a Windows machine that starts our program by calling a main class of a Java executable(.Jar)
Now I need to run this every 30 mins.
I gone through several ways of doing it, but unable to decide which is better.
Scheduling through Windows scheduler or Using Java Timer. Which one to choose?
I want only one instance of the process running. If the previous process doesnt complete within 30min, i could wait.
Please let me know what to go for, based on my use case.
Thanks in advance.
You're better off using the Windows Scheduler. If there's a real risk of the process taking too long, you can create a file, or open a socket while the process is running and when another one tries to start up, it can detect that and simply quit. This would make it "miss" the 30m window (i.e. if the first job started at 12 and finished at 12:35, the next job would not start until 1).
But this way you don't have to worry at all about setting up long running processes, starting and stopping the java service, etc. The Windows scheduler just makes everything easier for something like this.
TimerTask is not a scheduling system, it is a library that provides tools for in-app scheduling. Seems that for your use-case you need a the system: you need it to run whether or not your app is running, you need reporting, etc. Windows Scheduler (or cron on unix/linux) is more appropriate for your needs.
I am using eclipse to write java code. If I'm debugging some code I can set a breakpoint and follow along as the code goes through each of the functions or I can backtrack. I can also look at the call hierarchy or the references to get an idea. But that's not enough.
I would like to have a some sort of time-based visualization of what each thread is doing along the process from ... let's say "point A" (pressing a button on the interface) to "point B" (getting the result). I want to see which classes/methods were called in what order. I want a good way to visualize what kind of output is coming from one method and going into another method which fires off a new process ...etc.
Is a profiler the only thing available for this type of visualization? Basically I want an action diagram or flow diagram created. Is there some plugin or app which can generate something like this?
Edit: Here is an example of what I'm thinking ... at least visually:
essmodel.sourceforge.net/index.html
It has some flow of where the code is leading. But I think this is just a static map of what classes lead to other classes and what inputs/output options are available. I would want to map the flow based on a specific case.
JProfiler offers such a view, it's called the "Call tracer":
It's important to restrict your filters very carefully in order not to record to much data.
Disclaimer: My company develops JProfiler.
I believe using a profiler is going to be your best option. Are you familiar with VisualVM? It comes with the JDK (look for "jvisualvm.exe" inside your JDK's bin directory) and is capable of profiling local virtual machines automatically as well as remote machines when configured properly. And it does give a pretty slick overview of what threads are running and the code they are spending time in, so I think you could easily do what you need from it. And best of all, it's free :)
As I said, local profiling is a breeze. You just run JVisualVM.exe standalone, and it will find any and all java processes running on the local machine automatically (you can just pick them out of a menu that VisualVM gives you upfront). If you want to profile remotely, set the following VM arguments for whatever it is that you're running:
-Dcom.sun.management.jmxremote.port=[0-65535]
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Then within VisualVM, use the hostname of the machine your remote JVM is running on and the port you configured in the first VM argument above.
I'm trying to develop an application that just before quit has to run a new daemon process to execute the main method of a class.
I require that after the main application quits the daemon process must still be in execution.
It is a Java Stored Procedure running on Oracle DB so I can't use Runtime.exec because I can't locate the java class from the Operating System Shell because it's defined in database structures instead of file system files.
In particular the desired behavior should be that during a remote database session I should be able to
call the first java method that runs the daemon process and quits leaving the daemon process in execution state
and then (having the daemon process up and the session control, because the last call terminated) consequentially
call a method that communicates with the daemon process (that finally quits at the end of the communication)
Is this possible?
Thanks
Update
My exact need is to create and load (reaching the best performances) a big text file into the database supposing that the host doesn't have file transfer services from a Java JDK6 client application connecting to Oracle 11gR1 DB using JDBC-11G oci driver.
I already developed a working solution by calling a procedure that stores into a file the LOB(large database object) given as input, but such a method uses too many intermediate structures that I want to avoid.
So I thought about creating a ServerSocket on the DB with a first call and later connect to it and establish the data transfer with a direct and fast communication.
The problem I encountered comes out because the java procedure that creates the ServerSocket can't quit and leave an executing Thread/Process listening on that Socket and the client, to be sure that the ServerSocket has been created, can't run a separate Thread to handle the rest of the job.
Hope to be clear
I'd be surprised if this was possible. In effect you'd be able to saturate the DB Server machine with an indefinite number of daemon processes.
If such a thing is possible the technique is likely to be Oracle-specific.
Perhaps you could achieve your desired effect using database triggers, or other such event driven Database capabilities.
I'd recommend explaining the exact problem you are trying to solve, why do you need a daemon? My instict is that trying to manage your daemon's life is going to get horribly complex. You may well need to deal with problems such as preventing two instances being launched, unexpected termination of the daemon, taking daemon down when maintenance is needed. This sort of stuff can get really messy.
If, for example, you want to run some Java code every hour then almost certanly there are simpler ways to achieve that effect. Operating systems and databases tend to have nice methods for initiating work at desired times. So having a stored procedure called when you need it is probably a capability already present in your environment. Hence all you need to do is put your desired code in the stored procedure. No need for you to hand craft the shceduling, initiation and management. One quite significant advantage of this approach is that you end up using a tehcnique that other folks in your environment already understand.
Writing the kind of code you're considering is very intersting and great fun, but in commercial environments is often a waste of effort.
Make another jar for your other Main class and within your main application call the jar using the Runtime.getRuntime().exec() method which should run an external program (another JVM) running your other Main class.
The way you start subprocesses in Java is Runtime.exec() (or its more convenient wrapper, ProcessBuilder). If that doesn't work, you're SOL unless you can use native code to implement equivalent functionality (ask another question here to learn how to start subprocesses at the C++ level) but that would be at least as error-prone as using the standard methods.
I'd be startled if an application server like Oracle allowed you access to either the functionality of starting subprocesses or of loading native code; both can cause tremendous mischief so untrusted code is barred from them. Looking over your edit, your best approach is going to be to rethink how you tackle your real problem, e.g., by using NIO to manage the sockets in a more efficient fashion (and try to not create extra files on disk; you'll just have to put in extra elaborate code to clean them up…)