[jira] [Commented] (SOLR-7123) /update/json/docs should have nested document support

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7123:
--

There are 2 problems with the first command

1) There is no param called {{child.split}} anymore. So your "split" param 
should be {{split=split=/|/children|/children/grandchildren}}
2) The command line changes {{$FQN}} to an empty string because there is no 
environment variable called {{FQN}}. So escape that as {{f=\$FQN:/**}}

> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: EaseOfUse
> Fix For: 6.1, master (7.0)
>
> Attachments: NestedDocumentMapper.java, SOLR-7123-test.patch, 
> SOLR-7123.patch, SOLR-7123.patch
>
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested 
> document, 
> {code}
> {
> name: 'Joe Smith',
> phone: 876876687 ,
> orgs :[ {name : Microsoft,
>   city: "Seattle,
>   zip: 98052},
> {name: Apple,
>  city : Cupertino,
>  zip :95014 }
>   ]
> } 
> {code}
> The extra mapping parameters would be
> {noformat}
> split=/|/orgs&
> f=name:/orgs/name&
> f=city:/orgs/city&
> f=zip:/orgs/zip
> {noformat}
> * The objects at {{/org}} automatically becomes a child document because 
> {{/org}} is a child path of{{/}} 
> * All fields falling under the {{/orgs/}} will be mapped to the child document
> alternately you can just do
> {noformat}
> split=/|/orgs=$FQN:/**
> {noformat}
> The fully qualified name (FQN) for chiild docs begin from {{/org}}. So the 
> output would be
> {noformat}
> {
>   "name":"Joe Smith",
>   "phone":876876687,
>   "_childDocuments_":[
> {
>   "name":"Microsoft",
>   "city":"Seattle",
>   "zip":98052},
> {
>   "name":"Apple",
>   "city":"Cupertino",
>   "zip":95014}]}
> {noformat}



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

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

[jira] [Comment Edited] (SOLR-7123) /update/json/docs should have nested document support

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-7123 at 6/9/16 5:59 AM:
--

There are 2 problems with the first command

1) There is no param called {{child.split}} anymore. So your "split" param 
should be {{split=/|/children|/children/grandchildren}}
2) The command line changes {{$FQN}} to an empty string because there is no 
environment variable called {{FQN}}. So escape that as {{f=\$FQN:/**}}


was (Author: noble.paul):
There are 2 problems with the first command

1) There is no param called {{child.split}} anymore. So your "split" param 
should be {{split=split=/|/children|/children/grandchildren}}
2) The command line changes {{$FQN}} to an empty string because there is no 
environment variable called {{FQN}}. So escape that as {{f=\$FQN:/**}}

> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: EaseOfUse
> Fix For: 6.1, master (7.0)
>
> Attachments: NestedDocumentMapper.java, SOLR-7123-test.patch, 
> SOLR-7123.patch, SOLR-7123.patch
>
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested 
> document, 
> {code}
> {
> name: 'Joe Smith',
> phone: 876876687 ,
> orgs :[ {name : Microsoft,
>   city: "Seattle,
>   zip: 98052},
> {name: Apple,
>  city : Cupertino,
>  zip :95014 }
>   ]
> } 
> {code}
> The extra mapping parameters would be
> {noformat}
> split=/|/orgs&
> f=name:/orgs/name&
> f=city:/orgs/city&
> f=zip:/orgs/zip
> {noformat}
> * The objects at {{/org}} automatically becomes a child document because 
> {{/org}} is a child path of{{/}} 
> * All fields falling under the {{/orgs/}} will be mapped to the child document
> alternately you can just do
> {noformat}
> split=/|/orgs=$FQN:/**
> {noformat}
> The fully qualified name (FQN) for chiild docs begin from {{/org}}. So the 
> output would be
> {noformat}
> {
>   "name":"Joe Smith",
>   "phone":876876687,
>   "_childDocuments_":[
> {
>   "name":"Microsoft",
>   "city":"Seattle",
>   "zip":98052},
> {
>   "name":"Apple",
>   "city":"Cupertino",
>   "zip":95014}]}
> {noformat}



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9191:


FYI the ASF git/jira commit bot sends updates to all JIRA issues referenced by 
commits occurring on this branch (e.g. SOLR-8859) even though it has nothing to 
do with this issue.  I got the ASF to add a filter for branches following the 
pattern {{(lucene|solr).*}} (case sensitive) as that was the most common branch 
naming pattern.  Please next time make a branch named like solr9199 and then 
this won't happen.  I could ask for case insensitive but I figured it would be 
nice to encourage more branch naming consistency.

> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9191:
--

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/41


> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[GitHub] lucene-solr pull request #41: SOLR-9191: OverseerTaskQueue.peekTopN() fatall...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/lucene-solr/pull/41


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7313) Remove DocValuesDocIdSet

[ASF subversion and git services (JIRA)]

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

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

Commit 73045a4cd8ea5f0c8c4f418b6fbe99a94a21cf4a in lucene-solr's branch 
refs/heads/SOLR-9191 from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73045a4 ]

LUCENE-7313: Remove DocValuesDocIdSet.


> Remove DocValuesDocIdSet
> 
>
> Key: LUCENE-7313
> URL: https://issues.apache.org/jira/browse/LUCENE-7313
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0)
>
>
> This class is unused since we migrated the doc values filters to queries with 
> two-phase iteration.



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-9191:
--

I went ahead and committed to master to unblock [~noble.paul].

> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Commented] (SOLR-8859) AbstractSpatialFieldType can use ShapeContext to read/write shapes (WKT, GeoJSON)

[ASF subversion and git services (JIRA)]

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

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

Commit fb37b3eb8c4130c8b5f53e1741e9585743b26e4d in lucene-solr's branch 
refs/heads/SOLR-9191 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb37b3e ]

SOLR-8859: Fix AbstractSpatialFieldType to not cycle through all Spatial4j 
provided formats.
And Fix RptWithGeometrySpatialField to be less brittle on init()


> AbstractSpatialFieldType can use ShapeContext to read/write shapes (WKT, 
> GeoJSON)
> -
>
> Key: SOLR-8859
> URL: https://issues.apache.org/jira/browse/SOLR-8859
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Blocker
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8859.patch, SOLR-8859_part2.patch
>
>
> Right now the AbstractSpatialFieldType throws exceptions if it needs to 
> convert to/from a string.  We should use the context to convert



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[ASF subversion and git services (JIRA)]

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

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

Commit ed2621de8402154440e3e1e1979eb620bd23b926 in lucene-solr's branch 
refs/heads/SOLR-9191 from [~dragonsinth]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ed2621d ]

SOLR-9191: OverseerTaskQueue.peekTopN() fatally flawed


> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Commented] (SOLR-9198) config APIs is unable to add multiple values with same name

[ASF subversion and git services (JIRA)]

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

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

Commit be011097445cb558d5ebf014e8f0e23085fbaec5 in lucene-solr's branch 
refs/heads/SOLR-9191 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be01109 ]

SOLR-9198: config APIs unable to add multiple values with same name


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1, 5.5.2
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[ASF subversion and git services (JIRA)]

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

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

Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch 
refs/heads/SOLR-9191 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ]

SOLR-9107: When creating a randomized SSL test config, 100% effective odds of 
using SSL and/or client auth should never be trumped by chance.


> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9191: OverseerTaskQueue.peekTopN() fatally flawed


> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Commented] (SOLR-7123) /update/json/docs should have nested document support

[ASF subversion and git services (JIRA)]

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

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

Commit 66cd0edc52a35fa43182a57c1f3dbfb420334f1e in lucene-solr's branch 
refs/heads/SOLR-9191 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66cd0ed ]

SOLR-7123: Syntax modified. Multiple paths can be added in the split parameter 
itself (pipe separated)


> /update/json/docs should have nested document support
> -
>
> Key: SOLR-7123
> URL: https://issues.apache.org/jira/browse/SOLR-7123
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: EaseOfUse
> Fix For: 6.1, master (7.0)
>
> Attachments: NestedDocumentMapper.java, SOLR-7123-test.patch, 
> SOLR-7123.patch, SOLR-7123.patch
>
>
> It is the next logical step after SOLR-6304
> For the example document given below where the /orgs belong to a nested 
> document, 
> {code}
> {
> name: 'Joe Smith',
> phone: 876876687 ,
> orgs :[ {name : Microsoft,
>   city: "Seattle,
>   zip: 98052},
> {name: Apple,
>  city : Cupertino,
>  zip :95014 }
>   ]
> } 
> {code}
> The extra mapping parameters would be
> {noformat}
> split=/|/orgs&
> f=name:/orgs/name&
> f=city:/orgs/city&
> f=zip:/orgs/zip
> {noformat}
> * The objects at {{/org}} automatically becomes a child document because 
> {{/org}} is a child path of{{/}} 
> * All fields falling under the {{/orgs/}} will be mapped to the child document
> alternately you can just do
> {noformat}
> split=/|/orgs=$FQN:/**
> {noformat}
> The fully qualified name (FQN) for chiild docs begin from {{/org}}. So the 
> output would be
> {noformat}
> {
>   "name":"Joe Smith",
>   "phone":876876687,
>   "_childDocuments_":[
> {
>   "name":"Microsoft",
>   "city":"Seattle",
>   "zip":98052},
> {
>   "name":"Apple",
>   "city":"Cupertino",
>   "zip":95014}]}
> {noformat}



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

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

[jira] [Updated] (SOLR-9198) config APIs is unable to add multiple values with same name

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Fix Version/s: 5.5.2

> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1, 5.5.2
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Commented] (SOLR-9198) config APIs is unable to add multiple values with same name

[ASF subversion and git services (JIRA)]

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

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

Commit 9c4bad9188d86a8503a1816709933f4807b88f36 in lucene-solr's branch 
refs/heads/branch_5_5 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9c4bad9 ]

SOLR-9198: config APIs unable to add multiple values with same name


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Commented] (LUCENE-7321) Character Mapping

[Ivan Provalov (JIRA)]

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

Ivan Provalov commented on LUCENE-7321:
---

Koji, this one works on a token level, allowing do things like prefix/suffix 
manipulations.  Graph generator and collapser also makes it user friendly when 
dealing with a lot of mappings (please see the attached description file).

> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 6.0, 5.4.1, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
> for Japanese.  In the appendix, I give an example of implementing a Russian 
> light weight stemmer using this component.



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

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

[jira] [Commented] (LUCENE-7321) Character Mapping

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi commented on LUCENE-7321:


What is the advantage of this compared to MappingCharFilter?

> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 6.0, 5.4.1, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
> for Japanese.  In the appendix, I give an example of implementing a Russian 
> light weight stemmer using this component.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+121) - Build # 859 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/859/
Java: 32bit/jdk-9-ea+121 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.update.PeerSyncTest.test

Error Message:
.response[1][id][0]:2!=3

Stack Trace:
junit.framework.AssertionFailedError: .response[1][id][0]:2!=3
at 
__randomizedtesting.SeedInfo.seed([DDABDEB991044B60:55FFE1633FF82698]:0)
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:920)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:939)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryAndCompare(BaseDistributedSearchTestCase.java:657)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryAndCompare(BaseDistributedSearchTestCase.java:648)
at org.apache.solr.update.PeerSyncTest.test(PeerSyncTest.java:97)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Created] (SOLR-9200) Add Delegation Token Support to Solr

[Gregory Chanan (JIRA)]

Gregory Chanan created SOLR-9200:


 Summary: Add Delegation Token Support to Solr
 Key: SOLR-9200
 URL: https://issues.apache.org/jira/browse/SOLR-9200
 Project: Solr
  Issue Type: New Feature
  Components: security
Reporter: Gregory Chanan
Assignee: Gregory Chanan


SOLR-7468 added support for kerberos authentication via the hadoop 
authentication filter.  Hadoop also has support for an authentication filter 
that supports delegation tokens, which allow authenticated users the ability to 
grab/renew/delete a token that can be used to bypass the normal authentication 
path for a time.  This is useful in a variety of use cases:
1) distributed clients (e.g. MapReduce) where each client may not have access 
to the user's kerberos credentials.  Instead, the job runner can grab a 
delegation token and use that during task execution.
2) If the load on the kerberos server is too high, delegation tokens can avoid 
hitting the kerberos server after the first request
3) If requests/permissions need to be delegated to another user: the more 
privileged user can request a delegation token that can be passed to the less 
privileged user.

Note to self:
In 
https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
 I made the following comment which I need to investigate further, since I 
don't know if anything changed in this area:
{quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
moving forward (I understand this is more a generic auth question than kerberos 
specific). For example, in the latest version of the filter we are using at 
Cloudera, we play around with the ServletContext in order to pass information 
around 
(https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
 Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16951 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16951/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.RecoveryZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=1548, 
name=StoppableIndexingThread, state=RUNNABLE, group=TGRP-RecoveryZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1548, name=StoppableIndexingThread, 
state=RUNNABLE, group=TGRP-RecoveryZkTest]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([E483A65CABC70E3E]:0)
at java.util.HashMap$KeySet.iterator(HashMap.java:916)
at java.util.HashSet.iterator(HashSet.java:172)
at 
sun.security.util.AbstractAlgorithmConstraints.checkAlgorithm(AbstractAlgorithmConstraints.java:108)
at 
sun.security.util.DisabledAlgorithmConstraints.permits(DisabledAlgorithmConstraints.java:91)
at 
sun.security.ssl.SSLAlgorithmConstraints.permits(SSLAlgorithmConstraints.java:144)
at 
sun.security.ssl.Handshaker.getActiveCipherSuites(Handshaker.java:642)
at sun.security.ssl.Handshaker.activate(Handshaker.java:509)
at 
sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482)
at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.StoppableIndexingThread.indexDocs(StoppableIndexingThread.java:176)
at 
org.apache.solr.cloud.StoppableIndexingThread.run(StoppableIndexingThread.java:115)




Build Log:
[...truncated 10801 lines...]
   [junit4] Suite: org.apache.solr.cloud.RecoveryZkTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.RecoveryZkTest_E483A65CABC70E3E-001/init-core-data-001
   [junit4]   2> 251816 INFO  
(SUITE-RecoveryZkTest-seed#[E483A65CABC70E3E]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 251817 INFO  
(SUITE-RecoveryZkTest-seed#[E483A65CABC70E3E]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /v/
   [junit4]   2> 251819 INFO  
(TEST-RecoveryZkTest.test-seed#[E483A65CABC70E3E]) [] o.a.s.c.ZkTestServer 
STARTING ZK TEST SERVER
   [junit4]   2> 251819 INFO  (Thread-460) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 251819 INFO  (Thread-460) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 251919 INFO  
(TEST-RecoveryZkTest.test-seed#[E483A65CABC70E3E]) [] o.a.s.c.ZkTestServer 
start zk server on port:34273
   [junit4]   2> 251919 INFO  
(TEST-RecoveryZkTest.test-seed#[E483A65CABC70E3E]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 251919 INFO  
(TEST-RecoveryZkTest.test-seed#[E483A65CABC70E3E]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 251922 INFO  

[jira] [Commented] (SOLR-9199) ZkController#publishAndWaitForDownStates logic is inefficient

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-9199:
--

lgtm.  Could maybe quibble that the old code wouldn't print "timing out" if it 
never entered the loop (e.g. if wait time was 0), but that doesn't seem right 
or wrong.

I'll commit to trunk and 6.x assuming the precommit and tests pass.

> ZkController#publishAndWaitForDownStates logic is inefficient
> -
>
> Key: SOLR-9199
> URL: https://issues.apache.org/jira/browse/SOLR-9199
> Project: Solr
>  Issue Type: Bug
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
> Attachments: SOLR-9199.patch
>
>
> The following logic introduced as part of SOLR-8720 is inefficient. 
> https://github.com/apache/lucene-solr/blob/6c0331b8309603eaaf14b6677afba5ffe99f16a3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L687-L712
> Specifically,
> * foundStates flag is set to TRUE before the for loop.
> * In the for loop we check if any replica on this node is not in the DOWN 
> state. If yes, then foundStates = FALSE
> * If foundStates == TRUE then we break out of the loop and return.
> The problem here is that once foundStates is set to FALSE, it is never reset 
> to TRUE. Hence we end up spending the whole 60 secs iterating over the 
> collections even though all the replicas are marked as DOWN in later 
> iterations.



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

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

[jira] [Commented] (SOLR-9038) Ability to create/delete/list snapshots for a solr collection

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9038:


For clarification, do you mean you wonder why committing is distinct from doing 
a backup?  Well I guess that adds flexibility -- you might not want to incur 
opening of searchers just to do a regular backup.  I suppose then perhaps 
someone likewise might want to do a snapshot without a commit using the same 
rationale?  Although if snapshots are implemented using Lucene commit metadata 
(which sounds ideal to me), then we have to issue a commit but it could be done 
without opening a searcher.  In that case it may or may not accompany an 
explicit commit.

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9038
> URL: https://issues.apache.org/jira/browse/SOLR-9038
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>
> Currently work is under-way to implement backup/restore API for Solr cloud 
> (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files 
> and collection metadata to a configurable location. 
> In addition to this, we should also provide a facility to create "named" 
> snapshots for Solr collection. Here by "snapshot" I mean configuring the 
> underlying Lucene IndexDeletionPolicy to not delete a specific commit point 
> (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be 
> confused with SOLR-5340 which implements core level "backup" functionality.
> The primary motivation of this feature is to decouple recording/preserving a 
> known consistent state of a collection from actually "copying" the relevant 
> files to a physically separate location. This decoupling have number of 
> advantages
> - We can use specialized data-copying tools for transferring Solr index 
> files. e.g. in Hadoop environment, typically 
> [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to 
> copy files from one location to other. This tool provides various options to 
> configure degree of parallelism, bandwidth usage as well as integration with 
> different types and versions of file systems (e.g. AWS S3, Azure Blob store 
> etc.)
> - This separation of concern would also help Solr to focus on the key 
> functionality (i.e. querying and indexing) while delegating the copy 
> operation to the tools built for that purpose.
> - Users can decide if/when to copy the data files as against creating a 
> snapshot. e.g. a user may want to create a snapshot of a collection before 
> making an experimental change (e.g. updating/deleting docs, schema change 
> etc.). If the experiment is successful, he can delete the snapshot (without 
> having to copy the files). If the experiment is failed, then he can copy the 
> files associated with the snapshot and restore.
> Note that Apache Blur project is also providing a similar feature 
> [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132]



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

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

[jira] [Commented] (SOLR-9038) Ability to create/delete/list snapshots for a solr collection

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9038:


[~dsmiley] Thanks for the feedback.

The reason why I brought this up to make sure that this feature works nicely 
with the existing functionality (and requirements). The good point about 
integrating snapshot creation with commit work-flow is that the snapshot would 
always have the *latest* committed index state. 

Reviewing the current backup implementation, it looks like the backup logic 
does *not* commit anything. It just copies the *latest* commit to the backup 
directory. Obviously user can manually issue a *hard commit* before invoking 
backup operation or let the backup be created with the latest auto hard 
committed data. From Solr perspective these two are distinct operations. I 
wonder if there is a specific reason for this? 

> Ability to create/delete/list snapshots for a solr collection
> -
>
> Key: SOLR-9038
> URL: https://issues.apache.org/jira/browse/SOLR-9038
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>
> Currently work is under-way to implement backup/restore API for Solr cloud 
> (SOLR-5750). SOLR-5750 is about providing an ability to "copy" index files 
> and collection metadata to a configurable location. 
> In addition to this, we should also provide a facility to create "named" 
> snapshots for Solr collection. Here by "snapshot" I mean configuring the 
> underlying Lucene IndexDeletionPolicy to not delete a specific commit point 
> (e.g. using PersistentSnapshotIndexDeletionPolicy). This should not be 
> confused with SOLR-5340 which implements core level "backup" functionality.
> The primary motivation of this feature is to decouple recording/preserving a 
> known consistent state of a collection from actually "copying" the relevant 
> files to a physically separate location. This decoupling have number of 
> advantages
> - We can use specialized data-copying tools for transferring Solr index 
> files. e.g. in Hadoop environment, typically 
> [distcp|https://hadoop.apache.org/docs/r1.2.1/distcp2.html] tool is used to 
> copy files from one location to other. This tool provides various options to 
> configure degree of parallelism, bandwidth usage as well as integration with 
> different types and versions of file systems (e.g. AWS S3, Azure Blob store 
> etc.)
> - This separation of concern would also help Solr to focus on the key 
> functionality (i.e. querying and indexing) while delegating the copy 
> operation to the tools built for that purpose.
> - Users can decide if/when to copy the data files as against creating a 
> snapshot. e.g. a user may want to create a snapshot of a collection before 
> making an experimental change (e.g. updating/deleting docs, schema change 
> etc.). If the experiment is successful, he can delete the snapshot (without 
> having to copy the files). If the experiment is failed, then he can copy the 
> files associated with the snapshot and restore.
> Note that Apache Blur project is also providing a similar feature 
> [BLUR-132|https://issues.apache.org/jira/browse/BLUR-132]



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

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

Re: Lucene/Solr 6.1.0

[Steve Rowe]

Hi Adrien,

I remembered that I never fixed up the CHANGES.txt files on master and 
branch_6x after the 6.0.1 release to move the 6.0.1 changes out of the 6.1.0 
section into the 6.0.1 section, so I went and did that, and backported to 
branch_6_1.

I set up the ASF Jenkins jobs for 6.1 according to 
. 

I also set up the Policeman Jenkins jobs for 6.1 by cloning the 6.0 Linux and 
Windows jobs[1], switching to */branch_6_1, enabling them, then triggering them 
as post-build actions from the corresponding master jobs.  Uwe, apologies if I 
screwed this up :) - please fix if so!

[1] I didn’t set up OSX and Solaris jobs because I didn’t see those for the 5.5 
and 6.0 jobs.

--
Steve
www.lucidworks.com

> On Jun 8, 2016, at 8:38 AM, Adrien Grand  wrote:
> 
> 
> I just created the 6.1.0 branch. Can someone help me with setting up Apache 
> and Policeman Jenkins to test this branch?
> 
> I still plan on cutting a first RC on Friday (in two days), please let me 
> know if you know about issues that should be included in 6.1.0.


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

[jira] [Commented] (SOLR-9199) ZkController#publishAndWaitForDownStates logic is inefficient

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-9199:
--

LGTM

> ZkController#publishAndWaitForDownStates logic is inefficient
> -
>
> Key: SOLR-9199
> URL: https://issues.apache.org/jira/browse/SOLR-9199
> Project: Solr
>  Issue Type: Bug
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
> Attachments: SOLR-9199.patch
>
>
> The following logic introduced as part of SOLR-8720 is inefficient. 
> https://github.com/apache/lucene-solr/blob/6c0331b8309603eaaf14b6677afba5ffe99f16a3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L687-L712
> Specifically,
> * foundStates flag is set to TRUE before the for loop.
> * In the for loop we check if any replica on this node is not in the DOWN 
> state. If yes, then foundStates = FALSE
> * If foundStates == TRUE then we break out of the loop and return.
> The problem here is that once foundStates is set to FALSE, it is never reset 
> to TRUE. Hence we end up spending the whole 60 secs iterating over the 
> collections even though all the replicas are marked as DOWN in later 
> iterations.



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1205 - Failure

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior

Error Message:
Illegal state, was: down expected:active clusterState:live 
nodes:[]collections:{c1=DocCollection(c1)={   "shards":{"shard1":{   
"parent":null,   "range":null,   "state":"active",   
"replicas":{"core_node1":{   "base_url":"http://127.0.0.1/solr;,
   "node_name":"node1",   "core":"core1",   "roles":"", 
  "state":"down",   "router":{"name":"implicit"}}, 
test=LazyCollectionRef(test)}

Stack Trace:
java.lang.AssertionError: Illegal state, was: down expected:active 
clusterState:live nodes:[]collections:{c1=DocCollection(c1)={
  "shards":{"shard1":{
  "parent":null,
  "range":null,
  "state":"active",
  "replicas":{"core_node1":{
  "base_url":"http://127.0.0.1/solr;,
  "node_name":"node1",
  "core":"core1",
  "roles":"",
  "state":"down",
  "router":{"name":"implicit"}}, test=LazyCollectionRef(test)}
at 
__randomizedtesting.SeedInfo.seed([CB2577E0AE83409E:A33B740C4C131AD0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.verifyReplicaStatus(AbstractDistribZkTestBase.java:243)
at 
org.apache.solr.cloud.OverseerTest.testExternalClusterStateChangeBehavior(OverseerTest.java:1273)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9199) ZkController#publishAndWaitForDownStates logic is inefficient

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre updated SOLR-9199:
---
Attachment: SOLR-9199.patch

Please find the attached patch.

> ZkController#publishAndWaitForDownStates logic is inefficient
> -
>
> Key: SOLR-9199
> URL: https://issues.apache.org/jira/browse/SOLR-9199
> Project: Solr
>  Issue Type: Bug
>Reporter: Hrishikesh Gadre
>Assignee: Hrishikesh Gadre
> Attachments: SOLR-9199.patch
>
>
> The following logic introduced as part of SOLR-8720 is inefficient. 
> https://github.com/apache/lucene-solr/blob/6c0331b8309603eaaf14b6677afba5ffe99f16a3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L687-L712
> Specifically,
> * foundStates flag is set to TRUE before the for loop.
> * In the for loop we check if any replica on this node is not in the DOWN 
> state. If yes, then foundStates = FALSE
> * If foundStates == TRUE then we break out of the loop and return.
> The problem here is that once foundStates is set to FALSE, it is never reset 
> to TRUE. Hence we end up spending the whole 60 secs iterating over the 
> collections even though all the replicas are marked as DOWN in later 
> iterations.



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

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

[jira] [Updated] (LUCENE-7323) Compound file writing should verify checksum of its sub-files

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7323:
---
Attachment: LUCENE-7323.patch

Patch, I think it's close.  It fixes our default
Lucene50CompoundFileFormat to verify the checksum of its sub-files
when writing.

I also had to close up external access to SimpleText's doc values and
postings format, i.e., you must use them only via SimpleTextCodec,
because these files (intentionally) don't write codec headers and
footers so you can't put them into a "normal" CFS file (SimpleText has
its own CFS that doesn't verify checksums).

I also made {{CodecUtil.read/writeCRC}} package private: do they
really need to be public?


> Compound file writing should verify checksum of its sub-files
> -
>
> Key: LUCENE-7323
> URL: https://issues.apache.org/jira/browse/LUCENE-7323
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7323.patch
>
>
> For larger segments, there is a non-trivial window, from when IW
> writes sub-files, to when it then builds the CFS, during which the
> files can become corrupted (from external process, bad filesystem,
> hardware, etc.)
> Today we quietly build the CFS even if the sub-files are corrupted,
> but we can easily detect it, letting users catch corruption earlier
> (write time instead of read time).



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

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

[jira] [Created] (LUCENE-7323) Compound file writing should verify checksum of its sub-files

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7323:
--

 Summary: Compound file writing should verify checksum of its 
sub-files
 Key: LUCENE-7323
 URL: https://issues.apache.org/jira/browse/LUCENE-7323
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: master (7.0), 6.2


For larger segments, there is a non-trivial window, from when IW
writes sub-files, to when it then builds the CFS, during which the
files can become corrupted (from external process, bad filesystem,
hardware, etc.)

Today we quietly build the CFS even if the sub-files are corrupted,
but we can easily detect it, letting users catch corruption earlier
(write time instead of read time).




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

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

[jira] [Updated] (SOLR-9181) ZkStateReaderTest failure

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9181:

Attachment: SOLR-9181.patch

Here's an attempt to clean this up a bit.  Notifications are now fired from 
constructState(), which takes a map of changed collections.  This should ensure 
that a) we always take into account what has changed, and b) we fire 
notifications on every state updated.  Tests pass under beasting.

> ZkStateReaderTest failure
> -
>
> Key: SOLR-9181
> URL: https://issues.apache.org/jira/browse/SOLR-9181
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-9181.patch, SOLR-9181.patch, SOLR-9181.patch, 
> SOLR-9181.patch
>
>
> https://builds.apache.org/job/Lucene-Solr-Tests-6.x/243/



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

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

[jira] [Created] (SOLR-9199) ZkController#publishAndWaitForDownStates logic is inefficient

[Hrishikesh Gadre (JIRA)]

Hrishikesh Gadre created SOLR-9199:
--

 Summary: ZkController#publishAndWaitForDownStates logic is 
inefficient
 Key: SOLR-9199
 URL: https://issues.apache.org/jira/browse/SOLR-9199
 Project: Solr
  Issue Type: Bug
Reporter: Hrishikesh Gadre
Assignee: Hrishikesh Gadre


The following logic introduced as part of SOLR-8720 is inefficient. 

https://github.com/apache/lucene-solr/blob/6c0331b8309603eaaf14b6677afba5ffe99f16a3/solr/core/src/java/org/apache/solr/cloud/ZkController.java#L687-L712

Specifically,

* foundStates flag is set to TRUE before the for loop.
* In the for loop we check if any replica on this node is not in the DOWN 
state. If yes, then foundStates = FALSE
* If foundStates == TRUE then we break out of the loop and return.

The problem here is that once foundStates is set to FALSE, it is never reset to 
TRUE. Hence we end up spending the whole 60 secs iterating over the collections 
even though all the replicas are marked as DOWN in later iterations.




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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16949 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16949/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient

Error Message:
https://127.0.0.1:42789/solr/test_col_shard1_replica2/

Stack Trace:
org.apache.solr.common.SolrException: 
https://127.0.0.1:42789/solr/test_col_shard1_replica2/
at 
__randomizedtesting.SeedInfo.seed([907128AFC0619FEC:E89CA312B6C24019]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:745)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletes(TestTolerantUpdateProcessorCloud.java:322)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient(TestTolerantUpdateProcessorCloud.java:285)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[JIRA]

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

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

bq. Minor quibble: We should require a hyphen before the cp, as:
I hate that hyphen :-) It feels wrong, since it is really not an option but a 
command argument. I think it was technical limitations from SolrCLI.java which 
made it easiest to parse arguments that way?

So I'm more for removing the mandatory dash from up/downconfig (leaving the 
dash variant working for all of 6.x).

We then get this "man page" for {{solr zk}}
{noformat}
Usage: solr zk upconfig|downconfig -d  -n  [-z zkHost]
   solr zk cp [-r]   [-z zkHost]
   solr zk rm [-r]  [-z zkHost]
   solr zk mv   [-z zkHost]

 upconfig uploads a configset from the local machine to Zookeeper. 
(Backcompat: -upconfig)

 downconfig downloads a configset from Zookeeper to the local machine. 
(Backcompat: -downconfig)

 cp copies files or folders to/from Zookeeper
,  : [file:]/path/to/local/file or zk:/path/to/zk/node
When  is a zk resource,  may be "."
If  ends with "/", files are copied into that 
folder
Wildcards are not supported

 rm removes files or folders on Zookeeper
: [zk:]/path/to/zk/node

 mv moves and/or renames files internally on Zookeeper

 -z zkHostZookeeper connection string.

 -r   Recursive copying

 -n configNameName of the configset in Zookeeper that will be the 
destinatino of
   'upconfig' and the source for 'downconfig'.

 -d confdir   The local directory the configuration will be uploaded 
from for
  'upconfig' or downloaded to for 'downconfig'. For 
'upconfig', this
  can be one of the example configsets, basic_configs, 
data_driven_schema_configs or
  sample_techproducts_configs or an arbitrary directory.
{noformat}


> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+121) - Build # 856 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/856/
Java: 32bit/jdk-9-ea+121 -server -XX:+UseG1GC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([B182450F19129A0]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
Captured an uncaught exception in thread: Thread[id=1896, name=Thread-826, 
state=RUNNABLE, group=TGRP-TestSolrCLIRunExample]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1896, name=Thread-826, state=RUNNABLE, 
group=TGRP-TestSolrCLIRunExample]
Caused by: java.lang.RuntimeException: java.net.BindException: Address already 
in use
at __randomizedtesting.SeedInfo.seed([B182450F19129A0]:0)
at 
org.apache.solr.util.TestSolrCLIRunExample$RunExampleExecutor$1.run(TestSolrCLIRunExample.java:223)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(java.base@9-ea/Native Method)
at sun.nio.ch.Net.bind(java.base@9-ea/Net.java:433)
at sun.nio.ch.Net.bind(java.base@9-ea/Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(java.base@9-ea/ServerSocketChannelImpl.java:225)
at 
sun.nio.ch.ServerSocketAdaptor.bind(java.base@9-ea/ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:326)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:244)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:384)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:327)
at 
org.apache.solr.util.TestSolrCLIRunExample$RunExampleExecutor$1.run(TestSolrCLIRunExample.java:218)


FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:37357/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:37357/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([B182450F19129A0:834C1B8A5F6D4458]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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 

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 635 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/635/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.search.join.BlockJoinFacetDistribTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.search.join.BlockJoinFacetDistribTest: 1) Thread[id=13205, 
name=OverseerHdfsCoreFailoverThread-96037349953241106-127.0.0.1:52081_solr-n_04,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.search.join.BlockJoinFacetDistribTest: 
   1) Thread[id=13205, 
name=OverseerHdfsCoreFailoverThread-96037349953241106-127.0.0.1:52081_solr-n_04,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([ADCE4A4A6F9267DD]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.search.join.BlockJoinFacetDistribTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=13205, 
name=OverseerHdfsCoreFailoverThread-96037349953241106-127.0.0.1:52081_solr-n_04,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.interrupt0(Native Method) at 
java.lang.Thread.interrupt(Thread.java:923) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=13205, 
name=OverseerHdfsCoreFailoverThread-96037349953241106-127.0.0.1:52081_solr-n_04,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.interrupt0(Native Method)
at java.lang.Thread.interrupt(Thread.java:923)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([ADCE4A4A6F9267DD]:0)




Build Log:
[...truncated 11277 lines...]
   [junit4] Suite: org.apache.solr.search.join.BlockJoinFacetDistribTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.search.join.BlockJoinFacetDistribTest_ADCE4A4A6F9267DD-001/init-core-data-001
   [junit4]   2> 1273904 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1273904 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1273905 INFO  (Thread-6166) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1273905 INFO  (Thread-6166) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1274005 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:47603
   [junit4]   2> 1274005 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1274005 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1274009 INFO  (zkCallback-1409-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@3fee5cb5 
name:ZooKeeperConnection Watcher:127.0.0.1:47603 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1274009 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1274009 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1274009 INFO  
(SUITE-BlockJoinFacetDistribTest-seed#[ADCE4A4A6F9267DD]-worker) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 1274015 INFO  (jetty-launcher-1408-thread-2) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1274015 INFO  

[jira] [Commented] (SOLR-9198) config APIs is unable to add multiple values with same name

[ASF subversion and git services (JIRA)]

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

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

Commit 78b0fac5d1a795d708e1e3669f24ca7e4d3969c9 in lucene-solr's branch 
refs/heads/branch_6_1 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=78b0fac ]

SOLR-9198: config APIs unable to add multiple values with same name


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

Re: Lucene/Solr 6.1.0

[Noble Paul]

It is an optimization. But it is half-baked as it is committed now. It
should either be finished or rolled back

On Wed, Jun 8, 2016 at 8:50 PM, Adrien Grand  wrote:

> Thanks for letting me know. Isn't SOLR-8744 more an optimization than a
> bug fix? You know the code better than I do so I will leave the judgement
> call to you, but we should be careful as the release is approaching.
>
> Le mer. 8 juin 2016 à 16:55, Noble Paul  a écrit :
>
>> FYI
>> I have marked SOLR8744 and SOLR-9191as a blocker for 6.1
>> Hoping to fix those in the next couple of days
>>
>>
>> On Wed, Jun 8, 2016 at 6:08 PM, Adrien Grand  wrote:
>>
>>>
>>> I just created the 6.1.0 branch. Can someone help me with setting up
>>> Apache and Policeman Jenkins to test this branch?
>>>
>>> I still plan on cutting a first RC on Friday (in two days), please let
>>> me know if you know about issues that should be included in 6.1.0.
>>>
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>


-- 
-
Noble Paul

[jira] [Commented] (SOLR-9198) config APIs is unable to add multiple values with same name

[ASF subversion and git services (JIRA)]

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

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

Commit 73b73f068b1c513df6c87c41c12eece083c321e1 in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73b73f0 ]

SOLR-9198: config APIs unable to add multiple values with same name


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Commented] (SOLR-9198) config APIs is unable to add multiple values with same name

[ASF subversion and git services (JIRA)]

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

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

Commit be011097445cb558d5ebf014e8f0e23085fbaec5 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be01109 ]

SOLR-9198: config APIs unable to add multiple values with same name


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Updated] (SOLR-9198) config APIs is unable to add multiple values with same name

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Description: 
initArgs values with List should be converted to repeated NamedList entries
The {{SuggestComponent}} fails to add multiple suggesters

  was:The {{SuggestComponent}} fails to add multiple suggesters


> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> initArgs values with List should be converted to repeated NamedList 
> entries
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Updated] (SOLR-9198) config APIs is unable to add multiple values with same name

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Summary: config APIs is unable to add multiple values with same name   
(was: initArgs values with List should be converted to repeated NamedList 
entries)

> config APIs is unable to add multiple values with same name 
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Assigned] (SOLR-9198) initArgs values with List should be converted to repeated NamedList entries

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-9198:


