Closed Bug 567754 Opened 14 years ago Closed 9 years ago

Doing advanced Search Messages with 'run search on server' box ticked, still causes the search to be run locally on the client

Categories

(Thunderbird :: Search, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 546925

People

(Reporter: kbsingh, Unassigned)

Details

(Whiteboard: [dupeme])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100524 Minefield/3.7a5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100521 Lanikai/3.1.1pre

I'm trying to run a search through a large number of emails ( a few GB in size ), and even though the 'run search on server' is selected before I enter any criteria - it looks as if the search is being run locally on the laptop rather than on the server. 



Reproducible: Always

Actual Results:  

Thunderbird using lots of resources on the client machine during the search :

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                           
 4621 kbsingh   15   0  760m 277m  26m S 91.7 13.7  35:31.39 thunderbird-bin 

At the same time load on the server:
top - 15:01:32 up 7 days,  6:58,  1 user,  load average: 0.00, 0.04, 0.01
Tasks: 140 total,   1 running, 139 sleeping,   0 stopped,   0 zombie

Expected Results:  
Search should run on the server, therefore all activity for the search should be offloaded to the server resulting in minimal load / resource requirements on the client side

In case this is relevant: I'm running cyrus-imapd
Component: General → Search
QA Contact: general → search
ludo, Karanbir,
 duplicate of Bug 546925 ?? - custom header search is non-functional ('Run search on server' of Edit/Find/Search Messages doesn't work any more)
Whiteboard: [dupeme]
(In reply to Wayne Mery (:wsmwk) from comment #1)

Wayne, https://bugzilla.mozilla.org/show_bug.cgi?id=546925 seems to focus on Custom-Headers, whereas my issue was that server side search is completely non functional in tbird3. But if marking this as a dependency helps move the overall search issue forward, sure.
Karinbir, problem still exists in current TB 13?
Depends on: 546925
(In reply to Wayne Mery (:wsmwk) from comment #1)
> ludo, Karanbir,
>  duplicate of Bug 546925 ?? - custom header search is non-functional ('Run
> search on server' of Edit/Find/Search Messages doesn't work any more)

I'm the reporter of 546925.  The two bugs (and maybe others) should be consolidated into one titled:

HEADER SEARCH IS HARD CODED TO LOCAL

Header searches never go to IMAP.  Not the standard headers nor custom headers, only body searches will go to IMAP.  546925 exists because TB doesn't store custom headers in the standard indexes.  It only stores them if GLODA/offline cache is enabled, which is the secondary cause of 546925.  Karinbir didn't test body searches or he'd have realized his problem isn't wholesale broken IMAP search.  Karinbir please run server/body search to confirm.
 
This broken hard coded workflow logic is the root cause of both bugs.  Pseudo code:

if RUN_SEARCH_ON_SERVER=yes
   if BODY=yes 
       do 
           search IMAP
       else
           search local
   end if
end if

This pseudo code exactly describes the broken IMAP search behavior I seen, and applies to both bugs.
@Status: Confirm, present in TB 24.2.0
@Platform: should be ALL, Windows is affected the same

To repeat Stan: As can be seen in wireshark, only body searches will go to IMAP, header searches (subject, etc.) will be done locally, regardless of ticking the "search on server" radio button in the ctrl-shift-F "find" dialogue.
OS: Linux → All
Hardware: x86 → All
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Summary: Doing a search with 'run search on server' box ticked, still causes the search to be run locally on the client → Doing advanced Search Messages with 'run search on server' box ticked, still causes the search to be run locally on the client
No longer depends on: 546925
You need to log in before you can comment on or make changes to this bug.