Hi,
I've got some basic usage / design questions.
1. The SolrJ wiki proposes to use the same CommonsHttpSolrServer
instance for all requests to avoid connection leaks.
So if I create a Singleton instance upon application-startup I can
securely use this instance for ALL queries/updates t
eam.url" parameter. (Also stream.file.) Note
that there is no outbound authentication supported; your web server
has to be open (at least to the Solr instance).
On Sun, Oct 31, 2010 at 4:06 PM, getagrip wrote:
Hi,
I've got some basic usage / design questions.
1. The
Hi,
when I query solr (trunk) I get "numeric character references" instead
of regular UTF-8 strings in case of special characters in the
highlighting section, in the result section the characters are presented
fine.
e.g instead of the German Umlaut Ä I get ä
Example:
Vielfachmessgerät
Having updated from 1.4.1 to 3.1.0 some documents are not parsed
correctly anymore:
1. Both the result's id field and the highlighting's header do not
display special-characters e.g. German Umlauts anymore.
2. The highlighting section is messed up as words appear in random order
instead of r
This works with NEITHER HtmlEncoder NOR DefaultEncoder.
1. Special characters like öäüß simply are returned as question marks.
This goes for ALL document types.
2. The index is built in a way that randomly concatenates words and
puts them into the highlighting section in a way that does no
A bug was introduced between Solr 3.1 and 3.2.
With Solr 3.2 we are now getting the follwing error when querying
several pdf and word documents:
SEVERE: org.apache.solr.common.SolrException:
org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token
17 exceeds length of provided
