This is a weird one. My understanding (which has not changed after re-reading the docs recently) is that it’s safe to replace the jar on a JNLP launch server (web in our case) while clients are running. If I understand correctly, upon launch, the client downloads the jar and then runs it locally. Therefore, updating the source jar has no effect until the next launch, when it will be retrieved (as an updated version).
One of my co-workers recently said that he was only going to deploy new jars when all our clients were off the system as it was causing problems if he updated when they were on. That didn’t match up at all with either my previous experience or my understanding. So, I re-read the docs and felt really comfortable with my position on the matter. However, I then did an update to that project and pushed it out. Within the next hour, multiple clients started having all kinds of weird problems (the like of which you would get if you update a jar that someone is running directly off of). I’ve confirmed that they all are doing JNLP, I can watch the local Java do the download, etc. I have no idea how the copy they’re running would even know that the JNLP source jar was updated unless they re-launched.
Sometimes the clients run multiple copies of the software at the same time on the same machien. How smart is JNLP, will it download the updated jar on top of one in the cache that’s already in use? Any other things that might be causing the issue?
Appears that JNLP does indeed just copy the new .jar right on top of the old one in the cache. No problem if the client isn’t running another copy of the software at the same time, but a BIG problem if they are! The already running piece of software goes crazy, doing all kinds of weird things as the cached copy it’s now running from doesn’t match what’s in RAM.