Re: XSS in Solr admin interface
Le jeudi 19 juin 2008 à 19:21 -0700, Mike Klaas a écrit : > Fixed in r669766. I checked the patch and it's correctly patching this XSS. Thanks to the dev team ! Regards, Nicob
[jira] Commented: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606634#action_12606634 ] Noble Paul commented on SOLR-572: - Why do we need to add the queryConverter definition outside of the speallcheck search component? Is it going to be used by any other component other than this? > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > http://wiki.apache.org/solr/SpellCheckComponent > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Use method chaining in SolrQuery
SolrQuery has umpteen no:of setter methods and one needs to invoke a
lot of them before sending the query. Can we make the 'setter' methods
return 'this' so that users can chain the method calls and make the
client code simpler.
as follows
SolrQuery solrQuery = new SolrQuery().
setQuery("ipod").
setFacet(true).
setFacetMinCount(1).
setFacetLimit(8).
addFacetField("category").
addFacetField("inStock");
--
--Noble Paul
SolrJ javadocs
Where can I find javadocs for SolrJ? I want to put up the link in the SolrJ wiki? -- --Noble Paul
Re: [jira] Updated: (SOLR-502) Add search time out support
If the patch is going in immediately it may not be necessary. --Noble On Thu, Jun 5, 2008 at 8:37 PM, Sean Timm (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Sean Timm updated SOLR-502: > --- > >Attachment: SOLR-502.patch > > This patch adds a conditional to ensure backwards compatibility within SOLR > 1.3 nightly builds, per Noble Paul's suggestion. Is that necessary? > >> Add search time out support >> --- >> >> Key: SOLR-502 >> URL: https://issues.apache.org/jira/browse/SOLR-502 >> Project: Solr >> Issue Type: New Feature >> Components: search >>Reporter: Sean Timm >>Assignee: Otis Gospodnetic >>Priority: Minor >> Fix For: 1.3 >> >> Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, >> SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, >> solrTimeout.patch, solrTimeout.patch >> >> >> Uses LUCENE-997 to add time out support to Solr. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- --Noble Paul
Re: XSS in Solr admin interface
On 19-Jun-08, at 5:47 PM, Yonik Seeley wrote: On Thu, Jun 19, 2008 at 7:42 PM, Nicob <[EMAIL PROTECTED]> wrote: while testing the Solr search engine, I found a XSS vulnerability in its administration interface. I wrote to [EMAIL PROTECTED], but I wonder if this list could be a better place to find a security contact of the Solr project. This is definitely the right list. Is this vulnerability in the current dev version of solr? Fixed in r669766. -Mike
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[
https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606615#action_12606615
]
Lars Kotthoff commented on SOLR-443:
{quote}
Did you try setting URIEncoding="UTF-8" on the connector?
Without that, you can't even correctly do a query that contains international
chars.
{quote}
Yes. A lot of the queries I issue are in Japanese ;)
I should add that I'm using the debian flavour of Tomcat, the exact version
number is 5.5.26-3. I don't know whether this version is patched in a way that
affects this, but the Tomcat documentation
([http://tomcat.apache.org/tomcat-5.5-doc/config/http.html]) specifically
mentions decoding the *URL* for that setting. That may or may not be
intentional, but I'm pretty sure that the behaviour you're seeing is
"accidental".
As for the NPE, it occurs when a request for facet counts returns something for
a facet value which wasn't in the request. I think that it should only be
handled more gracefully to the extent of giving a more meaningful error
message. But there's no need to if the underlying issue is fixed :)
> POST queries don't declare its charset
> --
>
> Key: SOLR-443
> URL: https://issues.apache.org/jira/browse/SOLR-443
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 1.2
> Environment: Tomcat 6.0.14
>Reporter: Andrew Schurman
>Priority: Minor
> Attachments: SOLR-443-multipart.patch, solr-443.patch,
> solr-443.patch, SolrDispatchFilter.patch
>
>
> When sending a query via POST, the content-type is not set. The content
> charset for the POST parameters are set, but this only appears to be used for
> creating the Content-Length header in the commons library. Since a query is
> encoded in UTF-8, the http headers should also specify content type charset.
> On Tomcat, this causes problems when the query string contains non-ascii
> characters (characters with accents and such) as it tries to parse the POST
> body in its default ISO-9886-1. There appears to be no way to set/change the
> default encoding for a message body on Tomcat.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606614#action_12606614 ] Yonik Seeley commented on SOLR-443: --- Did you try setting URIEncoding="UTF-8" on the connector? Without that, you can't even correctly do a query that contains international chars. I indexed the example data, and with standard tomcat config, verified that SolrJ found nothing when searching for hello (with an accent over the e... it's in solr.xml) with both GET and POST. After editing the tomcat config and switching it to UTF-8, both GET and POST correctly find the solr example document. bq. a NullPointerException from the bowels of the faceting code. That seems like a related but separate issue, and it would be nice if it were handled more gracefully. > POST queries don't declare its charset > -- > > Key: SOLR-443 > URL: https://issues.apache.org/jira/browse/SOLR-443 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.2 > Environment: Tomcat 6.0.14 >Reporter: Andrew Schurman >Priority: Minor > Attachments: SOLR-443-multipart.patch, solr-443.patch, > solr-443.patch, SolrDispatchFilter.patch > > > When sending a query via POST, the content-type is not set. The content > charset for the POST parameters are set, but this only appears to be used for > creating the Content-Length header in the commons library. Since a query is > encoded in UTF-8, the http headers should also specify content type charset. > On Tomcat, this causes problems when the query string contains non-ascii > characters (characters with accents and such) as it tries to parse the POST > body in its default ISO-9886-1. There appears to be no way to set/change the > default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606610#action_12606610 ] Lars Kotthoff commented on SOLR-443: I'm also using tomcat 5.5.26 here, but I can't reproduce that behaviour. I've tested on two different machines, but my tomcat always assumes that the POST body is url-encoded ISO-8859-1; that is, when I use the current SVN version, it only works for ascii characters (encoding is the same in ISO-8859-1 and UTF-8). If I remove the line that sets the encoding of the POST body to UTF-8, it works for all ISO-8859-1 characters, as httpclient encodes to ISO-8859-1 by default. I'm very much in favour of a solution which works because all encodings are specified in the proper places as opposed to something that just happens to work with a "standard" configuration, but is not covered by any internet standard. This would be a timebomb just waiting to go off when somebody switches servlet container versions/configurations. Worse still, this problem is likely to affect people who are just using and not writing their own code for Solr and don't know anything about the internals (cf. SOLR-303). And they aren't going to get an error message telling them that the character encoding is wrong, but a NullPointerException from the bowels of the faceting code. The overhead from using multi-part requests may be considerable, but I don't think that network I/O and processing of network messages is likely to become a bottleneck in typical Solr applications. > POST queries don't declare its charset > -- > > Key: SOLR-443 > URL: https://issues.apache.org/jira/browse/SOLR-443 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.2 > Environment: Tomcat 6.0.14 >Reporter: Andrew Schurman >Priority: Minor > Attachments: SOLR-443-multipart.patch, solr-443.patch, > solr-443.patch, SolrDispatchFilter.patch > > > When sending a query via POST, the content-type is not set. The content > charset for the POST parameters are set, but this only appears to be used for > creating the Content-Length header in the commons library. Since a query is > encoded in UTF-8, the http headers should also specify content type charset. > On Tomcat, this causes problems when the query string contains non-ascii > characters (characters with accents and such) as it tries to parse the POST > body in its default ISO-9886-1. There appears to be no way to set/change the > default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XSS in Solr admin interface
On Thu, Jun 19, 2008 at 7:42 PM, Nicob <[EMAIL PROTECTED]> wrote: > while testing the Solr search engine, I found a XSS vulnerability in its > administration interface. I wrote to [EMAIL PROTECTED], but I wonder > if this list could be a better place to find a security contact of the > Solr project. This is definitely the right list. Is this vulnerability in the current dev version of solr? -Yonik
XSS in Solr admin interface
Hi, while testing the Solr search engine, I found a XSS vulnerability in its administration interface. I wrote to [EMAIL PROTECTED], but I wonder if this list could be a better place to find a security contact of the Solr project. Regards, Nicob
[jira] Resolved: (SOLR-424) The ruby output type produces incorrect output for numeric types without a value
[
https://issues.apache.org/jira/browse/SOLR-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-424.
---
Resolution: Fixed
committed.
> The ruby output type produces incorrect output for numeric types without a
> value
>
>
> Key: SOLR-424
> URL: https://issues.apache.org/jira/browse/SOLR-424
> Project: Solr
> Issue Type: Bug
> Components: clients - ruby - flare
>Affects Versions: 1.1.0, 1.2, 1.3
>Reporter: Kurt Schrader
>Assignee: Erik Hatcher
>Priority: Critical
> Fix For: 1.3
>
> Attachments: fix_ruby_output.patch, SOLR-424.patch,
> TextResponseWriter-424.java.patch, TextResponseWriter-SOLR-424.patch,
> zero_length_int.patch
>
>
> When parsing the Ruby output returned from Solr, if a numerical value has no
> value in the index, it causes an invalid Ruby hash to be returned. For
> instance:
> {code:xml}
> 'response'=>{'numFound'=>1,'start'=>0,'maxScore'=>4.951244,'docs'=>[
> {
>'subclass_t'=>'Protocol',
>'pk_i'=>1,
>'id'=>'Protocol:1',
>'name_t'=>'Falcipain IC50',
>'group_id_i'=>,
>'score'=>4.951244}]
> }}
> {code}
> is not a valid hash because 'group_id_i' does not resolve to anything. It
> should resolve to nil:
> {code:xml}
> 'response'=>{'numFound'=>1,'start'=>0,'maxScore'=>4.951244,'docs'=>[
> {
>'subclass_t'=>'Protocol',
>'pk_i'=>1,
>'id'=>'Protocol:1',
>'name_t'=>'Falcipain IC50',
>'group_id_i'=>nil,
>'score'=>4.951244}]
> }}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Runo updated SOLR-430: -- Description: SolrJ should support sending a request that interacts with the SpellCheckComponent from SOLR-572 and handling the results in a sane manner so users of SolrJ can make use of the SpellCheckComponent code without parsing XML themselves. (was: SolrJ should support at a minimum a basic SpellcheckRequest and Response. Response should return a set of strings, the suggestions returned by the SpellcheckQueryHandler. Request should accept the basic commands that SC accepts over HTTP.) Changed issue summary to reflect new code for the spellchecker in solr/lucene. > SpellcheckerRequest / Response > -- > > Key: SOLR-430 > URL: https://issues.apache.org/jira/browse/SOLR-430 > Project: Solr > Issue Type: New Feature > Components: clients - java, spellchecker >Affects Versions: 1.3 >Reporter: Matthew Runo > > SolrJ should support sending a request that interacts with the > SpellCheckComponent from SOLR-572 and handling the results in a sane manner > so users of SolrJ can make use of the SpellCheckComponent code without > parsing XML themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606532#action_12606532 ] Shalin Shekhar Mangar commented on SOLR-430: Matthew -- Can you update the issue description? I'll try to add a patch soon. > SpellcheckerRequest / Response > -- > > Key: SOLR-430 > URL: https://issues.apache.org/jira/browse/SOLR-430 > Project: Solr > Issue Type: New Feature > Components: clients - java, spellchecker >Affects Versions: 1.3 >Reporter: Matthew Runo > > SolrJ should support at a minimum a basic SpellcheckRequest and Response. > Response should return a set of strings, the suggestions returned by the > SpellcheckQueryHandler. > Request should accept the basic commands that SC accepts over HTTP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606531#action_12606531 ] Matthew Runo commented on SOLR-430: --- Seems like a very reasonable thing to do to me > SpellcheckerRequest / Response > -- > > Key: SOLR-430 > URL: https://issues.apache.org/jira/browse/SOLR-430 > Project: Solr > Issue Type: New Feature > Components: clients - java, spellchecker >Affects Versions: 1.3 >Reporter: Matthew Runo > > SolrJ should support at a minimum a basic SpellcheckRequest and Response. > Response should return a set of strings, the suggestions returned by the > SpellcheckQueryHandler. > Request should accept the basic commands that SC accepts over HTTP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606525#action_12606525 ] Shalin Shekhar Mangar commented on SOLR-430: Should we re-use this issue to implement support for SpellCheckComponent (SOLR-572) instead of the older SpellCheckerRequestHandler? > SpellcheckerRequest / Response > -- > > Key: SOLR-430 > URL: https://issues.apache.org/jira/browse/SOLR-430 > Project: Solr > Issue Type: New Feature > Components: clients - java, spellchecker >Affects Versions: 1.3 >Reporter: Matthew Runo > > SolrJ should support at a minimum a basic SpellcheckRequest and Response. > Response should return a set of strings, the suggestions returned by the > SpellcheckQueryHandler. > Request should accept the basic commands that SC accepts over HTTP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606483#action_12606483 ] Yonik Seeley commented on SOLR-502: --- I see your point on the overlap between something like QueryCommand and ResponseBuilder... but ResponseBuilder feels like it's at a higher level. Say that a custom component or handler wants to do a couple queries... or different queries depending on the results of the first query (or something like unsupervised feedback). Should a different ResponseBuilder object be built for each query that is part of a request/response? ResponseBuilder is also a bit big and ill-defined (but currently gets the job done for communication between different query components). Upgrading it to serve as something you pass to a SolrIndexSearcher to do a query doesn't feel quite right (or at least that's not the way I've been thinking about it). > Add search time out support > --- > > Key: SOLR-502 > URL: https://issues.apache.org/jira/browse/SOLR-502 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sean Timm >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, > SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, > solrTimeout.patch, solrTimeout.patch, solrTimeout.patch > > > Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-443) POST queries don't declare its charset
[ https://issues.apache.org/jira/browse/SOLR-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606474#action_12606474 ] Yonik Seeley commented on SOLR-443: --- I just tested the latest 5.5 tomcat (5.5.26). It appears that the coding of x-www-form-urlencoded assumes the the same as that of the URI encoding now (percent encoded UTF-8 rather than latin-1 if configured that way). I'm not sure if it was like that in the past, but it works now at least! Just set URIEncoding="UTF-8" for the connector... see http://wiki.apache.org/solr/SolrTomcat under "URI Charset Config" > POST queries don't declare its charset > -- > > Key: SOLR-443 > URL: https://issues.apache.org/jira/browse/SOLR-443 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.2 > Environment: Tomcat 6.0.14 >Reporter: Andrew Schurman >Priority: Minor > Attachments: SOLR-443-multipart.patch, solr-443.patch, > solr-443.patch, SolrDispatchFilter.patch > > > When sending a query via POST, the content-type is not set. The content > charset for the POST parameters are set, but this only appears to be used for > creating the Content-Length header in the commons library. Since a query is > encoded in UTF-8, the http headers should also specify content type charset. > On Tomcat, this causes problems when the query string contains non-ascii > characters (characters with accents and such) as it tries to parse the POST > body in its default ISO-9886-1. There appears to be no way to set/change the > default encoding for a message body on Tomcat. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606473#action_12606473 ] Sean Timm commented on SOLR-502: bq. that definitely cuts down the patch size [...] What's your take? Before I made the change, I was against it as it seems more logical to have the partialResults associated with the results list, where the total count, etc. are. But this greatly simplifies the patch. I could go either way. bq. Another thing to consider is perhaps a SolrIndexSearcher.search() method that uses a command pattern I think I agree. :-) How is this different than my suggestion of passing the ResponseBuilder into the searcher? It seems that it would be useful to take it even a step further and pass the ResonseBuilder object around everywhere including the response handlers and writers. > Add search time out support > --- > > Key: SOLR-502 > URL: https://issues.apache.org/jira/browse/SOLR-502 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sean Timm >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, > SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, > solrTimeout.patch, solrTimeout.patch, solrTimeout.patch > > > Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606428#action_12606428 ] Sean Timm commented on SOLR-502: The timeout is to protect the server side. The client side can be largely protected by setting a read timeout, but if the client aborts before the server responds, the server is just wasting resources processing a request that will never be used. The partial results is useful in a couple of scenarios, probably the most important is a large distributed complex where you would rather get whatever results you can from a slow shard rather than throw them away. As a real world example, the query "contact us about our site" on a 2.3MM document index (partial Dmoz crawl) takes several seconds to complete, while the mean response time is sub 50 ms. We've had cases where a bot walks the next page links (including expensive queries such as this). Also users are prone to repeatedly click the query button if they get impatient on a slow site. Without a server side timeout, this is a real issue. Rate limiting and limiting the number of next pages that can be fetched at the front end are also part of the solution to the above example. > Add search time out support > --- > > Key: SOLR-502 > URL: https://issues.apache.org/jira/browse/SOLR-502 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sean Timm >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, > SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, > solrTimeout.patch, solrTimeout.patch, solrTimeout.patch > > > Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[
https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12606424#action_12606424
]
Yonik Seeley commented on SOLR-502:
---
Thanks Sean, that definitely cuts down the patch size, and it seems nicer not
to be touching DocSet and ResponseWriters, etc. What's your take?
Another thing to consider is perhaps a SolrIndexSearcher.search() method that
uses a command pattern to avoid having to always change the signatures when we
want to pass something new in or out? It might be more natural than passing
down an un-typed NamedList
{code}
QueryCommand {
Query q
Sort s
List filters
DocSet filter
int flags
int timeout
...
}
QueryResult {
DocList list
DocSet set
boolean timedOut
...
}
{code}
> Add search time out support
> ---
>
> Key: SOLR-502
> URL: https://issues.apache.org/jira/browse/SOLR-502
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sean Timm
>Assignee: Otis Gospodnetic
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch,
> SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch,
> solrTimeout.patch, solrTimeout.patch, solrTimeout.patch
>
>
> Uses LUCENE-997 to add time out support to Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-502: --- Attachment: SOLR-502.patch Changes the setting of the partialResults flag from the results to the responseHeader. > Add search time out support > --- > > Key: SOLR-502 > URL: https://issues.apache.org/jira/browse/SOLR-502 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sean Timm >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-502.patch, SOLR-502.patch, SOLR-502.patch, > SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, > solrTimeout.patch, solrTimeout.patch, solrTimeout.patch > > > Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-572. -- Resolution: Fixed Committed revision 669485. Note, I incorporated LUCENE-1297. See http://wiki.apache.org/solr/SpellCheckComponent for more details on how to use it, as well as the unit tests. Thanks to all who helped/contributed. > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch > > > http://wiki.apache.org/solr/SpellCheckComponent > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #474
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/474/changes
