WebSphere Environment Setup:
The below mentioned issues are most commonly found if you have the Split web server and app server configuration, which means you have web server running on different physical box serving static contents and appserver running on different physical box serving dynamic content.
1. Web server plug-in updation
Due to the split webserver and appserver setup, plugin-cfg.xml file from appserver needs to regenerated/updated on web server for the changes to reflect.
You can suspect the need of plugin updation whenever the application is not working after the first deployment, new features involving the servlets does not work. Also in the webpage you get message saying 404 path not found.
Below mentioned are few of the instances you need plugin-cfg.xml propagation:
a. When you deploy any new application.
b. When you add new virtual host entry in the appserver plugin file.
c. When application incorporates new servlets in the code.
2. Time mismatch in Cached JSP page and the Deployed JSP page.
You can suspect this when user complains about the changes not getting updated, this is due to the fact that JSP file deployed newly has older time stamp then the JSP file in the cached path /global/site/vendor/WebSphere/AppServer/temp, due to which the latest JSP file never get compiled.
Solution is touch the specific JSP page and redeploy the application.
3. File upload problem, permissions issues with the existing id
Since web server serves the static content whenever the new file is uploaded to the appserver, the same needs to be propagated to the web server.
Below mentioned are the requirements to have file upload utility function properly.
a. File upload directories should have the full permission for the file upload user(Mostly this will be websphere admin id)
b. Setup SCP without prompting for the password for the application id( It will be generally websphere admin id) between websever and appserver.
4. Database index corruption.
You can suspect this when database intensive application is suddenly very slow, this may be due to the fact that database table index might have been corrupted.
5. Copy the WAR/EAR file in the BIN format
It is always good to ftp the WAR/EAR file in the BIN format for deploying the application.
6. File serving variable should be false in the WAS environment
In split environment web server is serving the static contents, so in order to maintain that file serving variable should be false. You face problem with the static entries not displaying.
#/clocal/www/servlets/webpub.ear/webpub.war/WEB-INF/ibm-web-ext.xmi
“FileServingEnabled="false
Also Alias created in the webserver config may not be proper.
7. Corruption in XML/INI files of the application
You can hint at XML properties file corruption, when you see that after deployment the application is not throwing login page itself. It may be missing variable in the XML file or the variable mentioned are not in single line. Also you can open the XML file in the browser, if it is corrupted then it will fail to open.
8. Virtual Host not found error when you are accessing application from the browser.
Virtual Host not defined in the web sphere configuration, meaning VH with which you deployed application was never created in WAS5.
Application might have wrong VH name in the /WEB-INF/ibm-web-ext.xmi file.
DNS name used for the application may not have been mentioned in the plugin file under specific VH.
Example: <VirtualHostGroup Name="wcm_elearning">
<VirtualHost name="www.abc.services.com:80">
</VirtualHostGroup>
9. Java out of memory exception.
Start with the application debug first, if application is having memory leaks, you can detect the same using the JPROBE tool (Run time analyses tool) and also Jtest tool with does static analyses of the code.
The last option should be to increase the JVM memory (HEAP SIZE), if you are absolutely convinced that the application needs so much memory for the proper functioning.
This could also be due to LDAP connection not closed after the use.
10. Connection pool running out of connections.
Start with the application, first option is to use JTEST tool to find weither all the opened connections are closed. If tool is not available check the code manually.
Run through the JPROBE tool to detect any over head functions, could this also be related to logic of closing the connection in the finally method, for some reason finally method does not get executed.
The below mentioned issues are most commonly found if you have the Split web server and app server configuration, which means you have web server running on different physical box serving static contents and appserver running on different physical box serving dynamic content.
1. Web server plug-in updation
Due to the split webserver and appserver setup, plugin-cfg.xml file from appserver needs to regenerated/updated on web server for the changes to reflect.
You can suspect the need of plugin updation whenever the application is not working after the first deployment, new features involving the servlets does not work. Also in the webpage you get message saying 404 path not found.
Below mentioned are few of the instances you need plugin-cfg.xml propagation:
a. When you deploy any new application.
b. When you add new virtual host entry in the appserver plugin file.
c. When application incorporates new servlets in the code.
2. Time mismatch in Cached JSP page and the Deployed JSP page.
You can suspect this when user complains about the changes not getting updated, this is due to the fact that JSP file deployed newly has older time stamp then the JSP file in the cached path /global/site/vendor/WebSphere/AppServer/temp, due to which the latest JSP file never get compiled.
Solution is touch the specific JSP page and redeploy the application.
3. File upload problem, permissions issues with the existing id
Since web server serves the static content whenever the new file is uploaded to the appserver, the same needs to be propagated to the web server.
Below mentioned are the requirements to have file upload utility function properly.
a. File upload directories should have the full permission for the file upload user(Mostly this will be websphere admin id)
b. Setup SCP without prompting for the password for the application id( It will be generally websphere admin id) between websever and appserver.
4. Database index corruption.
You can suspect this when database intensive application is suddenly very slow, this may be due to the fact that database table index might have been corrupted.
5. Copy the WAR/EAR file in the BIN format
It is always good to ftp the WAR/EAR file in the BIN format for deploying the application.
6. File serving variable should be false in the WAS environment
In split environment web server is serving the static contents, so in order to maintain that file serving variable should be false. You face problem with the static entries not displaying.
#/clocal/www/servlets/webpub.ear/webpub.war/WEB-INF/ibm-web-ext.xmi
“FileServingEnabled="false
Also Alias created in the webserver config may not be proper.
7. Corruption in XML/INI files of the application
You can hint at XML properties file corruption, when you see that after deployment the application is not throwing login page itself. It may be missing variable in the XML file or the variable mentioned are not in single line. Also you can open the XML file in the browser, if it is corrupted then it will fail to open.
8. Virtual Host not found error when you are accessing application from the browser.
Virtual Host not defined in the web sphere configuration, meaning VH with which you deployed application was never created in WAS5.
Application might have wrong VH name in the /WEB-INF/ibm-web-ext.xmi file.
DNS name used for the application may not have been mentioned in the plugin file under specific VH.
Example: <VirtualHostGroup Name="wcm_elearning">
<VirtualHost name="www.abc.services.com:80">
</VirtualHostGroup>
9. Java out of memory exception.
Start with the application debug first, if application is having memory leaks, you can detect the same using the JPROBE tool (Run time analyses tool) and also Jtest tool with does static analyses of the code.
The last option should be to increase the JVM memory (HEAP SIZE), if you are absolutely convinced that the application needs so much memory for the proper functioning.
This could also be due to LDAP connection not closed after the use.
10. Connection pool running out of connections.
Start with the application, first option is to use JTEST tool to find weither all the opened connections are closed. If tool is not available check the code manually.
Run through the JPROBE tool to detect any over head functions, could this also be related to logic of closing the connection in the finally method, for some reason finally method does not get executed.
No comments:
Post a Comment