Bug #5395


Get unexpected result if a search was done before metacat finishes its indexing during the inserting process.

Added by Jing Tao almost 13 years ago. Updated over 10 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi, Scott:

I dug around this issue a while and found it out it was a search cache issue in Metacat. Did you do an immediate search after you uploaded the szalt4twittergraph?

I guess you did a search before Metadata finished its indexing during the inserting (uploading), so the search didn't get the name of kar xml and docid of kar file. The worse case is that the broken search result was cached and it will persist forever. The only way to resolve the problem is to remove the cached item.

After I deleted the record of this document in the xml_queryresult table (the search cache table), the search worked for me. You might make a try as well. If you see any problem, please let me know.

I will file a bug about this issue.



Scott Zimmer wrote:

I am trying to upload some kar files that I created to the Kepler-Dev repository. I upload them from inside Kepler-2.2 and I always get the message that the component uploaded successfully. I am making them publicly available and logging in anonymously. Sometimes when I search the repository through the website ( I get "null" as the kar name and if I click download, I get the following return
<error>the requested docid '' does not exist</error>

I can still find the uploaded component if I search the repository from inside Kepler and I can drag it onto my canvas. I have uploaded szalt3twittergraph and szalt4twittergraph to the repository. I can find both kar files from within Kepler, but szalt4twittergraph shows up as null and can't be downloaded from the repository via the website. I'd appreciate any insight you have into the cause.


Related issues

Related to Metacat - Feature #5810: Implement SOLR-based searchClosedJing Tao01/24/2013

Actions #1

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 5395

Actions #2

Updated by ben leinfelder about 11 years ago

  • Assignee changed from Chad Berkley to Jing Tao
  • Target version changed from Unspecified to 2.1.0

There's nothing we can do about the indexing delay unless we perform indexing while blocking the insert/upload process. I don't think we want to go in that direction and our design for using SOLR is completely asynchronous. The good thing about the SOLR implementation is that the query result cache will not prevent the record from showing up once it has actually been indexed by SOLR.

Actions #3

Updated by ben leinfelder almost 11 years ago

  • Target version changed from 2.1.0 to 2.x.y

Deferring - though we don't really have a solution for this. Only affects a deprecated mechanism (pathquery), however.

Actions #4

Updated by ben leinfelder over 10 years ago

  • Status changed from New to Rejected

I think we should mark this as 'won't fix' since it is part of the deprecated pathquery feature.


Also available in: Atom PDF