Assignee: Noble Paul

> initArgs values with List should be converted to repeated NamedList 
> entries
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Updated] (SOLR-9198) initArgs values with List should be converted to repeated NamedList entries

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Summary: initArgs values with List should be converted to repeated 
NamedList entries  (was: initArgs values with List should be converted to 
separate entries with NamedList values)

> initArgs values with List should be converted to repeated NamedList 
> entries
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Updated] (SOLR-9198) initArgs values with List should be converted to repeated NamedList entries

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Fix Version/s: 6.1

> initArgs values with List should be converted to repeated NamedList 
> entries
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 6.1
>
> Attachments: SOLR-9198.patch
>
>
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Updated] (SOLR-9198) initArgs values with List should be converted to separate entries with NamedList values

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Description: The {{SuggestComponent}} fails to add multiple suggesters

> initArgs values with List should be converted to separate entries with 
> NamedList values
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
> Attachments: SOLR-9198.patch
>
>
> The {{SuggestComponent}} fails to add multiple suggesters



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

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

[jira] [Commented] (SOLR-9161) SolrPluginUtils.invokeSetters should accommodate setter variants

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9161:
--

Christine, I went back and, using Miller's beasting script, beasted 
{{SolrPluginUtilsTest}} for 100 iterations on the revision just before Hoss 
reverted, and it failed 72/100 iterations.  My seed above also failed for me at 
that revision.

