Jazz Register Log in
Jazz Forum Welcome to the Jazz Community Forum

Welcome to the Jazz Community Forum

 Connect and collaborate with IBM Engineering experts and users

Intermittent Exception from IItemManager.fetchCompleteItem

Questions
Tags
Users
Badges
Kirk Vogen
(127●1●15●18) edited
Oct 11 '12, 10:02 a.m.
IItemManager.fetchCompleteItem is throwing an intermittent exception. . The code is attempting to lookup a baseline. Given a valid snapshot UUID, the second line sometimes fails. The first line is able to find the handle, but the fetchCompleteItem sometimes fails reporting that the item does not exist. Trying again later with the same UUID later typically works. Is the code below not using the API as it was intended? 
IBaselineHandle baselineHandle = (IBaselineHandle) IBaseline.ITEM_TYPE.createItemHandle(UUID.valueOf(baselineUuid), null);
teamRepository.itemManager().fetchCompleteItem(baselineHandle, IItemManager.REFRESH, progressMonitor);

Here is the exception: 

com.ibm.team.repository.common.ItemNotFoundException: CRJAZ0215I The following recordwas not found in the database: com.ibm.team.scm.common.internal.impl.BaselineHandleImpl@1dbe1dbe (stateId: null, itemId: [UUID _7iGVEhMXEeK55MckdS-9yw], origin: <unset>, immutable: <unset>)

Are there situations that could cause an item to appear not to exist?

0 votes

Comments
Kirk Vogen
Oct 22 '12, 10:49 a.m.
 I've done a bit more investigation on the issue. On a Friday, I brought up a build result in RTC and the snapshot was reported as being deleted. In gray text it said "The snapshot has been deleted." The following Monday, I brought the build result up and now the snapshot is back. It no longer reports it as deleted but instead has the snapshot link in the build result.

Any thoughts on what could explain this behavior?

The scenario is this: we have a Jazz Build Engine (JBE) build that does the initial build. Following that build, an external build system executes long-running, higher-level testing. That external build system uses the snapshot from the JBE build to get the source files. It then creates a build result in RTC, gets a handle to the snapshot, then associates the snapshot to that build result. That is done via a mixture of the Jazz Build Toolkit Ant Tasks and the Plain Java Client API. Could misuse of those APIs results in a snapshot that temporarily appears to be deleted? 

1 answer
4,916 views
0 votes

Accepted answer

Permanent link
Nick Edgar
JAZZ DEVELOPER (6.5k●7●11) Dec 07 '12, 11:54 a.m.
I see a couple of possibilities:
  1. If the UUID is for a snapshot, you should be using IBaselineSetHandle, not IBaselineHandle.  It's possible that using the wrong type results in inconsistent behaviour, e.g. if the in-memory item caches don't check the item type so it works if the item is in the cache, but fails if reading from the DB (or vice versa).
  2. You're running with different user ids at different times, and the visibility of the snapshot is such that it's visible to one user but not the other.
Kirk Vogen selected this answer as the correct answer

2 votes

Comments
Kirk Vogen
Dec 11 '12, 10:34 a.m.

Thanks for the response! I'm going to play around with the code per your suggestion in #1. Regarding #2, we are using the same user ID both for snapshot creation and snapshot lookup, so I think that we can rule that out.

Kirk Vogen
Dec 19 '12, 10:57 a.m.

This appears to have addressed the issue. We have not seen the intermittent exception after making this change. We've given it several days of run time so far without issue.

Your answer

Register or log in to post 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,989

Question asked: Oct 11 '12, 9:59 a.m.

Question was seen: 4,916 times

Last updated: Dec 19 '12, 10:57 a.m.

Confirmation Cancel Confirm