Consequence of messing up a working Discovery URL on Edit Application Properties on the Registered Applications ?
Back to square one on our quest to upgrade CLM (RTC, RRC, RQM) 4.0.5 on separate servers to RTC 5.0.2 then 6.0.4 on single server topology with single JVM and 2 distinct public URIs for JTS and RTC respectively. Our application server is Websphere and our platform is Linux.
After several setbacks and issues with compatibility, and so on. We were told to simplify our process to "one change at a time" for easy of diagnosis.
We had first planned
- to upgrade to 5.0.2 onto a single server (for JTS and RTC), in 1 JVM
- From 4.0.5 JTS/RRC and RTC on 2 separate hosts, in 2 separate JVM
- Effectively combining the upgrade and the merge of RTC from its own separate server and its own JVM to JTS server and JTS JVM.
So we now just started from square one with the merge "of RTC from its own separate server and its own JVM to JTS server and JTS JVM"
So:
- We copied the RTC install area .../server/conf/ccm to the JTS server.
- We moved the ccm.war (from the RTC JVM) to the JTS JVM
- We are using address forwarding by spoofing the hosts file with the RTC URL tied to the JTS server IP
- We got into trouble as the RTC server was "either offline or unreachable" though JTS is working fine
Why trying to triage for a solution, we probably execute a big NONO:
- We modified the RTC Discovery URL on Edit Application Properties on the Registered Applications page (to the JTS Discovery URL.
- Thinking if the Discovery URL is as sacred as the public URI, then the address forwarding would have redirected it to the JTS server IP, hence the JTS URL any way.NO harm would be done.
- Otherwise, if it happen to be a phyysical address to find the RTC server on the JTS host, then we may resolve our issue.
Here was what happened that we look for way to revert the catastrophe:
- the RTC server was still "either offline or unreachable" while JTS continued to work fine
- We shut down the JVM, hoping the change will subsequently be effective.
- But the JVM can no longer be started from the WAS console.
Any idea what we need to do to be able to launch the JVM again?
What is the function of the Discovery URL?
Would modifying the Discovery URL (=<RTCpublicURI>/jazz/scr for RTC) also change the public URI?
One answer
Not able to launch the JVM was not the consequence of messing with the Discovery URL: We will submit a new post how to fix the messed up Discovery URL.
After 2.5 hrs working with IBM support, it was found that:
- Failing to launch the JVM is not a consequence of the faux pas of messing with the discovery URL: Apparently WAS won't work with Address forwarding if serverFQN is used (instead of DNS aliases) in the forwarded URL(s), as it would not accept any such forwarded address with duplicate IP to the first address read.
- Modify the discovery URL, which is used to get to the scr file (config file?) and is stored in the JTS DB, did not affect the public URI (in the teamserver.properties file).
- And there are issues with the discovery URLs observed, when JTS is up:
- But it does not seem to be caused by the modification of the RTC discover URL
- As both the discovey URL came up lame with Application Type "Unknown" for both:
- RQM: the JVM for the separate server is not up.
- RTC: the JVM for the separate server is not up and RTC is not yet accessible from the new single (JTS)JVM.
An error occurred communicating with the server at "https://<restored_rtcFQN>:9443/jazz/scr". Verify that the server is available, and that there are no firewalls or other artifacts between these two endpoints that could present a confirmation dialog.ID CRJAZ2287E
|
Name
|
Application Type
|
Version
|
Discovery URL
|
|
|
|
|
|
|---|---|---|---|---|---|---|---|---|
| /admin | Lifecycle Project Administration | 4.0.5 | https://<jtsFQN>:9443/admin/scr |
|
||||
| /jazz | Unknown | https://<jtsFQN: byMistake>:9443/jazz/scr |
|
|||||
| /qm | Unknown | https://<qmFQN>:9443/qm/scr |
|
|||||
| /rm | Requirements Management | 4.0.5 | https://<jtsFQN>:9443/rm/scr |
Healthy list of "Registered Applications"
|
Name
|
Application Type
|
Version
|
Discovery URL
|
|
|
|||
|---|---|---|---|---|---|---|---|---|
| /admin | Lifecycle Project Administration | 4.0.5 | https://<jtsFQN>:9443/admin/scr |
|
||||
| /jazz | Change and Configuration Management | 4.0.5 | https://<rtcFQN>:9443/jazz/scr |
|
|
|||
| /qm | Quality Management | 4.0.5 | https://<qmFQN>:9443/qm/scr |
|
||||
| /rm | Requirements Management | 4.0.5 | https://<jtsFQN>:9443/rm/scr |
|