I then applied your latest patch to current master and again beasted 100 
iterations of {{SolrPluginUtilsTest}}, and it failed 0/100 iterations.  (My 
reported seed also did not fail, but I'm not sure whether that's useful 
information.)

> SolrPluginUtils.invokeSetters should accommodate setter variants
> 
>
> Key: SOLR-9161
> URL: https://issues.apache.org/jira/browse/SOLR-9161
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9161.patch, SOLR-9161.patch
>
>
> The code currently assumes that there is only one setter (or if there are 
> several setters then the first one found is used and it could mismatch on the 
> arg type).
> Context and motivation is that a class with a
> {code}
> void setAFloat(float val) {
>   this.val = val;
> }
> {code}
> setter may wish to also provide a
> {code}
> void setAFloat(String val) {
>   this.val = Float.parseFloat(val);
> }
> {code}
> convenience setter.



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

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

[jira] [Resolved] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9107.
--
Resolution: Fixed

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9107: When creating a randomized SSL test config, 100% effective odds of 
using SSL and/or client auth should never be trumped by chance.


> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[ASF subversion and git services (JIRA)]

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

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

Commit eebce4a406716c1e1f31dd77a8d184d6e910df96 in lucene-solr's branch 
refs/heads/branch_6_1 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eebce4a ]

