I've got a (fairly typical) setup at the moment of launching my Java application through a batch file calling the jar file with appropriate parameters, which most of the time works absolutely fine. However, I'd like to be able to deal with any errors that might occur nicely.
At the moment I've got something like
java -Xms1024m -Xmx1024m -jar Quelea.jar
IF NOT (%ERRORLEVEL% == 0) cscript MessageBox.vbs "Application failed to start."
The last line is basically the first answer on this question.
I'd like something a bit more fully featured though, even if it's a case of capturing the output from launching the process and then dumping it in the message box (ok, it's not pretty but it shouldn't appear to start with and when it does appear that then gives me some immediate debugging information without having to ask the user to grab out log files!) Or are there any other approaches that people use in similar situations?
I'm not talking about exceptions thrown in my code (which I deal with once the application starts) I'm talking about hard errors that prevent it starting such as using an old JRE version, not having enough memory to reserve for heap, that sort of thing.
I suggest using a Java executable wrapper. I like the following, but there are others.
http://launch4j.sourceforge.net/
Related
I try to run my JAVA application with JVM arguments in Eclipse.
I noticed that a "-noverify" String is appended each time at the end of the parameters, which makes them unusable because I need that as a patch to my config files. (And the program say: "/home/user/config.properties-noverify" isn't exists.)
The arguments are:
-Djava.security.egd=file:/dev/./urandom -Dspring.config.location="/home/sige/guezbin/application.properties" -DconfigPath="/home/sige/eclipse-workspace/ImgCompr/config-default.properties"
I develop under Ubuntu. With Eclipse version 4.8.
I Googled a lot but I didn't find any answers.
Can somebody explain to me what is this and how can I use it in a proper way?
The JVM checks the byte code of the compile classes it is about to load to see that it is well behaved. This is an essential step for executing untrusted code.
Unfortunately this takes time and for a very large application like Eclipse this may increase the startup time quite a bit. The "-noverify" flag turns this off.
It sounds like that you need a space after your own string so the "-noverify" flag is not concatenated. If you cannot do this, then make a work around like "-Dignore" which becomes -Dignore-noverify and then your code should work.
I have a Java Webstart application that starts successfully with -Xmx1G, but fails to start with -Xmx2G. Some of my users really need 2G of heap.
This seems to be a problem with Java 8u60 only, because I have a report of someone launching successfully with Java 8u51.
The failure looks like this: I see the blue 'Java...' splash screen, and then after a few seconds, poof it's gone, before displaying the Java console and without producing any trace information in the expected place.
The failure occurs only on those clients with less than 2G of memory available. But, I am a little surprised that requesting a 'maximum' heap size could cause the application to fail so early and without any diagnostic information. We are dealing with a 'maximum' value, after all, not an 'initial' value. I read in multiple places that the JVM is not supposed to do this.
But I also remembered reading that the 'initial', if unspecified, is based on the maximum. So, along with passing -Xmx2G, I tried passing -Xms512M, -Xms256M, and -Xms128M. But, this attempt to shrink the initial heap size did not help. I cannot get this thing to start with -Xmx2G!
Does anyone have any light to shed on this situation? A solution? A workaround? In the short term, I'll change to -Xmx1G, but, as I said at the beginning, I have some users that really need -Xmx2G. I'd like to avoid having two separate *.jnlp files, which would also entail having two separate *.jar files!
Turns out that this is exactly what Webstart on Java8u60 does if the client machine does not have enough memory to satisfy -Xmx. It attempts to start, and then poof, it disappears without any indication as to what went wrong.
So, I will end up having to build my application in different configurations if I want to enable the users with more memory to allocate that memory to my application. This is because signing requires the *.jnlp file to into the *.jar file itself, and this *.jnlp file must be an exact match with the *.jnlp file used to launch the application.
I've run into the issue where I have a program (not written by me, by someone else) I want to run 24/7, but sometimes it crashes. Normally, this wouldn't be an issue because I can simply create a process watcher that checks if it crashed, and then restarts it if necessary.
But, this particular program sometimes throws an exception and outputs it into the graphical interface that's integrated into it. In this instance, the program doesn't crash at all. The interface stays up, but the actual server functionality is unavailable.
Is there any way I can intercept this information from this process?
You want to use the Java Virtual Machine Tools Interface. I can't give you the code to catch your exception, but this is where to look. You'll have to do some detective work to find the class that throws the exception, or at least to find some indicator that it has been thrown.
Edit: You can also try calling the vendor to see if they know of a way. You can also look to see if it is writing the exception to a log file, which you could then watch.
This may or may not work, but if when the application displays it's error and the server stops working does the memory usage drop? If so you could probably just add some logic to your process monitor to call the windows command tasklist to see if the memory usage drops below some threshold. You'll have to check how much memory the program normally uses and how much it uses after the error though.
Since you said the server functionality stops working, another option could be to write a simple program that basically just pings the server how ever often you want to make sure it is still up. If not, kill the process and restart it.
I assume you have no access to the source code, so if it is outputting to the GUI the answer is no. Even if you could attach to the running process you would need to intercept the exception, but it is caught and sent to the GUI, not thrown from the application.
In theory, you could screen scrape the application. I don't know of any specific tools for doing this, but they may be out there.
Edit: I may have been wrong above, check out a post here where they get the stack from a running thread. You probably won't be able to capture the exception this way, but if you're lucky the stack trace will look very different when the program is operating normally compared to when an exception has been thrown.
Edit 2: I submitted a second, more accurate answer. See below.
Is the other program Java? Look at AspectJ, you may be able to hack something using it if you have control on the program startup.
Without ability to rebuild the app you are generally out of luck unless you do some extensive hacking. Here is one option I can think of.
Most likely the application replaces System.out and/or System.err with its own stream implementation. If that's the case you can try to locate the class for this stream and replace it with your own wrapper with the same name. You may rename original class using jarjar. In the wapper you can provide console output to detect the exception.
I've a bash script that sequentially calls a java program. That's a bit tricky but mainly what i do is to have a loop and executes about 1500 times the same java program with different arguments.
My question is, when using java 1.5 (the sun VM), each time I'm calling the java program a new instance of the jvm is created ? (I'm not sure that's the right vocabulary...)
Should I avoid this situation by introducing a level of indirection, i.e building a list of all the parameters and then executing one java program which takes these parameters and executes what was previously my entry point ?
Or can I deal with the problem by configuring the JVM as resident or something like that and dynamically invokes my program....
hope this is clear....
thx...
You could save the parameters into a file and use the Java program to process it without constant restart. You could also pipe in the parameters into the running Java app through the console, similarly as for example ls | grep java
Edit: And for the first question. I doubt the java runtime would stay deliberately in memory. Probably most JRE files would remain in the disk cache anyway. On Windows there is a Java Quick Start service which keeps the JRE files around to reduce the startup time for a java program. Don't know whether there is a similar thing for *nix.
Obviously having all the parameters beforehand and running the program once after that would be the best solution. If you cannot do that for any reason i have a very dirty solution to this. Have your program register a port and listen to it for input. Then simply pass the arguments to that port and have your program handle them as a new instance.
JVM startup is notoriously slow, and it certainly not intended to be done in a loop like that. Unfortunately the only way to avoid this if you are passing command line parameters to the java program is to modify the java program itself in some way to have alternative forms of interaction (either from the console, or a port, or a read a file). Java Quick Start is the only (closest thing to a) solution if the java program cannot be changed.
The real solution is to change the Java program. The most obvious change would be to have your loop write to a file, and then start the java program that would read the file one line at a time. That works if the loop doesn't care about the results from the java program for the next set of parameters.
If it does, then it would really be necessary to understand that relationship to advise on an appropriate solution. The socket solution suggested by Savvas is certain a general purpose solution, but there may be better options, depending on what you need to accomplish.
You can use a launcher like in the answer to
Simultaneously run java programs run on same JVM? to read input line by line and start your program's main() method.
I find java starts up and runs practically instantly for me - but javac takes a few seconds, and ant makes it slower again. It's only a few seconds, but my edit-compile-test loop would be smoother without it. :-)
BTW: I've already used vim's ":make" with ant.
Is there a way to speed up javac and/or ant? I'm thinking of special switches, or tricks? Or maybe an alternative java compiler (I'm using 1.6, in linux)
Eclipse does that for you ... but it's probably a bit big as a "patch" for your problem.
That aside, you can roll your own compiler plugin. There are two approaches:
Run the java compiler from within ant (instead of creating a new process). Not sure if ant already does that; if not, that will save you a bit of time. Look at the Java 6 compiler API for details.
Run javac in a server process which listens for options on a socket. In ant, send the process the command line and wait for the output to be sent back. Saves you starting a new process all the time.
Try to use the eclipse compiler. Unlike the original javac, the Eclipse compiler is pretty good at "ignoring" errors, so it can produce class files even when they contain errors. That doesn't seem to mean much but it allows you to compile all the time in the background. When you do your last save (wrapping everything up), the compiler will have been able to compile everything else and will just have to look at a single file.
Google found these two (I haven't tried either yet)
javac -J-client -J-Xms100m -J-Xmx100m <src>
JBrownie "monitors Java sourcecode and automatically recompiles any files found changed" along the lines of Aaron Digulla's (2)
I can strongly recommend using a suitable IDE with Java as the productivity increase with using an editor which knows about your program is immense. Think of "goto the line containing the defintion of the variable/class/field the cursor is on", "rename this class and all references to it", and all other kinds of nice things. If you are annoyed with the time it takes to invoke Java, you might be ready :)
You may want to have a look at JavaRebel
I point all of my output files to a ramdisk that I create with this utility. It speeds up builds a fair bit (Though not to a magical extent) since almost everything is in memory. It's most noticeable when doing a 'clean' build which becomes almost instant.