You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Benson Margulies (Created) (JIRA)" <ji...@apache.org> on 2012/04/11 03:27:16 UTC

[jira] [Created] (SOLR-3347) deleteByQuery failing with SolrCloud

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, 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. In the debugger, 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.


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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Attachment: schema.xml
    
> 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. 
> 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.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ 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.

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.


  was:
I've got a SolrCloud configuration in which calling deleteByQuery on CloudSolrServer never works. The log looks plausible, but the documents never leave. 

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

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


[jira] [Commented] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Benson Margulies (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251784#comment-13251784 ] 

Benson Margulies commented on SOLR-3347:
----------------------------------------

Jan Høydahl,

I don't normally do radical edits to the description. However, in this particular case, my initial diagnostic theory was so wildly wrong that I felt it appropriate to either edit the description or close the JIRA and open a new one.

As for the patch file names, that's just laziness. On the other hand, I'm one of the many people around the ASF making use of the git mirrors, especially when working on code where I'm not a committer -- thus 'git format-patch'. You're the first person around here to express any problem with that. I wonder if there's some trick to get git to make a patch that is indistinguishable from svn diff.

                
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 Key: SOLR-3347
>                 URL: https://issues.apache.org/jira/browse/SOLR-3347
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Benson Margulies
>             Fix For: 4.0
>
>         Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Commented] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Steven Rowe (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251790#comment-13251790 ] 

Steven Rowe commented on SOLR-3347:
-----------------------------------

git patches can be applied to svn checkouts with {{patch -p1}}, instead of the usual {{patch -p0}} used with svn-generated patches.
                
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 Key: SOLR-3347
>                 URL: https://issues.apache.org/jira/browse/SOLR-3347
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Benson Margulies
>             Fix For: 4.0
>
>         Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Description: 
Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.





  was:
Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.





    
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 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
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Attachment: provision-and-start.sh
                solrconfig.xml
    
> 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, 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. In the debugger, 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.

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


[jira] [Commented] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Jan Høydahl (Commented JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251507#comment-13251507 ] 

Jan Høydahl commented on SOLR-3347:
-----------------------------------

Benson, here are a few friendly suggestions for working with JIRA and patches :) (ref http://wiki.apache.org/solr/HowToContribute)

Please use the JIRA "Comment" feature instead of editing the main description. The main description should be kept as a short problem description only, not involving solution...

Also, any potential patch should be in SVN diff format from project root and named SOLR-NNNN.patch, i.e. SOLR-3347.patch. JIRA will keep track of which is the newest one.
                
> 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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ 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. 

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.


  was:
I've got a SolrCloud configuration in which calling deleteByQuery on CloudSolrServer never works. The log looks plausible, but the documents never leave. In the debugger, 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, 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. 
> 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.

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


[jira] [Resolved] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man resolved SOLR-3347.
----------------------------

    Resolution: Fixed
      Assignee: Hoss Man

I'm going to go ahead and resolve this as fixed since the new sanity checks in SolrCloud mode should prevent this situation from ever happening (see linked issue).
                
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 Key: SOLR-3347
>                 URL: https://issues.apache.org/jira/browse/SOLR-3347
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Benson Margulies
>            Assignee: Hoss Man
>             Fix For: 4.0, 5.0
>
>         Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Attachment: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch

A patch as explained.
                
> 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, 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. In the debugger, 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.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Mark Miller (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Miller updated SOLR-3347:
------------------------------

    Fix Version/s: 4.0
    
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 Key: SOLR-3347
>                 URL: https://issues.apache.org/jira/browse/SOLR-3347
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Benson Margulies
>             Fix For: 4.0
>
>         Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Commented] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Jan Høydahl (Commented JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251909#comment-13251909 ] 

Jan Høydahl commented on SOLR-3347:
-----------------------------------

Cool, Steven, it worked well with -p1. I updated http://wiki.apache.org/solr/HowToContribute with this info.
                
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 Key: SOLR-3347
>                 URL: https://issues.apache.org/jira/browse/SOLR-3347
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>            Reporter: Benson Margulies
>             Fix For: 4.0
>
>         Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field \_version\_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ 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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Description: 
Distributed execution of deleteByQuery("*:*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.





  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.

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





        Summary: deleteByQuery failing with SolrCloud without _version_ in schema.xml  (was: deleteByQuery failing with SolrCloud)
    
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 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
>
>
> Distributed execution of deleteByQuery("*:*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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


[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml

Posted by "Benson Margulies (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benson Margulies updated SOLR-3347:
-----------------------------------

    Description: 
Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.





  was:
Distributed execution of deleteByQuery("*:*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.

I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.





    
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
> --------------------------------------------------------------------
>
>                 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
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a field _version_ in the schema. The default schema has no comment on this field to indicate its important or relevance to SolrCloud, and no message is logged nor error status returned when there is no such field. The code in DistributedUpdateProcessor just has an if statement that never ever does any local deleting without it.
> I don't know whether the intention was that this should work or not. If someone would clue me in, I'd make a patch for schema.xml to add comments, or a patch to D-U-P to add logging. If it was supposed to work, I'm probably not qualified to make the fix to make it work.

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