Last modified: 2013-06-18 13:32:21 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18236, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16236 - Searches that are complex and/or ask for a large number of results falsely return 'no results'
Searches that are complex and/or ask for a large number of results falsely re...
Status: RESOLVED WORKSFORME
Product: Wikimedia
Classification: Unclassified
lucene-search-2 (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Robert Stojnic
:
: 16522 17944 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-04 09:55 UTC by Gurch
Modified: 2013-06-18 13:32 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
A search for "sandwich" gets zero results (167.80 KB, image/png)
2012-12-31 17:07 UTC, Sumana Harihareswara
Details
A search for "sandwich" gets TWO results less than a minute later (180.52 KB, image/png)
2012-12-31 17:10 UTC, Sumana Harihareswara
Details

Description Gurch 2008-11-04 09:55:20 UTC
Search seems to persistently fail for certain namespace selections, but not others, even others that include those selections.

Example: searching on en.wikipedia for 'huggle'

(article) - works
user only - works
user talk only - fails
project only - fails
project talk only - fails
user + any of [user talk, project, project talk] - succeeds and returns pages from all the selected namespaces

By 'fails', I mean displays the "Note: unsuccessful searches are often caused ..." message, even though results clearly exist.

This has occurred every time I've tried in the last two weeks; reloading, clearing cache, using a different browser, machine or IP address does not fix the problem.

The problem is compounded by the fact that I am unable to use an external search engine to obtain many of these results.
Comment 1 Robert Stojnic 2008-11-04 12:51:10 UTC
Cannot reproduce. Was anyone able to reproduce this?
Comment 2 Gurch 2008-11-04 13:23:05 UTC
OK after some testing it seems to be related to your search preferences.

In particular increasing the "hits per page" option... I had mine at 100 rather than the default of 20, before, but whack it up to something like 1000 and this bug occurs in many more cases.

I guess MediaWiki doesn't like queries that big... it should do something less confusing than just returning the "no matches" message, though.
Comment 3 Gurch 2008-11-04 13:24:51 UTC
Oh, note also that clicking one of the higher links in the (20 | 50 | 100 | 250 | 500) line will give the same result, and is somewhat quicker than setting your preferences.
Comment 5 Robert Stojnic 2008-11-14 11:11:36 UTC
This is likely due to the way results are fetched on the backend. Results are fetched in a single thread, in a linear way from many index parts, so for large queries time accumulates for just more than 3 seconds, which is the default timeout in MWSearch. Possible solution would be:
1) increase timeout in MWSearch Http::get call to e.g. 6 seconds - obviously this would produce longer waiting times for the user
2) fetch results on the backend in parallel - this would produce additional synchronization and slow down typical queries, possibly bogging down searchers with syncrhonization
Comment 6 Gurch 2008-11-15 02:45:52 UTC
(In reply to comment #5)
> This is likely due to the way results are fetched on the backend. Results are
> fetched in a single thread, in a linear way from many index parts, so for large
> queries time accumulates for just more than 3 seconds, which is the default
> timeout in MWSearch. Possible solution would be:
> 1) increase timeout in MWSearch Http::get call to e.g. 6 seconds - obviously
> this would produce longer waiting times for the user
> 2) fetch results on the backend in parallel - this would produce additional
> synchronization and slow down typical queries, possibly bogging down searchers
> with syncrhonization
> 

I'm not too bothered about the actual queries timing out, just the way it's presented to the user. A "search timed out" error message would be fine, just something other than giving the impression there are no results for the query.
Comment 7 Robert Stojnic 2008-12-01 20:15:57 UTC
*** Bug 16522 has been marked as a duplicate of this bug. ***
Comment 8 Brion Vibber 2008-12-28 21:11:38 UTC
Bumping -- I think I saw some adjustments for the timeouts recently. Does this take care of it?
Comment 9 Gurch 2008-12-29 19:20:13 UTC
(In reply to comment #8)
> Bumping -- I think I saw some adjustments for the timeouts recently. Does this
> take care of it?

Some queries (such as the ones in comment #1) that used to fail now no longer do, so to some extent yes.

It is still possible to get a time-out by asking for even more results or using more complex search terms/namespace filters, but as I stated in comment #6, it isn't really the timeout that's the problem, it's that no indication is given to the user that this has happened, and they are led to believe there are no results.

It would be more helpful to tell them to ask for fewer results per page and/or try a less complex search.

There is a difference between the output from a search that returns no results and a timed-out search. A search with no results has a "No page text matches" <h2>, followed by a "Note: Choosing the right search terms..." message. A timed-out search does not have the <h2>, but does have the additional message. Since this difference exists MediaWiki can presumably distinguish the two states and inform the user.
Comment 10 Robert Stojnic 2009-03-11 19:53:07 UTC
*** Bug 17944 has been marked as a duplicate of this bug. ***
Comment 11 matanya 2012-07-30 22:06:36 UTC
tested, doesn't happen anymore.
Comment 12 Sumana Harihareswara 2012-12-27 19:35:05 UTC
This is happening intermittently but more often in the last 3 weeks or so. Reopening, marking "high" and asking some of our Java volunteers to take a look if they have a moment.
Comment 13 Andre Klapper 2012-12-31 11:44:13 UTC
An example query is welcome in order to reproduce...
Comment 14 Sumana Harihareswara 2012-12-31 17:07:22 UTC
Created attachment 11570 [details]
A search for "sandwich" gets zero results

I'm trying to reproduce it and it's intermittent.  It JUST happened now regarding the word "sandwich".

Attached is a screenshot where you see that the search turned up zero results.  I had used the search box in the upper right hand corner and 
https://www.mediawiki.org/w/index.php?search=sandwich&title=Special%3ASearch&fulltext=1 gave me "There were no results matching the query."
Comment 15 Sumana Harihareswara 2012-12-31 17:10:13 UTC
Created attachment 11571 [details]
A search for "sandwich" gets TWO results less than a minute later

I then searched again (I think it was via that same search box in the upper right hand corner, since as you can see in the screenshot the search term has been trapped there) and got 2 results -- see screenshot.  The URL was different this time:

https://www.mediawiki.org/w/index.php?search=sandwich&button=&title=Special%3ASearch

Results:

https://www.mediawiki.org/wiki/Mobile_mockups_for_Android_style
    Mobile mockups for Android style
    The action bar on Honeycomb and Ice Cream Sandwich tablets is similar to on ICS phones, and could have more or fewer items on it. ...
    3 KB (516 words) - 10:40, 10 October 2012

https://www.mediawiki.org/wiki/Language_tools/Daily
    Language tools/Daily
    Stand-up meeting 2011-12-23 Skype call initiated by _ (08:00 UTC, _ minutes): plan on buying an ice cream sandwich. need to finish document on ...
    605 KB (67,542 words) - 14:04, 29 October 2012
Comment 16 Andre Klapper 2012-12-31 19:31:20 UTC
I'm closing this again as WORSKFORME as this seems to be better handled in bug 42423.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links