SOLR-9107: When creating a randomized SSL test config, 100% effective odds of 
using SSL and/or client auth should never be trumped by chance.


> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[ASF subversion and git services (JIRA)]

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

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

Commit 86c053dd1055c5b2b4cfe3c8e6b573d3d1272b24 in lucene-solr's branch 
refs/heads/master from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86c053d ]

SOLR-9107: When creating a randomized SSL test config, 100% effective odds of 
using SSL and/or client auth should never be trumped by chance.


> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:55843/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:55843/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([C01793FB2788D995:4843AC218974B46D]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9107:
--

Hoss told me offline that my proposed fix sounds fine on cursory inspection, so 
I'll commit it shortly.

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Comment Edited] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[Scott Blum (JIRA)]

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

Scott Blum edited comment on SOLR-9191 at 6/8/16 6:19 PM:
--

Cool.  Any other feedback beyond the Predicate change?  [~shalinmangar] or 
[~markrmil...@gmail.com]?  Otherwise going to commit to master today and start 
backporting.

I want to backport this to any branches we might make a release on... 5.5.2, 
5.6, 6.0.2, 6.1.1, 6.2


was (Author: dragonsinth):
Cool.  Any other feedback beyond the Predicate change?  [~shalinmangar] or 
[~markrmil...@gmail.com]?  Otherwise going to commit to master today and start 
backporting.

I want to backport this to any branches we might make a release on... 5.5.2, 
5.6, 6.0.2, 6.1

> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Commented] (SOLR-9191) OverseerTaskQueue.peekTopN() fatally flawed

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-9191:
--

Cool.  Any other feedback beyond the Predicate change?  [~shalinmangar] or 
[~markrmil...@gmail.com]?  Otherwise going to commit to master today and start 
backporting.

I want to backport this to any branches we might make a release on... 5.5.2, 
5.6, 6.0.2, 6.1

> OverseerTaskQueue.peekTopN() fatally flawed
> ---
>
> Key: SOLR-9191
> URL: https://issues.apache.org/jira/browse/SOLR-9191
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4, 5.4.1, 5.5, 5.5.1, 6.0, 6.0.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Blocker
> Fix For: 5.6, 6.1, 5.5.2, 6.0.2, 6.2
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We rewrote DistributedQueue in SOLR-6760, to optimize its obvious use case as 
> a FIFO.  But in doing so, we broke the assumptions in 
> OverseerTaskQueue.peekTopN()..
> OverseerTaskQueue.peekTopN() involves filtering out items you're already 
> working on, it's trying to peek for new items in the queue beyond what you 
> already know about.  But DistributedQueue (being designed as a FIFO) doesn't 
> know about the filtering; as long as it has any items in-memory it just keeps 
> returning those over and over without ever pulling new data from ZK.  This is 
> true even if the watcher has fired and marked the state as dirty.  So 
> OverseerTaskQueue gets into a state where it can never read new items in ZK 
> because DQ keeps returning the same items that it has marked as in-progress.



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

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

[jira] [Updated] (LUCENE-7321) Character Mapping

[Ivan Provalov (JIRA)]

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

Ivan Provalov updated LUCENE-7321:
--
Description: 
One of the challenges in search is recall of an item with a common typing 
variant.  These cases can be as simple as lower/upper case in most languages, 
accented characters, or more complex morphological phenomena like prefix 
omitting, or constructing a character with some combining mark.  This component 
addresses the cases, which are not covered by ASCII folding component, or more 
complex to design with other tools.  The idea is that a linguist could provide 
the mappings in a tab-delimited file, which then can be directly used by Solr.

The mappings are maintained in the tab-delimited file, which could be just a 
copy paste from Excel spreadsheet.  This gives the linguists the opportunity to 
create the mappings, then for the developer to include them in Solr 
configuration.  There are a few cases, when the mappings grow complex, where 
some additional debugging may be required.  The mappings can contain any 
sequence of characters to any other sequence of characters.

Some of the cases I discuss in detail document are handling the voiced vowels 
for Japanese; common typing substitutions for Korean, Russian, Polish; 
transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
for Japanese.  In the appendix, I give an example of implementing a Russian 
light weight stemmer using this component.

  was:
One of the challenges in search is recall of an item with a common typing 
variant.  These cases can be as simple as lower/upper case in most languages, 
accented characters, or more complex morphological phenomena like prefix 
omitting, or constructing a character with some combining mark.  This component 
addresses the cases, which are not covered by ASCII folding component, or more 
complex to design with other tools.  The idea is that a linguist could provide 
the mappings in a tab-delimited file, which then can be directly used by Solr.

The mappings are maintained in the tab-delimited file, which could be just a 
copy paste from Excel spreadsheet.  This gives the linguists the opportunity to 
create the mappings, then for the developer to include them in Solr 
configuration.  There are a few cases, when the mappings grow complex, where 
some additional debugging may be required.  The mappings can contain any 
sequence of characters to any other sequence of characters.

