[jira] Updated: (SOLR-486) Support binary formats for QueryresponseWriter
[ https://issues.apache.org/jira/browse/SOLR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-486: Attachment: SOLR-486.patch This patch can add support for binary formats. > Support binary formats for QueryresponseWriter > -- > > Key: SOLR-486 > URL: https://issues.apache.org/jira/browse/SOLR-486 > Project: Solr > Issue Type: Improvement > Components: clients - java, search >Reporter: Noble Paul >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-486.patch > > > QueryResponse writer only allows text data to be written. > So it is not possible to implement a binary protocol . Create another > interface which has a method > write(OutputStream os, SolrQueryRequest request, SolrQueryResponse response) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-488) Solr does not generate highlights when uniqueId field is not defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572312#action_12572312
]
Mike Klaas commented on SOLR-488:
-
Thanks for the patch!
Tomer, I just tested this scenario under trunk (1.3dev), and Solr _does_
highlight documents if no uniqueKey is specified. It is true that the
highlight data is not labeled, but it is guaranteed to appear in the same order
as the documents in the section, so they are identifiable.
Why do you propose a query-time "link" field? Do you need to be able to vary
the field from request to request?
Also, it would be helpful to know why uniqueKey is not sufficient for this
purpose.
> Solr does not generate highlights when uniqueId field is not defined in the
> schema
> --
>
> Key: SOLR-488
> URL: https://issues.apache.org/jira/browse/SOLR-488
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.2
> Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
> Apache Tomcat 6.0.14
>Reporter: Tomer Gabel
> Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in
> the schema. I believe the reason for this is that it's very difficult to
> modify or extend the XmlWriter behavior, which is why highlights reside in
> their own "section" in the response XML and subsequently need to be "linked"
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need
> highlights; the solution we came up with was to provide a user-definable
> "link field," which is the document field whose value resides in the {{ name="215">}} elements in the generated output. I will presently attach a
> patch which adds a "hl.link" query parameter, which takes a field name and
> uses that as the "link field." If the parameter is not specified the original
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom
> handlers add a lot of information to each document, and the way the response
> writer is implemented makes it nigh impossible to add information to any
> specific document within the response. I should probably open an issue which
> calls to reimplement this aspect of 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-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-487. - Resolution: Fixed Thanks for the patch, but this functionality is already in trunk (1.3). http://wiki.apache.org/solr/HighlightingParameters has a list of what's new in the next version (a lot has changed since 1.2 in the Highlighter world) > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas closed SOLR-487. --- > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Assignee: Mike Klaas >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-487: Assignee: Mike Klaas > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Assignee: Mike Klaas >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572262#action_12572262 ] Sean Timm commented on SOLR-489: At Hoss' goading, here is my attempt at adding @deprecation tags where missing. The attached patch fixes adds comments where (I think) it is clear to me why something was deprecated and what to use now. Some files contain deprecations that I am less sure of--I didn't make any changes to those. They are primarily related to refactoring done in SOLR-135, SOLR-215, and SOLR-301. Additionally, I noticed that @Deprecated is commented out in two places in org/apache/solr/handler/XmlUpdateRequestHandler.java. I'm not sure if that is meant to be commented out or not. Here are the files which still have uncommented @Deprecation annotations. ./src/java/org/apache/solr/request/SolrQueryRequestBase.java ./src/java/org/apache/solr/request/SolrQueryRequest.java ./src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java ./src/java/org/apache/solr/handler/XmlUpdateRequestHandler.java ./src/java/org/apache/solr/tst/OldRequestHandler.java ./src/java/org/apache/solr/tst/TestRequestHandler.java ./src/java/org/apache/solr/util/TestHarness.java ./src/java/org/apache/solr/util/CommonParams.java ./src/java/org/apache/solr/core/Config.java ./src/java/org/apache/solr/core/SolrInfoRegistry.java ./src/java/org/apache/solr/core/SolrCore.java ./src/java/org/apache/solr/core/SolrConfig.java ./src/java/org/apache/solr/search/DocSet.java ./src/java/org/apache/solr/schema/IndexSchema.java ./src/java/org/apache/solr/schema/FieldType.java ./src/java/org/apache/solr/analysis/WordDelimiterFilter.java ./src/webapp/src/org/apache/solr/servlet/SolrUpdateServlet.java ./src/webapp/src/org/apache/solr/servlet/SolrServlet.java > Added @deprecation Javadoc comments > --- > > Key: SOLR-489 > URL: https://issues.apache.org/jira/browse/SOLR-489 > Project: Solr > Issue Type: Bug >Reporter: Sean Timm >Priority: Trivial > Attachments: deprecationDocumentation.patch > > > In a number of files, @Deprecation annotations were added without > accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-303: -- Attachment: distributed.patch New patch: - test framework using multiple embedded jetty servers that adds documents to multiple servers, and also to a control server, then executes both distributed and non-distributed queries and compares the results. - fixed merging for non-string uniqueKeyFields - fixed issue when id field was not selected by client - break facet count ties by label - added rudimentary duplicate detection in case one accidentally adds the same doc to different shards - add code to handle index changes between query phases (docs may no longer exist) Given that most of this is new functionality, I think things are in good enough shape to commit now (making it much easier for others to generate patches against it). > 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_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] Updated: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Timm updated SOLR-489: --- Attachment: deprecationDocumentation.patch Adds @deprecation comments to many of the files where they are missing. > Added @deprecation Javadoc comments > --- > > Key: SOLR-489 > URL: https://issues.apache.org/jira/browse/SOLR-489 > Project: Solr > Issue Type: Bug >Reporter: Sean Timm >Priority: Trivial > Attachments: deprecationDocumentation.patch > > > In a number of files, @Deprecation annotations were added without > accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-489) Added @deprecation Javadoc comments
Added @deprecation Javadoc comments --- Key: SOLR-489 URL: https://issues.apache.org/jira/browse/SOLR-489 Project: Solr Issue Type: Bug Reporter: Sean Timm Priority: Trivial In a number of files, @Deprecation annotations were added without accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Spell checking ?'s
On 24-Feb-08, at 11:36 PM, Chris Hostetter wrote: : Which leads me to the next question, in the extendedResults, shouldn't it use : the Query analyzer for the spellcheck field to tokenize the terms instead of : splitting on the space character? this question came up a little while back, and i made the same suggestion ... but Mike disagreed. I'm not a spellcheck user, but it still seems like the right choice to me... http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200711.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200712.mbox/[EMAIL PROTECTED] Hi Hoss, I've mostly come around to your view. Essentially, I don't think that this is a problem that is solvable solely via using analyzers, but I also think that applying the field analyzer is better than the current behaviour. Our input is a (single) string, and spellchecker output is essentially a map of tokens -> suggestions. The problem lies in that the client needs to know what was the tokenization to reconstruct the corrected query to display to the user. Query string: "ain't input/output paradigmic-oriented ad-hoc FastNetworks" output: "aint" -> ... "fast" -> ... "oriented" -> ... ... Now, the client has to embed the suggestions in the original query string for presentation. Without knowledge of the original offsets (or reconstructing the analysis itself), I'm not sure how it could do so robustly. (Perhaps returning offsets would be helpful.) But, as Hoss mentioned in his reply, users have to think carefully about analyzers anyway. (And whitespace tokenization is broken in other ways.) -Mike
Re: Spell checking ?'s
As I don't work for Google, I can only guess. :-) When they think that you have spelled something incorrectly, they seem to also search for what they deem to be the correct spelling. In this particular case, there are two "Abdur Chowdhury's" of some fame. One is the IR scientist, the other is a published economist. If you make it a phrase query: "abdur chowdhury" vs. "abdur choudhury", there are 8,240 hits for the former versus 26 hits for the latter. -Sean Otis Gospodnetic wrote: Aha, good example, Sean. What's the explanation? Note that doing: http://www.google.com/search?q=abdur+choudhury offers this alternative: http://www.google.com/searchq=abdur+chowdhury And that the number of hits is approximately the same in both cases and that Google is smart enough to search for and highlight chowdhury even when the search was for choudhury. Google's spelling corrections/suggestions are driven off of massive query (refinement) logs. Solr's suggestions are based on the index field content. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Sean Timm <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org Sent: Friday, February 22, 2008 4:03:58 PM Subject: Re: Spell checking ?'s Sometimes context can play into the correct spelling of a term. I haven't looked at the 1.3 spell check stuff, but it would be nice to do term n-gramming in order to check the terms in context. Since Otis brought up Google, here is an example of putting the term into context. http://www.google.com/search?q=choudhury http://www.google.com/search?q=abdur+choudhury -Sean Otis Gospodnetic wrote: Haven't used SCRH in a while, but what you are describing sounds right (thinking about how Google does it) - each word should be checked separately and we shouldn't assume splitting on whitespace. I'm trying to think if there are cases where you'd want to look at the surrounding terms instead of looking at each term in isolation can think of anything excitingmaybe ensure that words with dashes are properly handled. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Grant Ingersoll To: solr-dev@lucene.apache.org Sent: Thursday, February 21, 2008 3:13:20 PM Subject: Spell checking ?'s Hi, I've been looking a bit at the spell checker and the implementation in the SpellCheckerRequestHandler and I have some questions. In looking at the code and the wiki, the SpellChecker seems to treat multiword queries differently depending on whether extendedResults is true or not. Is the use case a multiword query or a single word query? It seems like one would want to pass the whole query to the spell checker and have it come back with results for each word, by default. Otherwise, the application would need to do the tokenization and send each term one by one to the spell checker. However, the app likely doesn't have access to the spell check tokenizer, so this is difficult. Which leads me to the next question, in the extendedResults, shouldn't it use the Query analyzer for the spellcheck field to tokenize the terms instead of splitting on the space character? Would it make sense to, for extendedResults anyway, do the following: Tokenize the query using the query analyzer for the spelling field for each token spell check the token add the results I see that extendedResults is a 1.3 addition, so we would be fine to change it, if it makes sense. Perhaps, for back compatibility, we keep the existing way for non extendedResults. However, it seems like multiword queries should be split even in the non-extended results, but I am not sure. How are others using it? Thanks, Grant
[jira] Commented: (SOLR-350) Manage Multiple SolrCores
[ https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572080#action_12572080 ] Henri Biestro commented on SOLR-350: Otis, reading your requirements, I'd be considering using a Solr core to handle an indexed version of multicore.xml; if you have a few thousands indices, it might be convenient to use queries in some occasions to select/retrieve one/many of them. The xml version of the multicore persistent file could be written at application/multicore shutdown and the Lucene based one could be recreated at application/multicore startup; creating a new index would just induce creating a new document in the multicore core (and in fact all CRUD operations could be handled that way) and we'd benefit from Solr autocommit feature & al, tackling your functional requirements reusing well-known capabilities & code. For ~10 indices/cores, this seems like overkill though... On configuring easily the data/index dir from multicore.xml, it seems we all agree that variables definitions should be able to allow just that; the non-extensible version of the feature (see previous comment)- where we dont allow the user to augment the environment but only expose 'solr.multicore.*'- did not trigger any comment yet, Otis/Hoss/Ryan what do you think of it ? > Manage Multiple SolrCores > - > > Key: SOLR-350 > URL: https://issues.apache.org/jira/browse/SOLR-350 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Ryan McKinley > Attachments: SOLR-350-MultiCore.patch, SOLR-350-MultiCore.patch, > SOLR-350-MultiCore.patch, SOLR-350-Naming.patch, SOLR-350-Naming.patch, > solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, > solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch, solr-350.patch > > > In SOLR-215, we enabled support for more then one SolrCore - but there is no > way to use them yet. > We need to make some interface to manage, register, modify avaliable SolrCores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-488) Solr does not generate highlights when uniqueId field is not defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomer Gabel updated SOLR-488:
-
Attachment: linkfield.HighlightingUtils.patch
Patch to HighlightingUtils.java: adds a "link field" parameter which allows
highlight generation even when uniqueId is not defined in the schema.
> Solr does not generate highlights when uniqueId field is not defined in the
> schema
> --
>
> Key: SOLR-488
> URL: https://issues.apache.org/jira/browse/SOLR-488
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.2
> Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
> Apache Tomcat 6.0.14
>Reporter: Tomer Gabel
> Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in
> the schema. I believe the reason for this is that it's very difficult to
> modify or extend the XmlWriter behavior, which is why highlights reside in
> their own "section" in the response XML and subsequently need to be "linked"
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need
> highlights; the solution we came up with was to provide a user-definable
> "link field," which is the document field whose value resides in the {{ name="215">}} elements in the generated output. I will presently attach a
> patch which adds a "hl.link" query parameter, which takes a field name and
> uses that as the "link field." If the parameter is not specified the original
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom
> handlers add a lot of information to each document, and the way the response
> writer is implemented makes it nigh impossible to add information to any
> specific document within the response. I should probably open an issue which
> calls to reimplement this aspect of Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-488) Solr does not generate highlights when uniqueId field is not defined in the schema
Solr does not generate highlights when uniqueId field is not defined in the
schema
--
Key: SOLR-488
URL: https://issues.apache.org/jira/browse/SOLR-488
Project: Solr
Issue Type: Improvement
Components: highlighter
Affects Versions: 1.2
Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
Apache Tomcat 6.0.14
Reporter: Tomer Gabel
Attachments: linkfield.HighlightingUtils.patch
Solr does not generate highlights when there is no uniqueId field defined in
the schema. I believe the reason for this is that it's very difficult to modify
or extend the XmlWriter behavior, which is why highlights reside in their own
"section" in the response XML and subsequently need to be "linked" to their
respective documents via the uniqueId field.
Our schema does not define a uniqueId for various reasons but we still need
highlights; the solution we came up with was to provide a user-definable "link
field," which is the document field whose value resides in the {{}} elements in the generated output. I will presently attach a patch
which adds a "hl.link" query parameter, which takes a field name and uses that
as the "link field." If the parameter is not specified the original behavior is
used, so backwards compatibility is maintained.
As an aside, we've found this technique to be useful because our custom
handlers add a lot of information to each document, and the way the response
writer is implemented makes it nigh impossible to add information to any
specific document within the response. I should probably open an issue which
calls to reimplement this aspect of 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-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Gabel updated SOLR-487: - Attachment: maxdocsize.HighlightingUtils.patch Patch to HighlightingUtils.java (based on Solr 1.2.0) to add the configuration parameter implementation. > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Gabel updated SOLR-487: - Attachment: maxdocsize.SolrConfig.patch Patch to default solr-config.xml (based on Solr 1.2.0) to add the configuration parameter implementation. > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
Add configuration option for maxDocBytesToAnalyze to solr-config.xml Key: SOLR-487 URL: https://issues.apache.org/jira/browse/SOLR-487 Project: Solr Issue Type: New Feature Components: highlighter Affects Versions: 1.2 Environment: Not that it matters, but: Windows Vista Business (x86, x64), latest Ubuntu server, Tomcat 6.0.14 Reporter: Tomer Gabel Priority: Trivial My team has hit the maxDocBytesToAnalyze limitation a while back and decided to add a quick configuration parameter to solr-config.xml. I'll attach a patch momentarily (based on Solr 1.2.0 source code) that includes the implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-486) Support binary formats for QueryresponseWriter
[
https://issues.apache.org/jira/browse/SOLR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572024#action_12572024
]
Noble Paul commented on SOLR-486:
-
Without breaking the existing stuff we can add another interface
BinaryQueryResponse extends QueryResponseWriter{
public void write(OutputStream out, SolrQueryRequest request,SolrQueryResponse
response) throws IOException;
and in the SolrDispatchFilter add the following linesQueryResponseWriter
responseWriter = core.getQueryResponseWriter(solrReq);
if (responseWriter instanceof BinaryQueryResponse ) {
BinaryQueryResponse binaryResp = (Object)
responseWriter;
binaryResp.write(response.getOutputStream(), solrReq, solrRsp);
} else {
responseWriter.write(response.getWriter(), solrReq, solrRsp);
}
> Support binary formats for QueryresponseWriter
> --
>
> Key: SOLR-486
> URL: https://issues.apache.org/jira/browse/SOLR-486
> Project: Solr
> Issue Type: Improvement
> Components: clients - java, search
>Reporter: Noble Paul
>Priority: Minor
> Fix For: 1.3
>
>
> QueryResponse writer only allows text data to be written.
> So it is not possible to implement a binary protocol . Create another
> interface which has a method
> write(OutputStream os, SolrQueryRequest request, SolrQueryResponse response)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-486) Support binary formats for QueryresponseWriter
Support binary formats for QueryresponseWriter -- Key: SOLR-486 URL: https://issues.apache.org/jira/browse/SOLR-486 Project: Solr Issue Type: Improvement Components: clients - java, search Reporter: Noble Paul Priority: Minor Fix For: 1.3 QueryResponse writer only allows text data to be written. So it is not possible to implement a binary protocol . Create another interface which has a method write(OutputStream os, SolrQueryRequest request, SolrQueryResponse response) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Build failed in Hudson: Solr-trunk #356
: @Hossman: : You should set a higher value for the timeout in : CacheHeaderTestBase.java (line 72). 5ms might be too short for a busy : server. done ... it would be nice if all of these tests that spin up a server had used a common test utility class for generating the CommonsHttpSolrServer with timeouts taken from systemproperties with long defaults (which would assume a lenient test environment) ... but that's a smaller fish to fry on another day. -Hoss
