You also need to find out _why_ you're trying to index such huge
tokens, they indicate that something you're ingesting isn't
reasonable
Just truncating the input will index things, true. But a 32K token is
unexpected, and indicates what's in your index may not be what you
expect and may not
CLASSIFICATION: UNCLASSIFIED
What I did was force nutch to truncate content to 32765 max before indexing
into solr and it solved my problem.
Thanks,
Kris
~~
Kris T. Musshorn
FileMaker Developer - Contractor – Catapult Technology Inc.
US Army Research Lab
what that error is telling you is that you have an unanalyzed term
that is, well, huge (i..e > 32K). Is your "content" field by chance a
"string" type? It's very rare that a term > 32K is actually useful.
You can't search on it except with, say, wildcards,there's no stemming
etc. So the first
CLASSIFICATION: UNCLASSIFIED
I am trying to index from nutch 1.12 to SOLR 6.1.0.
Got this error.
java.lang.Exception:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://localhost:8983/solr/ARLInside: Exception writing document
id
Many thanks for the assistance Hoss! After a couple of bumps, it worked
great.
I followed the recommendations (and read the explanation - thanks!)
Although I swear it threw the error once again, just to be sure I rebooted
everything (Zookeeper included) then reloaded the configs into
You don't really have to worry that much about memory consumed during indexing.
The ramBufferSizeMB setting in solrconfig.xml pretty much limits the amount of
RAM consumed, when adding a doc if that limit is exceeded then the
buffer is flushed.
So you can reduce that number, but it's default is
Another alternative is to use the TermsQueryParser which is intended to
deal with very large lists of values that should be ORed together. It may
be useful if your query pattern matches its intent. see:
https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-TermsQueryParser
On 8/3/2016 12:49 AM, liubiaoxin1 wrote:
> set exery core solrconfig.xml: 4096
Are you absolutely certain that you have set maxBooleanClauses on
*EVERY* core in that Solr instance?
This value is global, across the entire JVM, and the last core that
starts will set the value for all cores.
It is
I don't see any field level data exposed in the SolrDocumentList I get from
shardResponse.getSolrResponse().getResponse().get("response"). I see the
unique ID field and value. Is that by design or am I being stupid?
Separate but related question: the mergIds() method in the merge strategy
class -
If you need to aggregate after the join then you'll need to use the
rollup() function.
The rollup function requires the tuples be sorted by the group by fields.
So it's easiest to accomplish this using the hashOuterJoin, which doesn't
require a sort on the join keys.
If you're doing a parallel
Hi Steve,
I read the thread you sent me (SOLR-8812) and it seems that the 6.1
includes this fix, as you said.
I will upgrade.
Thank you!
Kind regards,
Bast
On 05/08/2016 14:37, Steve Rowe wrote:
Hi Bastien,
Have you tried upgrading to 6.1? SOLR-8812, mentioned earlier in the thread,
was
Hi Bastien,
Have you tried upgrading to 6.1? SOLR-8812, mentioned earlier in the thread,
was released with 6.1, and is directly aimed at fixing the problem you are
having in 6.0 (also a problem in 5.5): when mm is not explicitly provided and
the query contains explicit operators (except for
Hello,
I am looking for similar use case. Will it be possible for you to share the
corrected syntax ?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Streaming-expressions-malfunctioning-tp4281016p4290528.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hello,
I have two collections and need to join the results on uniqueIds.
I am able to do that with Streaming Expressions- LeftOuterJoin. Is there any
way to use facets along with this?
--
View this message in context:
Thanks Guys. Very very helpful.
I will probably look at consolidate 4 Solr servers into 2 bigger/better server
- it gives more memory, and it cut down the replica the Leader needs to manage.
Also, I may look into write a script to monitor the tomcat log and if there is
OOM, kill tomcat, then
On 8/4/2016 8:14 PM, Tim Chen wrote:
> Couple of thoughts: 1, If Leader goes down, it should just go down,
> like dead down, so other servers can do the election and choose the
> new leader. This at least avoids bringing down the whole cluster. Am I
> right?
Supplementing what Erick told you:
16 matches
Mail list logo
