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
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:
Why trying to triage for a solution, we probably execute a big NONO:
Here was what happened that we look for way to revert the catastrophe:
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:
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
Healthy list of "Registered Applications"
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.