I run a java application that's busy most of the time. When I need to upgrade it, I send it a message to exit cleanly at the next available opportunity, then upgrade the class files, then restart it. What I'd really like to be able to do is to upgrade the class files, then have the program kick itself at the next good opportunity, but what I've found (this is solaris) is that if you modify the files on disk while a program is running, sometimes bad things happen. I presume because not all the class files are live in the jvm all the time so sometimes it has to reload from disk, or maybe solaris is loading parts of the file from disk that don't match the old binary. I've seen it do this with C binaries as well. Any suggestions? Would it be safer to do a move and copy so the same disk info isn't written over, but a new inode is made for the new file?
Look also into automating the uprade using webstart (which has additional restrictions) or integrating the update into the startup script, for example something like this: 1. check if there are any files in new/, copy them into production 2. start application
This way all you need is a restart. And you can copy, rsync, ftp, ...
Overwriting jars/classes does not work. The reason is simple: you can have a class loaded in memory, then unloaded due to memory pressure then re-loaded again. If you change the underlying class file you get a new class with an old system, which spells trouble.
Your best bet is to build in hot deploy in the application ( or have the developers build it in ) using solutions such as:
or whatever suits you best.