[jira] [Commented] (SOLR-10619) When DQ.knowChildren is not empty, DQ should not refetch node children in case of single consumer

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10619:
---

I'll take another look tomorrow.

> When DQ.knowChildren is not empty, DQ should not refetch node children in 
> case of single consumer
> -
>
> Key: SOLR-10619
> URL: https://issues.apache.org/jira/browse/SOLR-10619
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-10619.patch, SOLR-10619.patch
>
>
> Right now, for every time childWatcher is kicked off. We refetch all children 
> of DQ's node. It is a wasted in case of single consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10285) Reduce state messages when there are leader only shards

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-10285:
---

[~jhump] did you have a patch for this?  or did we only discuss it?

> Reduce state messages when there are leader only shards
> ---
>
> Key: SOLR-10285
> URL: https://issues.apache.org/jira/browse/SOLR-10285
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Cao Manh Dat
>
> For shards which have 1 replica ( leader ) we know it doesn't need to recover 
> from anyone. We should short-circuit the recovery process in this case. 
> The motivation for this being that we will generate less state events and be 
> able to mark these replicas as active again without it needing to go into 
> 'recovering' state. 
> We already short circuit when you set {{-Dsolrcloud.skip.autorecovery=true}} 
> but that sys prop was meant for tests only. Extending this to make sure the 
> code short-circuits when the core knows its the only replica in the shard is 
> the motivation of the Jira.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 857 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/857/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([65B55789ABBBD6DE:F54D9E2962160A6]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12627 lines...]
   [junit4] Suite: org.apache.solr.cloud.CustomCollectionTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/

[jira] [Issue Comment Deleted] (SOLR-10619) When DQ.knowChildren is not empty, DQ should not refetch node children in case of single consumer

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat updated SOLR-10619:

Comment: was deleted

(was: [~dragonsinth] Can you take a look at this patch?
Thanks [~shalinmangar])

> When DQ.knowChildren is not empty, DQ should not refetch node children in 
> case of single consumer
> -
>
> Key: SOLR-10619
> URL: https://issues.apache.org/jira/browse/SOLR-10619
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-10619.patch, SOLR-10619.patch
>
>
> Right now, for every time childWatcher is kicked off. We refetch all children 
> of DQ's node. It is a wasted in case of single consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10619) When DQ.knowChildren is not empty, DQ should not refetch node children in case of single consumer

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat updated SOLR-10619:

Attachment: (was: SOLR-10619.patch)

> When DQ.knowChildren is not empty, DQ should not refetch node children in 
> case of single consumer
> -
>
> Key: SOLR-10619
> URL: https://issues.apache.org/jira/browse/SOLR-10619
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-10619.patch, SOLR-10619.patch
>
>
> Right now, for every time childWatcher is kicked off. We refetch all children 
> of DQ's node. It is a wasted in case of single consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10619) When DQ.knowChildren is not empty, DQ should not refetch node children in case of single consumer

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat updated SOLR-10619:

Attachment: SOLR-10619.patch

[~dragonsinth] Can you take a look at this patch?
Thanks [~shalinmangar]

> When DQ.knowChildren is not empty, DQ should not refetch node children in 
> case of single consumer
> -
>
> Key: SOLR-10619
> URL: https://issues.apache.org/jira/browse/SOLR-10619
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-10619.patch, SOLR-10619.patch, SOLR-10619.patch
>
>
> Right now, for every time childWatcher is kicked off. We refetch all children 
> of DQ's node. It is a wasted in case of single consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8440:
--

there is no concept of an {{admin}} role in Solr. So it makes no sense to have 
an argument such as {{adminuser}} and {{adminpassword}} . Can we have another 
choice?



> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10627) Security API should not let users create permission with collection:null for per collection permissions

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-10627:
--
Description: 
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "some-role"
}
{code}

They expect this to secure the update operations. This does not work and does 
not protect any operation 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . 
 
 * if {{collection:null}} is specified for a per-collection permission, that 
should be ignored
 * for permissions where collection is not required , such as 
{{collection-admin-edit}} , {{security-edit}} , value of collection is null 
anyway , no other value should be allowed to be specified



  was:
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "some-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . 
 
 * if {{collection:null}} is specified for a per-collection permission, that 
should be ignored
 * for permissions where collection is not required , such as 
{{collection-admin-edit}} , {{security-edit}} , value of collection is null 
anyway , no other value should be allowed to be specified




> Security API should not let users create permission with collection:null for 
> per collection permissions
> ---
>
> Key: SOLR-10627
> URL: https://issues.apache.org/jira/browse/SOLR-10627
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Users end up creating permissions like 
> {code}
> {
> "collection":null,
> "name": "update",
> "role": "some-role"
> }
> {code}
> They expect this to secure the update operations. This does not work and does 
> not protect any operation 
> The security API should throw an error when such a permission is created . 
> For the well-known permissions, we already know the value of {{collection}} . 
>  
>  * if {{collection:null}} is specified for a per-collection permission, that 
> should be ignored
>  * for permissions where collection is not required , such as 
> {{collection-admin-edit}} , {{security-edit}} , value of collection is null 
> anyway , no other value should be allowed to be specified



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10627) Security API should not let users create permission with collection:null for per collection permissions

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-10627:
--
Description: 
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "some-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . 
 
 * if {{collection:null}} is specified for a per-collection permission, that 
should be ignored
 * for permissions where collection is not required , such as 
{{collection-admin-edit}} , {{security-edit}} , value of collection is null 
anyway , no other value should be allowed to be specified



  was:
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "some-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . So, 
just don't let users specify it. Throw an error


> Security API should not let users create permission with collection:null for 
> per collection permissions
> ---
>
> Key: SOLR-10627
> URL: https://issues.apache.org/jira/browse/SOLR-10627
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Users end up creating permissions like 
> {code}
> {
> "collection":null,
> "name": "update",
> "role": "some-role"
> }
> {code}
> They expect this to secure the update operations. 
> The security API should throw an error when such a permission is created . 
> For the well-known permissions, we already know the value of {{collection}} . 
>  
>  * if {{collection:null}} is specified for a per-collection permission, that 
> should be ignored
>  * for permissions where collection is not required , such as 
> {{collection-admin-edit}} , {{security-edit}} , value of collection is null 
> anyway , no other value should be allowed to be specified



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10627) Security API should not let users create permission with collection:null for per collection permissions

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-10627:
--
Description: 
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "some-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . So, 
just don't let users specify it. Throw an error

  was:
Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "come-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . So, 
just don't let users specify it. Throw an error


> Security API should not let users create permission with collection:null for 
> per collection permissions
> ---
>
> Key: SOLR-10627
> URL: https://issues.apache.org/jira/browse/SOLR-10627
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Users end up creating permissions like 
> {code}
> {
> "collection":null,
> "name": "update",
> "role": "some-role"
> }
> {code}
> They expect this to secure the update operations. 
> The security API should throw an error when such a permission is created . 
> For the well-known permissions, we already know the value of {{collection}} . 
> So, just don't let users specify it. Throw an error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9804:
--

created SOLR-10627

> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10627) Security API should not let users create permission with collection:null for per collection permissions

