I'm trying to deploy my Java application using Java Web Start, but I've come across a problem. When running the application through my IDE (Netbeans) it's lightning fast; everything happens within seconds. However if it's launched with Web Start it's excruciatingly slow.
Any ideas why?
I'm self-signing everything and using full permissions in the JNLP.
Java Web Start applications will always launch more slowly than launching directly via the java executable. This is because Java Web Start is doing so much more than a standard java launch:
JWS accesses the network to download the JNLP (and possibly JARs, and other resources)
JWS is checking its local cache of JARs to see if it can skip downloading the JARs
JWS is potentially downloading the jars via HTTP, if the cache is empty or out of date
JWS is checking the validity of the cryptographically strong signatures of every single jar
I think most of this is an unavoidable cost for the added power of being able to launch your application via a web browser and update your application virtually "for free."
Another possibility: Is your application running with a different VM when you launch via webstart vs. when you launch with NetBeans? You can try printing:
System.getProperty("java.home")
to find out what VM is running the currently executing process.
If it's the same VM, you might also try diffing the Java system properties between the two scenarios. Try printing out all System properties:
System.getProperties().store(System.out, "");
Wireshark can be used to help diagnose Java Web Start network issues.
Sometimes the Java Console and Java Web Start Logging can be useful in diagnosing certain JWS problems. You can enable these features through the Java Control Panel:
You can enable full logging in the Java Console and see all the things that Java Web Start is printing of debug information. You can then see where the pauses happen, which may give you an indication of the problem.
My initial guess would be that you have DNS issues, especially if the pauses are very close to a multiplum of 30 seconds.
Related
As the title says - when launching Spring app (STS) with embedded Tomcat, both java.exe and javaw.exe processes are created on the same port.
That means I have troubles with busy port, even when using the Relaunch option (which typically shuts Tomcat down and then restarts it). Indeed, relaunching does stop one of the two processes but then I get an error stating that the port must be busy. Killing the remaining one does solve the issue but I life is too short to both develop in Java AND kill the process manually.
Is there a convenient way to overcome this? I see that is STS (and Eclipse too, of course) there's a way to specify project specific JRE but I'm unsure on how to proceed.
Note: I have both 32- and 64-bit java8 instances installed.
Try running it as a java application (ie, just run main).
It sounds like you are deploying it on Tomcat, while at the same time there is an embedded Tomcat being started... :)
I have implemented one application using JDK 1.6 64-bit, JSF, Tomcat server 64-bit etc at user system.I am integrating some devices(i.e. finereader, scanner, etc) into this application. Some of devices libraries are supported only on JRE 32-bit Only.
So, device integrated screens to be run on JRE 32-bit and non device screens should be run on a JRE 64-bit. Can I configure multiple JRE's in the same application? If possible, how?
A Java application runs in a JVM. The JVM is part of one single JRE. You could split your application into two parts, which each run in their own JVM. These applications then would have to communicate with each other to coordinate the user experience. This does not look like a good solution to me.
It all depends on how you define "application."
First, in regard to your question, each JVM instance runs a single kind of Java--32 or 64 bit--Java version and such.
Sometimes, an application consists of a single JVM running a single java executable, usually a jar and some stuff on the classpath with a single 'main'
Sometimes, an application consists of multiple JVMs running on one or more boxes. In this case, each JVM is running a single java executable. But there has to be some sort of communication between these executable parts to make it function as an application.
Alternatively, the same executable might run on multiple JVMs and we still call it one application. In this case, there would be some sort of outside stuff that decides how to allocate the work of the application amoung the multiple JVMs. For example, you could run 18 instances of Tomcat on 9 boxes with a hardware load balancer dividing up the network requests and assigning each one to one of the Tomcat instances. In this case, though, part of the application is probably running on 1000's of user's computers inside a browser.
Sometimes, we say multiple applications are running under another application. In this case, we might call the master application a container. One example is Tomcat. In this case, Tomcat manages the load of requests for each of the separate applications because the HTTP requests come in off the network with information in the header indicating which one handles that request.
You already say that you have some code running under Tomcat. Tomcat is a single executable (It runs in one JVM and has one variety of Java) and it manages running your one Java executable supplied as a .war file, usually. There could be other Java applications running in other JVMs that communicate through that Tomcat and with your executable. Or there might not be other JVMs that your executable communicates with running somewhere else.
So, you can see, the real answer is "it depends." If you have multiple JVM communicating in some way, you could have different Java varieties. If it's all running under a single Tomcat instance, then you have a single variety of Java.
I have a Java application which should run on a server machine in the background (the application can be started by a command without GUI). The problem is: When I log off from the server, the application gets killed. I'm looking for something similar like nohup under Linux. I found some solutions, but I'm unsure, what is the best for my situation (Windows Server 2003, Java Application run from BAT-Skript, restart after booting the machine)? What are the pros and cons of the solutions?
psexec: Do the process really need to run under the SYSTEM account?
Combination of instsrv and srvany: But srvany should should never be used in a production environment
I have started the application with the scheduled tasks with the option run as NT AUTHORITY\SYSTEM. But after log off, the application was still killed. Can I get this working?
The DOS Task Scheduler AT command
Write a windows service (on Java, C# - I don't think it does matter)
Start the app from your service
or
Run your app as a window service using 3d party utility
The only way in which you can get a process to run without a user being logged in is to have the process run as a windows service or at the very least called by a windows service.
Just to add to above answers.
Consider using http://wrapper.tanukisoftware.com.
It's rather mature and popular (in contrast to ServiceEx and RunAsService).
Yes, a Windows Service is definitely the way to go but there are a few things to watch out for when you run a Java application as a Windows Service. Most of them are covered in this tutorial showing how to setup a java application with our commercial run-anything-as-a-service application, AlwaysUp:
http://www.coretechnologies.com/products/AlwaysUp/Apps/RunJavaApplicationAsAService.html
Beware: You will almost surely need the "-Xrs" flag on Windows 2003 to prevent the closing-on-logoff behavior but things can get tricky if you are catching shutdown events. Let me know if that is an issue for your situation.
I have a console Java application, which runs all the time on a remote server (nohup java -jar myapp.jar &).
Frequently (every other day) I need to replace the JAR file by a newer one (whenever I fix a defect).
At the moment I do this by connecting to the server using ssh (WinSCP).
How can I create a mechanism, using which I could upgrade the application via the http protocol? Can I use JMX for that?
That mechanism should do following things:
a) Stop the currently running application.
b) Upload the new JAR file to the server.
c) Launch the new JAR file.
Basically you need to break down the program into two parts:
the monitor component which fetches the new jar, stops the program, replaces the jar, restarts the program
the actual program, the console java application
Theoretically you can do all of this in a single java process but the additional complexity is not worth the trouble in my opinion.
You might check out install4j or this similar StackOverflow question.
In LiveRebel, there's native support for standalone applications (i.e. daemons). So the main application is running with the watchdog agent which communicates to the command center. From command center it is possible then to manage the updates.
I wanted to get ideas from the SO community about this issue.
Here is the problem:
We have a user on the other side of the world launching our app through WebStart. The user, however, is complaining that her whole application freezes up and becomes unresponsive. Usually, the client is doing a lot of database queries to a distributed database.
Questions:
If we ask her to do a CTRL-Break on her application, where would the JVM write the stack trace to?
Would it be enough just to use JConsole?
Would implementing JMX beans on the client be overkill? Would it actually help in troubleshooting issues in production?
Right now the users are running on JRE 1.5.0-b08, but we do plan on migrating to JRE 6 in a couple of months.
What do you think?
José, you can get a lot of information from the JVM in a number of ways.
The best might be to enable debugging in the remote JVM. You can set them using the j2se element in the descriptor XML, as shown here. Since you can set -Xdebug you have a good start; I've never tried to do remote debugging on a web start app, so it may be a little bit of an issue setting up the remote part.
You could also set some things up yourself by adding a separate thread to talk to you remotely and send debugging messages.
You could use a native java or log4j remote logger.
If it's hanging the way you describe, though, the odds are very high that what's happening is a network hangup of some sort. Can you put some tracing/debugging onto your end of the conversation?
Instead of these debugging suggestions, why don't you install an exception handler for your threads? See java.lang.Thread.
void setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh)
Here's the relevant javadoc:
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler)
If you install that in your code, and once inside Swing's EDT, then just write some java code to e-mail it to yourself, save it on a server, show it to the user, etc.
You need to have the Java Console displayed (run javaws from the command line, and select this from the Preferences dialog), then hit "v"