Failed CC Synchronization Import into RTC
Our SCM team has been testing and evaluating the CC Synchronizer for a while now. We have a stream in CC that is comprised of ~15 components and have been able to successfully import that stream with the components into a test project with relative ease.
We're attempting the same import with a real project and have had a number of issues. Specifically, the synchronization was kicked off and in the current activity section, it was reported to be listing the directories in clearcase. It ran for hours and eventually the process had to be killed manually. This component has consistently failed since. We're going to attempt to load the component (which contains ~4k files and ~1k folders) by pieces. The command running at the time of failure is: cleartool ls -recurse -short <path> Are there concerns with loading the component in the proposed piecemeal way? Is there anyway to troubleshoot issues with respect to loading? It's not a scalable solution to have our SCM team try to import existing components piecemeal. While in the middle of importing, there doesn't appear to be a way to cancel/abort the import. Is there a command we're simply missing on the context menu? Are there ramifications for killing the import process manually (since there doesn't appear to be another option through the tool)? |
4 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 08 '10, 11:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments below.
On 12/7/2010 10:53 PM, roderick.thomas wrote: Our SCM team has been testing and evaluating the CC Synchronizer for a So far, so good (:-). We're attempting the same import with a real project and have had a The first thing to do in a case like this is to run the cleartool command directly from the command line. Note that the synchronizer is reporting the exact command it is running through cleartool ... not some internal variant. So when you run that command, it is doing precisely what the synchronizer is doing. Are there concerns with loading the component in the proposed No problem with doing that (other than the user annoyance of doing so). Also, note that you can specify a whole set of roots in one request ... that way, if it makes it pasts the first piece, it will automatically try the next one. And if a piece fails, it will automatically try the next one. And if one piece hangs (more comments below), you can kill that process, and your next sync request will start up at the one that didn't succeed. Is there anyway to troubleshoot issues with respect to loading? It's The simplest approach is to see what cleartool command is taking an unexpected amount of time. The "activities" reported back to the sync result give you a rough idea of how the operations are taking (Rational support can tell you how to adjust the level of operation tracing that occurs). While in the middle of importing, there doesn't appear to be a way to The only way to kill it at the moment is to kill the operating system process that is performing the sync (on the sync host). You usually have to "unlock" that sync stream (using the "unlock" command in the sync editor or the sync properties page. Then you can just request the sync, and it will re-try any of the sync roots that weren't successfully imported on the previous request. Cheers, Geoff |
|
So we tried the piecemeal approach and ran into further issues: Synchronization failed: Deferred operation failed. For instance, we're seeing stack traces like below.
To your point about running the command via the cmd prompt, the team has done that and it completes as expected. Is there nothing else happening that could impact the result (e.g., timeout properties)?
|
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 09 '10, 10:08 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Roderick,
It looks like you have some significant problems with your RTC configuration (I noticed that you reported other strange RTC errors unrelated to the synchronizer). When you work with support on your other RTC error, you'll want to mention this stack trace to them as well, since that might help them track down what is wrong, in particular, the "deferred operation" is just the checkin of a set of changes. SQL Exception #1 I'm not a database person, but this might indicate either a disk space problem, or a permissions problem. Cheers, Geoff On 12/9/2010 10:38 AM, roderick.thomas wrote: So we tried the piecemeal approach and ran into further issues: |
And the root cause was attributed to a DB space allocation issue. Thanks. |
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.