Project

General

Profile

Bug #5395

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

Added by Jing Tao over 8 years ago. Updated about 6 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
05/05/2011
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5395

Description

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.

Thanks,

Jing

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 (http://kepler-dev.nceas.ucsb.edu/kepler/metacat) 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.

Scott


Related issues

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

History

#1 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 5395

#2 Updated by ben leinfelder over 6 years ago

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

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.

#3 Updated by ben leinfelder over 6 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.

#4 Updated by ben leinfelder about 6 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