[
https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated SOLR-3347:
-----------------------------------
Description:
I've got a SolrCloud configuration in which calling deleteByQuery on
CloudSolrServer never works. The log looks plausible, but the documents never
leave.
Since I typed this up the first time, I tried using a completely stock
solrconfig.xml; I see the same problem. I've also used my provisioning script
to launch a vanilla set of 'example' shards, that also works. So my attention
is drawn, by seeming process of elimination, to my schema.xml, which is also
attached.
I've watched the process in the debugger when just using post.jar on simple XML
files with the delete on *:* and the commit, and the dbqlevel in
DistributedUpdateProcessor never gets to 3.
I'm going to attach a number of things. One is a unit test that passes, sadly.
Someone might like some small improvements in there in the cloud test classes,
even if you don't bother with the test itself.
I can now attach a 'freeze-dried' example of this problem. The root of the
tarball has a shell script: start-cloud.sh:
{noformat}
sh start-cloud.sh 8983 3
{noformat}
You can then observe some documents in the index.
If you then run:
{noformat}
sh del.sh http://localhost:8983/solr/update
{noformat}
you will observe, I hope, that the documents are still there.
The solrconfig.xml in the three shards (and the zoo_data, by extension) is an
exact copy of that from the 'example' directory. The schema.xml is mine.
was:
I've got a SolrCloud configuration in which calling deleteByQuery on
CloudSolrServer never works. The log looks plausible, but the documents never
leave.
Since I typed this up the first time, I tried using a completely stock
solrconfig.xml; I see the same problem. I've also used my provisioning script
to launch a vanilla set of 'example' shards, that also works. So my attention
is drawn, by seeming process of elimination, to my schema.xml, which is also
attached.
I've watched the process in the debugger when just using post.jar on simple XML
files with the delete on *:* and the commit, and the dbqlevel in
DistributedUpdateProcessor never gets to 3.
I'm going to attach a number of things. One is a unit test that passes, sadly.
Someone might like some small improvements in there in the cloud test classes,
even if you don't bother with the test itself.
Another is the solrconfig.xml that fails, and a third is the shell script I use
to launch.
I'm continuing to work on this; I guess the next step is to allow you to repro
what I'm doing by replacing my private URP with a dummy and seeing if I can get
the same wrong results.
> deleteByQuery failing with SolrCloud
> ------------------------------------
>
> Key: SOLR-3347
> URL: https://issues.apache.org/jira/browse/SOLR-3347
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Benson Margulies
> Attachments:
> 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch,
> provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> I've got a SolrCloud configuration in which calling deleteByQuery on
> CloudSolrServer never works. The log looks plausible, but the documents never
> leave.
> Since I typed this up the first time, I tried using a completely stock
> solrconfig.xml; I see the same problem. I've also used my provisioning script
> to launch a vanilla set of 'example' shards, that also works. So my attention
> is drawn, by seeming process of elimination, to my schema.xml, which is also
> attached.
> I've watched the process in the debugger when just using post.jar on simple
> XML files with the delete on *:* and the commit, and the dbqlevel in
> DistributedUpdateProcessor never gets to 3.
> I'm going to attach a number of things. One is a unit test that passes,
> sadly. Someone might like some small improvements in there in the cloud test
> classes, even if you don't bother with the test itself.
> I can now attach a 'freeze-dried' example of this problem. The root of the
> tarball has a shell script: start-cloud.sh:
> {noformat}
> sh start-cloud.sh 8983 3
> {noformat}
> You can then observe some documents in the index.
> If you then run:
> {noformat}
> sh del.sh http://localhost:8983/solr/update
> {noformat}
> you will observe, I hope, that the documents are still there.
> The solrconfig.xml in the three shards (and the zoo_data, by extension) is an
> exact copy of that from the 'example' directory. The schema.xml is mine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
