Community
Participate
Working Groups
I'm running into a problem with persisting our participant index entries. I turned on VERBOSE mode to see what's going on... when shutting down the workbench, it looks like our index entries are marked as "?" (UNKNOWN) I believe this is during IndexManager.cleanUpIndexes() - a PatternSearchJob is created - then job.getIndexes(...) returns only the Java indexes, but not the JSP indexes - if indexes aren't found in this list, they are marked UNKNOWN - as a result all the participant index states are set to "?" state The next time the workbench starts up, these indexes are ignored. (if they weren't in-memory indexes in the previous session, if they were in-memory, they will be marked SAVED after being marked '?') As a workaround is it safe to call IndexManager.saveIndex(index) at shutdown for our indexes that we wish to persist?
Reporter said he may have a workaround. Unclear we need to address it in 3.0 maintenance stream (where defects got observed - 3.0.1).
Why are your indexes not being saved? This is the first question that should be answered.
Actually now that I look at it, our index is being saved, but "cleared" at one point. There's 3 steps I need to do to produce this... The first time the workbench is up, I import some files. After the first search, our disk index is saved (w/ entries) Then when the workbench is brought down/up again and a search is performed, the disk index is cleared for some reason. (merging disk.index and memory.index?) Then when the workbench is brought down/up again we get no search hits. (because index was cleared previously?) This may have something to do with the way we use our participant... Here is basically how we use it. - resource change occurs - JSPSearchDocument is created (basically a fake Java file) - passed to searchParticipant.scheduleDocumentIndexing(...) - our JSPSearchParticipant.indexDocument() passes the call through to getDefaultSearchParticipant().indexDocument(document, indexPath); which is the java search participant At this point my index exists, but is empty. - a search is performed, our JSPSearchPartcipant is passed into a search. The disk index now has entries - at shutdown the disk index is marked to UNKNOWN (in the cleanUpIndexes method) - it seems like it's set back to SAVED afterwards (because they were in memory?) this session. At this point, my index file on disk still has entries in it. - if I bring the workbench up again, my search still works (because the index was saved?), but at some point after the search, the index.save() call is made, and makes my index entries go away (merging disk.index w/ memory.index, which is empty?) my index file becomes empty. I'm not clear on why this happens. - At this point my index file on disk is empty and the entries won't come back. I'm going to narrow down some more to make sure it's not something that we are doing incorrectly. It's slow because I have to bring down the workbench and bring it back up 2x.
I forgot to add build level for eclipse: Version: 3.0.1 Build id: 200409161125
In order for IndexManager to be "aware" of our indexes when the workbench comes up, would it be a relatively safe workaround to call "saveIndex(...)" for our index files? This way our index entries won't get "merged" and cleared as they are currently. public void saveIndexes() { IndexManager indexManager = JavaModelManager.getJavaModelManager().getIndexManager(); IPath workingLocation = getModelWorkingLocation(); File folder = new File(workingLocation.toOSString()); String[] files = folder.list(); String locay = ""; //$NON-NLS-1$ Index index = null; try { for(int i=0; i<files.length; i++) { if(files[i].toLowerCase().endsWith(".index")); { locay = workingLocation.toString() +"/" + files[i]; index = new Index(locay, "Index for " + locay, true /*reuse index file*/); indexManager.saveIndex(index); } } } catch (Exception e) { } }
The merge should only happen because changes were made to the index. The in memory index needs to have 'removed' elements to delete them from the on disk index. If the in memory index is empty, then nothing happens on the merge.
I think I see what's happening now... - I perform a Java search - PatternSearchJob runs and calls ensureReadyToRun(..) -> - this calls getIndexes(...) -> - IndexManager calls getIndex(...) -> - getIndex(...) thinks my index entry is UNKNOWN (because it was set to this in cleanupIndexes(...) when I last shutdown) so calls rebuildIndex(...) - rebuildIndex() calls -> IndexBinaryFolder() - * this causes removal of the in-memory index entries for my index - now when the index is saved, it has a bunch of changes, the removed in-memory entries, so merging clears my disk index file. It seems strange that IndexManager is assuming that the index for that location is a binary project, and tries to rebuild it that way. So there are a couple of problems. My index gets marked as UNKNOWN at shutdown during cleanupIndexes(...) So then when PatternSearchJob tries to getIndexes(..), it forces recreation of my index file, but IndexManager assumes it's a "Binary Folder", and removes any in memory entries. Now when the index is saved again, the disk changes are lost. JDT shouldn't be marking my index state as UNKNOWN, and shouldn't be removing my in memory index entries during rebuild. Is it possible that it's because I'm using IndexManager.indexLocations to store my index location? This was a workaround to get my index entries included during Java search.
Please reopen if this is still an issue for you with a more recent version (at least 3.1.x or last 3.2 milestone M5 - or M6 when available), thanks
I believe it is, but seems you are waiting for something from us? I'm not sure what this it, so will not reopen, and will try to determine what, exactly, we (still) need.
With bug on old version, we want to be sure that problem is still alive => so, reopen the bug...
So, with which version did you get this problem recently? Is it still a 3.0.1 or a more recent one?
I need to know build ID with which you still have this problem... In case it's still 3.0.1, is there any chance to make a try with 3.0.2 and let us know if you can reproduce with this new maintenance build? I also want to know if there's any chance to make a try using a 3.2 milestone build to know if this is a problem I have to look at before 3.2 delivery? Note that this problem seems to be specific to your configuration (perhaps your participant or something else) as we never heard similar problem with index manager. So, I definitely need your help to try to understand what happen here... Please reopen while answering these questions, thanks
Closing as got no answer on requested information for more than a year...
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
