[
https://issues.apache.org/jira/browse/SOLR-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100108#comment-14100108
]
Erick Erickson edited comment on SOLR-6386 at 9/5/14 11:17 PM:
---------------------------------------------------------------
You're probably right. I added some logging at the error to dump the responses
being compared
and pasted them below. Two interesting things:
1> one response has maxScore and the other does not. Not sure that would be
significant or not.
2> Your workaround is interesting. I think there's another bug here, see the
responses for
2010-05-03T11:00:00Z below. At least one problem is that there are counts of 0
returned in one
case but not in the other. Haven't even looked at which one this happens to
(expected or actual),
got some errands to run.
I'm also looking two other bugs, SOLR-6154 and SOLR-6187 both having to do with
mincount
and distributed search not being respected. Seems ... ummm... at least it's in
the vicinity ;). I'll
look some more later.
Response A
{responseHeader={status=0,QTime=8},response={numFound=68,start=0,maxScore=1.0,docs=[]},facet_counts={facet_queries={},facet_fields=
{a_n_tdt={2010-05-03T11:00:00Z=2,
2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,1970-01-01T00:00:00Z=0,2009-03-13T13:23:01.248Z=0,2010-04-15T05:45:19.616Z=0,2010-04-20T06:55:27.232Z=0,2010-04-20T10:55:45.152Z=0,2010-04-20T10:59:59.104Z=0,2010-04-27T16:01:01.44Z=0,2010-05-02T07:51:54.624Z=0,2010-05-02T10:59:46.816Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T07:10:00.704Z=0,2010-05-03T10:57:12.192Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:25:50.08Z=0,2010-05-05T10:56:25.088Z=0,2010-05-05T10:59:58.08Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
Response B
{responseHeader={status=0,QTime=5},response={numFound=68,start=0,
docs=[]},facet_counts={facet_queries={},facet_fields={a_n_tdt={
2010-05-03T11:00:00Z=2
,2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,2010-04-20T11:00:00Z=0,2010-05-02T11:00:00Z=0,
2010-05-03T11:00:00Z=0,
2010-05-05T11:00:00Z=0,2010-04-20T10:59:59.104Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:59:58.08Z=0,2010-04-20T10:55:45.152Z=0,2010-05-02T10:59:46.816Z=0,2010-05-03T10:57:12.192Z=0,2010-05-05T10:56:25.088Z=0,2010-04-20T06:55:27.232Z=0,2010-05-02T07:51:54.624Z=0,2010-05-03T07:10:00.704Z=0,2010-05-05T10:25:50.08Z=0,2010-04-15T05:45:19.616Z=0,2010-04-27T16:01:01.44Z=0,2009-03-13T13:23:01.248Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
was (Author: erickerickson):
You're probably right. I added some logging at the error to dump the responses
being compared
and pasted them below. Two interesting things:
1> one response has maxScore and the other does not. Not sure that would be
significant or not.
2> Your workaround is interesting. I think there's another bug here, see the
responses for
2010-05003T11:00:00Z below. At least one problem is that there are counts of 0
returned in one
case but not in the other. Haven't even looked at which one this happens to
(expected or actual),
got some errands to run.
I'm also looking two other bugs, SOLR-6154 and SOLR-6187 both having to do with
mincount
and distributed search not being respected. Seems ... ummm... at least it's in
the vicinity ;). I'll
look some more later.
Response A
{responseHeader={status=0,QTime=8},response={numFound=68,start=0,maxScore=1.0,docs=[]},facet_counts={facet_queries={},facet_fields=
{a_n_tdt={2010-05-03T11:00:00Z=2,
2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,1970-01-01T00:00:00Z=0,2009-03-13T13:23:01.248Z=0,2010-04-15T05:45:19.616Z=0,2010-04-20T06:55:27.232Z=0,2010-04-20T10:55:45.152Z=0,2010-04-20T10:59:59.104Z=0,2010-04-27T16:01:01.44Z=0,2010-05-02T07:51:54.624Z=0,2010-05-02T10:59:46.816Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T07:10:00.704Z=0,2010-05-03T10:57:12.192Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:25:50.08Z=0,2010-05-05T10:56:25.088Z=0,2010-05-05T10:59:58.08Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
Response B
{responseHeader={status=0,QTime=5},response={numFound=68,start=0,
docs=[]},facet_counts={facet_queries={},facet_fields={a_n_tdt={
2010-05-03T11:00:00Z=2
,2010-04-20T11:00:00Z=1,2010-05-02T11:00:00Z=1,2010-05-05T11:00:00Z=1,2010-04-20T11:00:00Z=0,2010-05-02T11:00:00Z=0,
2010-05-03T11:00:00Z=0,
2010-05-05T11:00:00Z=0,2010-04-20T10:59:59.104Z=0,2010-05-02T10:59:59.104Z=0,2010-05-03T10:59:56.032Z=0,2010-05-05T10:59:58.08Z=0,2010-04-20T10:55:45.152Z=0,2010-05-02T10:59:46.816Z=0,2010-05-03T10:57:12.192Z=0,2010-05-05T10:56:25.088Z=0,2010-04-20T06:55:27.232Z=0,2010-05-02T07:51:54.624Z=0,2010-05-03T07:10:00.704Z=0,2010-05-05T10:25:50.08Z=0,2010-04-15T05:45:19.616Z=0,2010-04-27T16:01:01.44Z=0,2009-03-13T13:23:01.248Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0,1970-01-01T00:00:00Z=0}},facet_dates={},facet_ranges={},facet_intervals={}}}
> make secondary ordering of facet.field values (and facet.pivot?) consistently
> deterministic
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-6386
> URL: https://issues.apache.org/jira/browse/SOLR-6386
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Erick Erickson
>
> as a fluke of how the SOLR-2894 patch evolved, it wound up adding a bit of
> testing of distributed facet.field on date fields (see [r1617789 changes to
> TestDistributedSearch|https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestDistributedSearch.java?r1=1617789&r2=1617788&pathrev=1617789])
> ... but this started triggering some random failures due to facet
> constraints with identical values being sorted differently between the
> distributed query and the single node control query.
> We should make the facet.field (and facet.pivot) code order constraints with
> tied counts consistently regardless of whether it's a distrib search or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
