Error while saving any test asset in RQM 2.0

Hi Maria -
We've seen some indexing problems in the past. Do you happen to have more than one Jazz based product installed on the server? I.e. 2 instances of RQM, or RQM + RTC, etc?
Check out this resolved issue: https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/18942

Regards,
John

Hi,

Getting the following error while trying to save any test asset in RQM. What could be reason behind this.

Error:
CRJAZ8184E: Error indexing Items ( )

This error is really a bad thing for us to use RQM with more confidence, we are thinking to rollback to our old test case management tool, though it's slow, at least it won't break from time to time for some unendurable errors!

Hi Maria -
We've seen some indexing problems in the past. Do you happen to have more than one Jazz based product installed on the server? I.e. 2 instances of RQM, or RQM + RTC, etc?
Check out this resolved issue: https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/18942

Regards,
John

Hi,

Getting the following error while trying to save any test asset in RQM. What could be reason behind this.

Error:
CRJAZ8184E: Error indexing Items ( )

We are experiencing this same problem and it has become a source of frustration for our user community. This error is occurring quite often now by our standards. We thought that it went away once we upgraded to RQM v2.0.1 iFix2 (we had v2.0.0.1), but now we're starting to see it again. It is occurring every other day on average now. It seems to go away if we bounce the RQM server, but it comes back again 1-3 days later. We have only RQM installed on our server. And only one instance of RQM. RTC is installed on a different server.

Ken,

With you it seems you were getting the error every other day. With out community we are seeing an error just about everyday. Not sure if I want to keep moving forward with RQM until it is more stable.

These errors related to the "full text index". This is an Apache-Lucene index that is stored on the serer's filesystem, as specified through the "com.ibm.team.fulltext.indexLocation" property in teamserver.properties.
Does this location point to a fast and reliable filesystem location? If you go to that directory, do you see any files ending in ".lock"?

The full text index is used when you use the search functionality in the upper right corner of the RQM web UI (where you can search across multiple test asset types). If you do not make use of it, this is ignorable.

Exporting and importing the repository through repotools will completely rebuild the full-text index.

There is also a "repotools -rebuildTextIndices" command but that only updates the Workitems/Defects and not the rest of the RQM artifacts.

If you delete the full text index it will get recreated over time as artifacts are updated, but you will "lose" existing artifacts until they are modified again and reindexed.

I hope this is a little bit of help.
Regards,
John Nason

Ken,

With you it seems you were getting the error every other day. With out community we are seeing an error just about everyday. Not sure if I want to keep moving forward with RQM until it is more stable.

John,

Thanks for the reply. I wanted to apply v2.0.1 iFix3 and iFix4 before replying, since it appears from the release notes that these patches addressed performance. We were hoping that the CRJAZ8184E errors would go away. However, that's not the case. RQM ran fine for one day and now no one can save any test assets in any RQM project. Saving a test case, test plan, test script . . . they all generate this error after clicking Save and nothing gets saved. If I go back and reopen the test asset, none of the changes were saved. So, this is not an error that we can ignore.

The "com.ibm.team.fulltext.indexLocation" entry in teamserver.properties points to the local directory /opt/IBM/RTC20/server/workitemindex, so we can safely assume it's a "fast and reliable filesystem location." There are no ___.lock files there either.

Do you recommend exporting and importing the repository? Do we need to do "repotools -dropTables" and "repotools -createTables" before doing the "repotools -import"? Is it possible that we need to rebuild all of the indices using "repotools -rebuildIndices" instead?

I have to tell you, RQM has a lot of nice functionality, but this issue is really frustrating our QA Teams greatly.

I'm sorry for the frustration.
Is the directory listed "writable" by the user running the RQM Server? Meaning, are the permissions set appropriately and recursively?
Is the disk that the full text index is on full?
I've seen occurrences of both of those.
A repotools -export followed by a -import would rebuild the index. However, I think it must be something simpler than that. I've yet to see a corrupted full text index preventing a save. The two reasons listed above are the majority case.
Regards,
John Nason
RQM Development

John,

Thanks for the reply. I wanted to apply v2.0.1 iFix3 and iFix4 before replying, since it appears from the release notes that these patches addressed performance. We were hoping that the CRJAZ8184E errors would go away. However, that's not the case. RQM ran fine for one day and now no one can save any test assets in any RQM project. Saving a test case, test plan, test script . . . they all generate this error after clicking Save and nothing gets saved. If I go back and reopen the test asset, none of the changes were saved. So, this is not an error that we can ignore.

The "com.ibm.team.fulltext.indexLocation" entry in teamserver.properties points to the local directory /opt/IBM/RTC20/server/workitemindex, so we can safely assume it's a "fast and reliable filesystem location." There are no ___.lock files there either.

Do you recommend exporting and importing the repository? Do we need to do "repotools -dropTables" and "repotools -createTables" before doing the "repotools -import"? Is it possible that we need to rebuild all of the indices using "repotools -rebuildIndices" instead?

I have to tell you, RQM has a lot of nice functionality, but this issue is really frustrating our QA Teams greatly.

You mention .lock files. Should one see those in practice ? I see some that are days and even weeks old in some index directories.

Thanks

These errors related to the "full text index". This is an Apache-Lucene index that is stored on the serer's filesystem, as specified through the "com.ibm.team.fulltext.indexLocation" property in teamserver.properties.
Does this location point to a fast and reliable filesystem location? If you go to that directory, do you see any files ending in ".lock"?

The full text index is used when you use the search functionality in the upper right corner of the RQM web UI (where you can search across multiple test asset types). If you do not make use of it, this is ignorable.

Exporting and importing the repository through repotools will completely rebuild the full-text index.

There is also a "repotools -rebuildTextIndices" command but that only updates the Workitems/Defects and not the rest of the RQM artifacts.

If you delete the full text index it will get recreated over time as artifacts are updated, but you will "lose" existing artifacts until they are modified again and reindexed.

I hope this is a little bit of help.
Regards,
John Nason

Ken,

With you it seems you were getting the error every other day. With out community we are seeing an error just about everyday. Not sure if I want to keep moving forward with RQM until it is more stable.