How can I replace a JAR file in Integration Server without having to restart the whole server (resulting in a downtime of a few minutes)?
I have multiple JARs deployed to IS under PackageName\code\jars that are used in Java services. If I want to replace an existing JAR with a new version, I can’t remove or replace the old one because it is “blocked” by IS (I guess the JVM holds a reference to the JAR). Stopping the package that contains the JAR doesn’t solve the problem, the file still can’t be removed. I have to restart the whole server and delete/replace the JAR file as soon as the server is down and before the packages are loaded again.
This is a real problem for us, because we run multiple IS deployments daily from our build server and the old JARs cannot be replaced during the deployment. So, after the deployment, the old JARs are still used or even worse the old JAR and the new JAR are both used (if the version number in the file name changed) which results in services that don’t work at all.
It depends. You have inside IS and related packages two types of jars: static (shared across packages) and non-static (local to a package).
The later you can update / replace with an IS package reload at IS runtime. However the “static jars” are to be loaded on IS startup and can only be altered this way.
Unfortunately, exactly this approach does not work for me.
I’ve attached two screenshots. I want to delete the non-static JAR but “java.exe” keeps me from doing so. Even if I shut down the whole package in IS, I still can’t delete the file.
That smells like your JAR is loaded as static JAR.
You can check that in the IS “About” page looking for the “Server Classpath”.
When your JAR is listed there it’s loaded as static JAR and can only be removed (on Windows) when IS is offline.
In a most Linux systems the file could be deleted, but the “open file” to the file inode would keep it active (even invisible now)
until the next IS restart. That way a new file copy with the same name could be put in place also while IS still use
the old JAR until restarted. While this is more convenient it also has it’s risks for confusion.
The result is the same: For static JAR you need a JVM restart.
