lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud
Date Wed, 11 Apr 2012 12:39:17 GMT

     [ 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.

The file is too big to attach, so I am copying it to people.apache.org:~bimargulies/del-test-case.tgz.





  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.

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.





    
> 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.
> The file is too big to attach, so I am copying it to people.apache.org:~bimargulies/del-test-case.tgz.

--
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message