Any bad experience with CLM 5.0.2 ifix7 ... or ifix6 ?
Have been having infrequent crashes & hangs of our RTC/RRC (Tomcat/Window/SQLserver) 5.0.2. One of the advice from IBM support&SWAT is to patch with ifix6 or ifix7 to fix Lucerne indexing issues.
We installed ifix7 on TST, an env cloned from PRD though almost idle, but for the (Java) ETL jobs: RTC/RRC kept hanging after only hours, when started with Tomcat Service, even after ifix7 got uninstalled (was running fine prior to ifix7 applied). SWAT had diagnosed as out of heapspace hence memory: However when starting by the server.startup.bat RTC/RRC stayed up till we manually stop at over 24 hrs.
This morning we were provided with a very sound and logical explanation:
- We have relative paths to indices locations, and on jts and ccm we have two relative paths each, starting from different point, which would cause full-reindexing whenever the apps are started.
For example in JTS teamserver.oproperties:
Line 18: com.ibm.team.fulltext.indexLocation=conf/jts/indices/workitemindex
Line 61: com.ibm.team.jfs.index.root.directory=indices
- -Xcompressedrefs, found in the startup script, but is missing from the Tomcat Service Java options. This would allow indexing to be compressed and to live within its means of heapspace.
However, when -Xcompressedrefs is added to Tomcat Java options, the service would not start. It looks like APAR IV71190 may be related.
Without the option -Xcompressedrefs, Tomcat service continue coring, heap dumping, and hanging.
Any ideas? A later version of Tomcat ?
One answer
Also, -Xcompressedrefs should be the default setting for IBM Java 6 on Windows with -Xmx smaller than 25GB. In other words, it should not matter whether you add it or not in the Java options.
http://www-01.ibm.com/support/knowledgecenter/SSYKE2_6.0.0/com.ibm.java.doc.60_26/vm626/J9/VM/xcompressedrefs.html
I'm not so sure about the relative paths of the indices location, although I would change them to absolute paths whenever possible (it is required for configuring Tomcat service). You can check the jts.log file and see if the paths being reported when JTS started changed at all - if you see a different path for each startup, the theory of reindexing should stand true.