I have to ask a completely different question: "Why are the replicas
down in the first place?" Having to restart the Solr node is a
sledgehammer of a solution, I'd put more effort into finding out why
that's happening in the first place.
Are you getting OOM errors? Any other exception? Is the OOM
Hi Markus,
I did encounter the error before. It was due to the usage of the memory of
the server is very high, at almost 98%.
The usage is not all contributed by Solr, there are other programs and
Virtual Machines running on the server.
What is the memory usage of the system, and do you have othe
if the "middle tier" of your application doesn't already have an easy
key-value lookup that you keep this translation data in (which would
suprise me, because i've never seen anyone care about this type of
"late-binding" translation of serach results w/o also caring about
late-binding translat
You are describing the idea pretty accurately. Apparently Endeca has
something that sort of supports this, which we used for the problem.
On Thu, Aug 31, 2017 at 1:59 PM, Chris Hostetter
wrote:
>
> ok, so lemme attempt to restate your objective to ensure no
> miscommunication:
>
> 1) you have fi
I just tried putting the solr-dataimporthandler-6.6.0.jar in server/solr/lib
and I got past the problem. I still don't understand why not found in /dist
-Original Message-
From: Steve Pruitt [mailto:bpru...@opentext.com]
Sent: Thursday, August 31, 2017 3:05 PM
To: solr-user@lucene.apach
I still can't understand how Solr establishes the classpath.
I have a custom entity processor that subclasses EntityProcessorBase. When I
execute the /dataimport call I get
java.lang.NoClassDefFoundError:
org/apache/solr/handler/dataimport/EntityProcessorBase
no matter how I state in solrconf
ok, so lemme attempt to restate your objective to ensure no
miscommunication:
1) you have fields like "color"
2) you want to index english words into the color field for docs
3) you want to search/filter against these fields using english words as
input
4) you want to facet on the fields like "
a field:* query always takes a long time, and should be avoided if at all
possible. solr/lucene is still going to try to rank the documents based on
that, even thought theres nothing to really rank. every single document
where that field is not empty will have the same score for that part of the
The closest thing to an execution plan that I know of is debug=true.That'll
show timings of some of the components
I also find it useful to add echoParams=all when troubleshooting. That'll
show every param solr is using for the request, including params set in
solrconfig.xml and not passed in the r
Thanks Lincoln for your suggestions. It was very helpful.
I am still curious as to why is the original query taking long time. It is
something that Lucene should have ideally optimized.
Is there any way to see the execution plan used by Lucene?
Thanks
Suresh
On Thu, Aug 31, 2017 at 11:11 AM, J
As I understand it, using a different fq for each clause makes the
resultant caches more likely to be used in future requests.
For the query
fq=first:bob AND last:smith
a subsequent query for
fq=first:tim AND last:smith
won't be able to use the fq cache from the first query.
However, if the first
Hello Team,
I have few experiences where restart of a solr node is the only option when
a core goes down. I am trying to automate the restart of a solr server when
a core goes down or the replica is unresponsive over a period of time.
I have a script to check if the cores/ replicas associated wit
>
> 2) Because all your clauses are more like filters and are ANDed together,
> you'll likely get better performance by putting them _each_ in an fq
> E.g.
> fq=product_identifier_type:DOTCOM_OFFER
> fq=abstract_or_primary_product_id:[* TO *]
why is this the case? is it just better to have no lo
Suresh,
Two things I noticed.
1) If your intent is to only match records where there's something,
anything, in abstract_or_primary_product_id, you should use fieldname:[* TO
*] but that will exclude records where that field is empty/missing. If you
want to match records even if that field is empty
Hello everybody,
We are seeing that the below query is running very slow and taking almost 4
seconds to finish
[] webapp=/solr path=/select
params={df=_text_&distrib=false&fl=id&shards.purpose=4&start=0&fsv=true&sort=modified_dtm+desc&shard.url=http://:8983/solr/flat_product_index_shard7_replica
A possible improvement for some multiValued fields might be to use the
"uif" facet method (UnInvertedField was the default method for
multiValued fields in 4.x)
I'm not sure if you would need to reindex without docValues on that
field to try it though.
Example: to enable on the "union" field, add
Well, isn't it always the same with Wikipedia?
It's already there .. so it has to be correct. If you're trying to remove
it, you have to prove it - but there is not even prove it should be there
in the first place oO
You really need to have time to go through that kind of argument ...
-Stefan
O
Wikipedia seems to be better now. Thank you, Peaceray.
Honestly, though, by the numbers, I think the comment was correct.
Elasticsearch has a much smoother on-ramp for IT developers, but it is much
harder to customize relevancy and integrate with BigData pipelines. IT
developers are the
I have no idea where to even start. Have you looked at your Solr logs
to see if there are helpful error messages? What is "reindex"?
Something from some program you're running? 'cause it's not a field
option for Solr schema field definitions, if you're putting that in a
Solr schema I wouldn't even
To pile on here: When you denormalize you also get some functionality
that you do not get with Solr joins, they've been called "pseudo
joins" in Solr for a reason.
If you just use the simple approach of indexing the two tables then
joining across them you can't return fields from both tables in a
Hi,
in the meantime I came across the reason for the slow facet processing
capacities of SOLR since version 5.x
https://issues.apache.org/jira/browse/SOLR-8096
https://issues.apache.org/jira/browse/LUCENE-5666
compared to version 4.x
Various library networks across the world are suffering f
Hi Rick,
right, I've already tried to correct the wikipedia page, to be honest, I've
just removed the sentence "Solr is the second-most... etc."
But my change has been discarded because I missed to add a valid motivation.
Anyway, not sure I'm the most representative person to discuss this in the
There is no way tell which is faster without trying it.
Query speed depends on the size of the data (rows), the complexity of the join,
which database, what kind of disk, etc.
Solr speed depends on the size of the documents, the complexity of your
analysis chains, what kind of disk, how much CP
>Can anyone tell is it possible to paginate the data using Solr UI?
use the start/rows input fields using standard array start as 0, ie
start=0, rows=10
start=10, rows=10
start=20, rows=10
On Thu, Aug 31, 2017 at 8:21 AM, Agrawal, Harshal (GE Digital) <
harshal.agra...@ge.com> wrote:
> Hello A
Hello All,
If I check out clear option while indexing 2nd table it worked.Thanks Gurdeep :)
Can anyone tell is it possible to paginate the data using Solr UI?
If yes please tell me the features which I can use?
Regards
Harshal
From: Agrawal, Harshal (GE Digital)
Sent: Wednesday, August 30, 2017
when indexing a relational database its generally always best to denormalize it
in a view or in your indexing code
On Thu, Aug 31, 2017 at 3:54 AM, Renuka Srishti
wrote:
> Thanks Erick, Walter
> But I think join query will reduce the performance. Denormalization will be
> the better way than joi
Thank all for sharing your thoughts :)
On Thu, Aug 31, 2017 at 5:28 PM, Susheel Kumar
wrote:
> Yes, if you can avoid join and work with flat/denormalized structure then
> that's the best.
>
> On Thu, Aug 31, 2017 at 3:54 AM, Renuka Srishti <
> renuka.srisht...@gmail.com>
> wrote:
>
> > Thanks E
Yes, if you can avoid join and work with flat/denormalized structure then
that's the best.
On Thu, Aug 31, 2017 at 3:54 AM, Renuka Srishti
wrote:
> Thanks Erick, Walter
> But I think join query will reduce the performance. Denormalization will be
> the better way than join query, am I right?
>
>
Hi Markus,
I don't know what Client you use, but if you are using SolrJ enabling the
logging could be an option to "dig deeper" into the problem. This can be
the ouput for example via log4j on log level info:
...
2017-08-31 10:01:56 INFO ZooKeeper:438 - Initiating client connection,
connectSt
Hello Stephan,
I know that restarting stuff can sometimes cure what's wrong, but we are nog
going to, we want to get rid of the problem, not restart microsoft windows
whenever things run slow. Also, there is no indexing going on right now.
We also see these sometimes, this explains at least why
Thanks Erick, Walter
But I think join query will reduce the performance. Denormalization will be
the better way than join query, am I right?
On Wed, Aug 30, 2017 at 10:18 PM, Walter Underwood
wrote:
> Think about making a denormalized view, with all the fields needed in one
> table. That view
Hi markus,
try to stop your indexing/update processes and restart your ZooKeeper
instances (not all at the same time of course). This is what I do in these
cases and helped me so far.
Von:Markus Jelsma
An: Solr-user
Datum: 31.08.2017 09:49
Betreff:6.6 Cannot talk to ZooKee
Hello,
One node is behaving badly, at least according to the logs, but the node is
green in the cluster overview although the logs claim recovery fails all the
time. It is not the first time this message pops up in the logs of one of the
nodes, why can it not talk to Zookeeper? I miss a reason.
No, not really. I'm wondering why on both Servers (each Collection has a
replica on a different server) doesn't have a problem with it in 6.5., but
if I update on Solr 6.6. on both instances the error occured. As I already
said, If i revert the instances back to 6.5. everything seems to be fine.
34 matches
Mail list logo
