[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-04-21 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252873#comment-15252873
 ] 

ASF subversion and git services commented on SOLR-8738:
---

Commit 66d3c2eb0a1e7b28621557c87c8d5b5219a95add in lucene-solr's branch 
refs/heads/branch_5_5 from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66d3c2e ]

SOLR-8738: Fixed false success response when invalid deleteByQuery requests 
intially hit non-leader cloud nodes


> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master, 6.0, 5.5.1
>
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-04-21 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15252820#comment-15252820
 ] 

ASF subversion and git services commented on SOLR-8738:
---

Commit 9e77319abcf3ff372b86cec4d66bac11f7e038b6 in lucene-solr's branch 
refs/heads/branch_5x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9e77319 ]

SOLR-8738: Fixed false success response when invalid deleteByQuery requests 
intially hit non-leader cloud nodes


> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master, 6.0, 5.5.1
>
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-03-01 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15174037#comment-15174037
 ] 

ASF subversion and git services commented on SOLR-8738:
---

Commit ff6557cbcb5308d60f17114de1d0ad29003e9668 in lucene-solr's branch 
refs/heads/jira/SOLR-445 from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ff6557c ]

SOLR-8738: Fixed false success response when invalid deleteByQuery requests 
intially hit non-leader cloud nodes


> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-03-01 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15174041#comment-15174041
 ] 

ASF subversion and git services commented on SOLR-8738:
---

Commit ff6557cbcb5308d60f17114de1d0ad29003e9668 in lucene-solr's branch 
refs/heads/master from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ff6557c ]

SOLR-8738: Fixed false success response when invalid deleteByQuery requests 
intially hit non-leader cloud nodes


> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-03-01 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15174040#comment-15174040
 ] 

ASF subversion and git services commented on SOLR-8738:
---

Commit 2401c9495319e1b5065b05ef3a36ee586f06b6d4 in lucene-solr's branch 
refs/heads/jira/SOLR-445 from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2401c94 ]

SOLR-445 Merge branch 'master' into jira/SOLR-445 (pick up SOLR-8738 changes)


> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-03-01 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173921#comment-15173921
 ] 

Noble Paul commented on SOLR-8738:
--

It is easy to understand why and how this fix works. 
But it's kinda hard to understand why DUP is written to look at classname to 
propagate the errors. 

+1 to commit

> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8738.patch, SOLR-8738.patch, SOLR-8738.patch
>
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org



[jira] [Commented] (SOLR-8738) invalid DBQ initially sent to a non-leader node will report success

2016-02-25 Thread Hoss Man (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167711#comment-15167711
 ] 

Hoss Man commented on SOLR-8738:


The most trivial/obvious way to reproduce is...

* {{bin/solr -e cloud}}
* Pick "*3*" for number of nodes
* accept the default port numbers (8983, 7574, 8984)
* accept the default collection name (gettingstarted)
* pick "*1*" for the number of shards
* accept the default number of replicas per shard (2)
* accept the default config set (data_driven_schema_configs)

(So now you should have a single collection with a single shard with 2 replicas 
on 2 diff nodes and the remaining node doesn't host any cores related to the 
collection)

Now try running a broken DBQ against all 3 nodes...

{noformat}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:8983/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":400,"QTime":18},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"Invalid
 Number: yak","code":400}}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:8984/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":0,"QTime":25}}
$ curl -H 'Content-Type: application/json' 
'http://127.0.1.1:7574/solr/gettingstarted/update' --data-binary 
'{"delete":{"query" : "foo_i:yak"}}'
{"responseHeader":{"status":0,"QTime":7}}
{noformat}

...only the node hosting the leader correctly repsponds back with the error, 
requests that initially hit nodes only hosting replicas or not hosting any 
cores incorrectly indicate that the delete succeeded.



2 important notes:

# This can also be reproduced using {{numShards > 1}}, most easily by running 
{{-e cloud}} and choosing *4* nodes, and accepting the default 2 shards, 2 
replicas.  Then repeat the same curl commands above over all 4 ports.
#* you should see 2 nodes correctly return failures, and 2 nodes incorrectly 
claim success
# You can also reproduce using {{-e cloud -noprompt}} but since that that 
defaults to only 2 nodes they are garunteed to each have a leader on them, so 
you have to be more explicit about the requests.
#* Use the Solr UI to determine the _non-leader_ core_node_names (ex: 
{{gettingstarted_shard1_replica1}}) and which node they are located on, then 
use those in url instead of the simple collection name (otherwise smple 
collection paths will be auto-route to a leader on each node)




> invalid DBQ initially sent to a non-leader node will report success
> ---
>
> Key: SOLR-8738
> URL: https://issues.apache.org/jira/browse/SOLR-8738
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Discovered this while working on SOLR-445.
> If a Delete By Query gets sent to a node which is not hosting a leader (ie: 
> only hosts replicas, or doesn't host any cores related to the specified 
> collection) then a success will be returned, even if the DBQ is completely 
> malformed and actually failed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org