Page MenuHomePhabricator

Search engine is unstable, producing false "not found" result
Closed, DeclinedPublic

Description

Author: folengo

Description:
screenshot of false "not found" search result

The following search request is unstable :

http://ja.wikipedia.org/w/index.php?title=%E7%89%B9%E5%88%A5%3A%E6%A4%9C%E7%B4%A2&profile=default&search=%E7%A0%B4%E9%82%AA%E9%A1%95%E6%AD%A3%E9%88%94&fulltext=Search

This string is available in one article. Every now and then the search result is that nothing is found, which is a wrong result.

When the article is found, the result is displayed quite quickly (less than one second). When it is not found, the server takes a long time (about ten seconds) to process the request.

Perhaps this is because the servers are too busy. In that case, the search engine should reply with a "sorry, we can't process your request now, try again later" error message rather than make the user believe that the searched string is absent.

Attachment : screenshot


Version: unspecified
Severity: normal

Attached:

search_engine_bug_February_19_2012.jpg (451×759 px, 40 KB)

Details

Reference
bz34518

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:12 AM
bzimport set Reference to bz34518.

rainman wrote:

The search rate that reaches search pool2 hosts (search6, search15) is unusually low in the last 3 days. Search6 seems to be fine, while search15 comes up with weird errors of not being able to contact itself when trying to bind RMI instances (Connection refused to host: 10.0.3.15).

Repeating queries on search6 gives expected results, but going through ja.wikipedia.org gives results only in about 50% of the cases, as suggested in the bug report.

Hi folengo,

(In reply to comment #0)

The following search request is unstable :
http://ja.wikipedia.org/w/index.
php?title=%E7%89%B9%E5%88%A5%3A%E6%A4%9C%E7%B4%A2&profile=default&search=%E7%
A0%B4%E9%82%AA%E9%A1%95%E6%AD%A3%E9%88%94&fulltext=Search

I've tried to reproduce this a few times but I always get one result instead of zero. Is this still an issue?

Issues such as this one should be fixed in CirrusSearch. As we're in the process of migrating over from Lucene to Cirrus, I'm marking this bug as RESOLVED WONTFIX.

If this bug persists in CirrusSearch post-migration, please don't hesitate to refile this bug in MediaWiki extensions -> CirrusSearch.