[Noble Paul (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul reassigned SOLR-10627:
-

Assignee: Noble Paul

> Security API should not let users create permission with collection:null for 
> per collection permissions
> ---
>
> Key: SOLR-10627
> URL: https://issues.apache.org/jira/browse/SOLR-10627
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Users end up creating permissions like 
> {code}
> {
> "collection":null,
> "name": "update",
> "role": "come-role"
> }
> {code}
> They expect this to secure the update operations. 
> The security API should throw an error when such a permission is created . 
> For the well-known permissions, we already know the value of {{collection}} . 
> So, just don't let users specify it. Throw an error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10627) Security API should not let users create permission with collection:null for per collection permissions

[Noble Paul (JIRA)]

Noble Paul created SOLR-10627:
-

 Summary: Security API should not let users create permission with 
collection:null for per collection permissions
 Key: SOLR-10627
 URL: https://issues.apache.org/jira/browse/SOLR-10627
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul


Users end up creating permissions like 

{code}
{
"collection":null,
"name": "update",
"role": "come-role"
}
{code}

They expect this to secure the update operations. 

The security API should throw an error when such a permission is created . For 
the well-known permissions, we already know the value of {{collection}} . So, 
just don't let users specify it. Throw an error



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-9804 at 5/8/17 1:53 AM:
--

[~sleem]

{{collection:null}} means it is not a collection specific request. (admin 
requests such as , {{collection-admin-read}} etc)

{{/update}} is a collection specific request. remove it and it should work



was (Author: noble.paul):
[~sleem]

{{collection:null}} means it is not a collection specific request. 

{{/update}} is a collection specific request. remove it and it should work


> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9804:
--

[~sleem]

{{collection:null}} means it is not a collection specific request. 

{{/update}} is a collection specific request. remove it and it should work


> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10626) Add covariance Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein resolved SOLR-10626.
---
   Resolution: Resolved
Fix Version/s: master (7.0)
   6.6

> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10626) Add covariance Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10626:


Commit 1f7974acc386928bb8c076fec891ebb86ba6b5b3 in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1f7974a ]

SOLR-10626: Update CHANGES.txt


> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10626) Add covariance Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10626:


Commit 34c6c9956dd4d0e3312ffb12a9a63facc4d6ad80 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=34c6c99 ]

SOLR-10626: Update CHANGES.txt


> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10626) Add covariance Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10626:


Commit 26edf7f7db05129b2dece29410ac4778a14c4eb3 in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=26edf7f ]

SOLR-10626: Add covariance Stream Evaluator


> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10626) Add covariance Stream Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10626:


Commit c6524c3d66b94947ec458582aa64585662d1497f in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c6524c3 ]

SOLR-10626: Add covariance Stream Evaluator


> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10625:
--
Attachment: (was: SOLR-10626.patch)

> Add convolve Stream Evaluator
> -
>
> Key: SOLR-10625
> URL: https://issues.apache.org/jira/browse/SOLR-10625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket adds a *convolve* stream evaluator that returns the convolution 
> of two sequences. The convolve function achieves a result similar to 
> *cross-correlation*.
> Syntax:
> {code}
> a = convolve(cola, colb)
> {code}
> Implementation is provided by Apache Commons Math.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10626) Add covariance Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10626:
--
Description: 
The covariance Stream Evaluator calculates the covariance of two columns of 
numbers.

Syntax:
{code}
c=cov(cola,colb)
{code}

The implementation is provided by Apache Commons Math

  was:
The covariance Stream Evaluator calculates the covariance of two columns of 
numbers.

Syntax:
{code}
c=cov(cola,colb)
{code}

The implementation is provided by Apache Match Commons 


> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10626) Add covariance Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10626:
--
Attachment: SOLR-10626.patch

> Add covariance Stream Evaluator
> ---
>
> Key: SOLR-10626
> URL: https://issues.apache.org/jira/browse/SOLR-10626
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> The covariance Stream Evaluator calculates the covariance of two columns of 
> numbers.
> Syntax:
> {code}
> c=cov(cola,colb)
> {code}
> The implementation is provided by Apache Match Commons 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10626) Add covariance Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10626:
-

 Summary: Add covariance Stream Evaluator
 Key: SOLR-10626
 URL: https://issues.apache.org/jira/browse/SOLR-10626
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The covariance Stream Evaluator calculates the covariance of two columns of 
numbers.

Syntax:
{code}
c=cov(cola,colb)
{code}

The implementation is provided by Apache Match Commons 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10625:
--
Attachment: SOLR-10626.patch

Patch with test

> Add convolve Stream Evaluator
> -
>
> Key: SOLR-10625
> URL: https://issues.apache.org/jira/browse/SOLR-10625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10626.patch
>
>
> This ticket adds a *convolve* stream evaluator that returns the convolution 
> of two sequences. The convolve function achieves a result similar to 
> *cross-correlation*.
> Syntax:
> {code}
> a = convolve(cola, colb)
> {code}
> Implementation is provided by Apache Commons Math.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19579 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19579/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:42054/solr/test_col: Failed synchronous update on shard 
StdNode: http://127.0.0.1:38065/solr/test_col_shard1_replica1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@51144778

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:42054/solr/test_col: Failed synchronous update on 
shard StdNode: http://127.0.0.1:38065/solr/test_col_shard1_replica1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@51144778
at 
__randomizedtesting.SeedInfo.seed([D4803C454DF81D97:E2945E03C7A52786]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apac

[JENKINS] Lucene-Solr-Tests-master - Build # 1815 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1815/

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([185FD2C51848EAB:B8042BF37D6E8A21]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:14&qt=standard&start=0&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:889)
... 40 more




Build Log:
[...truncated 12075 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/

[jira] [Commented] (SOLR-10042) Delete old deprecated Admin UI

[JIRA]

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

Jan Høydahl commented on SOLR-10042:


Linking some Angular UI bugs as "requires". I don't mean that all of these need 
to be fixed before we kill the old UI, but probably some of them should. We can 
discuss that further here and then attempt fixing the most serious ones before 
deleting the old UI code.

> Delete old deprecated Admin UI
> --
>
> Key: SOLR-10042
> URL: https://issues.apache.org/jira/browse/SOLR-10042
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
> Fix For: master (7.0)
>
>
> The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up 
> the last known bugs in Angular UI and simply delete the old UI in  master.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

[JIRA]

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

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

[~aniketkhare] is this still something you'd like to work on? A first baby step 
could perhaps be to ensure that Solr exposes ZK ensemble state somewhere, and 
once that is committed, continue with a UI to show it.

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein reassigned SOLR-10625:
-

Assignee: Joel Bernstein

> Add convolve Stream Evaluator
> -
>
> Key: SOLR-10625
> URL: https://issues.apache.org/jira/browse/SOLR-10625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket adds a *convolve* stream evaluator that returns the convolution 
> of two sequences. The convolve function achieves a result similar to 
> *cross-correlation*.
> Syntax:
> {code}
> a = convolve(cola, colb)
> {code}
> Implementation is provided by Apache Commons Math.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10625:
--
Description: 
This ticket adds a *convolve* stream evaluator that returns the convolution of 
two sequences. The convolve function achieves a result similar to 
*cross-correlation*.

Syntax:
{code}
a = convolve(cola, colb)
{code}

Implementation is provided by Apache Commons Math.

  was:
This ticket adds a *convolve* stream evaluator that returns the convolution of 
two sequences. The convolve function achieves a result similar to 
*cross-correlation*.

Syntax:
{code}
a = convolve(cola, colb)
{code}

Implementation is provided by apache commons math.


> Add convolve Stream Evaluator
> -
>
> Key: SOLR-10625
> URL: https://issues.apache.org/jira/browse/SOLR-10625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> This ticket adds a *convolve* stream evaluator that returns the convolution 
> of two sequences. The convolve function achieves a result similar to 
> *cross-correlation*.
> Syntax:
> {code}
> a = convolve(cola, colb)
> {code}
> Implementation is provided by Apache Commons Math.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10625:
--
Description: 
This ticket adds a *convolve* stream evaluator that returns the convolution of 
two sequences. The convolve function achieves a result similar to 
*cross-correlation*.

Syntax:
{code}
a = convolve(cola, colb)
{code}

Implementation is provided by apache commons math.

  was:
This ticket adds a *convolve* stream evaluator that returns the convolution of 
two sequences. The convolve function achieves a result similar to 
*cross-correlation*.

Syntax:
{code}
a = convolve(cola, colb)
{code}


> Add convolve Stream Evaluator
> -
>
> Key: SOLR-10625
> URL: https://issues.apache.org/jira/browse/SOLR-10625
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> This ticket adds a *convolve* stream evaluator that returns the convolution 
> of two sequences. The convolve function achieves a result similar to 
> *cross-correlation*.
> Syntax:
> {code}
> a = convolve(cola, colb)
> {code}
> Implementation is provided by apache commons math.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10625) Add convolve Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10625:
-

 Summary: Add convolve Stream Evaluator
 Key: SOLR-10625
 URL: https://issues.apache.org/jira/browse/SOLR-10625
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


This ticket adds a *convolve* stream evaluator that returns the convolution of 
two sequences. The convolve function achieves a result similar to 
*cross-correlation*.

Syntax:
{code}
a = convolve(cola, colb)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10622) Add regress and predict Stream Evaluators

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein resolved SOLR-10622.
---
   Resolution: Resolved
