There could be instances when your Websphere Deployment Manager server is crashed / down due any reasons .
It could be due to
a) Hardware issues
b) OS issues
c) Filesystem corruption
d) Configuration Issues etc ..
Consider a scenario wherein your DMGR is down, and at the same time there is an urgent configuration change / deployment / upgrade you need to do to your application .
In this case you may need to do the changes directly to the Application server node using wsadmin commands
NOTE : This is not a recommended way
NOTE : WHENEVER THE DMGR IS UP AND RUNNING THE CHANGES WILL BE LOST DURING THE NODE SYNC Process .
NOTE :Once the DMGR is started, you would need to make the changes which you made on Application Server again to the DMGR and do a complete Sync
NOTE :For a Clustered Environment ,, the below changes needs to be one on each of the Cluster Nodes
Following are the highlevel steps to deploy the application when the DMGR is down
Step 1 : To simulate that scenario of DMGR Crashed, I have stopped the DMGR using ./stopManager.sh
And the Application Servers is started
Step 2 : Login to the Application Server Node as the owner of the WAS installation .
Step 3 : Launch the wsadmin.sh from the APP_SRV_PROFILE/bin
| [root@mercury bin]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin |
Execute wsadmin.sh
| [root@mercury bin]# ./wsadmin.sh |
We will get an Error
“WASX7023E: Error creating “SOAP” connection to host “mercury.com”; exception information: com.ibm.websphere.management.exception.ConnectorNotAvailableException: [SOAPException: faultCode=SOAP-ENV:Protocol; msg=; targetException=java.net.MalformedURLException]”
The reason being that the wsadmin.properties file in the /opt/IBM/WebSphere/AppServer/profiles/Custom01/properties folder still refers to the DMGR hostname and DMGR Soap Port
We need to modify the values of the com.ibm.ws.scripting.port and com.ibm.ws.scripting.host values to match the hostname of Application Server Node
Step 4 : Modify the wsadmin.properties file
| [root@mercury bin]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/properties |
Edit the wsadmin.properties
| [root@mercury properties]# vi wsadmin.properties |
Currently the port 8879 is the SOAP port of the DMGR ..
Change the com.ibm.ws.scripting.port and com.ibm.ws.scripting.host values to the values of the Application Server Node
Here 8884 is the Soap Port of My application Server “MyServer”
Save the Changes in the wsadmin.properties file
Step 5 : Now execute the wsadmin.sh from the Application Server Node
| [root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/ |
| [root@mercury properties]# ./wsadmin.sh -lang jython -conntype NONE |
Step 6 : Deploy the application using wsadmin
In the wsadmin Prompt execute the below command . The DefaultApplication.ear is located in /opt/IBM/WebSphere/AppServer/installableApps/
NOTE : You can use wsadmin interactive Steps to deploy the application too
| wsadmin>AdminApp.install(‘/opt/IBM/WebSphere/AppServer/installableApps/DefaultApplication.ear’, ‘[-server MyServer]’) |
Save the configurations using AdminConfig.save
| wsadmin>AdminConfig.save() |
NOTE : You can use wsadmin commands to manipulate other configurations also of the Application Server
NOTE : These changes will get lost when the dmgr is started
Step 7 : Ensure the wc_default and wc_default_secure port of Application Server is available in the virtualhost.xml .
On the Application Server Node
| [root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cell/Cell01 |
Search for wc_default port in virtualhost.xml
| [root@mercury properties]# cat virtualhost.xml | grep 9082 |
Search for wc_default_secure port in virtualhost.xml
| [root@mercury properties]# cat virtualhost.xml | grep 9445 |
Where 9082 & 9445 are wc_default and wc_default_secure port of the Applicatioin server “MyServer”
NOTE : If the wc_default and wc_default_secure port of your Application Server is not present in the virtualhost.xml you will get the error
“A WebGroup/Virtual Host to handle /snoop has not been defined
SRVE0255E: A WebGroup/Virtual Host to handle localhost:80 has not been defined.”
Step 8 : Start the applications using wsadmin or Restart the application server .. depending on the changes which you have done
| [root@mercury properties]# cd /opt/IBM/WebSphere/AppServer/profiles/Custom01/bin |
| [root@mercury bin]# ./stopServer.sh MyServer |
| [root@mercury bin]# ./startServer.sh MyServer |
Step 9 : Validate if the application has been deployed only to the application node and not the DMGR .
Validation 1 : Check the Application Server SystemOut.log after the Application server / Application is started.
Check the systemOut.log to see if the Application DefaultApplication has started properly .
Also check if the web containers are mapped to the proper ports ..
Refer the screenshot of SystemOut.log
Validation 2 : Check the serverindex.xml of both Application Server Node and Dmgr Node
Application Node
| [root@mercury mercuryNode01]# cat /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cells/Cell01/nodes/mercuryNode01/serverindex.xml |
Here we can see the Application which we deployed ie DefaultApplication.ear.ear in the serverindex.xml
Dmgr Node
| [root@mercury mercuryNode01]# cat /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/nodes/mercuryNode01/serverindex.xml |
Similarly in the Dmgr Node’s Serverindex.xml we can not see the deployed application :DefaultApplication.ear.ear
Validation 3 : Check the <Profile_Home>/config/cells/Cell01/applications folder for the deployed application
Application Server Node
| [root@mercury mercuryNode01]# ls -l /opt/IBM/WebSphere/AppServer/profiles/Custom01/config/cells/Cell01/applications |
We can see the DefaultApplication.ear.ear in this folder
Dmgr Node
| [root@mercury mercuryNode01]# ls -l /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/Cell01/applications |
There is no DefaultApplication.ear.ear
Step 10 : Check the deployed application using the browser
url : http://IP of the Application Server:wc_default/snoop
As I have deployed the DefaultApplication I will be testing if the application snoop is accessible now on the applicaiton server when the DMGR is down
This shows we can deploy the application directly on the Application Server Node when the DMGR is down
NOTE : As mentioned above these changes will get overwritten when the Node sync happens when the DMGR is started
NOTE :Once the DMGR is started, you would need to make the changes which you made on Application Server again to the DMGR and do a complete Sync
To get automated mail updates of my Posts..
Please subscribe to the site http://webspherepundit.com
And also like the Facebook Page
https://www.facebook.com/webspherepundit