Consequence of messing up a working Discovery URL on Edit Application Properties on the Registered Applications ?

long TRUONG (365●4●111●141) | asked Oct 25 '18, 2:53 a.m.

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

Most liked answers ↑|Newest answers|Oldest answers

permanent link

long TRUONG (365●4●111●141) | answered Oct 26 '18, 10:49 a.m.
edited Oct 26 '18, 10:59 a.m.

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.

And "Unknown" seems to indicate that the file scr is not found via the Discovery URL

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

It's all about the answers!

Related questions

Consequence of messing up a working Discovery URL on Edit Application Properties on the Registered Applications ?

One answer

Your answer