Fix Version/s: master (7.0)
   6.6

> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10622) Add regress and predict Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10622:


Commit 6e6dd3332ac64a401977ee76684e2edcadc8476b in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6e6dd33 ]

SOLR-10622: Update CHANGES.txt


> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10622) Add regress and predict Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10622:


Commit fd24081c63fbe0da7406280c9fa2056c2d5a8862 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd24081 ]

SOLR-10622: Update CHANGES.txt


> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: More ASF Jenkins job triggering problems

[Mikhail Khludnev]

Hello, Steve.
I notice the same authorization warning at
https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/343/console
Do you know if there is a chance to get a nightly build?

On Tue, May 2, 2017 at 6:43 PM, Steve Rowe  wrote:

> Mikhail alerted me to the fact that the Lucene-Artifacts-6.x job hasn’t
> run recently on ASF Jenkins.  This job is a “downstream project” of
> Lucene-Solr-NightlyTests-6.x, i.e. once the latter has finished building,
> the former is triggered.  (Solr-Artifacts-6.x is a downstream project of
> Lucene-Artifacts-6.x, so as a result of this problem, it hasn’t run
> recently either.)
>
> I see the following in the log from the most recent
> Lucene-Solr-NightlyTests-6.x build  job/Lucene-Solr-NightlyTests-6.x/337/console>:
>
> -
> Warning: this build has no associated authentication, so build permissions
> may be lacking, and downstream projects which cannot even be seen by an
> anonymous user will be silently skipped
> You have no permission to build Lucene-Artifacts-6.x
> -
>
> Lucene-Solr-NightlyTests-master/Lucene-Artifacts-master is exhibiting the
> same behavior - the oldest retained log from April 28th <
> https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1288/console>
> has the same warning/permission text ^^.
>
> I mentioned the problem on Infra’s hipchat channel, and pono (Daniel
> Takamori), chatting with me on #lucene IRC, suggested the problem started
> with the Jenkins upgrade over the weekend, but the April 28th build
> predates that.  pono also noted that the Jenkins upgrade brought a new
> capability: the Jenkins Build Authorization plugin.  He had me configure
> the two jobs in question to first enable “Configure Build Authorization”
> and then select “Run as user who triggered build”.  This is an experiment:
> we’ll see how it goes.  (I’m wondering if this will cause a problem with
> manually kicked off jobs.)
>
> I’ll keep an eye on it but if anybody else notices problems, please let us
> know.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Sincerely yours
Mikhail Khludnev

[jira] [Commented] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10594:
-

bq. ant beast -Dbeast.iters=10  -Dtestcase=*ConfigHandler*
is fine, core tests are fine too. 

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch, TestSolrConfigHandlerCloud odd fail.txt
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10594 at 5/7/17 8:06 PM:
-

bq. ant beast -Dbeast.iters=10  -Dtestcase=\*ConfigHandler\*
is fine, core tests are fine too. 


was (Author: mkhludnev):
bq. ant beast -Dbeast.iters=10  -Dtestcase=*ConfigHandler*
is fine, core tests are fine too. 

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch, TestSolrConfigHandlerCloud odd fail.txt
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9804:
-

I have no idea if it's a real issue. However, pinging [~noble.paul] since he 
had told me privately that he was going to fix that separately but I don't know 
if he did.

> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10594 at 5/7/17 7:51 PM:
-

Hm. -It breaks cloud config update.- not at all [^TestSolrConfigHandlerCloud 
odd fail.txt] was just really unlucky. Stay tuned


was (Author: mkhludnev):
Hm. -It breaks cloud config update.- not at all. Stay tuned

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch, TestSolrConfigHandlerCloud odd fail.txt
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-10594:

Attachment: TestSolrConfigHandlerCloud odd fail.txt

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch, TestSolrConfigHandlerCloud odd fail.txt
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-10594 at 5/7/17 7:50 PM:
-

Hm. -It breaks cloud config update.- not at all. Stay tuned


was (Author: mkhludnev):
Hm. It breaks cloud config update. Stay tuned

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch, TestSolrConfigHandlerCloud odd fail.txt
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10622) Add regress and predict Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10622:


Commit 9499cfbfd5001d2cc8c87e7dd2a79a7d8ca1e96f in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9499cfb ]

SOLR-10622: Add regress and predict Stream Evaluators


> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10622) Add regress and predict Stream Evaluators

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10622:


Commit d724983c03249acd8a26e1c00b77b5573f6eefc0 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d724983 ]

SOLR-10622: Add regress and predict Stream Evaluators


> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-9753) Admin UI - Memory Graph on Dashboard shows NaN for unused Swap

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl closed SOLR-9753.
-
Resolution: Cannot Reproduce

Cannot reproduce, lots have changed. Please re-open if you still encounter this.

> Admin UI - Memory Graph on Dashboard shows NaN for unused Swap
> --
>
> Key: SOLR-9753
> URL: https://issues.apache.org/jira/browse/SOLR-9753
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, JSON Request API
>Affects Versions: 5.1
>Reporter: adeppa
>Assignee: Alexandre Rafalovitch
>
> If the System doesn't use Swap, the displayed memory graph on the dashboard 
> shows NaN (not a number) because it tries to divide by zero.
> admin url : solr/collection/admin/system?wt=json&&indent=true
> "system":{
> "name":"Linux",
> "version":"3.13.0-48-generic",
> "arch":"amd64",
> "systemLoadAverage":0.0,
> "committedVirtualMemorySize":27111653376,
> "freePhysicalMemorySize":48219590656,
> "freeSwapSpaceSize":0,
> "processCpuTime":6793865000,
> "totalPhysicalMemorySize":67548606464,
> "totalSwapSpaceSize":0,
> "openFileDescriptorCount":213,
> "maxFileDescriptorCount":4096,
> "uname":"Linux ip-172-22-65-57 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 
> 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux\n",
> "uptime":" 06:33:04 up 57 days, 20:20,  0 users,  load average: 0.00, 
> 0.01, 0.05\n"}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10511) Unable to view replication status

[JIRA]

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

Jan Høydahl commented on SOLR-10511:


Please describe how to reproduce this issue

> Unable to view replication status
> -
>
> Key: SOLR-10511
> URL: https://issues.apache.org/jira/browse/SOLR-10511
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.5
>Reporter: David Lee
>
> When viewing replication page none of the buttons work and no data shows up 
> for next run, iterations, index versions, and master settings.
> Javascript Console error:  
> angular.js:11617 TypeError: Cannot set property 'status' of undefined
> at getIterations (replication.js:114)
> at replication.js:32
> at angular-resource.min.js:33
> at processQueue (angular.js:13193)
> at angular.js:13209
> at Scope.$eval (angular.js:14406)
> at Scope.$digest (angular.js:14222)
> at Scope.$apply (angular.js:14511)
> at done (angular.js:9669)
> at completeRequest (angular.js:9859)
> The original UI works as expected



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10622) Add regress and predict Stream Evaluators

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10622:
--
Attachment: SOLR-10622.patch

Patch with tests

