We observed a strange problem with Weblogic JVM in 10.3.2 version:
1) We're adding the following as classpath during the cluster/server startup. Please note that, "config" below is a symbolic link and this gets into the Weblogic JVM's classpath.
2) The application is deployed and it works fine.
3) During the next release of the application, the "config" symbolic link used in the JVM classpath has been changed as below and the old project folder was removed. (THIS IS THE ISSUE).
4) Now the newly deployed application is trying to come up to ACTIVE state. As part of initializing the app, it reads a properties file from the classpath (which is supposed to be referenced through the config soft link in the classpath).
5) At this stage, the Weblogic JVM is still holding the softlink reference to the previous deployment folder which NO MORE EXISTS. I verified this with a sample program and have described about it further below.
6) As a result, the application throws FileNotFoundException.
More experiments:
I tried a simple experiment to reproduce this issue with a standalone JVM...
1) Create a folder: /mydrive/myfolder/myprojects/project.
2) Create two subfolders: project1 and project2.
3) Each folder must have config directory within itself and config folder should contain test.props with their own contents.
4) Create a config softlink at the base folder (/mydrive/myfolder/myprojects/project) to either project1/config or project2/config.
5) Create a Java file which will try to read the property file from the classpath ("test.props") and wait for a user input. And after user input is read, it should again read the same properties file.
6) After successfully compiling the program, run the program like: java -cp "/mydrive/myfolder/myprojects/project/config:." JavaFile
7) You will see the program reads the correct property file as pointed out through the softlink and waits for user input.
8) Now, on another terminal switch the config softlink to point to the other project's config folder, while the JVM is running on another terminal waiting for user input.
9) If you give 'Enter' on the waiting java process, it will READ again the test.props file AFRESH. But this time you can SEE IT STILL READS THE SAME OLD PROPERTY FILE AND NOT THE NEW ONE POINTED BY SOFTLINK.
10) If you had deleted the old projectX folder, instead of just changing the softlink as above, you will get null for the resource - test.props, which encounters just the same scenario as we observed in our application on Weblogic.
Bottom Line:
Never change a softlink that is part of a running JVM's classpath. This includes not just the soft link (versioned or non-versioned), but also the softlink contents. Instead add the PARENT FOLDER of the softlink in the JVM classpath, so that any changes to the softlink or contents of the softlink are decoupled from the running JVM.
1) We're adding the following as classpath during the cluster/server startup. Please note that, "config" below is a symbolic link and this gets into the Weblogic JVM's classpath.
/mydrive/myfolder/myprojects/project/config config -> project-1.1/config 2) The application is deployed and it works fine.
3) During the next release of the application, the "config" symbolic link used in the JVM classpath has been changed as below and the old project folder was removed. (THIS IS THE ISSUE).
config -> project-1.2/config 4) Now the newly deployed application is trying to come up to ACTIVE state. As part of initializing the app, it reads a properties file from the classpath (which is supposed to be referenced through the config soft link in the classpath).
5) At this stage, the Weblogic JVM is still holding the softlink reference to the previous deployment folder which NO MORE EXISTS. I verified this with a sample program and have described about it further below.
6) As a result, the application throws FileNotFoundException.
More experiments:
I tried a simple experiment to reproduce this issue with a standalone JVM...
1) Create a folder: /mydrive/myfolder/myprojects/project.
2) Create two subfolders: project1 and project2.
3) Each folder must have config directory within itself and config folder should contain test.props with their own contents.
4) Create a config softlink at the base folder (/mydrive/myfolder/myprojects/project) to either project1/config or project2/config.
5) Create a Java file which will try to read the property file from the classpath ("test.props") and wait for a user input. And after user input is read, it should again read the same properties file.
6) After successfully compiling the program, run the program like: java -cp "/mydrive/myfolder/myprojects/project/config:." JavaFile
7) You will see the program reads the correct property file as pointed out through the softlink and waits for user input.
8) Now, on another terminal switch the config softlink to point to the other project's config folder, while the JVM is running on another terminal waiting for user input.
9) If you give 'Enter' on the waiting java process, it will READ again the test.props file AFRESH. But this time you can SEE IT STILL READS THE SAME OLD PROPERTY FILE AND NOT THE NEW ONE POINTED BY SOFTLINK.
10) If you had deleted the old projectX folder, instead of just changing the softlink as above, you will get null for the resource - test.props, which encounters just the same scenario as we observed in our application on Weblogic.
Bottom Line:
Never change a softlink that is part of a running JVM's classpath. This includes not just the soft link (versioned or non-versioned), but also the softlink contents. Instead add the PARENT FOLDER of the softlink in the JVM classpath, so that any changes to the softlink or contents of the softlink are decoupled from the running JVM.
No comments:
Post a Comment