I'm not quite sure what logs you are talking about, but in the
tomcat/logs/catalina.out logs, i found the following [note, i can't
copy/paste, so i am typing up a summary]:
I execute command:
localhost:8080/bravo/select?q=fred&rows=102&start=0&shards=localhost:8080/alpha,localhost:8080/bravo
In this example, alpha has 27 instances of "fred", while bravo has 0.
Then in the catalina.out:
-There is the request for the command i sent, shards parameters and all. it
has the proper queryString.
-Then I see the two requests sent to the shards, apha and bravo. These two
requests weave between each other until they are finished:
INFO: REQUEST URI =/alpha/select
INFO: REQUEST URI =/bravo/select
The parameters have changed to:
wt=javabin&fsv=true&version=2.2&f1=docNumber,score&q=fred&rows=102&isShard=true&start=0
-Then 2 INFO's scroll across:
INFO: [] webapp=/bravo path=/select
params={wt=javabin&fsv=true&version=2.2&f1=docNumber,score&q=fred&rows=102&isShard=true&start=0}
hits=0 status=0 QTime=1
INFO: [] webapp=/alpha path=/select
params={wt=javabin&fsv=true&version=2.2&f1=docNumber,score&q=fred&rows=102&isShard=true&start=0}
hits=27 status=0 QTime=1
**Note, hits=27
-Then i see some octet-streams being transferred, with status 200, so those
are OK.
-The i see something peculiar:
It calls alpha with the following parameters:
wt=javabin&version=2.2&ids=ABC-1353,ABC-408,ABC-1355,ABC-1824,ABC-1354,FRED-ID-27,55&q=fred&rows=102¶meter=isShard=true&start=0
Performing this query on my own (without the wt=javabin) gives me
numFound=2, the result-set I get back from the overarching query.
Changing it to rows=10, it gives me numFound=2, and 2 <doc>'s. This is not
the strange functionality I was seeing with the overarching query and the
mis-matched "numfound" and <doc>'s.
This does beg the question.. why did it add:
"ids=ABC-1353,ABC-408,ABC-1355,ABC-1824,ABC-1354,FRED-ID-27,55" to the
query? They are the format that would be under docNumber, if that helps..
Any thoughts? I will do some research on those particular ID numbered docs,
in the mean time.
Here's the configuration information. I only posted the difference from the
default files in the solr/example/solr/conf
[solrconfig.xml]
<config>
<dataDir>${solr.data.dir:/data/indices/bravo/solr/data</dataDir>
<requestHandler name="/dataimport"
class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str
name="config">/data/indices/bravo/solr/conf/data-config.xml</str>
</lst>
</requestHandler>
<config>
[schema.xml]
<schema>
<fields>
<field name="docNumber" type="text" indexed="true"
stored="true" />
<field name="column1" type="text" indexed="true" stored="true"
/>
<field name="column2" type="text" indexed="true" stored="true"
/>
<field name="column3" type="text" indexed="true" stored="true"
/>
<field name="column4" type="text" indexed="true" stored="true"
/>
<field name="column5" type="text" indexed="true" stored="true"
/>
<field name="column6" type="text" indexed="true" stored="true"
/>
<field name="column7" type="text" indexed="true" stored="true"
/>
<field name="column8" type="text" indexed="true" stored="true"
/>
<field name="column9" type="text" indexed="true" stored="true"
/>
</fields>
<uniqueKey>docNumber</uniqueKey>
<defaultSearchField>column2</defaultSearchField>
</schema>
[data-config.xml]
<dataConfig>
<dataSource type="JdbcDataSource" driver="com.metamatrix.jdbc.MMDriver"
url="jdbc:metamatrix:b...@mms://hostname:port" user="username"
password="password"/>
<document naame="DOC_NAME">
<entity name="ENT_NAME" query="select * from ASDF.TABLE">
<field column="TABLE_COL_NO" name="docNumber" />
<field column="TABLE_COL_1" name="column1" />
<field column="TABLE_COL_2" name="column2" />
<field column="TABLE_COL_3" name="column3" />
<field column="TABLE_COL_4" name="column4" />
<field column="TABLE_COL_5" name="column5" />
<field column="TABLE_COL_6" name="column6" />
<field column="TABLE_COL_7" name="column7" />
<field column="TABLE_COL_8" name="column8" />
<field column="TABLE_COL_9" name="column9" />
</entity>
</document>
</dataConfig>
Yonik Seeley-2 wrote:
>
> On Fri, May 15, 2009 at 4:11 PM, CB-PO <charles.bush...@gmail.com> wrote:
>> Yeah, the first thing I thought of was that perhaps there was something
>> wrong
>> with the uniqueKey and they were clashing between the indexes, however
>> upon
>> visual inspection of the data the field we are using as the unique key in
>> each of the indexes is grossly different between the two databases, so
>> there
>> is no chance of them clashing.
>
> Yes, but is the same fieldname and FieldType used for both indexes?
> (that's sort of a requirement)
>
> You might also try looking at the logs for the exact requests that
> were sent to each shard as part of the distributed request, and
> manually sending those requests and inspecting the results. That
> should tell you if the shard requests or responses are weird, or if
> it's the top-level combining logic that's causing this.
>
> -Yonik
> http://www.lucidimagination.com
>
>
--
View this message in context:
http://www.nabble.com/Solr-Shard---Strange-results-tp23561201p23600878.html
Sent from the Solr - User mailing list archive at Nabble.com.