> Add regress and predict Stream Evaluators
> -
>
> Key: SOLR-10622
> URL: https://issues.apache.org/jira/browse/SOLR-10622
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-10622.patch
>
>
> This ticket will add two Stream Evaluators:
> a) *regress*: Performs simple regression on two columns of numbers and 
> returns a *regression result*.
> b) *predict*: returns a prediction for an independent variable based on a 
> *regression result*.
> syntax:
> {code}
> a = regress(colA, colB)
> b = predict(a, 50)
> {code}
> The implementations will be provided by Apache Commons Math



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[JIRA]

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

Jan Høydahl commented on SOLR-10494:


Solr 7 is just a month away, do you have time to work on this, Trey?

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Trey Grainger
>Priority: Minor
> Fix For: master (7.0)
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8440) Script support for enabling basic auth

[JIRA]

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

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

This patch assumes that Auth can only be enabled with SolrCloud. However, we 
now also support {{security.json}} in {{$SOLR_HOME}} for standalone.
Propose to try to replace explicit {{zkClient}} logic with using 
{{SecurityConfHandler}}, ({{SecurityConfHandlerLocal/SecurityConfHandlerZk}} 
somehow. They have a nice {{SecurityConfig}} abstraction as well as 
{{persistConf(SecurityConfig securityConfig)}} methods. May need to refactor 
some of these into static methods or something to access from SolrCLI though.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Attachments: SOLR-8440.patch, SOLR-8440.patch, SOLR-8440.patch, 
> SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 856 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/856/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest

Error Message:
org/apache/solr/client/solrj/request/schema/SchemaRequest$MultiUpdate

Stack Trace:
java.lang.NoClassDefFoundError: 
org/apache/solr/client/solrj/request/schema/SchemaRequest$MultiUpdate
at __randomizedtesting.SeedInfo.seed([91D61DB1737F577C]:0)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: 
org.apache.solr.client.solrj.request.schema.SchemaRequest$MultiUpdate
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 25 more
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-solrj/classes/java/org/apache/solr/client/solrj/request/schema/SchemaRequest$MultiUpdate.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 31 more


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.MigrateRouteKeyTest

Error Message:
Solr servers failed to register with ZK. Current count: 1; Expected count: 2

Stack Trace:
java.lang.IllegalStateException: Solr servers failed to register with ZK. 
Current count: 1; Expected count: 2
at __randomizedtesting.SeedInfo.seed([91D61DB1737F577C]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForAllNodes(MiniSolrCloudCluster.java:284)
 

[jira] [Closed] (SOLR-9541) Support configurable authentication mechanism for internode communication

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl closed SOLR-9541.
-
Resolution: Not A Problem

Closing this, please re-open if you believe there is still work to do on this.

Please open a new JIRA for the proposal of disabling PKI in case another plugin 
explicitly handles inter-node.

> Support configurable authentication mechanism for internode communication
> -
>
> Key: SOLR-9541
> URL: https://issues.apache.org/jira/browse/SOLR-9541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3, 6.0
>Reporter: Hrishikesh Gadre
>
> SOLR-7849 introduced PKI based authentication mechanism for internode 
> communication. The main reason for introducing SOLR-7849 was,
> >> Relying on every Authentication plugin to secure the internode 
> >> communication is error prone. 
> At Cloudera we are using Kerberos protocol for all communication without any 
> issues (i.e. between client/server as well as server/server). We should make 
> this internode authentication mechanism configurable (with default as PKI 
> based mechanism). This will allow users to decide the appropriate 
> authentication mechanism based on their security requirements.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Issue Comment Deleted] (SOLR-9541) Support configurable authentication mechanism for internode communication

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-9541:
--
Comment: was deleted

(was: Giving a ping on this issue in light of the new security vulnerability 
reported, that existing Solr nodes will accept requests from an attacker who 
pretends to be another Solr node with PKI...)

> Support configurable authentication mechanism for internode communication
> -
>
> Key: SOLR-9541
> URL: https://issues.apache.org/jira/browse/SOLR-9541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3, 6.0
>Reporter: Hrishikesh Gadre
>
> SOLR-7849 introduced PKI based authentication mechanism for internode 
> communication. The main reason for introducing SOLR-7849 was,
> >> Relying on every Authentication plugin to secure the internode 
> >> communication is error prone. 
> At Cloudera we are using Kerberos protocol for all communication without any 
> issues (i.e. between client/server as well as server/server). We should make 
> this internode authentication mechanism configurable (with default as PKI 
> based mechanism). This will allow users to decide the appropriate 
> authentication mechanism based on their security requirements.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[JIRA]

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

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

[~ctargett], do you want to open a separate issue for the {{collection:null}} 
issue, if you believe it is a real one?

Regarding this issue, we should either be explicit and return an exception, 
e.g. "Not updated, version N already in ZK", or we should disregard any version 
in the JSON and let it always succeed, with the risk of two admins editing the 
same config without knowing and the last one wins.

> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9804) Rule-Based Authorization Plugin does not secure access for update operations

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-9804:
--
Security: Public  (was: Private (Security Issue))
Priority: Major  (was: Critical)

Opening this issue to become a PUBLIC issue, as it cannot be exploited by 
outsiders. It is unfortunate that a Solr admin may mis-configure Auth because 
of it so we should definitely try to fix it.

