Bug 3068 - [resources] History Store is leaking (1GF9ZLP)
Summary: [resources] History Store is leaking (1GF9ZLP)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.0 M9   Edit
Assignee: DJ Houghton CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 33576
Blocks: 36907
  Show dependency tree
 
Reported: 2001-10-10 22:48 EDT by Rodrigo Peretti CLA
Modified: 2004-05-09 12:27 EDT (History)
1 user (show)

See Also:


Attachments
Code changes (9.30 KB, patch)
2003-05-05 10:52 EDT, Debbie Wilson CLA
no flags Details | Diff
Test suite changes (21.93 KB, patch)
2003-05-05 10:53 EDT, Debbie Wilson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Rodrigo Peretti CLA 2001-10-10 22:48:49 EDT
From DD:
This is what I think is happening in more detail: 

Your index (named "index") contains entries of the form (key, objectID). You probably
create these something like this:

Index index = store.createIndex("index");
...
ObjectID id = store.createObject(bsob);
index.insert(key, id);
...


When you remove an index entry (perhaps you've hit a limit and are cleaning up the store)
you probably do something like:

IndexCursor cursor = index.open();
cursor.find(name);
cursor.remove();

what I think this should be is:

cursor.find(name);
id = cursor.getValueAsObjectID();
store.removeObject(id);
cursor.remove();

NOTES:

RTP (6/13/01 4:11:26 PM)
	The right thing is done in the Property Store but the History Store does not
delete the BSOB, just the index entry.

RTP (6/13/01 4:10:43 PM)
	Moving to Deferred.

RTP (6/13/01 4:44:37 PM)
	Similiar problems detected in the property store when updating values.
From DD:
You could be getting the same effect if you are updating an index entry to point to a new object eg.

cursor.find(key);
ObjectID newID = store.createObject(newStuff);
cursor.updateValue(newID);

should be:

cursor.find(key);
ObjectID oldID = cursor.getValueAsObjectID();
store.removeObject(oldID);
ObjectID newID = store.createObject(newStuff);
cursor.updateValue(newID);

Could you be doing that when you update a property?

RTP (6/13/01 4:45:14 PM)
	That's exactly what we are doing.
Comment 1 DJ Houghton CLA 2001-10-24 06:43:04 EDT
PRODUCT VERSION:
	122

Comment 2 DJ Houghton CLA 2002-01-08 14:26:23 EST
Not a committed item on the 2.0 plan.
Changing resolution to LATER.
Comment 3 John Arthorne CLA 2002-03-06 13:10:45 EST
Fixed the property store update problem.  See bug 10548.
Comment 4 DJ Houghton CLA 2002-09-10 11:59:08 EDT
Reopening for investigation.
Comment 5 DJ Houghton CLA 2003-02-20 17:31:51 EST
Requires more investigation. 
Investigate for RC2.
Comment 6 Debbie Wilson CLA 2003-02-28 15:01:01 EST
The following is a code snippet from the method remove(HistoryStoreEntry 
entry) in the class HistoryStore.  This code should be tried again after bug 
#33576 has been solved.

Note that in order to fix this bug properly, we will also have to look at the 
way the HistoryStore creates a counter to uniquely distinguish between states 
for the same file that have the same last modified time.  Currently, the 
visitor in addState(IPath path, UniversalUniqueIdentifier uuid, long 
lastModified) just counts up the number of states with the same filename and 
lastmod time.  It then assigns a count number that is one bigger than the 
number of states it found.  If we remove some of these older states, we could 
end up creating a new state with a filename, lastmod time and counter which 
are the same as an existing state (the number of states is not sufficient for 
determining the counter if some previous states are removed).  Note that on a 
move for example, a new state is created with the new filename and the 
existing lastmod time (not the current system time).

protected void remove(HistoryStoreEntry entry) throws IndexedStoreException {
	// Do not remove the blob yet.  It may be referenced by another
	// history store entry.
	try {
		Vector objectIds = store.getIndex
().getObjectIdentifiersMatching(entry.getKey());
		if (objectIds.size() > 1) {
			System.out.println("Too many objects");
			for (int i = 0; i < objectIds.size(); i++) {
				long lastmod = entry.getLastModified();
				int count = entry.getCount();
				String objNum = ((ObjectID)objectIds.get
(i)).toString();
				String uuid = entry.getUUID().toString();
				System.out.println("last mod = " + lastmod + " 
count = " + count + " objNum = " + objNum + " uuid = " + uuid);
			}
		}
		for (int i = 0; i < objectIds.size(); i++) {
			store.removeObject((ObjectID)objectIds.get(i));
		}
	} catch (Exception e) {
		String message = Policy.bind("history.problemsCleaning"); //
$NON-NLS-1$
		ResourceStatus status = new ResourceStatus
(IResourceStatus.FAILED_DELETE_LOCAL, null, message, e);
		ResourcesPlugin.getPlugin().getLog().log(status);
	}
	entry.remove();
}
Comment 7 Debbie Wilson CLA 2003-03-03 14:48:30 EST
See previous comments for detailed description of what must change.  This 
issue being deferred to 2.2 as there is a high potential of deleting objects 
that are still in use.
Comment 8 Debbie Wilson CLA 2003-05-05 10:52:37 EDT
Created attachment 4781 [details]
Code changes

Patch for code for this bug fix and 36907 - [resources]
HistoryStore.removeAll() doesn't
Comment 9 Debbie Wilson CLA 2003-05-05 10:53:28 EDT
Created attachment 4782 [details]
Test suite changes

Patch for test suite changes for this bug fix and 36907 - [resources]
HistoryStore.removeAll() doesn't
Comment 10 DJ Houghton CLA 2003-05-14 15:11:27 EDT
Moving to component Inbox for review and release. Bug 3068 contains the patch 
for both fixes.
Comment 11 DJ Houghton CLA 2003-05-14 15:20:02 EDT
Note that the patch contains code which relies on being compiled against 1.4 
class libraries. We must change this to work against 1.3 libraries.
Comment 12 DJ Houghton CLA 2004-05-09 12:27:59 EDT
Released to HEAD.