Some of the cases I discuss in detail document are handling the voiced vowels 
for Japanese; common typing substitutions for Korean, Russian, Polish; 
transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
for Japanese.


> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 6.0, 5.4.1, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal for Arabic; suffix folding 
> for Japanese.  In the appendix, I give an example of implementing a Russian 
> light weight stemmer using this component.



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

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

[jira] [Updated] (LUCENE-7321) Character Mapping

[Ivan Provalov (JIRA)]

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

Ivan Provalov updated LUCENE-7321:
--
Attachment: CharacterMappingComponent.pdf

Detail component description.

> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 6.0, 5.4.1, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: CharacterMappingComponent.pdf, LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal   for Arabic; suffix 
> folding for Japanese.



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

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

[jira] [Updated] (LUCENE-7321) Character Mapping

[Ivan Provalov (JIRA)]

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

Ivan Provalov updated LUCENE-7321:
--
Attachment: LUCENE-7321.patch

Initial patch.

> Character Mapping
> -
>
> Key: LUCENE-7321
> URL: https://issues.apache.org/jira/browse/LUCENE-7321
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.6.1, 6.0, 5.4.1, 6.0.1
>Reporter: Ivan Provalov
>Priority: Minor
>  Labels: patch
> Fix For: 6.0.1
>
> Attachments: LUCENE-7321.patch
>
>
> One of the challenges in search is recall of an item with a common typing 
> variant.  These cases can be as simple as lower/upper case in most languages, 
> accented characters, or more complex morphological phenomena like prefix 
> omitting, or constructing a character with some combining mark.  This 
> component addresses the cases, which are not covered by ASCII folding 
> component, or more complex to design with other tools.  The idea is that a 
> linguist could provide the mappings in a tab-delimited file, which then can 
> be directly used by Solr.
> The mappings are maintained in the tab-delimited file, which could be just a 
> copy paste from Excel spreadsheet.  This gives the linguists the opportunity 
> to create the mappings, then for the developer to include them in Solr 
> configuration.  There are a few cases, when the mappings grow complex, where 
> some additional debugging may be required.  The mappings can contain any 
> sequence of characters to any other sequence of characters.
> Some of the cases I discuss in detail document are handling the voiced vowels 
> for Japanese; common typing substitutions for Korean, Russian, Polish; 
> transliteration for Polish, Arabic; prefix removal   for Arabic; suffix 
> folding for Japanese.



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

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

[jira] [Reopened] (SOLR-9107) add annotation for more fine grained control of SSL per test-class

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-9107:
--

My Jenkins found a reproducing seed for a 
{{TestSSLRandomization.testSslRandomizer()}} failure:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSSLRandomization -Dtests.method=testSSLRandomizer 
-Dtests.seed=2E775F0292A463C2 -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=en-PH -Dtests.timezone=Africa/Blantyre -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.05s J1  | TestSSLRandomization.testSSLRandomizer <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected: but 
was:
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([2E775F0292A463C2:84FFA6FD36CC78D6]:0)
   [junit4]>at 
org.apache.solr.cloud.TestSSLRandomization.testSSLRandomizer(TestSSLRandomization.java:199)
{noformat}

{code:java|title=TestSSLRandomization.testSSLRandomizer()}
195: r = SSLRandomizer.getSSLRandomizerForClass(MaxAnnotated.class);
196: assertEquals(1.0D, r.ssl, 0.0D);
197: assertEquals(1.0D, r.clientAuth, 0.0D);
198: conf = r.createSSLTestConfig();
199: assertEquals(true, conf.isSSLMode());
200: assertEquals(true, conf.isClientAuthMode());
{code}

{code:java|title=RandomizeSSL.SSLRandomizer}
public SSLTestConfig createSSLTestConfig() {
  // even if we know SSL is disabled, always consume the same amount of 
randomness
  // that way all other test behavior should be consistent even if a user 
adds/removes @SuppressSSL
  
  final boolean useSSL = TestUtil.nextInt(LuceneTestCase.random(), 0, 1000) < 
(int)(1000 * getEffectiveOdds(ssl, LuceneTestCase.TEST_NIGHTLY, 
LuceneTestCase.RANDOM_MULTIPLIER));
  final boolean useClientAuth = TestUtil.nextInt(LuceneTestCase.random(), 0, 
1000) < 
(int)(1000 * getEffectiveOdds(clientAuth, LuceneTestCase.TEST_NIGHTLY, 
LuceneTestCase.RANDOM_MULTIPLIER));

  return new SSLTestConfig(useSSL, useClientAuth);
}
{code}
With the above seed {{TestUtil.nextInt()}} produces the top of the range 
(1000), and so {{useSSL}} is set to {{false}}, since {{1000}} is not less than 
{{1000 * the effective odds (1.0)}}.

One way to fix this is to reduce the top of the range of random ints from 1000 
to 999, so that effective 100% odds are never randomly trumped.

I believe that the inverse is not a problem currently or with my proposed fix: 
when the effective odds are {{0.0}}, if the next random int happens to be 
{{0}}, {{0 < 0}} will evaluate to {{false}}.

The {{useClientAuth}} calculation will also need the same fix.

> add annotation for more fine grained control of SSL per test-class
> --
>
> Key: SOLR-9107
> URL: https://issues.apache.org/jira/browse/SOLR-9107
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9107.patch, SOLR-9107.patch
>
>
> Spinning off this idea from my earlier comment in SOLR-5776...
> 
> At some point in the future, after all this soaks, we should consider 
> increasing the odds of using SSL – perhaps even add a new annotation (or 
> replace @SupressSSL) with a param to help control the odds of using SSL / 
> clientAuth on a per-class basis, ie...
> {noformat}
>   @UseSSL(false) // same as @SupressSSL
>   @UseSSL() //  same as default if no annotation: SolrTestCaseJ4 picks SSL / 
> clientAuth using LuceneTestCase.rarely
>   @UseSSL(ssl=0.75,clientAuth=0.25) // fine control of odds of using ssl & 
> clientauth
> {noformat}
> ...some tests, like TestSSLRandomization should ideally have much higher odds 
> of using SSL then other tests, and if we had an easy way to say "these 
> handful of simple cloud tests should use SSL very frequently" then it 
> wouldn't matter so much if the odds of other really 'expensive' tests only 
> use SSL once in a blue moon.



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

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

[jira] [Updated] (SOLR-9198) initArgs values with List should be converted to separate entries with NamedList values

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9198:
-
Attachment: SOLR-9198.patch

> initArgs values with List should be converted to separate entries with 
> NamedList values
> 
>
> Key: SOLR-9198
> URL: https://issues.apache.org/jira/browse/SOLR-9198
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
> Attachments: SOLR-9198.patch
>
>




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

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

[jira] [Created] (SOLR-9198) initArgs values with List should be converted to separate entries with NamedList values

[Noble Paul (JIRA)]

Noble Paul created SOLR-9198:


 Summary: initArgs values with List should be converted to 