> Rule-Based Authorization Plugin does not secure access for update operations
> 
>
> Key: SOLR-9804
> URL: https://issues.apache.org/jira/browse/SOLR-9804
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 6.3
> Environment: Linux:
> # uname -a
> Linux hostname 3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016 
> x86_64 x86_64 x86_64 GNU/Linux
> /solr -version
> 6.3.0
>Reporter: Sleem
>  Labels: authorization, security, update
>
> It looks like the /update path is not filtered by the Rule-Based 
> Authorization Plugin. Even if you set permission using the path permission 
> "/update" or the pre-defined permission "update". Below is the security.json
> {code:JavaScript}
> {
>   "authentication":{
> "class":"solr.BasicAuthPlugin",
> "blockUnknown":true,
> "credentials":{
>   "admin":"JrcQ8Lh/xKmucz9CaGVXwTpXxGSUZOt32i6W2f4tIfY= 
> PuAJx8DjI0Ozy2gQXteG5KfRAbOmXuRFZVjHbrIIzVk=",
>   "update":"tFdQLTQd9qXAStQek5xQQPlVcmXgjI/w4+9rjAZyqTU= 
> by0LXUAdNAtcJW+DuycI2zc4NyDjCiexOgMaqEFIklU=",
>   "solr":"GglOeZytbUBCKW8QT1H7kVs0eHc0x8+iNmpz7x8DKMI= 
> 5JR1Ul8QehmP3nb2U6Bc/N1qwrQljLfiKPTxm35FikA="}},
>   "authorization":{
> "class":"solr.RuleBasedAuthorizationPlugin",
> "user-role":{
>   "admin":["admin_role"],
>   "update":["update_role"],
>   "solr":["read_role"]},
> "permissions":[
>   {
> "collection":null,
> "name":"security-edit",
> "role":["admin_role"],
> "index":1},
>   {
> "collection":null,
> "name":"schema-edit",
> "role":["admin_role"],
> "index":2},
>   {
> "collection":null,
> "name":"config-edit",
> "role":["admin_role"],
> "index":3},
>   {
> "collection":null,
> "name":"core-admin-edit",
> "role":["admin_role"],
> "index":4},
>   {
> "collection":null,
> "name":"collection-admin-edit",
> "role":["admin_role"],
> "index":5},
>   {
> "collection":null,
> "name":"security-read",
> "role":["admin_role"],
> "index":6},
>   {
> "collection":null,
> "name":"schema-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":7},
>   {
> "collection":null,
> "name":"core-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":8},
>   {
> "collection":null,
> "name":"config-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":9},
>   {
> "collection":null,
> "name":"collection-admin-read",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":10},
>   {
> "collection":null,
> "name":"update",
> "role":[
>   "admin_role",
>   "update_role"],
> "index":11},
>   {
> "collection":null,
> "name":"read",
> "role":[
>   "admin_role",
>   "update_role",
>   "read_role"],
> "index":12},
>   {
> "collection":null,
> "name":"all",
> "role":["admin_role"],
> "index":13},
>   {
> "collection":null,
> "path":"/*",
> "role":["admin_role"],
> "index":14}],
> "":{"v":138}}}
> {code}
> I have tested update using SolrJ and by hitting the /update on the browser 
> using the solr user (who has no rights to update). Both were suceeded update



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1814 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1814/

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:35005/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:37278/solr/test_col_shard1_replica2: Server Errorrequest: 
http://127.0.0.1:37278/solr/test_col_shard1_replica2/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A35005%2Fsolr%2Ftest_col_shard2_replica2%2F&wt=javabin&version=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:60260/solr/test_col_shard1_replica1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@71170f38

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:35005/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:37278/solr/test_col_shard1_replica2: Server Error



request: 
http://127.0.0.1:37278/solr/test_col_shard1_replica2/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A35005%2Fsolr%2Ftest_col_shard2_replica2%2F&wt=javabin&version=2
Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:60260/solr/test_col_shard1_replica1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@71170f38
at 
__randomizedtesting.SeedInfo.seed([3795AD6AA3D98D24:181CF2C2984B735]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.

[jira] [Commented] (SOLR-9541) Support configurable authentication mechanism for internode communication

[JIRA]

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

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

Giving a ping on this issue in light of the new security vulnerability 
reported, that existing Solr nodes will accept requests from an attacker who 
pretends to be another Solr node with PKI...

> Support configurable authentication mechanism for internode communication
> -
>
> Key: SOLR-9541
> URL: https://issues.apache.org/jira/browse/SOLR-9541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3, 6.0
>Reporter: Hrishikesh Gadre
>
> SOLR-7849 introduced PKI based authentication mechanism for internode 
> communication. The main reason for introducing SOLR-7849 was,
> >> Relying on every Authentication plugin to secure the internode 
> >> communication is error prone. 
> At Cloudera we are using Kerberos protocol for all communication without any 
> issues (i.e. between client/server as well as server/server). We should make 
> this internode authentication mechanism configurable (with default as PKI 
> based mechanism). This will allow users to decide the appropriate 
> authentication mechanism based on their security requirements.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9790) Thers is a xss issue in schema-browser page of old.html

[JIRA]

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

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

Can we close this, as we plan to remove {{old.html}} in 7.x?

> Thers is a xss issue in schema-browser page of old.html
> ---
>
> Key: SOLR-9790
> URL: https://issues.apache.org/jira/browse/SOLR-9790
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.2.1
>Reporter: liuyang
>Assignee: Alexandre Rafalovitch
>Priority: Minor
>
> In Solr Admin Web UI click "original UI", and then input a url like 
> "https://127.0.0.1:8986/solr/old.html#/testxss_shard1_replica1/schema-browser?field=alert(123456);"
>  to the browser address, you will get alert box with "123456".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-1687) add param for limiting start and rows params

[JIRA]

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

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

I have written a generic {{RequestSanitizerComponent}} that can solve this in a 
generic way, see https://github.com/cominvent/request-sanitizer-component. If 
there is interest, I can prepare it for inclusion.

> add param for limiting start and rows params
> 
>
> Key: SOLR-1687
> URL: https://issues.apache.org/jira/browse/SOLR-1687
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-1687.patch
>
>
> conventional wisdom is that it doesn't make sense to paginate with "huge" 
> pages, or to drill down "deep" into high numbered pages -- features like 
> faceting tend to be a better UI experience, and less intensive on solr.
> At the moment, Sold adminstrators can use "invariant" params to hardcode the 
> "rows" param to something reasonable, but unless they only want to allow 
> users to look at page one, the can't do much to lock down the "start" param 
> expect inforce these rules in the client code
> we should add new params that set an upper bound on both of these, which can 
> then be specified as default/invarient params in solrconfig.xml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3461 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3461/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([EFC78EF80795C88:85DBAB3EC17FF70C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)

[jira] [Commented] (SOLR-10612) make ':toclevels:' work in our jekyll templates

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10612:
--

And then there's also this in the jekyll-asciidoctor gem, which we could just 
use to replace the javascript from the theme: 
https://github.com/asciidoctor/jekyll-asciidoc#generating-a-table-of-contents

I believe that would allow us to set {{:toclevels:}} in individual pages, or 
decide in some cases to put it in a different location (more inline with text, 
or maybe on the right side). But, we'd have to experiment a bit.

> make ':toclevels:' work in our jekyll templates
> ---
>
> Key: SOLR-10612
> URL: https://issues.apache.org/jira/browse/SOLR-10612
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: lang-analysis-1-level-toc.png
>
>
> asciidoc has a concept called {{:toclevels:}} which is suppose to determine 
> which how deep down a page's section/header depth the generated table of 
> contents will show -- ie: some LONG pages have a huge number of level 2 
> headings, and on those pages we only want to show level 1.
> but in jekyll, asciidoctor isn't responsible for generating the TOC -- 
> instead it's done by some javascript (which is better for a variety of 
> reasons) and at the moment this javascript doesn't know anything about 
> {{:toclevels:}}
> But it should be possible to tweak our rendering templates to include 
> {{:toclevels:}} as an attribute in the generated HTML, and then we can tweak 
> the javascript call made to generate the TOC so that it respects it on a 
> per-page basis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10612) make ':toclevels:' work in our jekyll templates

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett updated SOLR-10612:
-
Attachment: lang-analysis-1-level-toc.png

> make ':toclevels:' work in our jekyll templates
> ---
>
> Key: SOLR-10612
> URL: https://issues.apache.org/jira/browse/SOLR-10612
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: lang-analysis-1-level-toc.png
>
>
> asciidoc has a concept called {{:toclevels:}} which is suppose to determine 
> which how deep down a page's section/header depth the generated table of 
> contents will show -- ie: some LONG pages have a huge number of level 2 
> headings, and on those pages we only want to show level 1.
> but in jekyll, asciidoctor isn't responsible for generating the TOC -- 
> instead it's done by some javascript (which is better for a variety of 
> reasons) and at the moment this javascript doesn't know anything about 
> {{:toclevels:}}
> But it should be possible to tweak our rendering templates to include 
> {{:toclevels:}} as an attribute in the generated HTML, and then we can tweak 
> the javascript call made to generate the TOC so that it respects it on a 
> per-page basis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10612) make ':toclevels:' work in our jekyll templates

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10612:
--

I discovered a way we could do this today.

The theme TOC has support already for disabling it on a per-page basis 
({{_layouts/page.html}} has an {{unless page.toc == false}} statement at line 
37). If you add {{:page-toc: false}} to any page, it will not generate the 
table of contents.

The problem is that the asciidoctor syntax for adding a TOC is {{:toc:}}, which 
is page-level so basically interpreted as {{:page-toc:}}, negating the previous 
statement.

If we change the unless statement to something like {{unless page.jstoc == 
false}}, then we can declare the following in the page:

{code}
= Language Analysis
:page-shortname: language-analysis
:page-permalink: language-analysis.html
:page-jstoc: false
:toc: 
:toclevels: 1
{code}

This generates a single-level-deep TOC (see screenshot). It still uses the JS 
template to render it (so, we don't gain back control of where to put the TOC, 
which asciidoctor natively supports several options for, but I suspect this is 
partly a limitation in the jekyll-asciidoctor gem). 

It does not add any TOC to the PDF, because a rule there prevents it.

