Update requests are routed only to leader nodes by CloudSolrServer so
there is a 1/numShards probability of avoiding an extra network hop.
It is *not* a 1/(number of nodes in cluster) probability as you may
think.
You may also be interested in
https://issues.apache.org/jira/browse/SOLR-4816 . Perh
There are three "concepts" to grasp:
1. You can send Solr update requests to ANY node of the cluster. Period.
2. Any extra network traffic (within the cluster) is likely to be negligible
and absolutely not worrying about unless you have definitive evidence to the
contrary.
3. Leader nodes in So
Hi Erik,
I just wanted to clarify if u got my concern right. If i send some documents
to the replica core wont it first have to send the documents to the leader
core which in turn would be sending it back to the replica cores. If yes
then this will lead to additional network traffic which can be a
thanks Erick.
My tomcat setup is running on Ubuntu and has nothing else deployed other than
the Solr war. My suspicion is it takes a long time to de-allocate the memory it
has reserved for itself, but will get dump to find better.
regards,
Ayush
> Date: Sat, 6 Jul 2013 07:55:57 -0400
> Subject
Why is LUCENE-474 not committed?
On Thu, Jul 4, 2013 at 4:21 PM, Koji Sekiguchi wrote:
> Hi Dotan,
>
>
> (13/07/04 23:51), Dotan Cohen wrote:
>
>> Thank you Jack and Koji. I will take a look at MLT and also at the
>> .zip files from LUCENE-474. Koji, did you have to modify the code for
>> the l
I submitted a JIRA ticket a while ago, since I thought that having a way to
use the Lucene facets in SOLR could speed up our faceting. However, no one
seems to have picked up the development.
https://issues.apache.org/jira/browse/SOLR-4774
What is involved with "hooking it into SOLR" ? Similar to
Can it do Geo Spatial searching? (i.e. Find documents within 10 miles of a
lat,long?)
On Fri, Jul 5, 2013 at 12:53 PM, Fergus McDowall
wrote:
> Here is some news that might be of interest to users and implementers of
> Solr
>
>
> http://blog.comperiosearch.com/blog/2013/07/05/norch-a-search-eng
Nope no custom plugin. Just use the DirectSpellCheck component.
We have raised a ticket with LucidWorks i will followup with that and once
have a JIRA will update this post.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Concurrent-Modification-Exception-tp4074371p40760
You _should_ be able to use an HttpSolrServer, set
the base URL and then go ahead and make the
request. Haven't done it myself, but the SolrJ
"support" for various Solr features often consists of
just convenience methods over the underlying HTTP,
saving you the necessity of, say, parsing the respon
Thanks for your response.
But it seems like there should be a way to issue the equivalent of
http://localhost:8983/solr/schema/version
which returns
{
"responseHeader":{
"status":0,
"QTime":4},
"version":1.5}
from the server. I know how to do it using HTTPGet in
Steven,
Some information can be gleaned from the "system" admin request handler:
http://localhost:8983/solr/admin/system
I am specifically looking at this:
example
Mind you, that is a manually-set value in the schema file. But just in case
you want to get crazy you can also call the "file" a
Does anyone have any idea how I can access the schema version info using SolrJ?
Thanks.
On Jul 3, 2013, at 4:16 PM, Steven Glass wrote:
> I'm using a Solr 4.3 server and accessing it from both a Java based desktop
> application using SolrJ and an Android based mobile application using my
> ho
On Sat, Jul 6, 2013 at 2:22 PM, mihaela olteanu wrote:
> Hello,
>
> I have 3 indices that form a hierarchy. Basically these were constructed from
> 3 tables: parent, child1 and child2 and between parent and children there is
> a one to many relationship.
> parent (id,name)
>
> child1(id,join_key
If you flatten this to make a single table with rows for each combination of
parent, child1, and child2, the query will be simple and probably very fast.
You've said it makes more sense to have three tables, and that is true for a
relational database. For a search engine, like Solr, it makes mor
Hello,
I have 3 indices that form a hierarchy. Basically these were constructed from 3
tables: parent, child1 and child2 and between parent and children there is a
one to many relationship.
parent (id,name)
child1(id,join_key,field1)
child2(id,join_key,field2)
"join_key" is the foreign key
On Fri, Jul 5, 2013 at 10:57 AM, adityab wrote:
> well our observation leads us that this happens only during spell check.
> If we turn off the spell check we don't see this issue occurring at all from
> our 24hrs test run.
Are you using any custom components / plugins, or is this stock 4.2.1?
-
I know this stuff can be confusing, but I think my statement is still true -
it uses the phrase "NEW primary shard" - the "promotion" of a shard can only
be to "replace" an existing primary shard, not to create a new and separate
partitioning of key values.
You left out the next sentence from
Solr only returns the number of documents specified by the "rows"
parameter.
You can page through your results by specifying, say,
&start=20&rows=20
then
&start=40&rows=20
etc.
Or you can bump rows, but you really don't want to return
huge result sets so you'll probably be paging sometime.
But i
uniqueKey is used to enforce there
being only a single copy of a doc. Say
a doc changes and you re-index it. If
there is a doc in the index already _with
the same uniqueKey_ it'll be deleted
and the new one will be the only one
visible.
Which implies that if you do implement
the suggestions, be su
Oh, P.S. Solr is a great search engine, but it's
certainly not the perfect answer to all problems.
Mayhap you've hit on a case where it isn't the
best solution
On Sat, Jul 6, 2013 at 8:22 AM, Erick Erickson wrote:
> What does this have to to with removing the
> int32 limit? It's still the sa
What does this have to to with removing the
int32 limit? It's still the same problem if you have
a high start parameter, it's the "deep paging"
issue that's part of Solr.
I know there has been work on this (you'll have to
search the JIRAs), the basic idea is that you pass
enough information that y
Ok. If you can create a test setting to repro the bug, I would suggest
filing a jira. Sounds like a regression if your config remained otherwise
same.
On 5 Jul 2013 16:57, "adityab" wrote:
> well our observation leads us that this happens only during spell check.
> If we turn off the spell check
That's exactly what turned out to be the problem. We thought we had
already tried that permutation but apparently hadn't. I know it's obvious
in retrospect. Thanks for the suggestion.
Thanks,
Andy Pickler
On Wed, Jul 3, 2013 at 2:38 PM, Alexandre Rafalovitch wrote:
> On Tue, Jul 2, 2013 at 10
Not a problem. index time boosts are boosts made
_when you're indexing_, not when you're querying
so omitting norms should stil have your query boosting
work.
Also, try adding &debug=all and examining the results,
it'll show you exactly how scores were calculated. It does
take a bit to work though
The process looks like this:
each shard returns the top 100K documents
(actually the doc ID and whatever your
sort criteria is, often just the score).
_from every shard_ and the node that
distributes that request then takes those
900K items and merges the list to get the
100K that satisfy the requ
kill -9 is evil, you aren't certain what the state is afterwards,
so the presence of the lock file is not surprising..
solrconfig.xml has a commented-out entry
false
I haven't personally used it, but it looks like it might
help if you insist on kill -9.
Personally I'd try to figure out why your
Neither ORing or ANDing the terms together will help you
regardless of whether you do it or the query parser
you use does it behind the scenes. That's
because you have _string_ fields. So
Google Cloud Storage
is a single token in your index, not three.
You probably want to spend some time on the
a
Not saying it's always one way or the other, just
that one shouldn't automatically _assume_
putting the most recent data on a single node
is automatically good. It may well be, but
not in all cases.
On Wed, Jul 3, 2013 at 12:21 PM, Otis Gospodnetic <
otis.gospodne...@gmail.com> wrote:
> Exactl
bq: Reason being If a write request is sent to the replica it
relays it to the leader and then the leader relays it to all the replicas.
This will help me in saving some network traffic as my application performs
continuous writes
How are you indexing? SolrJ already is "leader aware" and sends
up
Well, you've just restated the problem. I'm asking
what use-case this is supporting? You've said:
"he/she wants to know the occurrence of a
specific term in the result set of that 'X1' search criteria"
OK, _why_? Idle curiosity? Ranking the docs?
Choosing the most relevant? I don't think you can
Hi,
I am working on solr 3.3. i am getting total 120 records with below query,
in response xml "numFound" is showing 540 records.
http://localhost:8080/test/select?q=*:*&rows=*120*
0
1
*:*
120
green
blue
red
.. (120 record
If you are asking about how to use Solrj with SolrCloud, see
http://wiki.apache.org/solr/Solrj#Using_with_SolrCloud
If you are not using SolrCloud then add
"shards=solr_server1:port/solr,solr_server2:port/solr" as a parameter
to a query request. Indexing doesn't need anything special -- you just
s
Norch is based on the node module "search-index" which is like a simplified
lucene, built with Google's levelDB library
(https://github.com/fergiemcdowall/search-index)
(so posting here is a bit cheeky- but I figured the solr/lucene readership
might be interested :-)
F
On Jul 6, 2013, at 1
(Given that hardware is sufficient) The upper limit of documents in Norch is
determined by the capacity of levelDB, the underlying data store. I have heard
tell of a slight performance drop off in LevelDB after 200 000 000 million
entries. If you say that one Norch document generates roughly 200
Hi,
We migrated from solr 3.6 to solr 4.3, when we fire a backup command
(/replication?command=backup&location=/disk4/backups ) on the salve the slave
stops replicating OR starts full replication from the master. This was not the
behavior in the earlier version or solr, I have check the logs bu
Hello!
Just to be perfectly clear here - Solr has advantage over
ElasticSearch because it can split the live index. However, this
sentence from Jack's mail is not true:
"In other words, even though you can easily “add shards” on ES,
those are really just replicas of existing primary shards and ca
36 matches
Mail list logo