separate entries with NamedList values
 Key: SOLR-9198
 URL: https://issues.apache.org/jira/browse/SOLR-9198
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul






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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1203 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:60896/jqgg","node_name":"127.0.0.1:60896_jqgg","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:50698/jqgg;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:50698_jqgg"}, "core_node2":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:60896/jqgg;,   
"node_name":"127.0.0.1:60896_jqgg",   "state":"active",   
"leader":"true"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:45595/jqgg;,   
"node_name":"127.0.0.1:45595_jqgg",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node2:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:60896/jqgg","node_name":"127.0.0.1:60896_jqgg","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:50698/jqgg;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:50698_jqgg"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:60896/jqgg;,
  "node_name":"127.0.0.1:60896_jqgg",
  "state":"active",
  "leader":"true"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:45595/jqgg;,
  "node_name":"127.0.0.1:45595_jqgg",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([662DA4EFF8C31DB5:EE799B35563F704D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

New patch.
# Increasing the timeout of the threadpool termination in 
TestInPlaceUpdatesDistrib from 2s to 5s, and added assertion message.
# Fixing some review comments in the TestStressInPlaceUpdates (more remains to 
be fixed).

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

Re: [jira] [Commented] (SOLR-7123) /update/json/docs should have nested document support

[Noble Paul]

child.split is no longer there
On Jun 8, 2016 9:23 PM, "Anshum Gupta (JIRA)"  wrote:

>
> [
> https://issues.apache.org/jira/browse/SOLR-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320793#comment-15320793
> ]
>
> Anshum Gupta commented on SOLR-7123:
> 
>
> There seems to be some issue here. Here's what I'm trying to do:
>
> {code}
> anshum$ curl -X POST -H 'Content:application/json' "
> http://localhost:8983/solr/foo/update/json/docs?child.split=/children|/children/grandchildren=$FQN:/**=id:/children/id=name:/children/name=cat:/children/cat=id:/children/grandchildren/id=name:/children/grandchildren/name=cat:/children/grandchildren/cat=true"
> --data-binary '{"id":"1","name": "i am the parent","cat":
> "parent","children" : [{"id": "1.1", "name": "i am the 1st child", "cat":
> "child"}, {"id":"1.2", "name": "i am the 2nd child", "cat": "child",
> "grandchildren" : [{"id": "1.2.1", "name": "i am the grandchild","cat" :
> "grandchild"}]}]}'
> {code}
>
> and here's the error
> {code}
> {
>   "responseHeader":{
> "status":500,
> "QTime":0},
>   "error":{
> "msg":"All paths must start with '/' :/**",
> "trace":"java.lang.RuntimeException: All paths must start with '/'
> :/**\n\tat
> org.apache.solr.common.util.JsonRecordReader.addField(JsonRecordReader.java:99)\n\tat
> org.apache.solr.common.util.JsonRecordReader.getInst(JsonRecordReader.java:49)\n\tat
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:211)\n\tat
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:129)\n\tat
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:114)\n\tat
> org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:77)\n\tat
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)\n\tat
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)\n\tat
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
> java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> {code}
>
>
> When I try to add an explicit mapping for field 'id', here's what I get:
> {code}
>
> curl -X POST -H 'Content:application/json' "
> 

[jira] [Commented] (SOLR-7123) /update/json/docs should have nested document support

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7123:


There seems to be some issue here. Here's what I'm trying to do:

{code}
anshum$ curl -X POST -H 'Content:application/json' 
"http://localhost:8983/solr/foo/update/json/docs?child.split=/children|/children/grandchildren=$FQN:/**=id:/children/id=name:/children/name=cat:/children/cat=id:/children/grandchildren/id=name:/children/grandchildren/name=cat:/children/grandchildren/cat=true"
 --data-binary '{"id":"1","name": "i am the parent","cat": "parent","children" 
: [{"id": "1.1", "name": "i am the 1st child", "cat": "child"}, {"id":"1.2", 
"name": "i am the 2nd child", "cat": "child", "grandchildren" : [{"id": 
"1.2.1", "name": "i am the grandchild","cat" : "grandchild"}]}]}'
{code}

and here's the error
{code}
{
  "responseHeader":{
"status":500,
"QTime":0},
  "error":{
"msg":"All paths must start with '/' :/**",
"trace":"java.lang.RuntimeException: All paths must start with '/' 
:/**\n\tat 
org.apache.solr.common.util.JsonRecordReader.addField(JsonRecordReader.java:99)\n\tat
 
org.apache.solr.common.util.JsonRecordReader.getInst(JsonRecordReader.java:49)\n\tat
 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleSplitMode(JsonLoader.java:211)\n\tat
 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:129)\n\tat
 
org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:114)\n\tat
 org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:77)\n\tat 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)\n\tat
 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:69)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
 org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:465)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
 java.lang.Thread.run(Thread.java:745)\n",
"code":500}}
{code}


When I try to add an explicit mapping for field 'id', here's what I get:
{code}

curl -X POST -H 'Content:application/json' 
"http://localhost:8983/solr/foo/update/json/docs?child.split=/children|/children/grandchildren=id:/children/id=name:/children/name=cat:/children/cat=id:/children/grandchildren/id=name:/children/grandchildren/name=cat:/children/grandchildren/cat=true"
 --data-binary '{"id":"1","name": "i am the parent","cat": "parent","children" 
: [{"id": "1.1", "name": "i am 

Re: Lucene/Solr 6.1.0

[Adrien Grand]

Thanks for letting me know. Isn't SOLR-8744 more an optimization than a bug
fix? You know the code better than I do so I will leave the judgement call
to you, but we should be careful as the release is approaching.

Le mer. 8 juin 2016 à 16:55, Noble Paul  a écrit :

> FYI
> I have marked SOLR8744 and SOLR-9191as a blocker for 6.1
> Hoping to fix those in the next couple of days
>
>
> On Wed, Jun 8, 2016 at 6:08 PM, Adrien Grand  wrote:
>
>>
>> I just created the 6.1.0 branch. Can someone help me with setting up
>> Apache and Policeman Jenkins to test this branch?
>>
>> I still plan on cutting a first RC on Friday (in two days), please let me
>> know if you know about issues that should be included in 6.1.0.
>>
>
>
>
> --
> -
> Noble Paul
>

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[tomjon]

Github user tomjon commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66273240
  
--- Diff: solr/core/src/test/org/apache/solr/cloud/ShardSplitTest.java ---
@@ -57,7 +57,6 @@
 import static 
org.apache.solr.common.cloud.ZkStateReader.MAX_SHARDS_PER_NODE;
 import static 
org.apache.solr.common.cloud.ZkStateReader.REPLICATION_FACTOR;
 
-@Slow
--- End diff --

Restored


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[tomjon]

Github user tomjon commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66272908
  
--- Diff: solr/core/src/java/org/apache/solr/update/UpdateHandler.java ---
@@ -200,4 +187,16 @@ public void registerOptimizeCallback( 
SolrEventListener listener )
   }
 
   public abstract void split(SplitIndexCommand cmd) throws IOException;
+  
+  private static UpdateLog initialisePluginUpdateLog(SolrCore core, String 
dataDir, PluginInfo ulogPluginInfo)
+  {
+String className = ulogPluginInfo.className;
+if (System.getProperty("test.hdfs.forceHdfsUpdateLog") != null) {
+  className = "solr.HdfsUpdateLog";
+}
+if (className != null) {
+  return core.getResourceLoader().newInstance(className, 
UpdateLog.class);
+}
+return new UpdateLog();
+  }
 }
--- End diff --

Seems reasonable, done.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 80 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/80/

No tests ran.

Build Log:
[...truncated 40524 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (15.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.2.0-src.tgz...
   [smoker] 28.7 MB in 0.02 sec (1202.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.2.0.tgz...
   [smoker] 63.0 MB in 0.05 sec (1204.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.2.0.zip...
   [smoker] 73.6 MB in 0.06 sec (1203.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6009 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.2.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 218 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (50.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.2.0-src.tgz...
   [smoker] 37.9 MB in 0.31 sec (121.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.2.0.tgz...
   [smoker] 132.4 MB in 1.03 sec (128.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.2.0.zip...
   [smoker] 141.0 MB in 1.02 sec (138.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.2.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]   [-]  
   

Re: Lucene/Solr 6.1.0

[Noble Paul]

FYI
I have marked SOLR8744 and SOLR-9191as a blocker for 6.1
Hoping to fix those in the next couple of days


On Wed, Jun 8, 2016 at 6:08 PM, Adrien Grand  wrote:

>
> I just created the 6.1.0 branch. Can someone help me with setting up
> Apache and Policeman Jenkins to test this branch?
>
> I still plan on cutting a first RC on Friday (in two days), please let me
> know if you know about issues that should be included in 6.1.0.
>



-- 
-
Noble Paul

[jira] [Created] (SOLR-9197) Audit all solrconfig components and ensure that they work with the Config APIs

[Noble Paul (JIRA)]

Noble Paul created SOLR-9197:


 Summary: Audit all solrconfig components and ensure that they work 
with the Config APIs
 Key: SOLR-9197
 URL: https://issues.apache.org/jira/browse/SOLR-9197
 Project: Solr
  Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul


Components assume that the configuration is read from {{solrconfig.xml}} and 
all values are NamedList. Config APIs  use and store JSON and the syntax is 
different. Components should work with both syntax.



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

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

[jira] [Comment Edited] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-9194 at 6/8/16 2:43 PM:
--

My original suggestion was more along the lines of trying to emulate the 
current zkcli pattern. Which I've always found difficult to remember anyway. 

Hmmm, while we're at it, what about adding rm?
{noformat}
bin/solr zk -rm /whatever
bin/solr zk -rm -r /whatever
{noformat}
What do others think? If we adopt this suggestion I'd think that the upconfig 
and downconfig should stay as a way to be a bit more structured about 
configsets, as well as find the pre-packaged configsets by just name. If you 
knew exactly what you were doing you could just use the 'cp' syntax and ignore 
them.

//Removed truly silly comment, no coffee yet.

Minor quibble: We should require a hyphen before the cp, as:
{noformat}
bin/solr zk -cp zk:/security.json .
{noformat}
for consistency's sake with other commands if nothing else I think.


was (Author: erickerickson):
My original suggestion was more along the lines of trying to emulate the 
current zkcli pattern. Which I've always found difficult to remember anyway. 

Hmmm, while we're at it, what about adding rm?
{noformat}
bin/solr zk -rm zk:/whatever
bin/solr zk -rm -r zk:/whatever
{noformat}
What do others think? If we adopt this suggestion I'd think that the upconfig 
and downconfig should stay as a way to be a bit more structured about 
configsets, as well as find the pre-packaged configsets by just name. If you 
knew exactly what you were doing you could just use the 'cp' syntax and ignore 
them.

//Removed truly silly comment, no coffee yet.

Minor quibble: We should require a hyphen before the cp, as:
{noformat}
bin/solr zk -cp zk:/security.json .
{noformat}
for consistency's sake with other commands if nothing else I think.

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



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

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

[jira] [Comment Edited] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-9194 at 6/8/16 2:40 PM:
--

My original suggestion was more along the lines of trying to emulate the 
current zkcli pattern. Which I've always found difficult to remember anyway. 

Hmmm, while we're at it, what about adding rm?
{noformat}
bin/solr zk -rm zk:/whatever
bin/solr zk -rm -r zk:/whatever
{noformat}
What do others think? If we adopt this suggestion I'd think that the upconfig 
and downconfig should stay as a way to be a bit more structured about 
configsets, as well as find the pre-packaged configsets by just name. If you 
knew exactly what you were doing you could just use the 'cp' syntax and ignore 
them.

//Removed truly silly comment, no coffee yet.

Minor quibble: We should require a hyphen before the cp, as:
{noformat}
bin/solr zk -cp zk:/security.json .
{noformat}
for consistency's sake with other commands if nothing else I think.


was (Author: erickerickson):
My original suggestion was more along the lines of trying to emulate the 
current zkcli pattern. Which I've always found difficult to remember anyway. 

Hmmm, while we're at it, what about adding rm?
{noformat}
bin/solr zk -rm zk:/whatever
bin/solr zk -rm -r zk:/whatever
{noformat}
What do others think? If we adopt this suggestion I'd think that the upconfig 
and downconfig should stay as a way to be a bit more structured about 
configsets, as well as find the pre-packaged configsets by just name. If you 
knew exactly what you were doing you could just use the 'cp' syntax and ignore 
them.

Minor quibble1: If we require the 'zk:' prefix, then order doesn't matter, 
right? Seems to me like we should either do things positionally or with the 
'zk:' tag. Personally I prefer the 'zk:' tag.

Minor quibble2: We should require a hyphen before the cp, as:
{noformat}
bin/solr zk -cp zk:/security.json .
{noformat}
for consistency's sake with other commands if nothing else I think.

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



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

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

[jira] [Commented] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9194:
--

My original suggestion was more along the lines of trying to emulate the 
current zkcli pattern. Which I've always found difficult to remember anyway. 

Hmmm, while we're at it, what about adding rm?
{noformat}
bin/solr zk -rm zk:/whatever
bin/solr zk -rm -r zk:/whatever
{noformat}
What do others think? If we adopt this suggestion I'd think that the upconfig 
and downconfig should stay as a way to be a bit more structured about 
configsets, as well as find the pre-packaged configsets by just name. If you 
knew exactly what you were doing you could just use the 'cp' syntax and ignore 
them.

Minor quibble1: If we require the 'zk:' prefix, then order doesn't matter, 
right? Seems to me like we should either do things positionally or with the 
'zk:' tag. Personally I prefer the 'zk:' tag.

Minor quibble2: We should require a hyphen before the cp, as:
{noformat}
bin/solr zk -cp zk:/security.json .
{noformat}
for consistency's sake with other commands if nothing else I think.

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



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

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

[jira] [Commented] (LUCENE-4499) Multi-word synonym filter (synonym expansion)

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-4499:


LUCENE-6664 fixes the multi-term synonym problems "correctly", meaning the 
synonym filter produces a correct graph, which e.g. a query parser could then 
do the right thing with ... but the patch proved controversial so it won't be 
committed any time soon.

But it's quite standalone in the patch (just another {{TokenFilter}}) so you 
could maybe plug it into Solr and try it out.

> Multi-word synonym filter (synonym expansion)
> -
>
> Key: LUCENE-4499
> URL: https://issues.apache.org/jira/browse/LUCENE-4499
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: 4.1, 6.0
>Reporter: Roman Chyla
>  Labels: analysis, multi-word, synonyms
> Fix For: 6.0
>
> Attachments: LUCENE-4499.patch, LUCENE-4499.patch
>
>
> I apologize for bringing the multi-token synonym expansion up again. There is 
> an old, unresolved issue at LUCENE-1622 [1]
> While solving the problem for our needs [2], I discovered that the current 
> SolrSynonym parser (and the wonderful FTS) have almost everything to 
> satisfactorily handle both the query and index time synonym expansion. It 
> seems that people often need to use the synonym filter *slightly* differently 
> at indexing and query time.
> In our case, we must do different things during indexing and querying.
> Example sentence: Mirrors of the Hubble space telescope pointed at XA5
> This is what we need (comma marks position bump):
> indexing: mirrors,hubble|hubble space 
> telescope|hst,space,telescope,pointed,xa5|astroobject#5
> querying: +mirrors +(hubble space telescope | hst) +pointed 
> +(xa5|astroboject#5)
> This translated to following needs:
>   indexing time: 
> single-token synonyms => return only synonyms
> multi-token synonyms => return original tokens *AND* the synonyms
>   query time:
> single-token: return only synonyms (but preserve case)
> multi-token: return only synonyms
>  
> We need the original tokens for the proximity queries, if we indexed 'hubble 
> space telescope'
> as one token, we cannot search for 'hubble NEAR telescope'
> You may (not) be surprised, but Lucene already supports ALL of these 
> requirements. The patch is an attempt to state the problem differently. I am 
> not sure if it is the best option, however it works perfectly for our needs 
> and it seems it could work for general public too. Especially if the 
> SynonymFilterFactory had a preconfigured sets of SynonymMapBuilders - and 
> people would just choose what situation they use. Please look at the unittest.
> links:
> [1] https://issues.apache.org/jira/browse/LUCENE-1622
> [2] http://labs.adsabs.harvard.edu/trac/ads-invenio/ticket/158
> [3] seems to have similar request: 
> http://lucene.472066.n3.nabble.com/Proposal-Full-support-for-multi-word-synonyms-at-query-time-td4000522.html



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

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

[jira] [Commented] (SOLR-9196) Dead link on SolrConfigXml wiki page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9196:
-

There is already some template language and some discussion about what to do 
here in the INTERNAL pages of the Solr Ref Guide: 
https://cwiki.apache.org/confluence/display/solr/Internal+-+Maintaining+Documentation#Internal-MaintainingDocumentation-Migrating"Official"DocumentationfromMoinMoin

IMO, we should update pages as we come across them. There are *many* cases 
where the content in the old wiki is completely replaced/superseded by the 
current Solr Ref Guide, and those can just be updated without a lot of 
additional discussion. It would be nice if we could do a band-aid style 
migration of everything, but at this point the reality is that no one is 
volunteering to do that so there's no point in waiting.

> Dead link on SolrConfigXml wiki page
> 
>
> Key: SOLR-9196
> URL: https://issues.apache.org/jira/browse/SOLR-9196
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Steen Manniche
>Assignee: Stefan Matheis (steffkes)
>Priority: Trivial
>  Labels: documentation
>
> Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
> the example solrconfig.xml at 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
>  is a 404
> Should perhaps point to 
> https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
>  instead?



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

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5898 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5898/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=15, 
name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
group=TGRP-IndexAndTaxonomyReplicationClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=15, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
at 
__randomizedtesting.SeedInfo.seed([8C4D3E93DFF05824:3C3D933CD9CABDB]:0)
Caused by: java.lang.AssertionError: handler failed too many times: -1
at __randomizedtesting.SeedInfo.seed([8C4D3E93DFF05824]:0)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:434)
at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)




Build Log:
[...truncated 8113 lines...]
   [junit4] Suite: 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest
   [junit4]   2> thg 6 08, 2016 10:47:03 SA 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[ReplicationThread-indexAndTaxo,5,TGRP-IndexAndTaxonomyReplicationClientTest]
   [junit4]   2> java.lang.AssertionError: handler failed too many times: -1
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([8C4D3E93DFF05824]:0)
   [junit4]   2>at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:434)
   [junit4]   2>at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexAndTaxonomyReplicationClientTest 
-Dtests.method=testConsistencyOnExceptions -Dtests.seed=8C4D3E93DFF05824 
-Dtests.slow=true -Dtests.locale=vi-VN -Dtests.timezone=America/Santarem 
-Dtests.asserts=true -Dtests.file.encoding=Cp1252
   [junit4] ERROR   2.25s J0 | 
IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=15, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([8C4D3E93DFF05824:3C3D933CD9CABDB]:0)
   [junit4]> Caused by: java.lang.AssertionError: handler failed too many 
times: -1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([8C4D3E93DFF05824]:0)
   [junit4]>at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:434)
   [junit4]>at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): 
{$full_path$=Lucene50(blocksize=128), $facets=PostingsFormat(name=Direct), 
$payloads$=FSTOrd50}, docValues:{$facets=DocValuesFormat(name=Direct)}, 
maxPointsInLeafNode=329, maxMBSortInHeap=5.423157961620648, 
sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=vi-VN, 
timezone=America/Santarem
   [junit4]   2> NOTE: Windows 10 10.0 x86/Oracle Corporation 1.8.0_92 
(32-bit)/cpus=3,threads=1,free=53938824,total=64880640
   [junit4]   2> NOTE: All tests run in this JVM: [LocalReplicatorTest, 
IndexAndTaxonomyReplicationClientTest]
   [junit4] Completed [2/9 (1!)] on J0 in 4.80s, 5 tests, 1 error <<< FAILURES!

[...truncated 53 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:740: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:684: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:59: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build.xml:476: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2161:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\module-build.xml:58:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:1427:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:984:
 There were 

[jira] [Updated] (SOLR-8744) Overseer operations need more fine grained mutual exclusion

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8744:
-
Priority: Blocker  (was: Major)

> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, 
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this 
> is a big scaling problem.  Multiple split shard operations could happen at 
> the time time, as long as different shards are being split.  In practice, 
> those shards often reside on different machines, so there's no I/O bottleneck 
> in those cases, just the mutex in Overseer forcing the operations to be done 
> serially.
> Given that a single split can take many minutes on a large collection, this 
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need 
> exclusive access at various levels. Each operation must define the Access 
> level at which the access is required. Access level is an enum. 
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look 
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend: 
> C1, C2 -> Collections
> S1, S2 -> Shards 
> R1,R2,R3,R4 -> Replicas
>  Cluster
> /   \
>/ \ 
>   C1  C2
>  / \ /   \ 
> /   \   / \  
>S1   S2  S1 S2
> R1, R2  R3.R4  R1,R2   R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate 
> lock from the tree. For example, if an operation needs a lock at a Collection 
> level and it needs to operate on Collection C1, the node C1 and all child 
> nodes of C1 must be free. 
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and 
> start moving down depending upon the operation. After it reaches the right 
> node, it checks if all the children are free from a lock.  If it fails to 
> acquire a lock, it remains in the work queue. A scheduler thread waits for 
> notification from the current set of tasks . Every task would do a 
> {{notify()}} on the monitor of  the scheduler thread. The thread would start 
> from the head of the queue and check all tasks to see if that task is able to 
> acquire the right lock. If yes, it is executed, if not, the task is left in 
> the work queue.  
> When a new task arrives in the work queue, the schedulerthread wakes and just 
> try to schedule that task.



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

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

[jira] [Updated] (SOLR-8744) Overseer operations need more fine grained mutual exclusion

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-8744:
-
Fix Version/s: 6.1

> Overseer operations need more fine grained mutual exclusion
> ---
>
> Key: SOLR-8744
> URL: https://issues.apache.org/jira/browse/SOLR-8744
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Noble Paul
>Priority: Blocker
>  Labels: sharding, solrcloud
> Fix For: 6.1
>
> Attachments: SOLR-8744.patch, SOLR-8744.patch, SOLR-8744.patch, 
> SOLR-8744.patch, SOLR-8744.patch, SmileyLockTree.java, SmileyLockTree.java
>
>
> SplitShard creates a mutex over the whole collection, but, in practice, this 
> is a big scaling problem.  Multiple split shard operations could happen at 
> the time time, as long as different shards are being split.  In practice, 
> those shards often reside on different machines, so there's no I/O bottleneck 
> in those cases, just the mutex in Overseer forcing the operations to be done 
> serially.
> Given that a single split can take many minutes on a large collection, this 
> is a bottleneck at scale.
> Here is the proposed new design
> There are various Collection operations performed at Overseer. They may need 
> exclusive access at various levels. Each operation must define the Access 
> level at which the access is required. Access level is an enum. 
> CLUSTER(0)
> COLLECTION(1)
> SHARD(2)
> REPLICA(3)
> The Overseer node maintains a tree of these locks. The lock tree would look 
> as follows. The tree can be created lazily as and when tasks come up.
> {code}
> Legend: 
> C1, C2 -> Collections
> S1, S2 -> Shards 
> R1,R2,R3,R4 -> Replicas
>  Cluster
> /   \
>/ \ 
>   C1  C2
>  / \ /   \ 
> /   \   / \  
>S1   S2  S1 S2
> R1, R2  R3.R4  R1,R2   R3,R4
> {code}
> When the overseer receives a message, it tries to acquire the appropriate 
> lock from the tree. For example, if an operation needs a lock at a Collection 
> level and it needs to operate on Collection C1, the node C1 and all child 
> nodes of C1 must be free. 
> h2.Lock acquiring logic
> Each operation would start from the root of the tree (Level 0 -> Cluster) and 
> start moving down depending upon the operation. After it reaches the right 
> node, it checks if all the children are free from a lock.  If it fails to 
> acquire a lock, it remains in the work queue. A scheduler thread waits for 
> notification from the current set of tasks . Every task would do a 
> {{notify()}} on the monitor of  the scheduler thread. The thread would start 
> from the head of the queue and check all tasks to see if that task is able to 
> acquire the right lock. If yes, it is executed, if not, the task is left in 
> the work queue.  
> When a new task arrives in the work queue, the schedulerthread wakes and just 
> try to schedule that task.



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

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

[jira] [Commented] (SOLR-9186) Logistic regression modeling for text

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9186:
--

I'm focusing on SOLR-9193 first. So feel free to submit a patch. Let me know if 
you'd like to discuss the design before you start.

> Logistic regression modeling for text
> -
>
> Key: SOLR-9186
> URL: https://issues.apache.org/jira/browse/SOLR-9186
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> SOLR-8492 optimizes a logistic regression model for numeric fields. While 
> this is interesting, I think it would be more interesting to build logistic 
> regression models on text within an inverted index.
> This ticket will use the same *parallel iterative framework* as SOLR-8492, 
> but different data access patterns on the shards, to optimize a logistic 
> regression model on text.
> This will support use cases such as building models for spam detection, 
> sentiment analysis and threat detection.



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

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

[jira] [Commented] (SOLR-9196) Dead link on SolrConfigXml wiki page

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) commented on SOLR-9196:
-

Excellent Point Jan, didn't think about that before applying the change. At 
least put a large banner on top of the page as we did on other pages as well, 
in case we're not entirely sure that all relevant content got already moved 
into the ref guide - until we're done with that migration.

> Dead link on SolrConfigXml wiki page
> 
>
> Key: SOLR-9196
> URL: https://issues.apache.org/jira/browse/SOLR-9196
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Steen Manniche
>Assignee: Stefan Matheis (steffkes)
>Priority: Trivial
>  Labels: documentation
>
> Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
> the example solrconfig.xml at 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
>  is a 404
> Should perhaps point to 
> https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
>  instead?



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

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

[jira] [Commented] (SOLR-9196) Dead link on SolrConfigXml wiki page

[JIRA]

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

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

Should we not delete the contents of the page and instead put a link to 
https://cwiki.apache.org/confluence/display/solr/Configuring+solrconfig.xml
If there is crucial info in wiki that is not present in refGuide, we should 
update refGuide first?

> Dead link on SolrConfigXml wiki page
> 
>
> Key: SOLR-9196
> URL: https://issues.apache.org/jira/browse/SOLR-9196
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Steen Manniche
>Assignee: Stefan Matheis (steffkes)
>Priority: Trivial
>  Labels: documentation
>
> Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
> the example solrconfig.xml at 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
>  is a 404
> Should perhaps point to 
> https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
>  instead?



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

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

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[tomjon]

Github user tomjon commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66249148
  
--- Diff: solr/core/ivy.xml ---
@@ -61,15 +61,6 @@
 
 
 
-
-
-
-
-
 
--- End diff --

solr.core.src.java.org.apache.solr.security.KerberosFilter uses 
org.apache.hadoop.security.authentication.server.AuthenticationFilter from 
hadoop-auth JAR. That class is itself used by KerberosPlugin in the same package


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[tomjon]

Github user tomjon commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66247316
  
--- Diff: lucene/core/src/java/org/apache/lucene/store/Directory.java ---
@@ -165,4 +165,13 @@ public void copyFrom(Directory from, String src, 
String dest, IOContext context)
* @throws AlreadyClosedException if this Directory is closed
*/
   protected void ensureOpen() throws AlreadyClosedException {}
+  
--- End diff --

Now you mention it, I do remember wondering whether the blockcache package 
should move over to the contrib. I'll do that


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Lucene/Solr 6.1.0

[Adrien Grand]

I just created the 6.1.0 branch. Can someone help me with setting up Apache
and Policeman Jenkins to test this branch?

I still plan on cutting a first RC on Friday (in two days), please let me
know if you know about issues that should be included in 6.1.0.

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[romseygeek]

Github user romseygeek commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66244801
  
--- Diff: lucene/core/src/java/org/apache/lucene/store/Directory.java ---
@@ -165,4 +165,13 @@ public void copyFrom(Directory from, String src, 
String dest, IOContext context)
* @throws AlreadyClosedException if this Directory is closed
*/
   protected void ensureOpen() throws AlreadyClosedException {}
+  
--- End diff --

I think this means that org.apache.solr.store.blockcache also needs to 
move?  It's only used by the HDFS stuff, so far as I can tell.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7313) Remove DocValuesDocIdSet

[ASF subversion and git services (JIRA)]

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

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

Commit 73045a4cd8ea5f0c8c4f418b6fbe99a94a21cf4a in lucene-solr's branch 
refs/heads/master from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73045a4 ]

LUCENE-7313: Remove DocValuesDocIdSet.


> Remove DocValuesDocIdSet
> 
>
> Key: LUCENE-7313
> URL: https://issues.apache.org/jira/browse/LUCENE-7313
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0)
>
>
> This class is unused since we migrated the doc values filters to queries with 
> two-phase iteration.



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

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