> make ':toclevels:' work in our jekyll templates
> ---
>
> Key: SOLR-10612
> URL: https://issues.apache.org/jira/browse/SOLR-10612
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: lang-analysis-1-level-toc.png
>
>
> asciidoc has a concept called {{:toclevels:}} which is suppose to determine 
> which how deep down a page's section/header depth the generated table of 
> contents will show -- ie: some LONG pages have a huge number of level 2 
> headings, and on those pages we only want to show level 1.
> but in jekyll, asciidoctor isn't responsible for generating the TOC -- 
> instead it's done by some javascript (which is better for a variety of 
> reasons) and at the moment this javascript doesn't know anything about 
> {{:toclevels:}}
> But it should be possible to tweak our rendering templates to include 
> {{:toclevels:}} as an attribute in the generated HTML, and then we can tweak 
> the javascript call made to generate the TOC so that it respects it on a 
> per-page basis



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3994 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3994/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  org.apache.solr.cloud.DistribCursorPagingTest.test

Error Message:
Failed to list contents of 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/test-files/solr

Stack Trace:
java.io.IOException: Failed to list contents of 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/test-files/solr
at 
__randomizedtesting.SeedInfo.seed([FA6C41DA94C392F2:72387E003A3FFF0A]:0)
at org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1426)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1388)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1268)
at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1237)
at 
org.apache.solr.BaseDistributedSearchTestCase.seedSolrHome(BaseDistributedSearchTestCase.java:1092)
at 
org.apache.solr.BaseDistributedSearchTestCase.setupJettySolrHome(BaseDistributedSearchTestCase.java:1117)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:401)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:335)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:983)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  juni

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_131) - Build # 6551 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6551/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.store.TestFileSwitchDirectory

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001\bar-003:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001\bar-003

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001\bar-003:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001\bar-003
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestFileSwitchDirectory_D2E097B345EB4628-001

at __randomizedtesting.SeedInfo.seed([D2E097B345EB4628]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.asserting.TestAssertingDocValuesFormat

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001\dvduel-012:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001\dvduel-012

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001\dvduel-012:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001\dvduel-012
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingDocValuesFormat_A6E62116453E1D0C-001

at __randomizedtesting.SeedInfo.seed([A6E62116453E1D0C]:0)
at 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10317:
-

[~mkhludnev] and I (mentors) warmly welcome [~viveknarang], whose proposal has 
been selected for GSoC 2017.
Also, many thanks to [~michael.sun] for your kind offer to co-mentor in this 
project. Your help will be valuable in taking this forward.

Vivek, please take this opportunity (the community bonding period) to interact 
with the community using JIRA, mailing lists, IRC (#solr-dev, #lucene-dev, 
#solr, #lucene). Please also take a moment to review & participate in SOLR-2646 
and see how you could leverage the good work Mark is doing there. Your formal 
coding time begins 31 May, but feel free to start early if you want.

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+168) - Build # 19576 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19576/
Java: 32bit/jdk-9-ea+168 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "overlay":{ "znodeVersion":0, 
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1,  from server:  null
at 
__randomizedtesting.SeedInfo.seed([99ADA8D4144B3862:41E08583E3969DC2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.

[jira] [Assigned] (SOLR-10623) Add sql Streaming Expression

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein reassigned SOLR-10623:
-

Assignee: Joel Bernstein

> Add sql Streaming Expression
> 
>
> Key: SOLR-10623
> URL: https://issues.apache.org/jira/browse/SOLR-10623
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> The existing jdbc Streaming Expression is really designed for querying 
> outside SQL engines. 
> The sql expression is designed to talk directly with Solr's parallel SQL 
> interface. 
> This will make it much easier to intermingle SQL queries with other 
> expressions and leverage the new math expressions on top of SQL result sets.
> Sample syntax:
> {code}
> sql(dbcollection, stmt="SELECT ...")
> {code}
> The dbcollection parameter is the distributed front end to the database. Like 
> all parallel SQL queries the stmt can reference any collection in the Zk 
> instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10623) Add sql Streaming Expression

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10623:
--
Description: 
The existing jdbc Streaming Expression is really designed for querying outside 
SQL engines. 

The sql expression is designed to talk directly with Solr's parallel SQL 
interface. 

This will make it much easier to intermingle SQL queries with other expressions 
and leverage the new math expressions on top of SQL result sets.

Sample syntax:

{code}
sql(dbcollection, stmt="SELECT ...")
{code}

The dbcollection is the distributed front end to the database. Like all 
parallel SQL queries the stmt can reference any collection in the Zk instance.




  was:
The existing jdbc Streaming Expression is really designed for querying outside 
SQL engines. 

The sql expression is designed to talk directly with Solr's parallel SQL 
interface. 

This will make it much easier to intermingle SQL queries with other expressions 
and leverage the new math expressions on top of SQL result result sets.

Sample syntax:

{code}
sql(dbcollection, stmt="SELECT ...")
{code}

The dbcollection is the distributed front end to the database. Like all 
parallel SQL queries the stmt can reference any collection in the Zk instance.





> Add sql Streaming Expression
> 
>
> Key: SOLR-10623
> URL: https://issues.apache.org/jira/browse/SOLR-10623
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The existing jdbc Streaming Expression is really designed for querying 
> outside SQL engines. 
> The sql expression is designed to talk directly with Solr's parallel SQL 
> interface. 
> This will make it much easier to intermingle SQL queries with other 
> expressions and leverage the new math expressions on top of SQL result sets.
> Sample syntax:
> {code}
> sql(dbcollection, stmt="SELECT ...")
> {code}
> The dbcollection is the distributed front end to the database. Like all 
> parallel SQL queries the stmt can reference any collection in the Zk instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10623) Add sql Streaming Expression

[Joel Bernstein (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-10623:
--
Description: 
The existing jdbc Streaming Expression is really designed for querying outside 
SQL engines. 

The sql expression is designed to talk directly with Solr's parallel SQL 
interface. 

This will make it much easier to intermingle SQL queries with other expressions 
and leverage the new math expressions on top of SQL result sets.

Sample syntax:

{code}
sql(dbcollection, stmt="SELECT ...")
{code}

The dbcollection parameter is the distributed front end to the database. Like 
all parallel SQL queries the stmt can reference any collection in the Zk 
instance.




  was:
The existing jdbc Streaming Expression is really designed for querying outside 
SQL engines. 

The sql expression is designed to talk directly with Solr's parallel SQL 
interface. 

This will make it much easier to intermingle SQL queries with other expressions 
and leverage the new math expressions on top of SQL result sets.

Sample syntax:

{code}
sql(dbcollection, stmt="SELECT ...")
{code}

The dbcollection is the distributed front end to the database. Like all 
parallel SQL queries the stmt can reference any collection in the Zk instance.





> Add sql Streaming Expression
> 
>
> Key: SOLR-10623
> URL: https://issues.apache.org/jira/browse/SOLR-10623
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The existing jdbc Streaming Expression is really designed for querying 
> outside SQL engines. 
> The sql expression is designed to talk directly with Solr's parallel SQL 
> interface. 
> This will make it much easier to intermingle SQL queries with other 
> expressions and leverage the new math expressions on top of SQL result sets.
> Sample syntax:
> {code}
> sql(dbcollection, stmt="SELECT ...")
> {code}
> The dbcollection parameter is the distributed front end to the database. Like 
> all parallel SQL queries the stmt can reference any collection in the Zk 
> instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10623) Add sql Streaming Expression

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10623:
-

 Summary: Add sql Streaming Expression
 Key: SOLR-10623
 URL: https://issues.apache.org/jira/browse/SOLR-10623
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The existing jdbc Streaming Expression is really designed for querying outside 
SQL engines. 

The sql expression is designed to talk directly with Solr's parallel SQL 
interface. 

This will make it much easier to intermingle SQL queries with other expressions 
and leverage the new math expressions on top of SQL result result sets.

Sample syntax:

{code}
sql(dbcollection, stmt="SELECT ...")
{code}

The dbcollection is the distributed front end to the database. Like all 
parallel SQL queries the stmt can reference any collection in the Zk instance.






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10563) One of the replica is marked as down for only one collection in the cluster

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-10563 at 5/7/17 12:13 PM:
--

Please ask questions to the user mailing list instead of opening a bug ticket. 
See http://lucene.apache.org/solr/community.html#mailing-lists-irc for how to 
sign up for the mailing list.


was (Author: sarkaramr...@gmail.com):
Please ask questions to the user mailing list instead of opening a bug ticket. 
See http://lucene.apache.org/solr/community.html#mailing-lists-irc for how to 
sign up for the mailing list.
Closing as invalid.

> One of the replica is marked as  down for only one collection in the cluster 
> -
>
> Key: SOLR-10563
> URL: https://issues.apache.org/jira/browse/SOLR-10563
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Vijaya Jonnakuti
>
> One of the replica is marked as  down for only one collection in the cluster .
> and only recovers only when REQUESTRECOVERY is invoked..
> Is there any configuration that can automatically do the retry?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10563) One of the replica is marked as down for only one collection in the cluster

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10563:
-

Please ask questions to the user mailing list instead of opening a bug ticket. 
See http://lucene.apache.org/solr/community.html#mailing-lists-irc for how to 
sign up for the mailing list.
Closing as invalid.

> One of the replica is marked as  down for only one collection in the cluster 
> -
>
> Key: SOLR-10563
> URL: https://issues.apache.org/jira/browse/SOLR-10563
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Vijaya Jonnakuti
>
> One of the replica is marked as  down for only one collection in the cluster .
> and only recovers only when REQUESTRECOVERY is invoked..
> Is there any configuration that can automatically do the retry?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 873 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/873/

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at http://127.0.0.1:42032/solr/awhollynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 510HTTP ERROR: 510 Problem 
accessing /solr/awhollynewcollection_0/select. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={"awhollynewcollection_0":6},code=510}
 http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.14.v20161028   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:42032/solr/awhollynewcollection_0: Expected 
