Re: [jira] Commented: (SOLR-127) Make Solr more friendly to external HTTP caches

2008-03-19 Thread Shalin Shekhar Mangar
Hoss, I apologize for spamming the issue comments. I just thought it
would be the appropriate place to record all critical discussions and
decisions related to the issue so that people who read it later get to
know all arguments made.

In general, emitting the cache header based on whether the Index is
modified or not can have problem with these cases:
1. Solr Statistics page (statistics change even though index doesn't)
2. Distributed Search (results on another shard may change and this
index remains same)
3. Partial Results in case of timeouts
4. DataImportHandler - the status page keeps changing even though the
IndexReader remains the same (until committed)

I think we both are in agreement that this should configurable on a
per-handler basis instead of on a global basis.

To your point #2, it is true that Solr should be emitting the cache
headers to conform to HTTP spec but, the strategy used to compute
those headers should be varying for different handlers. If we take a
leaf out of the servlet API, the servlets are the ones which decide
the lastModifiedSince and expires headers and not Tomcat. Similiarily,
here the handler which is the actual one writing out the response,
should be the one deciding on the strategy.

IMHO, the approach taken by SOLR-505 and SOLR-506 is good enough. So
using, SOLR-505 handlers can decide to emit/suppress cache headers on
a per-response basis (e.g. partial resutls, errors etc.). Using
SOLR-506, the end user can enable/disable emitting cache headers
per-handler. We can emit cache headers as the default behavior for
SearchHandler, SpellCheckerHandler and MoreLikeThisHandler to begin
with.

What do you think?

On Tue, Mar 18, 2008 at 11:25 PM, Hoss Man (JIRA) <[EMAIL PROTECTED]> wrote:
>
> [ 
> https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579953#action_12579953
>  ]
>
>
>  Hoss Man commented on SOLR-127:
>  ---
>
>  For the record: most of this discussion should have happened on the solr-dev 
> list, not in the issue comments ... but i would like to address some points, 
> so I'll do it here since this is where the discussion is.
>
>  1) It's true, there is no way to configure caching on a per request handler 
> basis -- if you look at the history of the issue we looked into that but 
> because of the necessary API changes we scaled back the scope of the patch -- 
> it can be done, it just needs more thought into how to do it and people 
> interested in working on it.
>
>  2) there is no doubt in my mind that having the cache awareness code on by 
> default is the right approach moving forward.  These options don't cause Solr 
> do do any caching, or to force any external caches to cache the pages -- they 
> only result in Solr behaving correctly according to the HTTP spec sections 
> relating to cache headers:
>* *if* a request is made to Solr via an HTTP cache that cache will receive 
> headers it can use to decide if/how-long to cache the response
>* *if* Solr receives a request with cache validation information then it 
> responds with a 304
>  if you don't want that behavior then either don't access Solr via a cache, 
> or explicitly set the  option; but the default 
> behavior for people who are upgrading from 1.2 should be for Solr to emit 
> Correct headers and to respect validation requests.  Requiring Solr users to 
> explicitly turn on an option to get Solr to emit correct Caching headers 
> would be like requiring them to explicitly set an option to get well formed 
> XML instead of invalid XML -- the default should be the one that behaves the 
> most correctly.
>
>  I admit however: this is a notable enough change that it should be mentioned 
> in the "Upgrading from 1.2" section of CHANGES.txt -- I will add that.
>
>  3) if other pending patches attached to other issues have poor behavior as a 
> result of the caching code, the appropriate place to discuss that is in those 
> issue -- the solution may be to mark those issues dependent on a new issue to 
> add the API hooks for request handlers to suppress caching (that's a good 
> idea in general) but it's also possible that there are 
> better/safer/more-logical solutions specific to those patches ... if the 
> DataImportHandler is having problems because the caching code, i'm guessing 
> it's because people use it to trigger updates using an HTTP GET -- that 
> violates the semantics of GET and making work arounds in the the HttpCaching 
> code to allow for that is a bad idea.
>
>  4) saying only the "/select" handler should get it's responses cached is 
> missleading -- under Solr 1.3 there won't be anything special about /select 
> ... any handler name can be used for queries, and any handler name can be 
> used for updates ... if you are issuing a request that modifies the index, 
> you should be sending a POST and no caching headers (or validation) will be 
> done by Solr reg

