Description
There are a number of situations in which cleartool exits with an error code that FishEye doesn't consider to be errors:
- cleartool lsview <viewname> for a viewname that does not exist
- cleartool lshistory -branch <branch-name> vob/component-path for a branch that has no versions in the vob/component-path
FishEye deals with this by inspecting the error message returned by cleartool and handling 'expected' error messages.
However, sometimes FishEye doesn't receive the error message from cleartool and can't handle the error gracefully. As a result indexing stops with an indexing error, for instance:
2011-02-22 13:02:16,647 ERROR [IncrementalPinger2 some-repo] fisheye.app BaseRepositoryScanner-handleSlurpException - Problem processing revisions from repo TestAutomation_14.0 due to class com.cenqua.fisheye.rep.RepositoryClientException - com.atlassian.fisheye.clearcase.ClearCaseProcessException: Error executing command (lshistory -all -since 31-December-1969.19:00:00 -branch some-branch -fmt "%Nd %[activity]p\n" vob/somevob ) : : com.cenqua.fisheye.rep.RepositoryClientException: com.atlassian.fisheye.clearcase.ClearCaseProcessException: Error executing command (lshistory -all -since 31-December-1969.19:00:00 -branch some-branch -fmt "%Nd %[activity]p\n" vob/somevob ) : : at com.atlassian.fisheye.clearcase.ClearCaseRepositoryScanner.processRevisions(ClearCaseRepositoryScanner.java:559) at com.cenqua.fisheye.rep.BaseRepositoryScanner.slurpRepository(BaseRepositoryScanner.java:291) at com.cenqua.fisheye.rep.BaseRepositoryScanner.doSlurpTransaction(BaseRepositoryScanner.java:258) at com.cenqua.fisheye.rep.BaseRepositoryScanner.ping(BaseRepositoryScanner.java:190) at com.cenqua.fisheye.rep.BaseRepositoryEngine.doSlurp(BaseRepositoryEngine.java:85) at com.cenqua.fisheye.rep.RepositoryEngine.slurp(RepositoryEngine.java:387) at com.cenqua.fisheye.rep.ping.OneOffPingRequest.doRequest(OneOffPingRequest.java:25) at com.cenqua.fisheye.rep.ping.PingRequest.process(PingRequest.java:66) at com.cenqua.fisheye.rep.RepositoryHandle.processPingRequests(RepositoryHandle.java:132) at com.cenqua.fisheye.rep.RepositoryHandle.queuePingRequest(RepositoryHandle.java:122) at com.cenqua.fisheye.rep.ping.PingRequest.run(PingRequest.java:33) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) Caused by: com.atlassian.fisheye.clearcase.ClearCaseProcessException: Error executing command (lshistory -all -since 31-December-1969.19:00:00 -branch some-branch -fmt "%Nd %[activity]p\n" vob/somevob ) : *<missing error message>* : at com.atlassian.fisheye.clearcase.ClearCaseContext.runInteractiveProcess(ClearCaseContext.java:304)
These errors are intermittent; as far as we've seen the same command succeeds (that is, FishEye will intercept and handle the cleartool error) on the next indexing run.
We need to investigate whether we can handle this more gracefully. One option is to use the exit code of the cleartool process to identify the error condition, assuming that the exit code uniquely identifies the error conditions.
Another strategy is to avoid the error conditions by changing the cleartool commands that FishEye is using. Most of the issues we've seen are triggered by the lshistory command. An option is to move from per-branch processing to per-vob/component processing and filter the output for the branches we're interested in. However, this will result in much more cleartool output and potentially decreased indexing performance.
Attachments
Issue Links
- relates to
-
FE-3343 UCM ClearCase: FishEye doesn't index project components that aren't components of the project's PVOB
-
- Closed
-