mime type application/octet-stream but got text/html. 


Error 510 


HTTP ERROR: 510
Problem accessing /solr/awhollynewcollection_0/select. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={"awhollynewcollection_0":6},code=510}
http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([FD58D75E367F9ADC:B52DA3EA304CB549]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:578)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:447)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:388)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1237)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:522)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
a

[jira] [Resolved] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler resolved LUCENE-5365.
---
Resolution: Fixed

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7818) Suspicious condition

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999794#comment-15999794
 ] 

ASF subversion and git services commented on LUCENE-7818:
-

Commit a46b5fc1b6609b6b7723f328c6150c314e3c0d9c in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a46b5fc ]

LUCENE-5365, LUCENE-7818: Fix incorrect condition in queryparser's 
QueryNodeOperation#logicalAnd()


> Suspicious condition
> 
>
> Key: LUCENE-7818
> URL: https://issues.apache.org/jira/browse/LUCENE-7818
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/queryparser
>Affects Versions: 6.5
>Reporter: AppChecker
>Assignee: Uwe Schindler
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999793#comment-15999793
 ] 

ASF subversion and git services commented on LUCENE-5365:
-

Commit a46b5fc1b6609b6b7723f328c6150c314e3c0d9c in lucene-solr's branch 
refs/heads/branch_6x from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a46b5fc ]

LUCENE-5365, LUCENE-7818: Fix incorrect condition in queryparser's 
QueryNodeOperation#logicalAnd()


> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999791#comment-15999791
 ] 

ASF subversion and git services commented on LUCENE-5365:
-

Commit 0ed39b2774c1c39faf5a6c4cfc9cb68540b16f11 in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0ed39b2 ]

LUCENE-5365, LUCENE-7818: Fix incorrect condition in queryparser's 
QueryNodeOperation#logicalAnd()


> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7818) Suspicious condition

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999792#comment-15999792
 ] 

ASF subversion and git services commented on LUCENE-7818:
-

Commit 0ed39b2774c1c39faf5a6c4cfc9cb68540b16f11 in lucene-solr's branch 
refs/heads/master from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0ed39b2 ]

LUCENE-5365, LUCENE-7818: Fix incorrect condition in queryparser's 
QueryNodeOperation#logicalAnd()


> Suspicious condition
> 
>
> Key: LUCENE-7818
> URL: https://issues.apache.org/jira/browse/LUCENE-7818
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/queryparser
>Affects Versions: 6.5
>Reporter: AppChecker
>Assignee: Uwe Schindler
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999790#comment-15999790
 ] 

Uwe Schindler commented on LUCENE-5365:
---

Hi, I just wondered why the whole thing does not cause a test failure. The 
problem here is that this code is just for "optimization" (it merges nodes, if 
they are AndNodes, otherwise it creates a new AndNode and both childs (this is 
what happens). So in fact this is not a real bug, everything works. IMHO: The 
whole logic should be removed!

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5365:
--
Priority: Minor  (was: Critical)

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5365:
--
Fix Version/s: 6.6
   master (7.0)
   6.x

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Minor
> Fix For: 6.x, master (7.0), 6.6
>
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned LUCENE-5365:
-

Assignee: Uwe Schindler

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Assignee: Uwe Schindler
>Priority: Critical
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999786#comment-15999786
 ] 

Uwe Schindler commented on LUCENE-5365:
---

Hi, this is indeed a bug. I will take care of fixing this. -- Uwe

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Priority: Critical
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

How to secure solr-6.2.0 in standalone mode?

[FOTACHE CHRISTIAN]

Hi
I'm using solr-6.2.0 in standalone and i need to setup security with kerberos 
(???) for standalone
Please help
Thank you,

Christian Fotache Tel: 0728.297.207


On Sun, 5/7/17, Policeman Jenkins Server  wrote:

 Subject: [JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3993 - 
Still Unstable!
 To: dev@lucene.apache.org
 Date: Sunday, May 7, 2017, 9:32 AM
 
 Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3993/
 Java: 64bit/jdk1.8.0
 -XX:-UseCompressedOops -XX:+UseParallelGC
 
 3 tests failed.
 FAILED: 
 
org.apache.solr.cloud.TestCloudDeleteByQuery.testMalformedDBQViaShard1NonLeaderClient
 
 Error Message:
 IOException occured when talking to
 server at: http://127.0.0.1:55904/solr/test_col
 
 Stack Trace:
 org.apache.solr.client.solrj.SolrServerException:
 IOException occured when talking to server at: 
http://127.0.0.1:55904/solr/test_col
     at
 __randomizedtesting.SeedInfo.seed([E8754961B02F2DE5:7D62952CD51C52B2]:0)
     at
 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:641)
     at
 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
     at
 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
     at
 org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
     at
 org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
     at
 
org.apache.solr.cloud.TestCloudDeleteByQuery.testMalformedDBQ(TestCloudDeleteByQuery.java:203)
     at
 
org.apache.solr.cloud.TestCloudDeleteByQuery.testMalformedDBQViaShard1NonLeaderClient(TestCloudDeleteByQuery.java:221)
     at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
     at
 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
     at
 java.lang.reflect.Method.invoke(Method.java:498)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
     at
 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
     at
 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
     at
 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
     at
 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
     at
 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
     at
 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
     at
 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
     at
 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
     at
 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
     at
 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
     at
 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
     at
 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
     at
 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
     at
 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
     at
 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
     at
 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapt

[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-5365:
--
Priority: Critical  (was: Minor)

> Typo with QueryNodeOperation.logicalAnd
> ---
>
> Key: LUCENE-5365
> URL: https://issues.apache.org/jira/browse/LUCENE-5365
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 4.6, 4.7, 6.0
>Reporter: Olivier Binda
>Priority: Critical
> Attachments: typo.patch
>
>   Original Estimate: 1m
>  Remaining Estimate: 1m
>
> Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd
> -> a boolean condition is always false
> Which means that A and B fails when A is not an ANDQueryNode and B is



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (LUCENE-7818) Suspicious condition

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler closed LUCENE-7818.
-
Resolution: Duplicate
  Assignee: Uwe Schindler

I marked this as a duplicate of LUCENE-5365. Issue closed.

> Suspicious condition
> 
>
> Key: LUCENE-7818
> URL: https://issues.apache.org/jira/browse/LUCENE-7818
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/queryparser
>Affects Versions: 6.5
>Reporter: AppChecker
>Assignee: Uwe Schindler
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (LUCENE-7818) Suspicious condition

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999759#comment-15999759
 ] 