Solr nightly build failure

2008-03-19 Thread solr-dev

init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build

compile-common:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/common
[javac] Compiling 31 source files to /tmp/apache-solr-nightly/build/common
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/core
[javac] Compiling 310 source files to /tmp/apache-solr-nightly/build/core
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compile-solrj-core:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/client/solrj
[javac] Compiling 22 source files to 
/tmp/apache-solr-nightly/build/client/solrj
[javac] Note: 
/tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

compile-solrj:
[javac] Compiling 2 source files to 
/tmp/apache-solr-nightly/build/client/solrj

compileTests:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/tests
[javac] Compiling 85 source files to /tmp/apache-solr-nightly/build/tests
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

junit:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results
[junit] Running org.apache.solr.BasicFunctionalityTest
[junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 97.725 sec
[junit] Running org.apache.solr.ConvertedLegacyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 46.812 sec
[junit] Running org.apache.solr.DisMaxRequestHandlerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 22.132 sec
[junit] Running org.apache.solr.EchoParamsTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.774 sec
[junit] Running org.apache.solr.OutputWriterTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.608 sec
[junit] Running org.apache.solr.SampleTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.664 sec
[junit] Running org.apache.solr.TestDistributedSearch
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 9.622 sec
[junit] 2008-03-19 08:12:39.859::INFO:  Shutdown hook executing
[junit] 2008-03-19 08:12:39.863::INFO:  Shutdown hook complete
[junit] Test org.apache.solr.TestDistributedSearch FAILED
[junit] Running org.apache.solr.analysis.HTMLStripReaderTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.031 sec
[junit] Running org.apache.solr.analysis.TestBufferedTokenStream
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.994 sec
[junit] Running org.apache.solr.analysis.TestCapitalizationFilter
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.073 sec
[junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.401 sec
[junit] Running org.apache.solr.analysis.TestKeepWordFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.289 sec
[junit] Running org.apache.solr.analysis.TestPatternReplaceFilter
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.334 sec
[junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.038 sec
[junit] Running org.apache.solr.analysis.TestPhoneticFilter
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.758 sec
[junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.326 sec
[junit] Running org.apache.solr.analysis.TestSynonymFilter
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 3.536 sec
[junit] Running org.apache.solr.analysis.TestTrimFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.228 sec
[junit] Running org.apache.solr.analysis.TestWordDelimiterFilter
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 45.707 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.433 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.643 sec
[junit] Running org.apache.solr.common.util.ContentStreamTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time el

Re: NEW Facetting Problem

2008-03-19 Thread Yonik Seeley
On Tue, Mar 18, 2008 at 3:19 PM, Tejaswi_Haramurali <[EMAIL PROTECTED]> wrote:
>  The problem is , when I do a search on 'Mellon' or any word associated with
>  the 'features' field ,I get the results. But However when I do a search on
>  any of the other fields, I dont get the results.

You don't get search results, or facet results?
What is the exact query you are sending?

Testing first with URLs from your browser would help...
http://localhost:8989/solr/select?q=features:Mellon

-Yonik


[jira] Commented: (SOLR-303) Distributed Search over HTTP

2008-03-19 Thread Sean Timm (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580392#action_12580392
 ] 

Sean Timm commented on SOLR-303:


Jayson--

I agree.  I've been meaning to recommend that be added.  We've found it 
invaluable in the past (mostly with debugging) when doing federated and 
distributed search.  I would like to see a "shard" field added which would 
contain the base URI of the shard where the result originated as provided in 
the request.  The index of each result is less important to me, but I can see 
how that would be useful.

> Distributed Search over HTTP
> 
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Attachments: distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed_add_tests_for_intended_behavior.patch, 
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch, 
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, 
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, 
> fedsearch.stu.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SOLR-303) Distributed Search over HTTP

2008-03-19 Thread Jayson Minard (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580403#action_12580403
 ] 

Jayson Minard commented on SOLR-303:


I'll see if I can work up a patch tonight on the extended response...

> Distributed Search over HTTP
> 
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Attachments: distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed.patch, distributed.patch, distributed.patch, 
> distributed.patch, distributed_add_tests_for_intended_behavior.patch, 
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch, 
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, 
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, 
> fedsearch.stu.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.