[jira] [Comment Edited] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-5944 at 6/8/16 12:21 PM:
-

New patch. Fixes to TestInPlaceUpdatesStandalone (formerly TestInPlaceUpdate).

TODO items in the test are:
# Randomize the replay based tests.
# Add new tests that validate sorting, searching, filter queries involving the 
updated DV.


was (Author: ichattopadhyaya):
New patch. Fixes to TestInPlaceUpdatesStandalone (formerly TestInPlaceUpdate).

TODO items in the test are:
# Randomize the replay based tests.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[jira] [Resolved] (LUCENE-7313) Remove DocValuesDocIdSet

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7313.
--
   Resolution: Fixed
Fix Version/s: master (7.0)

> Remove DocValuesDocIdSet
> 
>
> Key: LUCENE-7313
> URL: https://issues.apache.org/jira/browse/LUCENE-7313
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0)
>
>
> This class is unused since we migrated the doc values filters to queries with 
> two-phase iteration.



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

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

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

New patch. Fixes to TestInPlaceUpdatesStandalone (formerly TestInPlaceUpdate).

TODO items in the test are:
# Randomize the replay based tests.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



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

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

[GitHub] lucene-solr pull request #34: Move hdfs stuff out into a new contrib

[tomjon]

Github user tomjon commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/34#discussion_r66244222
  
