Shawn ,
Just wanted to follow up , I still face this issue of inconsistent search
results on Solr Cloud 4.1.0.1 , upon further looking into logs , I found
out a few exceptions , what was obvious was zkConnection time out issues
and other exceptions , please take a look .
*Logs*
/opt/tomcat1/logs
Shawn,
Just wondering if you have any other suggestions on what the next steps
whould be ? Thanks.
On Thu, Oct 16, 2014 at 11:12 PM, S.L wrote:
> Shawn ,
>
>
>1. I will upgrade to 67 JVM shortly .
>2. This is a new collection as , I was facing a similar issue in 4.7
>and based on
Shawn ,
1. I will upgrade to 67 JVM shortly .
2. This is a new collection as , I was facing a similar issue in 4.7
and based on Erick's recommendation I updated to 4.10.1 and created a new
collection.
3. Yes, I am hitting the replicas of the same shard and I see the lists
are
On 10/16/2014 6:27 PM, S.L wrote:
1. Java Version :java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
I believe that build 51 is one of those that is known to have bugs
related to Lucene. If you can upgr
Shawn,
Please find the answers to your questions.
1. Java Version :java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
2.OS
CentOS Linux release 7.0.1406 (Core)
3. Everything is 64 bit , OS , Java , and CPU
On 10/15/2014 10:24 PM, S.L wrote:
Yes , I tried those two queries with distrib=false , I get 0 results for
first and 1 result for the second query( (i.e. server 3 shard 2 replica
2) consistently.
However if I run the same second query (i.e. server 3 shard 2 replica 2)
with distrib=true, I som
Shawn,
Yes , I tried those two queries with distrib=false , I get 0 results for
first and 1 result for the second query( (i.e. server 3 shard 2 replica
2) consistently.
However if I run the same second query (i.e. server 3 shard 2 replica 2)
with distrib=true, I sometimes get a result and somet
On 10/15/2014 9:26 PM, S.L wrote:
Look at the logging information I provided below , looks like the results
are only being returned back for this solrCloud cluster if the request
goes to one of the two replicas of a shard.
I have verified that numDocs in the replicas for a given shard is same b
Look at the logging information I provided below , looks like the results
are only being returned back for this solrCloud cluster if the request
goes to one of the two replicas of a shard.
I have verified that numDocs in the replicas for a given shard is same but
there is difference in the maxDoc
Tim,
Thanks for the suggestion.
I have rerun the query by adding shards.info=true and debug= track. I have
included the xml data for both teh scenarios below , thin happens
intermittently on SolrCloud 4.10.1 , with a replication factor of 2 and 3
shards (6 cores) , I get result in one execution o
Try adding shards.info=true and debug=track to your queries ... these will
give more detailed information about what's going behind the scenes.
On Mon, Oct 13, 2014 at 11:11 PM, S.L wrote:
> Erick,
>
> I have upgraded to SolrCloud 4.10.1 with the same toplogy , 3 shards and 2
> replication facto
Erick,
I have upgraded to SolrCloud 4.10.1 with the same toplogy , 3 shards and 2
replication factor with six cores altogether.
Unfortunately , I still see the issue of intermittently no results being
returned.I am not able to figure out whats going on here, I have included
the logging informatio
Not, I'm not guaranteeing that it'll actually cure the problem, just
that enough has changed since 4.7 that it'd be a good place to start.
Things have been reported off and on, but they're often pesky race
conditions or something else that takes a long time to track down, you
just are lucky perhap
Erick,
Thanks for the suggestion , I am not sure if I would be able to capture
what went wrong , so upgrading to 4.10 seems easier even though it means ,
a days work of effort :) . I will go ahead and upgrade and let me know ,
although I am surprised that this issue never got reported for 4.7 up u
I think there were some holes that would allow replicas and leaders to
be out of synch that have been patched up in the last 3 releases.
There shouldn't be anything you need to do to keep these in synch, so
if you can capture what happened when things got out of synch we'll
fix it. But a lot has c
Hi Erick,
Before I tried your suggestion of issung a commit=true update, I realized that
for eaach shard there was atleast a node that had its index directory named
like index..
I went ahead and deleted index directory that restarted that core and now the
index directory got syched with the o
H. Assuming that you aren't re-indexing the doc you're searching for...
Try issuing http://blah blah:8983/solr/collection/update?commit=true.
That'll force all the docs to be searchable. Does <1> still hold for
the document in question? Because this is exactly backwards of what
I'd expect. I'd
Eirck,
0> Load balancer is out of the picture
.
1>When I query with *distrib=false* , I get consistent results as expected
for those shards that dont have the key i.e I dont get the results back for
those shards, however I just realized that while *distrib=false* is present
in the query for the sh
bq: Also ,the collection is being actively indexed as I query this, could that
be an issue too ?
Not if the documents you're searching aren't being added as you search
(and all your autocommit intervals have expired).
I would turn off indexing for testing, it's just one more variable
that can get
Erick,
I would like to add that the interesting behavior i.e point #2 that I
mentioned in my earlier reply happens in all the shards , if this were to
be a distributed search issue this should have not manifested itself in the
shard that contains the key that I am searching for , looks like the s
Erick,
Thanks for your reply, I tried your suggestions.
1 . When not using loadbalancer if *I have distrib=false* I get consistent
results across the replicas.
2. However here's the insteresting part , while not using load balancer if
I *dont have distrib=false* , then when I query a particular
Hmmm, nothing quite makes sense here
Here are some experiments:
1> avoid the load balancer and issue queries like
http://solr_server:8983/solr/collection/q=whatever&distrib=false
the &distrib=false bit will cause keep SolrCloud from trying to send
the queries anywhere, they'll be served only
22 matches
Mail list logo
