Hello,
I am a bit puzzled by this one and not sure if it is the correct behaviour.
I am using apache solr search and it is returning the results as nids which are then used to filter a view so giving search results in a table. This is of course slows down the return of search results. I am using authcache primarily to speed up this search system and it was working great on older versions (1.4). I changed to 2.0 for other reasons and since then the caching of search results doesn't seem to work for logged in users.
The issue I am seeing is that for anonymous users the search results are being cached. So once the cache is warmed for any particular search the results are returned very quickly.
For logged in users, in the autcache debug message for the search results page I get:
Cache Status: "Caching CANCELLED"
Reason: "Redirecting to http://sitename.com/search/site/searchterm"
If i reload the search results page caching occurs and the page is returned lightning fast. if I repeat the search by submitting the search term again I get the above message and the page age is shown as a couple of seconds.
The fact that the search results page can be cached by reloading says to me the issue is with the redirect but why only with logged in users?
Loving the module in general because it transforms the usability of my Drupal sites.
Comment | File | Size | Author |
---|---|---|---|
#5 | 2101955-tmpfix-do-not-preclude-on-search-form.diff | 705 bytes | znerol |
Comments
Comment #1
znerol CreditAttribution: znerol commentedIn the source code of apachesolr I see one
drupal_goto
which potentially causes this redirect. This is around line 500 in apachesolr.module:The path
search
is normally indeed mapped to the core search module. It seems that the solr module somehow encounters an error and then tries to fall back on the core search module. Are there any suspicious entries in your watchdog log?Comment #2
milton_segretti CreditAttribution: milton_segretti commentedHello, Thanks for the reply.
Nothing in the logs. Search is working as I expect it to.
In poking around both search module (search.pages.inc - line 45) and apachesolr module (apachesolr_search.module - line 829) I found the below code:
search.pages.inc
apachesolr_search.module
Mostly clutching at straws because I don't really know whats going on but I thought the comment "In other words, the search form submits with POST but redirects to GET." was interesting.
Comment #3
znerol CreditAttribution: znerol commentedCould you try and figure out whether you end up in
apachesolr_failure
somehow? If you don't have a debugger ready, use eitherdrupal_set_message()
orwatchdog()
in order to log a message whenapachesolr_failure
is entered.Protip: Install devel and FirePHP and see your watchdog messages scroll by in the Firebug Console during page loads.
Comment #4
milton_segretti CreditAttribution: milton_segretti commentedHello,
Thanks for the tip.
I can confirm it does not enter
apachesolr_failure
.Comment #5
znerol CreditAttribution: znerol commentedOk, figured out whats happening. What you see is actually a combination of bugs.
First off, the message reported by Authcache Debug is actually misleading. The reason the search results page is not delivered from the cache for authenticated users actually has nothing to do with the preceding redirect itself (I've opened a separate issue for that #2104653: Authcache Debug shows wrong no-cache reason after redirect).
Rather Authcache 2.x simply prevents that the first request after a POST is delivered from the cache. I see that in your situation this behavior is not desirable. I have to examine some more cases before deciding whether this is a reasonable default behavior #2104661: Rethink automatic preclusion after POST-request. In the meantime you may apply the attached temporary fix, which will disable the mechanism for all pages beneath /search.
HTH
Comment #6
znerol CreditAttribution: znerol commentedFixed in 7.x-2.0-alpha4