--- Diff: lucene/core/src/java/org/apache/lucene/store/Directory.java ---
@@ -165,4 +165,13 @@ public void copyFrom(Directory from, String src, 
String dest, IOContext context)
* @throws AlreadyClosedException if this Directory is closed
*/
   protected void ensureOpen() throws AlreadyClosedException {}
+  
--- End diff --

This change was made to eliminate the "instanceof HdfsDirectory" in the 
fileModified() method of BlockDirectory.  The polymorphism solution seemed 
best, but as you say, means modifying Lucene classes (all the relevant 
subclasses of Directory are in Lucene, except HdfsDirectory)...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7318) Graduate StandardAnalyzer out of analyzers module into core

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7318:
-

+1

> Graduate StandardAnalyzer out of analyzers module into core
> ---
>
> Key: LUCENE-7318
> URL: https://issues.apache.org/jira/browse/LUCENE-7318
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.2
>
>
> Spinoff from LUCENE-7314:
> {{StandardAnalyzer}} has progressed substantially since we broke out the 
> analyzers module ... it now follows a real Unicode standard (UAX #29 Unicode 
> Text Segmentation).  It's also much faster than it used to be, since it 
> switched to JFlex a while back.  Many bug fixes, etc.
> I think it would make a good default for most Lucene users, and we should 
> graduate it from the analyzers module into core, and make it the default for 
> {{IndexWriter}}.
> It's really quite crazy that users must go digging in the analyzers module to 
> get started with Lucene ... we don't make them dig through the codecs module 
> to find a good default codec ...



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

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

[jira] [Created] (LUCENE-7322) Remove CompressionTools

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7322:


 Summary: Remove CompressionTools
 Key: LUCENE-7322
 URL: https://issues.apache.org/jira/browse/LUCENE-7322
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: master (7.0)


We do not use this class internally, and codec-level compression of stored 
fields should be a better alternative since it has the ability to compress 
several documents/values at once.



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

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 634 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/634/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse

Error Message:
expected same: was not:

Stack Trace:
java.lang.AssertionError: expected same: was not:
at 
__randomizedtesting.SeedInfo.seed([6E7736ECD41ED287:34765300FA245F5E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at org.junit.Assert.assertSame(Assert.java:593)
at 
org.apache.solr.cloud.AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse(AsyncCallRequestStatusResponseTest.java:38)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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)
   

[jira] [Commented] (SOLR-8354) RecoveryStrategy retry timing is innaccurate

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8354:
---

SOLR-9045 would be related if we decide to make something configurable here.

> RecoveryStrategy retry timing is innaccurate
> 
>
> Key: SOLR-8354
> URL: https://issues.apache.org/jira/browse/SOLR-8354
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Drob
> Attachments: SOLR-8354.patch
>
>
> At the end of {{RecoveryStrategy::doRecovery}} there is a retry segment, with 
> a comment that suggests the code will {{// start at 1 sec and work up to a 
> min}}. The code will actually start at 10 seconds, and work up to 5 minutes. 
> Additionally, the log statement incorrectly reports how long the next wait 
> will be. Either the comment and log should be corrected or the logic adjusted.



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

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

[jira] [Updated] (SOLR-9161) SolrPluginUtils.invokeSetters should accommodate setter variants

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-9161:
--
Attachment: SOLR-9161.patch

Unable to reproduce the test failure locally (with that seed).

Attaching alternative patch using the java.beans.Introspector class as Uwe 
suggested, the tests pass locally for me (but then they also did so with the 
original patch).

Steve, Uwe - when you have a spare moment, would you mind applying/running the 
test locally to you? If all is well I'd be aiming to commit the change sometime 
next week.

> SolrPluginUtils.invokeSetters should accommodate setter variants
> 
>
> Key: SOLR-9161
> URL: https://issues.apache.org/jira/browse/SOLR-9161
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9161.patch, SOLR-9161.patch
>
>
> The code currently assumes that there is only one setter (or if there are 
> several setters then the first one found is used and it could mismatch on the 
> arg type).
> Context and motivation is that a class with a
> {code}
> void setAFloat(float val) {
>   this.val = val;
> }
> {code}
> setter may wish to also provide a
> {code}
> void setAFloat(String val) {
>   this.val = Float.parseFloat(val);
> }
> {code}
> convenience setter.



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

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

[jira] [Resolved] (SOLR-9196) Dead link on SolrConfigXml wiki page

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) resolved SOLR-9196.
-
Resolution: Fixed

I've fixed the link you've mentioned and another one pointing to the very same 
broken destination - it's currently persisting, which takes quite some time. 
just so you're not wondering why the change itself might not yet be visible.

Since the Solr Wiki is maintained by the Community, you can always get an 
account and help improve the documentation on your own [~steen.manniche] - if 
you like to do so, drop a short note on the mailing list requesting access as 
wiki contributor.

> Dead link on SolrConfigXml wiki page
> 
>
> Key: SOLR-9196
> URL: https://issues.apache.org/jira/browse/SOLR-9196
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Steen Manniche
>Assignee: Stefan Matheis (steffkes)
>Priority: Trivial
>  Labels: documentation
>
> Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
> the example solrconfig.xml at 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
>  is a 404
> Should perhaps point to 
> https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
>  instead?



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

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

[jira] [Assigned] (SOLR-9196) Dead link on SolrConfigXml wiki page

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) reassigned SOLR-9196:
---

Assignee: Stefan Matheis (steffkes)

> Dead link on SolrConfigXml wiki page
> 
>
> Key: SOLR-9196
> URL: https://issues.apache.org/jira/browse/SOLR-9196
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Steen Manniche
>Assignee: Stefan Matheis (steffkes)
>Priority: Trivial
>  Labels: documentation
>
> Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
> the example solrconfig.xml at 
> https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
>  is a 404
> Should perhaps point to 
> https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
>  instead?



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 87 - Still Failing

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=207586, name=collection1, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=207586, name=collection1, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:43784/z: collection already exists: 
awholynewstresscollection_collection1_3
at __randomizedtesting.SeedInfo.seed([92B1F4F0A1883F9]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1599)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1620)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:987)


FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=200747, name=collection5, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=200747, name=collection5, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:35922/gqx/tw: Could not find collection : 
awholynewstresscollection_collection5_6
at __randomizedtesting.SeedInfo.seed([92B1F4F0A1883F9]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1228)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:994)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([92B1F4F0A1883F9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 16945 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16945/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{ "a":"A 
val", "b":"B val", "wt":"json", "useParams":""},   "context":{ 
"webapp":"", "path":"/dump1", "httpMethod":"GET"}},  from server:  
https://127.0.0.1:39883/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{
"a":"A val",
"b":"B val",
"wt":"json",
"useParams":""},
  "context":{
"webapp":"",
"path":"/dump1",
"httpMethod":"GET"}},  from server:  https://127.0.0.1:39883/collection1
at 
__randomizedtesting.SeedInfo.seed([C804E71256A6F2C1:4050D8C8F85A9F39]: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:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:172)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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)
  

[jira] [Created] (SOLR-9196) Dead link on SolrConfigXml wiki page

[Steen Manniche (JIRA)]

Steen Manniche created SOLR-9196:


 Summary: Dead link on SolrConfigXml wiki page
 Key: SOLR-9196
 URL: https://issues.apache.org/jira/browse/SOLR-9196
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Steen Manniche
Priority: Trivial


Under the headline http://wiki.apache.org/solr/SolrConfigXml#lib the link to 
the example solrconfig.xml at 
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/example/solr/collection1/conf/solrconfig.xml
 is a 404

Should perhaps point to 
https://raw.githubusercontent.com/apache/lucene-solr/master/solr/example/files/conf/solrconfig.xml
 instead?



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

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