Arun K Sriramaiah 2700076GE8 Visits (724)
The idle standby configuration enables recovery from failover to help ensure minimal impact on business operations during planned or unplanned server outages and Idle standby deployment for crash recovery.
Refer to Impl
Important: Jazz Team Server applications allow only a single server to be active at any one time to a repository; therefore the backup (or Idle) server is configured to never run asynchronous (or background) tasks. If a switch is made to the backup server, you must plan to bring the primary server back up as quickly as possible.
Index corruption can be caused by Network, database or application server issues, to name a few. Below are the steps to fix the index corruption issue on active server, using the idle standby server.
Index corrupted occurred on the Active server and you were unable to fix it by running the repotool command on it. So we can still fix the index issue by running a repotool command on the idle standby server.
Fixing the index issue on active RTC server using the Idle standby server.
Below are steps to fix the index problem, using the IDLE standby server. The standby server is on a different machine (and pointing to a different jazz_home than the active one).
Rajeshavanthi 2700022MCX Visits (583)
There are many instances where you get reports indicating higher page response times in the IBM Rational Performance Tester (RPT) generated reports. You tend to correlate these metrics against the usual time behavior noticed when accessing the application under test outside RPT. It could be a case as well where even if you add all the page elements listed in report, the response time is much less compared to overall response time for the transaction.
The page is considered to begin when the first action (typically a request) associated with the page starts execution. If this request needs to make a connection, the page response time will include the connection time. The page ends when the last action (usually a response) of the page completes. RPT would adjust the page response time to remove the time spent in client delays. In RPT 8.2 this changed after determining it was more representative of the real-world response time to leave the client delays in the page response time. Thus, in RPT 8.2 and later, the page response time does include client delays.
However the Think Time value set in the schedule is not included in the page response times displayed in the Performance report. It should be noted that there are potential "delays" in the script that could increase page response times. Think times are associated with pages and are intended to represent human pauses during recording - these don't impact page response times. For individual page elements (requests), there may also be delays which are intended to represent client (browser) delays (processing time for example). These will be reflected in page response times
Questions could arise such as: How does RPT calculate the Page level response time as compared to Request level response time for a given page?
In case the first request used a new TCP connection, it calculates the difference between the timestamp when the connection for the first request in the page was made and the timestamp of when the last byte was received for the last request in the page. In case an existing connection was reused, the timestamp of when the first request was sent is used. All these timestamps are available in the test log if full logging is on. If a existing TCP connection is re-used, the value "Time to Connect" in the test log will be 0 .
Arun K Sriramaiah 2700076GE8 Visits (822)
Rational Team Concert server is expected to have a common user base management. In order to correctly perform process enforcement for Git operations by Rational Team Concert it is imperative that the identity of the Git user be known to Rational Team Concert. Therefore, the need to have a common user base across Rational Team Concert and Git server (Apache HTTP server) via a different LDAP arrangement.
We can still get the integration done using a common user name with different user base across Rational Team Concert and Git server via an different LDAP arrangement.
Example: Git is configured with Apache DS LDAP and RTC configured with different LDAP registry.
Note: Common user id used for both GIT and RTC using different registry (with different password) and provide all necessary permissions.
Below are checkpoints for verifying the integrations:
1) Verify the GIT login, just to ensure GIT login is fine
$ git remote show origin
2) Verify the GIT GIt repo configuration
Update respective "repokey" and "repourl" information
3) Verify the GIT GIt repo configuration
Update respective "pre-receive" and "post-receive" hooks information
Note: The above configuration will give a clear understanding about RTC-GIT integrations and using a common user name with different user base across Rational Team Concert and Git server via different LDAP arrangements.
Kiran Byrappa 270001YMWT Visits (647)
Post upgrade of your CLM application you may come across the below error while trying to access any Project Areas in Rational Quality Manager.
The error occurs when QM is not deployed correctly which could be the result of an incomplete / improper upgrade process and when WebSphere cache was not cleaned prior to deploying 5.0.2 war file.
Checking the logs reveals the below error:
You may follow the below steps to redeploy QM:
3. Re-deploy QM.war
4. Redo the group mapping in WebSphere by following the below steps:
Map security roles to a user or repository group:
a) Go to Applications > Application Types > WebSphere enterprise applications.
e) Enter a search string to return your group names from the LDAP server. Click Search to run the query.
Kiran Byrappa 270001YMWT Visits (757)
Post upgrade of CLM your attempt to login to Rational Quality Manager instance displays an error indicating that your server appears to be in bad state.
You may want to check the following to ensure that the required services are setup properly and are up and running.