awesome Yonik. I'll indeed try this. Thanks!
On Thu, Apr 5, 2012 at 10:20 AM, Yonik Seeley
wrote:
> On Thu, Apr 5, 2012 at 12:19 AM, Jamie Johnson wrote:
>> Not sure if this got lost in the shuffle, were there any thoughts on this?
>
> Sorting by "id" could be pretty expensive (memory-wise), s
On Thu, Apr 5, 2012 at 12:19 AM, Jamie Johnson wrote:
> Not sure if this got lost in the shuffle, were there any thoughts on this?
Sorting by "id" could be pretty expensive (memory-wise), so I don't
think it should be default or anything.
We also need a way for a client to hit the same set of ser
Not sure if this got lost in the shuffle, were there any thoughts on this?
On Wed, Mar 21, 2012 at 11:02 AM, Jamie Johnson wrote:
> Given that in a distributed environment the docids are not guaranteed
> to be the same across shards should the sorting use the uniqueId field
> as the tie breaker b
Given that in a distributed environment the docids are not guaranteed
to be the same across shards should the sorting use the uniqueId field
as the tie breaker by default?
On Tue, Mar 20, 2012 at 2:10 PM, Yonik Seeley
wrote:
> On Tue, Mar 20, 2012 at 2:02 PM, Jamie Johnson wrote:
>> I'll try to
Thanks Yonik, I really appreciate the explanation. It sounds like the
best solution for me to solve this is to add the additional sort
parameter. That being said is there a significant memory increase to
do this when sorting by score? I don't see how with SolrCloud I can
avoid doing this, and ho
I believe we're using replication to only duplicate the index
(standard SolrCloud nothing special on our end) so I don't see why the
docids wouldn't be the sameam I missing something that is
happening there that I am unaware of?
On Tue, Mar 20, 2012 at 11:50 AM, Yonik Seeley
wrote:
> On Tue,
On Tue, Mar 20, 2012 at 11:39 AM, Jamie Johnson wrote:
> HmmmOk, I don't see how it's possible for me to ensure that there
> are no ties. If a query were for *:* everything has a constant score,
> if the user requested 1 page then requested the next the results on
> the second page could be d
HmmmOk, I don't see how it's possible for me to ensure that there
are no ties. If a query were for *:* everything has a constant score,
if the user requested 1 page then requested the next the results on
the second page could be duplicates from what was on the first page.
I don't remember ever
On Tue, Mar 20, 2012 at 11:17 AM, Jamie Johnson wrote:
> ok, with my custom component out of the picture I still have the same
> issue. Specifically, when sorting by score on a leader and replica I
> am getting different doc orderings. Is this something anyone has
> seen?
This is certainly poss
ok, with my custom component out of the picture I still have the same
issue. Specifically, when sorting by score on a leader and replica I
am getting different doc orderings. Is this something anyone has
seen?
On Tue, Mar 20, 2012 at 11:09 AM, Jamie Johnson wrote:
> DocCounts are the same. I a
DocCounts are the same. I am going to disable my custom component to
see if that is mucking with something but it seems to be working
properly.
After looking at the results a little closer (expanding the number of
results coming back) it seems that the same information is in both but
the order in
Do you have the logs for this? Either around startup or when you are forcing
replication. Logs around both would be helpful.
Also the doc counts for each shard?
On Mar 20, 2012, at 10:16 AM, Jamie Johnson wrote:
> I'm trying to figure out how it's possible for 2 solr instances (1
> which is lea
I'm trying to figure out how it's possible for 2 solr instances (1
which is leader 1 is replica) to be out of sync. I've done commits to
the solr instances, forced replication but still the solr instances
have different info. The relevant snippet from my clusterstate.json
is listed below.
\
13 matches
Mail list logo