Uwe Schindler edited comment on LUCENE-7818 at 5/7/17 11:12 AM:


Already listed: LUCENE-5365


was (Author: sarkaramr...@gmail.com):
Already listed: https://issues.apache.org/jira/browse/LUCENE-5365

> Suspicious condition
> 
>
> Key: LUCENE-7818
> URL: https://issues.apache.org/jira/browse/LUCENE-7818
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/queryparser
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Moved] (LUCENE-7818) Suspicious condition

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler moved SOLR-10621 to LUCENE-7818:
--

Affects Version/s: (was: 6.5)
   6.5
 Security: (was: Public)
  Component/s: (was: query parsers)
   modules/queryparser
Lucene Fields: New
  Key: LUCENE-7818  (was: SOLR-10621)
  Project: Lucene - Core  (was: Solr)

> Suspicious condition
> 
>
> Key: LUCENE-7818
> URL: https://issues.apache.org/jira/browse/LUCENE-7818
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/queryparser
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19575 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19575/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([AC98AD25AEBFE39:81EE59031BED55BD]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:861)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:442)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)

[jira] [Commented] (SOLR-10615) latch SolrDispatchFilter.doFilter() on init() completion

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10615:
-

Although, I'm open for concerns about UnavailableException. 

> latch SolrDispatchFilter.doFilter() on init() completion
> 
>
> Key: SOLR-10615
> URL: https://issues.apache.org/jira/browse/SOLR-10615
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10615.patch
>
>
> The motivation is in SOLR-10611, the earlier discussion and review is done in 
> enclosing ticket SOLR-9867. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10611) TestLeaderElectionWithEmptyReplica failure on jenkins

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev resolved SOLR-10611.
-
   Resolution: Fixed
Fix Version/s: 6.6

Fixed under SOLR-10615

> TestLeaderElectionWithEmptyReplica failure on jenkins
> -
>
> Key: SOLR-10611
> URL: https://issues.apache.org/jira/browse/SOLR-10611
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.6, master (7.0)
>
> Attachments: consoleText.txt, SOLR-10611.patch, SOLR-10611.patch
>
>
> See https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/875/
> {code}
> FAILED:  org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.test
> Error Message:
> Shard shard1 replicas do not have same number of documents expected:<10> but 
> was:<0>
> Stack Trace:
> java.lang.AssertionError: Shard shard1 replicas do not have same number of 
> documents expected:<10> but was:<0>
> at 
> __randomizedtesting.SeedInfo.seed([2093B412EF46AACD:A8C78BC841BAC735]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at 
> org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.assertConsistentReplicas(TestLeaderElectionWithEmptyReplica.java:119)
> at 
> org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.test(TestLeaderElectionWithEmptyReplica.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-10594:
-

Hm. It breaks cloud config update. Stay tuned

> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch, 
> SOLR-10594.patch
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency 
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design 
> it better. And it's also worth to think about overall flow: core reload is 
> triggered by Zk listener and SolrConfigHandler see SOLR-10588



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1289 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1289/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([3D6B646D6CEAD5A4:751E10D96AD9FA31]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:530)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12160 lines...]
   [junit4] Suite: org.apache.solr.clou

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 343 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/343/

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:54905/sf: Error CREATEing SolrCore 
'test_unload_shard_and_collection_1': Unable to create core 
[test_unload_shard_and_collection_1] Caused by: Direct buffer memory

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54905/sf: Error CREATEing SolrCore 
'test_unload_shard_and_collection_1': Unable to create core 
[test_unload_shard_and_collection_1] Caused by: Direct buffer memory
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.testUnloadShardAndCollection(UnloadDistributedZkTest.java:125)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(Te

[jira] [Commented] (SOLR-10621) Suspicious condition

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10621:
-

Already listed: https://issues.apache.org/jira/browse/LUCENE-5365

> Suspicious condition
> 
>
> Key: SOLR-10621
> URL: https://issues.apache.org/jira/browse/SOLR-10621
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10621) Suspicious condition

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10621:
-

Seems like _QueryNodeOperation.java_ is never referred and used anywhere.

> Suspicious condition
> 
>
> Key: SOLR-10621
> URL: https://issues.apache.org/jira/browse/SOLR-10621
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10621) Suspicious condition

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10621:
-

BTW this is part of LUCENE than SOLR, it should be reported in Lucene project.

> Suspicious condition
> 
>
> Key: SOLR-10621
> URL: https://issues.apache.org/jira/browse/SOLR-10621
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10621) Suspicious condition

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10621:
-

That's a legit code bug, wonder how it was not reported till now.

> Suspicious condition
> 
>
> Key: SOLR-10621
> URL: https://issues.apache.org/jira/browse/SOLR-10621
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5
>Reporter: AppChecker
>  Labels: static-analysis
>
> Hi
> Please, look this [code 
> fragment:|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/core/util/QueryNodeOperation.java#L57-L60]
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> (q1 instanceof AndQueryNode) is checked twice.
> Probably it should be:
> {code}
> else if (q1 instanceof AndQueryNode)
>   op = ANDOperation.Q1;
> else if (q2 instanceof AndQueryNode)
>   op = ANDOperation.Q2;
> {code}
> This possible defect found by 
> [AppChecker|https://npo-echelon.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10619) When DQ.knowChildren is not empty, DQ should not refetch node children in case of single consumer

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar edited comment on SOLR-10619 at 5/7/17 8:00 AM:
--

I read the code again and yeah my understanding was wrong. The watcher is set 
on each fetch from zk which either happens because we are in a dirty state or 
when we run out of items in the knownChildren so we end up having a watcher all 
the time. The docs in the implementation notes are also wrong.

I'll lean towards the option that keeps things simple for the use-case we need 
this queue for -- which is the overseer. There's no harm in explicitly 
marking/documenting DistributedQueue as a single-consumer queue.

If the overseer sees a node disappear from ZK it is either because someone 
mucked around with ZK manually or a new overseer has been elected and the old 
overseer hasn't realised that yet. In such a case, it might be worth to add a 
callback which the overseer can use to check if it is still the leader. The 
result of this callback can be used to abort further calls to ZK.

Wow, I'm glad Dat caught this! Thanks Dat!


was (Author: shalinmangar):
I read the code again and yeah my understanding was wrong. The watcher is set 
on each fetch from zk which either happens because we are in a dirty state or 
when we run out of items in the knownChildren so we ends up having a watcher 
all the time. The docs in the implementation notes are also wrong.

I'll lean towards the option that keeps things simple for the use-case we need 
this queue for -- which is the overseer. There's no harm in explicitly 
marking/documenting DistributedQueue as a single-consumer queue.

If the overseer sees a node disappear from ZK it is either because someone 
mucked around with ZK manually or the overseer has changed and the currently 
executing overseer hasn't realised that yet. In such a case, it might be worth 
to add a callback which the overseer can use to check if it is still the 
leader. The result of this callback can be used to abort further calls to ZK.

Wow, I'm glad Dat caught this! Thanks Dat!

> When DQ.knowChildren is not empty, DQ should not refetch node children in 
> case of single consumer
> -
>
> Key: SOLR-10619
> URL: https://issues.apache.org/jira/browse/SOLR-10619
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Attachments: SOLR-10619.patch, SOLR-10619.patch
>
>
> Right now, for every time childWatcher is kicked off. We refetch all children 
> of DQ's node. It is a wasted in case of single consumer.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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