[jira] [Resolved] (SOLR-10304) Refactor Document/Stored-field handling out of SolrIndexSearcher

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-10304.
-
   Resolution: Fixed
Fix Version/s: 6.6

> Refactor Document/Stored-field handling out of SolrIndexSearcher
> 
>
> Key: SOLR-10304
> URL: https://issues.apache.org/jira/browse/SOLR-10304
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.6
>
> Attachments: SOLR_10304_SolrDocumentFetcher.patch, 
> SOLR_10304_SolrDocumentFetcher.patch
>
>
> SolrIndexSearcher is nearly 3 thousand lines of code.  A sizable part of it 
> pertains to Document handling, including various stored-field concerns and 
> docValue substitutions (docValueAsStored related).  There are already 
> comments marking the start and end of this part of SolrIndexSearcher, plus 
> there some fields and their initialization that are only in support of those 
> methods.  I propose that all of this go to a new companion class 
> {{SolrDocumentFetcher}}. SolrIndexSearcher can add a getter for it, and where 
> applicable existing callers can call to this instead.  "Override"'s will need 
> to stay of course.
> ( Originally proposed in SOLR-10286 )



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

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

[jira] [Commented] (SOLR-10304) Refactor Document/Stored-field handling out of SolrIndexSearcher

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10304:


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

SOLR-10304: Refactor new SolrDocumentFetcher out of SolrIndexSearcher

(cherry picked from commit f1aef3d)


> Refactor Document/Stored-field handling out of SolrIndexSearcher
> 
>
> Key: SOLR-10304
> URL: https://issues.apache.org/jira/browse/SOLR-10304
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10304_SolrDocumentFetcher.patch, 
> SOLR_10304_SolrDocumentFetcher.patch
>
>
> SolrIndexSearcher is nearly 3 thousand lines of code.  A sizable part of it 
> pertains to Document handling, including various stored-field concerns and 
> docValue substitutions (docValueAsStored related).  There are already 
> comments marking the start and end of this part of SolrIndexSearcher, plus 
> there some fields and their initialization that are only in support of those 
> methods.  I propose that all of this go to a new companion class 
> {{SolrDocumentFetcher}}. SolrIndexSearcher can add a getter for it, and where 
> applicable existing callers can call to this instead.  "Override"'s will need 
> to stay of course.
> ( Originally proposed in SOLR-10286 )



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

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

[jira] [Resolved] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-10249.
-
   Resolution: Fixed
 Assignee: David Smiley
Fix Version/s: (was: 6.5)
   6.6

> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Assignee: David Smiley
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.6
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10249:


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

SOLR-10249: Refactor IndexFetcher to return detailed result

(cherry picked from commit 8664f1f)


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[jira] [Commented] (SOLR-10304) Refactor Document/Stored-field handling out of SolrIndexSearcher

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10304:


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

SOLR-10304: Refactor new SolrDocumentFetcher out of SolrIndexSearcher


> Refactor Document/Stored-field handling out of SolrIndexSearcher
> 
>
> Key: SOLR-10304
> URL: https://issues.apache.org/jira/browse/SOLR-10304
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10304_SolrDocumentFetcher.patch, 
> SOLR_10304_SolrDocumentFetcher.patch
>
>
> SolrIndexSearcher is nearly 3 thousand lines of code.  A sizable part of it 
> pertains to Document handling, including various stored-field concerns and 
> docValue substitutions (docValueAsStored related).  There are already 
> comments marking the start and end of this part of SolrIndexSearcher, plus 
> there some fields and their initialization that are only in support of those 
> methods.  I propose that all of this go to a new companion class 
> {{SolrDocumentFetcher}}. SolrIndexSearcher can add a getter for it, and where 
> applicable existing callers can call to this instead.  "Override"'s will need 
> to stay of course.
> ( Originally proposed in SOLR-10286 )



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

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

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10249:


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

SOLR-10249: Refactor IndexFetcher to return detailed result


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 6 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper, InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:484)  
at org.apache.solr.core.SolrCore.(SolrCore.java:925)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:849)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:950)  at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:583)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:406)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:278) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:408) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$2(ReplicationHandler.java:1154)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1021)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:642)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1139)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:822) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:406)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:278) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:408) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$2(ReplicationHandler.java:1154)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:353)  at 

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

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

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

Commit 07479e9414cbe040de008bafef6aed9133cfb9cb in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=07479e9 ]

SOLR-7452: add support for _m buckets, missing and has sub-facets in need of 
refinement


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



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

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

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7452: add support for _m buckets, missing and has sub-facets in need of 
refinement


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6472/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestUseDocValuesAsStored2

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core\data

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core\data
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores\core
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003\cores
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_2CAE778C6449172B-001\tempDir-003

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




Build Log:
[...truncated 12890 lines...]
   [junit4] Suite: org.apache.solr.schema.TestUseDocValuesAsStored2
   [junit4]   2> Creating dataDir: 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3140/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=864, name=Lucene Merge 
Thread #2, state=RUNNABLE, group=TGRP-TestIndexWriterExceptions]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=864, name=Lucene Merge Thread #2, 
state=RUNNABLE, group=TGRP-TestIndexWriterExceptions]
Caused by: org.apache.lucene.index.MergePolicy$MergeException: 
org.apache.lucene.store.MockDirectoryWrapper$FakeIOException
at __randomizedtesting.SeedInfo.seed([44938B34BDB1D495]:0)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:703)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:683)
Caused by: org.apache.lucene.store.MockDirectoryWrapper$FakeIOException
at 
org.apache.lucene.index.TestIndexWriterExceptions$11.eval(TestIndexWriterExceptions.java:1875)
at 
org.apache.lucene.store.MockDirectoryWrapper.maybeThrowDeterministicException(MockDirectoryWrapper.java:1022)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:144)
at 
org.apache.lucene.store.MockIndexOutputWrapper.writeByte(MockIndexOutputWrapper.java:126)
at org.apache.lucene.store.DataOutput.writeInt(DataOutput.java:71)
at org.apache.lucene.codecs.CodecUtil.writeHeader(CodecUtil.java:92)
at 
org.apache.lucene.codecs.CodecUtil.writeIndexHeader(CodecUtil.java:133)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesConsumer.(Lucene54DocValuesConsumer.java:74)
at 
org.apache.lucene.codecs.lucene54.Lucene54DocValuesFormat.fieldsConsumer(Lucene54DocValuesFormat.java:108)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.getInstance(PerFieldDocValuesFormat.java:213)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.addNumericField(PerFieldDocValuesFormat.java:111)
at 
org.apache.lucene.index.ReadersAndUpdates.handleNumericDVUpdates(ReadersAndUpdates.java:328)
at 
org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:521)
at 
org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:272)
at org.apache.lucene.index.IndexWriter._mergeInit(IndexWriter.java:4109)
at org.apache.lucene.index.IndexWriter.mergeInit(IndexWriter.java:4065)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3919)
at 
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:624)
at 
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:661)


FAILED:  
org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates

Error Message:
this IndexWriter is closed

Stack Trace:
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at 
__randomizedtesting.SeedInfo.seed([44938B34BDB1D495:2DE889BF4B1F1ED5]:0)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:747)
at org.apache.lucene.index.IndexWriter.getConfig(IndexWriter.java:1087)
at 
org.apache.lucene.index.TestIndexWriterExceptions.testNoLostDeletesOrUpdates(TestIndexWriterExceptions.java:1992)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.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 

[VOTE] Release Lucene/Solr 6.5.0 RC1

[jim ferenczi]

This vote has passed, I'll start the rest of the release process and
announce the release on Monday.
Thanks to all who voted.

Le 24 mars 2017 21:01, "Tommaso Teofili"  a
écrit :

+1 SUCCESS [1:24:22.418315]

Il giorno ven 24 mar 2017 alle ore 19:23 Martijn v Groningen <
martijn.v.gronin...@gmail.com> ha scritto:

> +1 SUCCESS! [1:16:42.421075]
>
> On 24 March 2017 at 17:11, Steve Rowe  wrote:
>
> +1
>
> Lucene changes, docs and javadocs look good.  The smoke tester passed for
> me (I’ve lost the timing, sorry, was like 28 minutes).
>
> Solr’s HTML changes, docs and javadocs have moved online (see SOLR-9450),
> and so aren’t part of the release artifacts.  I think vetting these docs
> can happen separately from the release vote - it’ll be kosher to fix if
> necessary after a release, since they are excluded from the release vote.
>
> --
> Steve
> www.lucidworks.com
>
> > On Mar 22, 2017, at 3:39 PM, Andi Vajda  wrote:
> >
> >
> > On Tue, 21 Mar 2017, jim ferenczi wrote:
> >
> >> Please vote for release candidate 1 for Lucene/Solr 6.5.0
> >
> > +1
> >
> > I checked out branch_6_5 and built PyLucene with it, all tests pass.
> >
> > Andi..
> >
> >>
> >> The artifacts can be downloaded from:
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.
> 5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.
> 5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> Here's my +1
> >> SUCCESS! [0:49:02.989006 <02%20989006>]
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen
>

Re: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3138 - Unstable!

[Chris Hostetter]

https://issues.apache.org/jira/browse/SOLR-10362

: Date: Fri, 24 Mar 2017 15:55:28 + (UTC)
: From: Policeman Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_121) - Build # 3138 -
:  Unstable!
: 
: Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3138/
: Java: 32bit/jdk1.8.0_121 -server -XX:+UseConcMarkSweepGC
: 
: 2 tests failed.
: FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testCompact
: 
: Error Message:
: Memory Pool not found
: 
: Stack Trace:
: java.lang.InternalError: Memory Pool not found
:   at 
__randomizedtesting.SeedInfo.seed([8F4813A324434093:A1485FF45CBE4A6C]:0)
:   at sun.management.MemoryPoolImpl.getUsage0(Native Method)
:   at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:96)
:   at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:177)
:   at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:174)
:   at 
org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:215)
:   at 
org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:142)
:   at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
:   at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
:   at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
:   at java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)
:   at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
:   at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
:   at 
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
:   at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
:   at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
:   at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
:   at org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:135)
:   at 
org.apache.solr.util.stats.MetricUtils.toNamedList(MetricUtils.java:117)
:   at 
org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:85)
:   at 
org.apache.solr.handler.admin.MetricsHandlerTest.testCompact(MetricsHandlerTest.java:160)
:   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
:   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
:   at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
:   at java.lang.reflect.Method.invoke(Method.java:498)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
:   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
:   at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
:   at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
:   at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
:   at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
:   at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
:   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
:   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
:   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
:   at 

[jira] [Created] (SOLR-10362) "Memory Pool not found" error when reporting JVM metrics

[Andrzej Bialecki (JIRA)]

Andrzej Bialecki  created SOLR-10362:


 Summary: "Memory Pool not found" error when reporting JVM metrics
 Key: SOLR-10362
 URL: https://issues.apache.org/jira/browse/SOLR-10362
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: metrics
Affects Versions: 6.5, master (7.0)
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 


These test failures are likely caused by a JVM bug. We should catch and work 
around it to be able report other existing metrics:
{code}
https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3138/testReport/junit/org.apache.solr.handler.admin/MetricsHandlerTest/testCompact/

java.lang.InternalError: Memory Pool not found
at 
__randomizedtesting.SeedInfo.seed([8F4813A324434093:A1485FF45CBE4A6C]:0)
at sun.management.MemoryPoolImpl.getUsage0(Native Method)
at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:96)
at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:177)
at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:174)
at 
org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:215)
at 
org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:142)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:135)
at 
org.apache.solr.util.stats.MetricUtils.toNamedList(MetricUtils.java:117)
at 
org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:85)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testCompact(MetricsHandlerTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}

See here for a possible explanation (thanks Hoss!): 
https://bugs.openjdk.java.net/browse/JDK-8025089



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

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

[jira] [Commented] (SOLR-10361) Add a solr-docs.tar.gz file

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10361:
---

Okay, what you say makes sense, Uwe.

> Add a solr-docs.tar.gz file
> ---
>
> Key: SOLR-10361
> URL: https://issues.apache.org/jira/browse/SOLR-10361
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Uwe Schindler
>
> On SOLR-9450 we decided to add a separate documentation package to the Solr 
> downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
> file should contain Lucene and Solr Javadocs.
> This would solve the following problems:
> - People can still download Javadocs, if they like to browse them offline, 
> but it won't blow the release
> - The release manager has an easier job to push them to the website. The 
> current process broke by SOLR-9450.



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

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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Tommaso Teofili]

+1 SUCCESS [1:24:22.418315]

Il giorno ven 24 mar 2017 alle ore 19:23 Martijn v Groningen <
martijn.v.gronin...@gmail.com> ha scritto:

> +1 SUCCESS! [1:16:42.421075]
>
> On 24 March 2017 at 17:11, Steve Rowe  wrote:
>
> +1
>
> Lucene changes, docs and javadocs look good.  The smoke tester passed for
> me (I’ve lost the timing, sorry, was like 28 minutes).
>
> Solr’s HTML changes, docs and javadocs have moved online (see SOLR-9450),
> and so aren’t part of the release artifacts.  I think vetting these docs
> can happen separately from the release vote - it’ll be kosher to fix if
> necessary after a release, since they are excluded from the release vote.
>
> --
> Steve
> www.lucidworks.com
>
> > On Mar 22, 2017, at 3:39 PM, Andi Vajda  wrote:
> >
> >
> > On Tue, 21 Mar 2017, jim ferenczi wrote:
> >
> >> Please vote for release candidate 1 for Lucene/Solr 6.5.0
> >
> > +1
> >
> > I checked out branch_6_5 and built PyLucene with it, all tests pass.
> >
> > Andi..
> >
> >>
> >> The artifacts can be downloaded from:
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> Here's my +1
> >> SUCCESS! [0:49:02.989006 <02%20989006>]
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>
> --
> Met vriendelijke groet,
>
> Martijn van Groningen
>

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:44 PM:


The patch that was just added does the following:

1) It aligns the *facet* and *map_reduce* aggregation outputs fixing SOLR-9372. 
Now both approaches output a long when sum, min, max are applied to long 
fields. 

2) The *avg* function now works on int fields. The avg function by default 
always returns a *rounded long* when averaging an int field. You can *cast* to 
return a double when averaging a long field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added aggregation support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the *facet* and *map_reduce* aggregation outputs fixing SOLR-9372. 
Now both approaches output a long when sum, min, max are applied to long 
fields. 

2) The *avg* function now works on int fields. The avg function by default 
always returns a *rounded long* when averaging an int field. You can *cast* to 
return a double when averaging a long field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Commented] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10341:
---

I'll do some manual testing before committing

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:42 PM:


The patch that was just added does the following:

1) It aligns the *facet* and *map_reduce* aggregation outputs fixing SOLR-9372. 
Now both approaches output a long when sum, min, max are applied to long 
fields. 

2) The *avg* function now works on int fields. The avg function by default 
always returns a *rounded long* when averaging an int field. You can *cast* to 
return a double when averaging a long field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) The avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a double when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:39 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) The avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a double when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) The avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:37 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) The avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:37 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a double is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:36 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:35 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), 
  cast(avg(1.0 * field_i) as float) 
  from collection1 where text='' group by str_s 
  order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), " +
  "cast(avg(1.0 * field_i) as float) from collection1 where text='' 
group by str_s " +
  "order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Comment Edited] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-10341 at 3/24/17 7:34 PM:


The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float when averaging a long 
field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), " +
  "cast(avg(1.0 * field_i) as float) from collection1 where text='' 
group by str_s " +
  "order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.


was (Author: joel.bernstein):
The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float from when averaging a 
long field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), " +
  "cast(avg(1.0 * field_i) as float) from collection1 where text='' 
group by str_s " +
  "order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Commented] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10341:
---

The patch that was just added does the following:

1) It aligns the facet and map_reduce aggregation outputs (SOLR-9372). Now both 
the approaches output a long when sum, min, max are applied to long fields. 

2) the avg function by default always returns a rounded long when averaging a 
long field. You can cast as following to return a float from when averaging a 
long field:

{code}
select str_s, count(*), sum(field_i), min(field_i), max(field_i), " +
  "cast(avg(1.0 * field_i) as float) from collection1 where text='' 
group by str_s " +
  "order by sum(field_i) asc limit 2
{code}

When averaging a float field a float is always returned.

3) Added support for tint, tlong and tdouble fields.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Updated] (SOLR-10341) SQL AVG function mis-interprets field type.

[Joel Bernstein (JIRA)]

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

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

Patch which addresses all the issues discussed in this ticket.

> SQL AVG function mis-interprets field type.
> ---
>
> Key: SOLR-10341
> URL: https://issues.apache.org/jira/browse/SOLR-10341
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.5
>Reporter: Timothy Potter
> Attachments: Screen Shot 2017-03-22 at 8.12.33 AM.png, 
> SOLR-10341.patch
>
>
> Using movielens data (users, movies, ratings), I tried the following SQL:
> {code}
> curl --data-urlencode "stmt=SELECT solr.title as title, avg(rating) as 
> avg_rating FROM ratings INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10" 
> "http://localhost:8983/solr/movies/sql?aggregationMode=facet;
> {code}
> Solr returns this error: 
> {code}
> {"result-set":{"docs":[{"EXCEPTION":"Failed to execute sqlQuery 'SELECT 
> solr.title as title, avg(rating) as avg_rating FROM ratings INNER JOIN 
> (select movie_id,title from movies where _query_='plot_txt_en:love') as solr 
> ON ratings.movie_id = solr.movie_id GROUP BY title ORDER BY avg_rating DESC 
> LIMIT 10' against JDBC connection 'jdbc:calcitesolr:'.\nError while executing 
> SQL \"SELECT solr.title as title, avg(rating) as avg_rating FROM ratings 
> INNER JOIN (select movie_id,title from movies where 
> _query_='plot_txt_en:love') as solr ON ratings.movie_id = solr.movie_id GROUP 
> BY title ORDER BY avg_rating DESC LIMIT 10\": From line 1, column 29 to line 
> 1, column 39: Cannot apply 'AVG' to arguments of type 'AVG( JAVA.LANG.STRING)>)'. Supported form(s): 
> 'AVG()'","EOF":true,"RESPONSE_TIME":92}]}}
> {code}
> rating is a TrieInt with docValues enabled.
> {code}
>  indexed="true" stored="true"/>
> {code}
> see screenshot



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

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

[jira] [Commented] (SOLR-10076) Hiding keystore and truststore passwords from /admin/info/* outputs

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10076:


Thanks [~manokovacs]! We missed 6.5, so I have to move the changes entry on 
master and then I'll close.

> Hiding keystore and truststore passwords from /admin/info/* outputs
> ---
>
> Key: SOLR-10076
> URL: https://issues.apache.org/jira/browse/SOLR-10076
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10076.6x.patch, SOLR-10076.patch, SOLR-10076.patch
>
>
> Passing keystore and truststore password is done by system properties, via 
> cmd line parameter.
> As result, {{/admin/info/properties}} and {{/admin/info/system}} will print 
> out the received password.
> Proposing solution to automatically redact value of any system property 
> before output, containing the word {{password}}, and replacing its value with 
> {{**}}.



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

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

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10338:


Good discussion on this, I don't have much to add at the moment. [~hossman] or 
[~ichattopadhyaya], feel free to grab this issue. Otherwise I'll wait and take 
a look at the next patch.

> Configure SecureRandom non blocking
> ---
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 4.9, 6.0
>
> Attachments: SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



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

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

[jira] [Commented] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10360:
---

GitHub user hgadre opened a pull request:

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

[SOLR-10360] Remove an extra space from Hadoop distcp cmd used by Sol…

…r backup/restore

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgadre/lucene-solr SOLR-10360_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/173.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #173


commit ae9c60094e3007e3bac42a222f47c296abf8adae
Author: Hrishikesh Gadre 
Date:   2017-03-24T18:47:56Z

[SOLR-10360] Remove an extra space from Hadoop distcp cmd used by Solr 
backup/restore




> Solr HDFS snapshot export fails due to FileNotFoundException error
> --
>
> Key: SOLR-10360
> URL: https://issues.apache.org/jira/browse/SOLR-10360
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
> Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> The Solr snapshot export command (implemented in the snapshotscli.sh) uses 
> Hadoop distcp tool to copy the Solr index files to the desired location. When 
> the cluster is configured with MR1 framework (instead of YARN), this command 
> fails with following error,
> {noformat}
> Err:With failures, global counters are inaccurate; consider running with -i
> Copy failed: java.io.FileNotFoundException: File does not exist: 
> /user/systest/ /backups/mysnap/copylistings/shard1
>   at 
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
>   at 
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
> {noformat}
> During investigation I found that an extra space in the distcp command was 
> causing this failure. For example,
> This command fails with the error mentioned above,
> {noformat}
> hadoop distcp -f  ' /backups/mysnap/copylistings/shard1' 
> /backups/mysnap/snapshot.shard1
> {noformat}
> Removing the space from the copylisting directory path fixes this issue.
> {noformat}
> hadoop distcp -f  '/backups/mysnap/copylistings/shard1' 
> /backups/mysnap/snapshot.shard1
> {noformat}



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

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

[GitHub] lucene-solr pull request #173: [SOLR-10360] Remove an extra space from Hadoo...

[hgadre]

GitHub user hgadre opened a pull request:

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

[SOLR-10360] Remove an extra space from Hadoop distcp cmd used by Sol…

…r backup/restore

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgadre/lucene-solr SOLR-10360_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/173.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #173


commit ae9c60094e3007e3bac42a222f47c296abf8adae
Author: Hrishikesh Gadre 
Date:   2017-03-24T18:47:56Z

[SOLR-10360] Remove an extra space from Hadoop distcp cmd used by Solr 
backup/restore




---
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] (SOLR-10361) Add a solr-docs.tar.gz file

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10361:
--

It is open for discussion! :-)

Previously we only had Solr Documentation and a link to the Lucene online 
version, which was far from ideal. The idea is to have both in one file for 
Solr users. Lucene already has its own docs in its own tar.gz file (there is no 
change). This is why I opened it in Solr's project. It is for publishing the 
"full Solr documentation" (which must include Lucene for navigation purposes).

> Add a solr-docs.tar.gz file
> ---
>
> Key: SOLR-10361
> URL: https://issues.apache.org/jira/browse/SOLR-10361
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Uwe Schindler
>
> On SOLR-9450 we decided to add a separate documentation package to the Solr 
> downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
> file should contain Lucene and Solr Javadocs.
> This would solve the following problems:
> - People can still download Javadocs, if they like to browse them offline, 
> but it won't blow the release
> - The release manager has an easier job to push them to the website. The 
> current process broke by SOLR-9450.



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9450:
--

Thanks for taking care, Uwe!

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Updated] (SOLR-1105) Use a different stored field for highlighting

[Julien Martin (JIRA)]

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

Julien Martin updated SOLR-1105:

Attachment: SOLR-1105.patch

> Use a different stored field for highlighting
> -
>
> Key: SOLR-1105
> URL: https://issues.apache.org/jira/browse/SOLR-1105
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Dmitry Lihachev
>Assignee: David Smiley
> Attachments: SOLR-1105-1_4_1.patch, SOLR-1105.patch, 
> SOLR-1105_shared_content_field_1.3.0.patch
>
>
> DefaultSolrHighlighter uses stored field content to highlight. It has some 
> disadvantages, because index grows up fast when using multilingual indexing 
> due to several fields has to be stored with same content. This patch allows 
> DefaultSolrHighlighter to use "contentField" attribute to loockup content in 
> external field.
> Excerpt from old schema:
> {code:xml}
> 
> 
> 
> 
> {code}
> The same after patching, highlighter will now get content stored in "title" 
> field
> {code:xml}
> 
>  contentField="title"/>
>  contentField="title"/>
>  contentField="title"/>
> {code}



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

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

[jira] [Updated] (SOLR-1105) Use a different stored field for highlighting

[Julien Martin (JIRA)]

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

Julien Martin updated SOLR-1105:

Attachment: (was: SOLR-1105.patch)

> Use a different stored field for highlighting
> -
>
> Key: SOLR-1105
> URL: https://issues.apache.org/jira/browse/SOLR-1105
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Dmitry Lihachev
>Assignee: David Smiley
> Attachments: SOLR-1105-1_4_1.patch, SOLR-1105.patch, 
> SOLR-1105_shared_content_field_1.3.0.patch
>
>
> DefaultSolrHighlighter uses stored field content to highlight. It has some 
> disadvantages, because index grows up fast when using multilingual indexing 
> due to several fields has to be stored with same content. This patch allows 
> DefaultSolrHighlighter to use "contentField" attribute to loockup content in 
> external field.
> Excerpt from old schema:
> {code:xml}
> 
> 
> 
> 
> {code}
> The same after patching, highlighter will now get content stored in "title" 
> field
> {code:xml}
> 
>  contentField="title"/>
>  contentField="title"/>
>  contentField="title"/>
> {code}



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

OK, changed the release documentation: 
https://wiki.apache.org/lucene-java/ReleaseTodo#Push_docs.2C_changes_and_javadocs_to_the_CMS_production_tree

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-10361) Add a solr-docs.tar.gz file

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10361:
---

Since the idea is to include both Lucene and Solr docs in the docs package: a) 
this issue's title says "solr-docs.tar.gz" but I think it should be 
"docs.tar.gz"?  And b) maybe this should be a LUCENE issue instead of a SOLR 
one?

> Add a solr-docs.tar.gz file
> ---
>
> Key: SOLR-10361
> URL: https://issues.apache.org/jira/browse/SOLR-10361
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Uwe Schindler
>
> On SOLR-9450 we decided to add a separate documentation package to the Solr 
> downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
> file should contain Lucene and Solr Javadocs.
> This would solve the following problems:
> - People can still download Javadocs, if they like to browse them offline, 
> but it won't blow the release
> - The release manager has an easier job to push them to the website. The 
> current process broke by SOLR-9450.



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

I will now update the release docs.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

I opened SOLR-10361 for the solr-docs.tgz file.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Updated] (SOLR-10361) Add a solr-docs.tar.gz file

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-10361:
-
Description: 
On SOLR-9450 we decided to add a separate documentation package to the Solr 
downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
file should contain Lucene and Solr Javadocs.

This would solve the following problems:
- People can still download Javadocs, if they like to browse them offline, but 
it won't blow the release
- The release manager has an easier job to push them to the website. The 
current process broke by SOLR-9450.

  was:
On SOLR-6806 we decided to add a separate documentation package to the Solr 
downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
file should contain Lucene and Solr Javadocs.

This would solve the following problems:
- People can still download Javadocs, if they like to browse them offline, but 
it won't blow the release
- The release manager has an easier job to push them to the website. The 
current process broke by SOLR-6806.


> Add a solr-docs.tar.gz file
> ---
>
> Key: SOLR-10361
> URL: https://issues.apache.org/jira/browse/SOLR-10361
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Uwe Schindler
>
> On SOLR-9450 we decided to add a separate documentation package to the Solr 
> downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
> file should contain Lucene and Solr Javadocs.
> This would solve the following problems:
> - People can still download Javadocs, if they like to browse them offline, 
> but it won't blow the release
> - The release manager has an easier job to push them to the website. The 
> current process broke by SOLR-9450.



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

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

[jira] [Created] (SOLR-10361) Add a solr-docs.tar.gz file

[Uwe Schindler (JIRA)]

Uwe Schindler created SOLR-10361:


 Summary: Add a solr-docs.tar.gz file
 Key: SOLR-10361
 URL: https://issues.apache.org/jira/browse/SOLR-10361
 Project: Solr
  Issue Type: Sub-task
  Components: documentation
Reporter: Uwe Schindler


On SOLR-6806 we decided to add a separate documentation package to the Solr 
downloads. I did something similar for forbiddenapis, too. This docs.tar.gz 
file should contain Lucene and Solr Javadocs.

This would solve the following problems:
- People can still download Javadocs, if they like to browse them offline, but 
it won't blow the release
- The release manager has an easier job to push them to the website. The 
current process broke by SOLR-6806.



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

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

[jira] [Created] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error

[Hrishikesh Gadre (JIRA)]

Hrishikesh Gadre created SOLR-10360:
---

 Summary: Solr HDFS snapshot export fails due to 
FileNotFoundException error
 Key: SOLR-10360
 URL: https://issues.apache.org/jira/browse/SOLR-10360
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.3
 Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
Reporter: Hrishikesh Gadre
Priority: Minor


The Solr snapshot export command (implemented in the snapshotscli.sh) uses 
Hadoop distcp tool to copy the Solr index files to the desired location. When 
the cluster is configured with MR1 framework (instead of YARN), this command 
fails with following error,

{noformat}
Err:With failures, global counters are inaccurate; consider running with -i
Copy failed: java.io.FileNotFoundException: File does not exist: /user/systest/ 
/backups/mysnap/copylistings/shard1
at 
org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
at 
org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
at 
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
{noformat}

During investigation I found that an extra space in the distcp command was 
causing this failure. For example,

This command fails with the error mentioned above,

{noformat}
hadoop distcp -f  ' /backups/mysnap/copylistings/shard1' 
/backups/mysnap/snapshot.shard1
{noformat}

Removing the space from the copylisting directory path fixes this issue.
{noformat}
hadoop distcp -f  '/backups/mysnap/copylistings/shard1' 
/backups/mysnap/snapshot.shard1
{noformat}




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

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

[jira] [Commented] (SOLR-10359) User Events Logger Component

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10359:
--

There seem to be two things mixed in here:

* Logging the search queries and results received (either as count or as 
specific ids). And - maybe - statistics on that.
* User interactions on front-end

The first item can probably be solved with a SearchComponent and I would love 
to see what that could look like. Especially if it is flexible enough to be 
also used for debugging.

The second one seems to be happening well out of Solr control (UI clicks, what 
user selected, etc). I am not sure if that fits into Solr itself. Commercial 
platforms (such as Fusion) might be integrating it, but they control more of a 
stack.



> User Events Logger Component
> 
>
> Key: SOLR-10359
> URL: https://issues.apache.org/jira/browse/SOLR-10359
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alessandro Benedetti
>  Labels: CTR, evaluation
>
> *Introduction*
> Being able to evaluate the quality of your search engine is becoming more and 
> more important day by day.
> This issue is to put a milestone to integrate online evaluation metrics with 
> Solr.
> *Scope*
> Scope of this issue is to provide a set of components able to :
> 1) Collect Search Results impressions ( results shown per query)
> 2) Collect Users events ( user interactions on the search results per query 
> e.g. clicks, bookmarking,ect )
> 3) Calculate evaluation metrics on demand, such as Click Through Rate, DCG ...
> *Technical Design*
> A SearchComponent can be designed :
> *UsersEventsLoggerComponent*
> A property (such as storeDir) will define where the data collected will be 
> stored.
> Different data structures can be explored, to keep it simple, a first 
> implementation can be a Lucene Index.
> *Data Model*
> The user event can be modelled in the following way :
>  - the user query the event is related to
>  - the ID of the search result involved in the interaction
>  - the position in the ranking of the search result involved 
> in the interaction
>  - time when the interaction happened
>  - 0 for impressions, a value between 1-5 to identify the 
> type of user event, the semantic will depend on the domain and use cases
>  - this can identify a variant, in A/B testing
> *Impressions Logging*
> When the SearchComponent  is assigned to a request handler, everytime it 
> processes a request and return to the user a result set for a query, the 
> component will collect the impressions ( results returned) and index them in 
> the auxiliary lucene index.
> This will happen in parallel as soon as you return the results to avoid 
> affecting the query time.
> Of course an impact on CPU load and memory is expected, will be interesting 
> to minimise it.
> * User Events Logging *
> An UpdateHandler will be exposed to accept POST requests and collect user 
> events.
> Everytime a request is sent, the user event will be indexed in the underline 
> auxiliary Lucene Index.
> * Stats Calculation *
> A RequestHandler will be exposed to be able to calculate stats and 
> aggregations for the metrics :
> /evaluation?metric=ctr=query=testA,testB
> This request could calculate the CTR for our testA and testB to compare.
> Showing stats in total and per query ( to highlight the queries with 
> lower/higher CTR).
> The calculations will happen separating the  for an easy 
> comparison.
> Will be important to keep it as simple as possible for a first version, to 
> then extend it as much as we like



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

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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Martijn v Groningen]

+1 SUCCESS! [1:16:42.421075]

On 24 March 2017 at 17:11, Steve Rowe  wrote:

> +1
>
> Lucene changes, docs and javadocs look good.  The smoke tester passed for
> me (I’ve lost the timing, sorry, was like 28 minutes).
>
> Solr’s HTML changes, docs and javadocs have moved online (see SOLR-9450),
> and so aren’t part of the release artifacts.  I think vetting these docs
> can happen separately from the release vote - it’ll be kosher to fix if
> necessary after a release, since they are excluded from the release vote.
>
> --
> Steve
> www.lucidworks.com
>
> > On Mar 22, 2017, at 3:39 PM, Andi Vajda  wrote:
> >
> >
> > On Tue, 21 Mar 2017, jim ferenczi wrote:
> >
> >> Please vote for release candidate 1 for Lucene/Solr 6.5.0
> >
> > +1
> >
> > I checked out branch_6_5 and built PyLucene with it, all tests pass.
> >
> > Andi..
> >
> >>
> >> The artifacts can be downloaded from:
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-
> rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> You can run the smoke tester directly with this command:
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-
> rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
> >>
> >> Here's my +1
> >> SUCCESS! [0:49:02.989006]
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Met vriendelijke groet,

Martijn van Groningen

[jira] [Commented] (SOLR-10076) Hiding keystore and truststore passwords from /admin/info/* outputs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10076:


Commit 81e85993bd32f6475e762086bbd4f32dec76ca53 in lucene-solr's branch 
refs/heads/branch_6x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81e8599 ]

SOLR-10076: Hide keystore and truststore passwords from /admin/info/* outputs.


> Hiding keystore and truststore passwords from /admin/info/* outputs
> ---
>
> Key: SOLR-10076
> URL: https://issues.apache.org/jira/browse/SOLR-10076
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10076.6x.patch, SOLR-10076.patch, SOLR-10076.patch
>
>
> Passing keystore and truststore password is done by system properties, via 
> cmd line parameter.
> As result, {{/admin/info/properties}} and {{/admin/info/system}} will print 
> out the received password.
> Proposing solution to automatically redact value of any system property 
> before output, containing the word {{password}}, and replacing its value with 
> {{**}}.



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9450:
--

bq. What do you think? I would prefer the first in later releases: Just make a 
docs tar.gz with Lucene and Solr docs? [this would be a future improvement]

+1

For now though the RM will likely have to checkout the release tag and rebuild 
the Solr docs prior to uploading to the website. 

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 24366 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/contrib/solr-uima/test/temp/junit4-J1-20170324_173726_2185983250556828500834.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  Internal Error (sharedRuntime.cpp:873), pid=45385, 
tid=0x4a03
   [junit4] #  guarantee(nm != NULL) failed: must have containing nmethod for 
implicit division-by-zero exceptions
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 
1.8.0_121-b13)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode 
bsd-amd64 compressed oops)
   [junit4] # Failed to write core dump. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/contrib/solr-uima/test/J1/hs_err_pid45385.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J1: EOF 

[...truncated 5 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/bin/java 
-XX:+UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/heapdumps -ea 
-esa -Dtests.prefix=tests -Dtests.seed=DEA5F8D470FEC450 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=6.6.0 
-Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/contrib/solr-uima/test/temp
 -Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build/clover/db
 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=6.6.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX 
-Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/contrib/solr-uima/test/J1
 -Djunit4.childvm.id=1 -Djunit4.childvm.count=2 -Dtests.leaveTemporary=false 
-Dtests.filterstacks=true -Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dfile.encoding=UTF-8 -classpath 

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10249:
---

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107959546
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

Yes, those sound good. I personally like **EXPECTING_NON_LEADER** better


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[tflobbe]

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107959546
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

Yes, those sound good. I personally like **EXPECTING_NON_LEADER** better


---
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] (SOLR-9515) Update to Hadoop 3

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9515:
--

The kite/morphlines/map-reduce contribs were removed in SOLR-9221 , which will 
affect the patch here greatly.

> Update to Hadoop 3
> --
>
> Key: SOLR-9515
> URL: https://issues.apache.org/jira/browse/SOLR-9515
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9515.patch
>
>
> Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. 
> I'll start up a dev branch.



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

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

[jira] [Comment Edited] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-9450 at 3/24/17 5:33 PM:
--

Ah, OK. Then that does not work. We have 2 possibilities:
- pack a tar.gz with only javadocs
- or the release person has to copy the javadocs away early, so they don't get 
changed after release was built (e.g. by pending commits in checkout or by 
running smoke tester,...).

What do you think? I would prefer the first in later releases: Just make a docs 
tar.gz with Lucene and Solr docs? [this would be a future improvement]


was (Author: thetaphi):
Ah, OK. Then that does not work. We have 2 possibilities:
- pack a tar.gz with only javadocs
- or the release person has to copy the javadocs away early, so they don't get 
changed after release was built (e.g. by pending commits in checkout) or by 
running smoke tester,...

What do you think? I would prefer the first in later releases: Just make a docs 
tar.gz with Lucene and Solr docs? [this would be a future improvement]

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

Ah, OK. Then that does not work. We have 2 possibilities:
- pack a tar.gz with only javadocs
- or the release person has to copy the javadocs away early, so they don't get 
changed after release was built (e.g. by pending commits in checkout) or by 
running smoke tester,...

What do you think? I would prefer the first in later releases: Just make a docs 
tar.gz with Lucene and Solr docs? [this would be a future improvement]

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-10356) Add Streaming Evaluators for basic math functions

[Vish Persaud (JIRA)]

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

Vish Persaud commented on SOLR-10356:
-

I think the scale will control placement of the decimal (10^1, 10^2, 10^-1, 
etc), as opposed to rounding.  Seems like rounding while retaining one or more 
decimal places would need to be handled by setting precision in BigDecimal.  In 
any case, not sure how performant that is, compared to say basic rounding to 
integers via Math.round().

> Add Streaming Evaluators for basic math functions
> -
>
> Key: SOLR-10356
> URL: https://issues.apache.org/jira/browse/SOLR-10356
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-10356.patch
>
>




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

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

[jira] [Closed] (SOLR-8049) MorphlineGoLiveMiniMRTest is failing about 50% of the time on my local Jenkins machine.

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-8049.

Resolution: Won't Fix

> MorphlineGoLiveMiniMRTest is failing about 50% of the time on my local 
> Jenkins machine.
> ---
>
> Key: SOLR-8049
> URL: https://issues.apache.org/jira/browse/SOLR-8049
> Project: Solr
>  Issue Type: Test
>  Components: contrib - MapReduce, contrib - morphlines-core
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> I am seeing two fails:
> {noformat}java.lang.AssertionError: expected:<0> but was:<-1>
>   at 
> __randomizedtesting.SeedInfo.seed([7AEAA2B65C8B6219:F2BE9D6CF2770FE1]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.failNotEquals(Assert.java:647)
>   at org.junit.Assert.assertEquals(Assert.java:128)
>   at org.junit.Assert.assertEquals(Assert.java:472)
>   at org.junit.Assert.assertEquals(Assert.java:456)
>   at 
> org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.test(MorphlineGoLiveMiniMRTest.java:551){noformat}
> and
> {noformat}
> java.io.IOException: java.net.ConnectException: Call From fullmetal/127.0.1.1 
> to fullmetal:0 failed on connection exception: java.net.ConnectException: 
> Connection refused; For more details see:  
> http://wiki.apache.org/hadoop/ConnectionRefused
>   at 
> __randomizedtesting.SeedInfo.seed([D236ECA21D1ECF9C:5A62D378B3E2A264]:0)
>   at 
> org.apache.hadoop.mapred.ClientServiceDelegate.invoke(ClientServiceDelegate.java:337)
>   at 
> org.apache.hadoop.mapred.ClientServiceDelegate.getJobStatus(ClientServiceDelegate.java:422)
>   at org.apache.hadoop.mapred.YARNRunner.getJobStatus(YARNRunner.java:575)
>   at org.apache.hadoop.mapreduce.Job$1.run(Job.java:325)
>   at org.apache.hadoop.mapreduce.Job$1.run(Job.java:322)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
>   at org.apache.hadoop.mapreduce.Job.updateStatus(Job.java:322)
>   at org.apache.hadoop.mapreduce.Job.isComplete(Job.java:610)
>   at 
> org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.test(MorphlineGoLiveMiniMRTest.java:404)
> {noformat}
> The first issue requires digging into the job logs to see what is actually 
> going wrong.
> The second may mean we need to raise the connect timeout YARN is using if 
> possible.



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

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

[jira] [Updated] (SOLR-8049) MorphlineGoLiveMiniMRTest is failing about 50% of the time on my local Jenkins machine.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-8049:
-
Component/s: contrib - morphlines-core
 contrib - MapReduce

> MorphlineGoLiveMiniMRTest is failing about 50% of the time on my local 
> Jenkins machine.
> ---
>
> Key: SOLR-8049
> URL: https://issues.apache.org/jira/browse/SOLR-8049
> Project: Solr
>  Issue Type: Test
>  Components: contrib - MapReduce, contrib - morphlines-core
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> I am seeing two fails:
> {noformat}java.lang.AssertionError: expected:<0> but was:<-1>
>   at 
> __randomizedtesting.SeedInfo.seed([7AEAA2B65C8B6219:F2BE9D6CF2770FE1]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.failNotEquals(Assert.java:647)
>   at org.junit.Assert.assertEquals(Assert.java:128)
>   at org.junit.Assert.assertEquals(Assert.java:472)
>   at org.junit.Assert.assertEquals(Assert.java:456)
>   at 
> org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.test(MorphlineGoLiveMiniMRTest.java:551){noformat}
> and
> {noformat}
> java.io.IOException: java.net.ConnectException: Call From fullmetal/127.0.1.1 
> to fullmetal:0 failed on connection exception: java.net.ConnectException: 
> Connection refused; For more details see:  
> http://wiki.apache.org/hadoop/ConnectionRefused
>   at 
> __randomizedtesting.SeedInfo.seed([D236ECA21D1ECF9C:5A62D378B3E2A264]:0)
>   at 
> org.apache.hadoop.mapred.ClientServiceDelegate.invoke(ClientServiceDelegate.java:337)
>   at 
> org.apache.hadoop.mapred.ClientServiceDelegate.getJobStatus(ClientServiceDelegate.java:422)
>   at org.apache.hadoop.mapred.YARNRunner.getJobStatus(YARNRunner.java:575)
>   at org.apache.hadoop.mapreduce.Job$1.run(Job.java:325)
>   at org.apache.hadoop.mapreduce.Job$1.run(Job.java:322)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
>   at org.apache.hadoop.mapreduce.Job.updateStatus(Job.java:322)
>   at org.apache.hadoop.mapreduce.Job.isComplete(Job.java:610)
>   at 
> org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.test(MorphlineGoLiveMiniMRTest.java:404)
> {noformat}
> The first issue requires digging into the job logs to see what is actually 
> going wrong.
> The second may mean we need to raise the connect timeout YARN is using if 
> possible.



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

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

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10249:
---

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107955318
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

Thanks @tflobbe .  I can make this simple change before committing today.  
Perhaps the constant should be SELF_LEADER_REPLICATE or EXPECTING_NON_LEADER ?  
Be my guest to make suggestions.


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107955318
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

Thanks @tflobbe .  I can make this simple change before committing today.  
Perhaps the constant should be SELF_LEADER_REPLICATE or EXPECTING_NON_LEADER ?  
Be my guest to make suggestions.


---
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] [Closed] (SOLR-9076) Update to Hadoop 2.7.2

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-9076.

Resolution: Fixed

Closing now that the kite/morphlines/map-reduce contribs have been removed, so 
the test failures are no longer an issue: SOLR-9221.

> Update to Hadoop 2.7.2
> --
>
> Key: SOLR-9076
> URL: https://issues.apache.org/jira/browse/SOLR-9076
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master (7.0), 6.2
>
> Attachments: SOLR-9076-Fix-dependencies.patch, 
> SOLR-9076-fixnetty.patch, SOLR-9076-Hack.patch, SOLR-9076.patch, 
> SOLR-9076.patch, SOLR-9076.patch, SOLR-9076.patch, SOLR-9076.patch, 
> SOLR-9076.patch
>
>




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

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

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10249:
---

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107954150
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

This message (and variable name) seems wrong. Looking at the case where 
this is thrown, it seems like this would happen if "OnlyLeaderIndexes" feature 
is being used, and this replica is the current leader. Message should be 
something like"Replicating from leader but I'm the shard leader"


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[tflobbe]

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

https://github.com/apache/lucene-solr/pull/169#discussion_r107954150
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean successful;
+private final Throwable exception;
+
+public static final String FAILED_BY_INTERRUPT_MESSAGE = "Fetching 
index failed by interrupt";
+public static final String FAILED_BY_EXCEPTION_MESSAGE = "Fetching 
index failed by exception";
+
+/** pre-defined results */
+public static final IndexFetchResult ALREADY_IN_SYNC = new 
IndexFetchResult("Local index commit is already in sync with peer", true, null);
+public static final IndexFetchResult INDEX_FETCH_FAILURE = new 
IndexFetchResult("Fetching lastest index is failed", false, null);
+public static final IndexFetchResult INDEX_FETCH_SUCCESS = new 
IndexFetchResult("Fetching latest index is successful", true, null);
+public static final IndexFetchResult LOCK_OBTAIN_FAILED = new 
IndexFetchResult("Obtaining SnapPuller lock failed", false, null);
+public static final IndexFetchResult MASTER_VERSION_ZERO = new 
IndexFetchResult("Index in peer is empty and never committed yet", true, null);
+public static final IndexFetchResult NO_INDEX_COMMIT_EXIST = new 
IndexFetchResult("No IndexCommit in local index", false, null);
+public static final IndexFetchResult PEER_INDEX_COMMIT_DELETED = new 
IndexFetchResult("No files to download because IndexCommit in peer was 
deleted", false, null);
+public static final IndexFetchResult LOCAL_ACTIVITY_DURING_REPLICATION 
= new IndexFetchResult("Local index modification during replication", false, 
null);
+public static final IndexFetchResult CORE_NODE_IS_NOT_LEADER = new 
IndexFetchResult("Core Name Name Equals Leader Replica Name", false, null);
--- End diff --

This message (and variable name) seems wrong. Looking at the case where 
this is thrown, it seems like this would happen if "OnlyLeaderIndexes" feature 
is being used, and this replica is the current leader. Message should be 
something like"Replicating from leader but I'm the shard leader"


---
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] (SOLR-5584) Update to Guava 15.0

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-5584:
--

Now that the kite/morphlines contribs have been removed (SOLR-9221), can this 
be reconsidered?  Or closed?

> Update to Guava 15.0
> 
>
> Key: SOLR-5584
> URL: https://issues.apache.org/jira/browse/SOLR-5584
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Priority: Minor
> Fix For: 6.0
>
>




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

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

[jira] [Updated] (SOLR-9073) MapReduce contrib is using single core conf layout that no longer seems to work.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9073:
-
Component/s: contrib - MapReduce

> MapReduce contrib is using single core conf layout that no longer seems to 
> work.
> 
>
> Key: SOLR-9073
> URL: https://issues.apache.org/jira/browse/SOLR-9073
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>
> The tests that catch this are nightly because they are so long, but our 
> nightlies fail always anyway. Need to add a test that does more but also very 
> little.



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

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

[jira] [Closed] (SOLR-9073) MapReduce contrib is using single core conf layout that no longer seems to work.

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-9073.

Resolution: Won't Fix

> MapReduce contrib is using single core conf layout that no longer seems to 
> work.
> 
>
> Key: SOLR-9073
> URL: https://issues.apache.org/jira/browse/SOLR-9073
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>
> The tests that catch this are nightly because they are so long, but our 
> nightlies fail always anyway. Need to add a test that does more but also very 
> little.



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

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

[jira] [Updated] (SOLR-5778) AbstractSolrMorphlineTestBase has issues with BuddhistCalendar

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5778:
-
Component/s: contrib - morphlines-core

> AbstractSolrMorphlineTestBase has issues with BuddhistCalendar
> --
>
> Key: SOLR-5778
> URL: https://issues.apache.org/jira/browse/SOLR-5778
> Project: Solr
>  Issue Type: Bug
>  Components: Build, contrib - morphlines-core
>Reporter: Robert Muir
>
> Somewhere, something isnt write locale-wise. For now I'll add an assume.
> {noformat}
> REGRESSION:  
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2
> Error Message:
> key:ignored_creation_date expected:<[2007-10-01T16:13:56Z]> but 
> was:<[1464-10-01T16:13:56Z]>
> Stack Trace:
> java.lang.AssertionError: key:ignored_creation_date 
> expected:<[2007-10-01T16:13:56Z]> but was:<[1464-10-01T16:13:56Z]>
> at 
> __randomizedtesting.SeedInfo.seed([ED5579F40B19071D:66D5C2140CEF94E3]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at 
> org.apache.solr.morphlines.solr.AbstractSolrMorphlineTestBase.testDocumentTypesInternal(AbstractSolrMorphlineTestBase.java:165)
> at 
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2(SolrCellMorphlineTest.java:255)
> {noformat}



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

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

[jira] [Closed] (SOLR-5778) AbstractSolrMorphlineTestBase has issues with BuddhistCalendar

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-5778.

Resolution: Won't Fix

> AbstractSolrMorphlineTestBase has issues with BuddhistCalendar
> --
>
> Key: SOLR-5778
> URL: https://issues.apache.org/jira/browse/SOLR-5778
> Project: Solr
>  Issue Type: Bug
>  Components: Build, contrib - morphlines-core
>Reporter: Robert Muir
>
> Somewhere, something isnt write locale-wise. For now I'll add an assume.
> {noformat}
> REGRESSION:  
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2
> Error Message:
> key:ignored_creation_date expected:<[2007-10-01T16:13:56Z]> but 
> was:<[1464-10-01T16:13:56Z]>
> Stack Trace:
> java.lang.AssertionError: key:ignored_creation_date 
> expected:<[2007-10-01T16:13:56Z]> but was:<[1464-10-01T16:13:56Z]>
> at 
> __randomizedtesting.SeedInfo.seed([ED5579F40B19071D:66D5C2140CEF94E3]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at 
> org.apache.solr.morphlines.solr.AbstractSolrMorphlineTestBase.testDocumentTypesInternal(AbstractSolrMorphlineTestBase.java:165)
> at 
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes2(SolrCellMorphlineTest.java:255)
> {noformat}



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

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

[jira] [Updated] (SOLR-10304) Refactor Document/Stored-field handling out of SolrIndexSearcher

[David Smiley (JIRA)]

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

David Smiley updated SOLR-10304:

Attachment: SOLR_10304_SolrDocumentFetcher.patch

Update patch with small changes pertaining to the move of 
SolrPluginUtils.docListToSolrDocumentList to the ClusteringComponent.  The test 
needed to move to which in turn required some additions to the CC's schema.xml.

All tests pass and ant precommit.  I'll commit this later today.

Further consolidation/moving around relative to RealTimeGetComponent can happen 
in another issue.

> Refactor Document/Stored-field handling out of SolrIndexSearcher
> 
>
> Key: SOLR-10304
> URL: https://issues.apache.org/jira/browse/SOLR-10304
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10304_SolrDocumentFetcher.patch, 
> SOLR_10304_SolrDocumentFetcher.patch
>
>
> SolrIndexSearcher is nearly 3 thousand lines of code.  A sizable part of it 
> pertains to Document handling, including various stored-field concerns and 
> docValue substitutions (docValueAsStored related).  There are already 
> comments marking the start and end of this part of SolrIndexSearcher, plus 
> there some fields and their initialization that are only in support of those 
> methods.  I propose that all of this go to a new companion class 
> {{SolrDocumentFetcher}}. SolrIndexSearcher can add a getter for it, and where 
> applicable existing callers can call to this instead.  "Override"'s will need 
> to stay of course.
> ( Originally proposed in SOLR-10286 )



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

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

[jira] [Closed] (SOLR-5668) Solr map-reduce should try and turn on hard auto commit by default to deal with the transaction log.

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-5668.

Resolution: Won't Fix

> Solr map-reduce should try and turn on hard auto commit by default to deal 
> with the transaction log.
> 
>
> Key: SOLR-5668
> URL: https://issues.apache.org/jira/browse/SOLR-5668
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> We still count on the transaction log to generate versions for us.



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

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

[jira] [Reopened] (SOLR-5668) Solr map-reduce should try and turn on hard auto commit by default to deal with the transaction log.

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-5668:
--

Re-opening to mark as "Won't Fix".

> Solr map-reduce should try and turn on hard auto commit by default to deal 
> with the transaction log.
> 
>
> Key: SOLR-5668
> URL: https://issues.apache.org/jira/browse/SOLR-5668
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> We still count on the transaction log to generate versions for us.



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

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

[jira] [Closed] (SOLR-5668) Solr map-reduce should try and turn on hard auto commit by default to deal with the transaction log.

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-5668.

   Resolution: Fixed
Fix Version/s: (was: 6.0)
   (was: 4.9)

> Solr map-reduce should try and turn on hard auto commit by default to deal 
> with the transaction log.
> 
>
> Key: SOLR-5668
> URL: https://issues.apache.org/jira/browse/SOLR-5668
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> We still count on the transaction log to generate versions for us.



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

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

[jira] [Updated] (SOLR-10359) User Events Logger Component

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti updated SOLR-10359:

Summary: User Events Logger Component  (was: Users Events Logger Component)

> User Events Logger Component
> 
>
> Key: SOLR-10359
> URL: https://issues.apache.org/jira/browse/SOLR-10359
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alessandro Benedetti
>  Labels: CTR, evaluation
>
> *Introduction*
> Being able to evaluate the quality of your search engine is becoming more and 
> more important day by day.
> This issue is to put a milestone to integrate online evaluation metrics with 
> Solr.
> *Scope*
> Scope of this issue is to provide a set of components able to :
> 1) Collect Search Results impressions ( results shown per query)
> 2) Collect Users events ( user interactions on the search results per query 
> e.g. clicks, bookmarking,ect )
> 3) Calculate evaluation metrics on demand, such as Click Through Rate, DCG ...
> *Technical Design*
> A SearchComponent can be designed :
> *UsersEventsLoggerComponent*
> A property (such as storeDir) will define where the data collected will be 
> stored.
> Different data structures can be explored, to keep it simple, a first 
> implementation can be a Lucene Index.
> *Data Model*
> The user event can be modelled in the following way :
>  - the user query the event is related to
>  - the ID of the search result involved in the interaction
>  - the position in the ranking of the search result involved 
> in the interaction
>  - time when the interaction happened
>  - 0 for impressions, a value between 1-5 to identify the 
> type of user event, the semantic will depend on the domain and use cases
>  - this can identify a variant, in A/B testing
> *Impressions Logging*
> When the SearchComponent  is assigned to a request handler, everytime it 
> processes a request and return to the user a result set for a query, the 
> component will collect the impressions ( results returned) and index them in 
> the auxiliary lucene index.
> This will happen in parallel as soon as you return the results to avoid 
> affecting the query time.
> Of course an impact on CPU load and memory is expected, will be interesting 
> to minimise it.
> * User Events Logging *
> An UpdateHandler will be exposed to accept POST requests and collect user 
> events.
> Everytime a request is sent, the user event will be indexed in the underline 
> auxiliary Lucene Index.
> * Stats Calculation *
> A RequestHandler will be exposed to be able to calculate stats and 
> aggregations for the metrics :
> /evaluation?metric=ctr=query=testA,testB
> This request could calculate the CTR for our testA and testB to compare.
> Showing stats in total and per query ( to highlight the queries with 
> lower/higher CTR).
> The calculations will happen separating the  for an easy 
> comparison.
> Will be important to keep it as simple as possible for a first version, to 
> then extend it as much as we like



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

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

[jira] [Updated] (SOLR-5668) Solr map-reduce should try and turn on hard auto commit by default to deal with the transaction log.

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5668:
-
Component/s: contrib - MapReduce

> Solr map-reduce should try and turn on hard auto commit by default to deal 
> with the transaction log.
> 
>
> Key: SOLR-5668
> URL: https://issues.apache.org/jira/browse/SOLR-5668
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, 6.0
>
>
> We still count on the transaction log to generate versions for us.



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

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

[jira] [Updated] (SOLR-5758) need ref guide doc on building indexes with mapreduce (morphlines-cell contrib)

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-5758:
-
Component/s: contrib - MapReduce

> need ref guide doc on building indexes with mapreduce (morphlines-cell 
> contrib)
> ---
>
> Key: SOLR-5758
> URL: https://issues.apache.org/jira/browse/SOLR-5758
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, documentation
>Reporter: Hoss Man
>Assignee: Mark Miller
>
> This is marked experimental for 4.7, but we should have a section on it in 
> the ref guide in 4.8



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

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

[jira] [Closed] (SOLR-5758) need ref guide doc on building indexes with mapreduce (morphlines-cell contrib)

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-5758.

   Resolution: Won't Fix
Fix Version/s: (was: 6.0)
   (was: 4.9)

> need ref guide doc on building indexes with mapreduce (morphlines-cell 
> contrib)
> ---
>
> Key: SOLR-5758
> URL: https://issues.apache.org/jira/browse/SOLR-5758
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, documentation
>Reporter: Hoss Man
>Assignee: Mark Miller
>
> This is marked experimental for 4.7, but we should have a section on it in 
> the ref guide in 4.8



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

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

[jira] [Updated] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[David Smiley (JIRA)]

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

David Smiley updated SOLR-10249:

Attachment: SOLR_10249.patch

Here's the patch.  All tests pass and precommit.  I'll commit later today.

Thanks for the contribution Jeff.

> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
> Attachments: SOLR_10249.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



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

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

[jira] [Created] (SOLR-10359) Users Events Logger Component

[Alessandro Benedetti (JIRA)]

Alessandro Benedetti created SOLR-10359:
---

 Summary: Users Events Logger Component
 Key: SOLR-10359
 URL: https://issues.apache.org/jira/browse/SOLR-10359
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Alessandro Benedetti


*Introduction*
Being able to evaluate the quality of your search engine is becoming more and 
more important day by day.
This issue is to put a milestone to integrate online evaluation metrics with 
Solr.

*Scope*
Scope of this issue is to provide a set of components able to :
1) Collect Search Results impressions ( results shown per query)
2) Collect Users events ( user interactions on the search results per query 
e.g. clicks, bookmarking,ect )
3) Calculate evaluation metrics on demand, such as Click Through Rate, DCG ...

*Technical Design*
A SearchComponent can be designed :
*UsersEventsLoggerComponent*
A property (such as storeDir) will define where the data collected will be 
stored.
Different data structures can be explored, to keep it simple, a first 
implementation can be a Lucene Index.
*Data Model*
The user event can be modelled in the following way :
 - the user query the event is related to
 - the ID of the search result involved in the interaction
 - the position in the ranking of the search result involved 
in the interaction
 - time when the interaction happened
 - 0 for impressions, a value between 1-5 to identify the 
type of user event, the semantic will depend on the domain and use cases
 - this can identify a variant, in A/B testing

*Impressions Logging*
When the SearchComponent  is assigned to a request handler, everytime it 
processes a request and return to the user a result set for a query, the 
component will collect the impressions ( results returned) and index them in 
the auxiliary lucene index.
This will happen in parallel as soon as you return the results to avoid 
affecting the query time.
Of course an impact on CPU load and memory is expected, will be interesting to 
minimise it.

* User Events Logging *
An UpdateHandler will be exposed to accept POST requests and collect user 
events.
Everytime a request is sent, the user event will be indexed in the underline 
auxiliary Lucene Index.

* Stats Calculation *
A RequestHandler will be exposed to be able to calculate stats and aggregations 
for the metrics :
/evaluation?metric=ctr=query=testA,testB
This request could calculate the CTR for our testA and testB to compare.
Showing stats in total and per query ( to highlight the queries with 
lower/higher CTR).
The calculations will happen separating the  for an easy comparison.

Will be important to keep it as simple as possible for a first version, to then 
extend it as much as we like



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

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

[jira] [Closed] (SOLR-7501) map-reduce index tool has timing bugs

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-7501.

Resolution: Won't Fix

> map-reduce index tool has timing bugs
> -
>
> Key: SOLR-7501
> URL: https://issues.apache.org/jira/browse/SOLR-7501
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Shenghua Wan
>Assignee: Mark Miller
>Priority: Minor
>
> map-reduce index tool has timing bugs in several classes.
> ^ is bitwise OR operator, not power function.
> bug fix is provided in https://github.com/apache/lucene-solr/pull/146



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

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

[jira] [Closed] (SOLR-8011) MapReduceIndexerTool uses 10^9 to convert nanos to seconds

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-8011.

   Resolution: Won't Fix
Fix Version/s: (was: 6.0)

> MapReduceIndexerTool uses 10^9 to convert nanos to seconds
> --
>
> Key: SOLR-8011
> URL: https://issues.apache.org/jira/browse/SOLR-8011
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Mike Drob
>Priority: Minor
> Attachments: SOLR-8011.patch
>
>
> MRIT incorrectly converts between nanos and seconds, inappropriately using a 
> bitwise operation instead of exponents.



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

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

[jira] [Closed] (SOLR-7946) After Solr 5.0, The script(set-map-reduce-classpath.sh) of MapReduceIndexTool should be made a change.

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-7946.

   Resolution: Won't Fix
Fix Version/s: (was: 6.0)
   (was: 5.5)

> After Solr 5.0, The script(set-map-reduce-classpath.sh) of MapReduceIndexTool 
> should be made a change.
> --
>
> Key: SOLR-7946
> URL: https://issues.apache.org/jira/browse/SOLR-7946
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.0, 5.2.1
>Reporter: davidchiu
>Priority: Minor
>
> The original code as following:
> [code]
> if [ ! -d "$solr_distrib/example/solr-webapp/webapp" ]; then
>unzip -o $solr_distrib/example/webapps/solr.war -d 
> $solr_distrib/example/solr-webapp/webapp
> fi
> 
> dir7=`absPath "$solr_distrib/example/solr-webapp/webapp/WEB-INF/lib"`
> [/code]
> It should be  changed to as following:
> [code]
> if [ ! -d "$solr_distrib/server/solr-webapp/webapp" ]; then
>unzip -o $solr_distrib/server/webapps/solr.war -d 
> $solr_distrib/server/solr-webapp/webapp
> fi
> 
> dir7=`absPath "$solr_distrib/server/solr-webapp/webapp/WEB-INF/lib"`
> [/code]



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

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

[jira] [Closed] (SOLR-8898) Solr mapreduce doesn't work in kerberized environment

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-8898.

Resolution: Won't Fix

> Solr mapreduce doesn't work in kerberized environment
> -
>
> Key: SOLR-8898
> URL: https://issues.apache.org/jira/browse/SOLR-8898
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: Kerberos
>Reporter: Łukasz Dywicki
>
> Jobs, skeltons and tools available in mapreduce do not work with Kerberos. Ie 
> MapReduceIndexerTool is breaking up at Golive phase when it needs to execute 
> HTTP action in kerberized solr. Entire story is written on hortonworks 
> community forum, however it affects solr in very same way.



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

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

[jira] [Closed] (SOLR-6230) SolrCellMorphlineTest.testSolrCellDocumentTypes failures on jenkins

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-6230.

Resolution: Won't Fix

> SolrCellMorphlineTest.testSolrCellDocumentTypes failures on jenkins
> ---
>
> Key: SOLR-6230
> URL: https://issues.apache.org/jira/browse/SOLR-6230
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
>
> This test fails frequently on jenkins.
> {code}
> 1 tests failed.
> FAILED:  
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes
> Error Message:
> key:ignored__attachment_mimetype expected:<[message/rfc822]> but 
> was:<[text/plain]>
> Stack Trace:
> java.lang.AssertionError: key:ignored__attachment_mimetype 
> expected:<[message/rfc822]> but was:<[text/plain]>
> at 
> __randomizedtesting.SeedInfo.seed([436A6179722A6D29:D9A9C2E717F133FC]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at 
> org.apache.solr.morphlines.solr.AbstractSolrMorphlineTestBase.testDocumentTypesInternal(AbstractSolrMorphlineTestBase.java:170)
> at 
> org.apache.solr.morphlines.cell.SolrCellMorphlineTest.testSolrCellDocumentTypes(SolrCellMorphlineTest.java:193)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10636/
> http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1639/
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10401/



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

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

[jira] [Closed] (SOLR-6134) MapReduce GoLive code improvements

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-6134.

Resolution: Won't Fix

> MapReduce GoLive code improvements
> --
>
> Key: SOLR-6134
> URL: https://issues.apache.org/jira/browse/SOLR-6134
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - MapReduce
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-6134_GoLive.patch
>
>
> I looked at the GoLive.java source quite a bit and found myself editing the 
> source to make it clearer.  It wasn't hard to understand before but I felt it 
> could be better.  Furthermore, when not in SolrCloud mode, the commit 
> messages are now submitted asynchronously using the same thread pool used for 
> merging.
> This refactoring does away with the inner class "Result", the 
> CompletionService, and any keeping track of Future's/Result's in collections 
> and looping over them.  Fundamentally the code never cared about the result; 
> it just wanted to know if it all worked or not.  This refactoring uses Java's 
> "Phaser" concurrency utility which may seem advanced (especially with the 
> cool name :-) but I find it quite understandable how to use, and is very 
> flexible. I added an inner class implementing Runnable to avoid some 
> duplication across the merge and commit phases.
> The tests pass but I confess to not having used it for real.  I certainly 
> don't feel comfortable committing this until someone does try it; especially 
> try and break it ;-).



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

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

[jira] [Closed] (SOLR-8172) MorphlineBasicMiniMRTest failure

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-8172.

Resolution: Won't Fix

> MorphlineBasicMiniMRTest failure
> 
>
> Key: SOLR-8172
> URL: https://issues.apache.org/jira/browse/SOLR-8172
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Reporter: Steve Rowe
>
> My Jenkins found a seed that reproduces for me on branch_5x and trunk with 
> Java8 on Linux:
> {noformat}
> [junit4]   2> org.apache.hadoop.HadoopIllegalArgumentException: An XAttr name 
> must be prefixed with user/trusted/security/system/raw, followed by a '.'
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.XAttrHelper.buildXAttr(XAttrHelper.java:72)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.server.namenode.FSDirectory.(FSDirectory.java:137)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:894)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.(FSNamesystem.java:755)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:934)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:294)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.DFSTestUtil.formatNameNode(DFSTestUtil.java:162)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:969)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:738)
>[junit4]   2>  at 
> org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:608)
>[junit4]   2>  at 
> org.apache.solr.hadoop.MorphlineBasicMiniMRTest.setupClass(MorphlineBasicMiniMRTest.java:166)
>[junit4]   2>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>[junit4]   2>  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]   2>  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]   2>  at java.lang.reflect.Method.invoke(Method.java:497)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:804)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>[junit4]   2>  at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
>[junit4]   2>  at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>[junit4]   2>  at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>[junit4]   2>  at 
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>[junit4]   2>  at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>[junit4]   2>  at java.lang.Thread.run(Thread.java:745)
>[junit4]   2> 4376 INFO  
> 

[jira] [Closed] (SOLR-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-7948.

Resolution: Won't Fix

> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data,
>  with permdir 
> hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.426; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml
> INFO  - 2015-08-20 11:44:45.474; [   ] 
> org.apache.solr.core.CorePropertiesLocator; Config-defined core root 
> directory: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> New CoreContainer 1656436773
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> Loading cores into CoreContainer 
> [instanceDir=/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/]
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> loading shared library: 
> 

[jira] [Closed] (SOLR-7734) MapReduce Indexer can error when using secure collection

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-7734.

   Resolution: Won't Fix
Fix Version/s: (was: 6.0)
   (was: 5.5)

> MapReduce Indexer can error when using secure collection
> 
>
> Key: SOLR-7734
> URL: https://issues.apache.org/jira/browse/SOLR-7734
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
>Reporter: Mike Drob
>Assignee: Gregory Chanan
> Attachments: SOLR-7734.branch5x.patch, SOLR-7734.patch, 
> SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch, SOLR-7734.patch, 
> SOLR-7734.patch, SOLR-7734.patch
>
>
> When running the MapReduceIndexerTool, it will usually pull a 
> {{solrconfig.xml}} from ZK for the collection that it is running against. 
> This can be problematic for several reasons:
> * Performance: The configuration in ZK will likely have several query 
> handlers, and lots of other components that don't make sense in an 
> indexing-only use of EmbeddedSolrServer (ESS).
> * Classpath Resources: If the Solr services are using some kind of additional 
> service (such as Sentry for auth) then the indexer will not have access to 
> the necessary configurations without the user jumping through several hoops.
> * Distinct Configuration Needs: Enabling Soft Commits on the ESS doesn't make 
> sense. There's other configurations that 
> * Update Chain Behaviours: I'm under the impression that UpdateChains may 
> behave differently in ESS than a SolrCloud cluster. Is it safe to depend on 
> consistent behaviour here?



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

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

[jira] [Closed] (SOLR-7523) Maven test fails in solr/contrib/map-reduce

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-7523.

Resolution: Won't Fix

> Maven test fails in solr/contrib/map-reduce
> ---
>
> Key: SOLR-7523
> URL: https://issues.apache.org/jira/browse/SOLR-7523
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.1
>Reporter: Jonas van Vliet
>Assignee: Steve Rowe
>Priority: Critical
>  Labels: maven, test
> Attachments: SOLR-7523.patch
>
>
> Maven test fails on the following package:
> solr/contrib/map-reduce/
> (seen on solr6 trunk and solr 5.x branch)
> The underlying problem seems to be that when running maven test, the java 
> security manager is not set. When running ant test, the security manager is 
> set to org.apache.lucene.util.TestSecurityManager. 
> The failing test is skipped while running ant test due to an assumption in 
> org/apache/solr/hadoop/MorphlineBasicMiniMRTest.java:
> assumeTrue(
> "Currently this test can only be run without the lucene test security 
> policy in place",
> System.getProperty("java.security.manager", "").equals(""));
> In maven, the test is not skipped and fails.
> I propose aligning the ant and maven test so they use the same security 
> manager.



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

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

[jira] [Closed] (SOLR-6489) morphlines-cell tests fail after upgrade to TIKA 1.6 or TIKA 1.7

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-6489.

   Resolution: Won't Fix
Fix Version/s: (was: 6.0)
   (was: 5.0)

> morphlines-cell tests fail after upgrade to TIKA 1.6 or TIKA 1.7
> 
>
> Key: SOLR-6489
> URL: https://issues.apache.org/jira/browse/SOLR-6489
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.0
>Reporter: Uwe Schindler
>Assignee: Mark Miller
>
> After upgrade tp Apache TIKA 1.6 (SOLR-6488), solr-morphlines-cell tests fail 
> with scripting error messages.
> Due to missing understanding, caused by the crazy configuration file format 
> and inability to figure out the test setup, I have to give up and hope that 
> somebody else can take care. In addition, on my own machines, all of Hadoop 
> does not work at all, so I cannot debug (Windows).
> The whole Morphlines setup is not really good, because Solr core depends on 
> another TIKA version than the included morphlines libraries. This is not a 
> good situation for Solr, because we should be able to upgrade to any version 
> of our core components and not depend on external libraries that itsself 
> depend on Solr in older versions!



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

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

[jira] [Closed] (SOLR-9220) mapreduce and morphlines-cell contribs have failing tests after Tika upgrade to 1.13

[Steve Rowe (JIRA)]

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

Steve Rowe closed SOLR-9220.

Resolution: Won't Fix

> mapreduce and morphlines-cell contribs have failing tests after Tika upgrade 
> to 1.13
> 
>
> Key: SOLR-9220
> URL: https://issues.apache.org/jira/browse/SOLR-9220
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
>
> After the Tika 1.13 upgrade (SOLR-8981), some Morphlines contrib tests are 
> failing:
> {noformat}
> Checking out Revision 1f7b9555076b4a46cc44cc9d4c8619ebe340f350 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrCellMorphlineTest -Dtests.method=testSolrCellDocumentTypes2 
> -Dtests.seed=9B88EA69660A1C83 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=en -Dtests.timezone=Europe/Skopje -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   11.2s | SolrCellMorphlineTest.testSolrCellDocumentTypes2 
> <<<
>[junit4]> Throwable #1: 
> org.kitesdk.morphline.api.MorphlineCompilationException: Cannot instantiate 
> Tika parser: org.apache.tika.parser.crypto.Pkcs7Parser near: {
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  199
>[junit4]> #  rename "content" field to "text" fields
>[junit4]> "dateFormats" : [
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  199
>[junit4]> "-MM-dd'T'HH:mm:ss",
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  199
>[junit4]> "-MM-dd"
>[junit4]> ],
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  198
>[junit4]> "fmap" : {
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  198
>[junit4]> "content-type" : "content_type",
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  198
>[junit4]> "content" : "text"
>[junit4]> },
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  207
>[junit4]> #  Tika parsers to be registered. If multiple parsers 
> support the same MIME type, 
>[junit4]> #  the parser is chosen that is closest to the bottom in 
> this list:
>[junit4]> "parsers" : [
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  208
>[junit4]> {
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  208
>[junit4]> "parser" : 
> "org.apache.tika.parser.asm.ClassParser"
>[junit4]> },
>[junit4]> # 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-6.x/workspace/solr/build/contrib/solr-morphlines-cell/test/J0/temp/solr.morphlines.cell.SolrCellMorphlineTest_9B88EA69660A1C83-001/tempDir-003/test-morphlines/solrCellDocumentTypes.conf:
>  211
>[junit4]> #  { parser : 
> org.apache.tika.parser.AutoDetectParser }  
>[junit4]> #  { parser : 

[jira] [Commented] (SOLR-9221) Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9221:
--

the git bot failed to post the branch_6x commit - here it is from the commit 
notification email:

{noformat}
SOLR-9221: Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell

Conflicts:

solr/contrib/map-reduce/src/java/org/apache/solr/hadoop/TreeMergeOutputFormat.java

solr/contrib/map-reduce/src/test/org/apache/solr/hadoop/MorphlineMapperTest.java

solr/contrib/map-reduce/src/test/org/apache/solr/hadoop/MorphlineReducerTest.java

solr/contrib/morphlines-core/src/java/org/apache/solr/morphlines/solr/LoadSolrBuilder.java

solr/contrib/morphlines-core/src/test/org/apache/solr/morphlines/solr/AbstractSolrMorphlineTestBase.java

solr/contrib/morphlines-core/src/test/org/apache/solr/morphlines/solr/AbstractSolrMorphlineZkTestBase.java


Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/ac221b96
Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/ac221b96
Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/ac221b96

Branch: refs/heads/branch_6x
Commit: ac221b96b6d16569ca17e37cbebe717f7b86484c
Parents: 2adbd76
Author: Steve Rowe 
Authored: Fri Mar 24 12:31:16 2017 -0400
Committer: Steve Rowe 
Committed: Fri Mar 24 12:35:46 2017 -0400
{noformat}

> Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell
> -
>
> Key: SOLR-9221
> URL: https://issues.apache.org/jira/browse/SOLR-9221
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, contrib - morphlines-cell, contrib 
> - morphlines-core
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (7.0), 6.6
>
> Attachments: SOLR-9221.patch, SOLR-9221.patch, SOLR-9221.patch, 
> SOLR-9221-review.patch
>
>
> The Solr contribs map-reduce, morphlines-cell and morphlines-core contain 
> tests that are not being fixed: SOLR-6489 and SOLR-9220.
> (Some subset of?) these components live in the Kite SDK: http://kitesdk.org - 
> why are they also hosted in Solr?



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

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

[jira] [Resolved] (SOLR-9221) Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9221.
--
   Resolution: Done
 Assignee: Steve Rowe
Fix Version/s: 6.6
   master (7.0)

> Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell
> -
>
> Key: SOLR-9221
> URL: https://issues.apache.org/jira/browse/SOLR-9221
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, contrib - morphlines-cell, contrib 
> - morphlines-core
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (7.0), 6.6
>
> Attachments: SOLR-9221.patch, SOLR-9221.patch, SOLR-9221.patch, 
> SOLR-9221-review.patch
>
>
> The Solr contribs map-reduce, morphlines-cell and morphlines-core contain 
> tests that are not being fixed: SOLR-6489 and SOLR-9220.
> (Some subset of?) these components live in the Kite SDK: http://kitesdk.org - 
> why are they also hosted in Solr?



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

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

[jira] [Commented] (SOLR-9221) Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9221: Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell


> Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell
> -
>
> Key: SOLR-9221
> URL: https://issues.apache.org/jira/browse/SOLR-9221
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, contrib - morphlines-cell, contrib 
> - morphlines-core
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-9221.patch, SOLR-9221.patch, SOLR-9221.patch, 
> SOLR-9221-review.patch
>
>
> The Solr contribs map-reduce, morphlines-cell and morphlines-core contain 
> tests that are not being fixed: SOLR-6489 and SOLR-9220.
> (Some subset of?) these components live in the Kite SDK: http://kitesdk.org - 
> why are they also hosted in Solr?



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

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

[jira] [Commented] (SOLR-1105) Use a different stored field for highlighting

[Julien Martin (JIRA)]

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

Julien Martin commented on SOLR-1105:
-

Thank you for looking at it David! We really need the feature over here :)

As for unique field loading, my understanding is that the stored fields visitor 
pattern applied to the index searcher object ensures that no field is loaded 
twice per document. 

But this was a good point anyway because I had other issues with multiple 
fields highlighting which I solved in a new version of the patch you can find 
attached here.

Sincerely,
Julien

> Use a different stored field for highlighting
> -
>
> Key: SOLR-1105
> URL: https://issues.apache.org/jira/browse/SOLR-1105
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Dmitry Lihachev
>Assignee: David Smiley
> Attachments: SOLR-1105-1_4_1.patch, SOLR-1105.patch, 
> SOLR-1105_shared_content_field_1.3.0.patch
>
>
> DefaultSolrHighlighter uses stored field content to highlight. It has some 
> disadvantages, because index grows up fast when using multilingual indexing 
> due to several fields has to be stored with same content. This patch allows 
> DefaultSolrHighlighter to use "contentField" attribute to loockup content in 
> external field.
> Excerpt from old schema:
> {code:xml}
> 
> 
> 
> 
> {code}
> The same after patching, highlighter will now get content stored in "title" 
> field
> {code:xml}
> 
>  contentField="title"/>
>  contentField="title"/>
>  contentField="title"/>
> {code}



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

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

[jira] [Updated] (SOLR-1105) Use a different stored field for highlighting

[Julien Martin (JIRA)]

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

Julien Martin updated SOLR-1105:

Attachment: (was: SOLR-1105.patch)

> Use a different stored field for highlighting
> -
>
> Key: SOLR-1105
> URL: https://issues.apache.org/jira/browse/SOLR-1105
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Dmitry Lihachev
>Assignee: David Smiley
> Attachments: SOLR-1105-1_4_1.patch, SOLR-1105.patch, 
> SOLR-1105_shared_content_field_1.3.0.patch
>
>
> DefaultSolrHighlighter uses stored field content to highlight. It has some 
> disadvantages, because index grows up fast when using multilingual indexing 
> due to several fields has to be stored with same content. This patch allows 
> DefaultSolrHighlighter to use "contentField" attribute to loockup content in 
> external field.
> Excerpt from old schema:
> {code:xml}
> 
> 
> 
> 
> {code}
> The same after patching, highlighter will now get content stored in "title" 
> field
> {code:xml}
> 
>  contentField="title"/>
>  contentField="title"/>
>  contentField="title"/>
> {code}



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

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

[jira] [Updated] (SOLR-1105) Use a different stored field for highlighting

[Julien Martin (JIRA)]

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

Julien Martin updated SOLR-1105:

Attachment: SOLR-1105.patch

> Use a different stored field for highlighting
> -
>
> Key: SOLR-1105
> URL: https://issues.apache.org/jira/browse/SOLR-1105
> Project: Solr
>  Issue Type: Improvement
>  Components: highlighter
>Reporter: Dmitry Lihachev
>Assignee: David Smiley
> Attachments: SOLR-1105-1_4_1.patch, SOLR-1105.patch, 
> SOLR-1105_shared_content_field_1.3.0.patch
>
>
> DefaultSolrHighlighter uses stored field content to highlight. It has some 
> disadvantages, because index grows up fast when using multilingual indexing 
> due to several fields has to be stored with same content. This patch allows 
> DefaultSolrHighlighter to use "contentField" attribute to loockup content in 
> external field.
> Excerpt from old schema:
> {code:xml}
> 
> 
> 
> 
> {code}
> The same after patching, highlighter will now get content stored in "title" 
> field
> {code:xml}
> 
>  contentField="title"/>
>  contentField="title"/>
>  contentField="title"/>
> {code}



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9450:
--

Uwe,

The current instructions 
[https://wiki.apache.org/lucene-java/ReleaseTodo#Push_docs.2C_changes_and_javadocs_to_the_CMS_production_tree]
 say to unpack the release archives and copy from there: 

{quote}
2. untar the lucene and solr release .tgz to create lucene-X.Y.Z and 
solr-X.Y.Z. Example:
{noformat}
tar -xzvf 
/tmp/releases/6.0.1/lucene-solr-6.0.1-RC2-rev.../lucene/lucene-6.0.1.tgz

tar -xzvf /tmp/releases/6.0.1/lucene-solr-6.0.1-RC2-rev.../solr/solr-6.0.1.tgz
{noformat}
3. Upload via subversion import. Example:
\[...\]
{quote}

Steve

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

Hi Steve,

there is nothing special to do. The Javadocs are still built as usual, but no 
longer packaged into the targz. You will find them after building at the same 
place as before, so just copy them from your checkout's docs dir.

Uwe

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-9221) Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9221:
--

No objections => committing removal patch shortly.

> Remove Solr contribs: map-reduce, morphlines-core and morphlines-cell
> -
>
> Key: SOLR-9221
> URL: https://issues.apache.org/jira/browse/SOLR-9221
> Project: Solr
>  Issue Type: Task
>  Components: contrib - MapReduce, contrib - morphlines-cell, contrib 
> - morphlines-core
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-9221.patch, SOLR-9221.patch, SOLR-9221.patch, 
> SOLR-9221-review.patch
>
>
> The Solr contribs map-reduce, morphlines-cell and morphlines-core contain 
> tests that are not being fixed: SOLR-6489 and SOLR-9220.
> (Some subset of?) these components live in the Kite SDK: http://kitesdk.org - 
> why are they also hosted in Solr?



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

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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Steve Rowe]

+1

Lucene changes, docs and javadocs look good.  The smoke tester passed for me 
(I’ve lost the timing, sorry, was like 28 minutes).

Solr’s HTML changes, docs and javadocs have moved online (see SOLR-9450), and 
so aren’t part of the release artifacts.  I think vetting these docs can happen 
separately from the release vote - it’ll be kosher to fix if necessary after a 
release, since they are excluded from the release vote.

--
Steve
www.lucidworks.com

> On Mar 22, 2017, at 3:39 PM, Andi Vajda  wrote:
> 
> 
> On Tue, 21 Mar 2017, jim ferenczi wrote:
> 
>> Please vote for release candidate 1 for Lucene/Solr 6.5.0
> 
> +1
> 
> I checked out branch_6_5 and built PyLucene with it, all tests pass.
> 
> Andi..
> 
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
>> 
>> Here's my +1
>> SUCCESS! [0:49:02.989006]
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Comment Edited] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-9450 at 3/24/17 4:01 PM:
---

[~thetaphi], please update 
[https://wiki.apache.org/lucene-java/ReleaseTodo#Update_the_rest_of_the_website]
 with RM instructions for building/uploading the online docs ASAP, so that 
[~jim.ferenczi] knows what to do for the 6.5 release.


was (Author: steve_rowe):
[~thetaphi], please update 
[https://wiki.apache.org/lucene-java/ReleaseTodo#Update_the_rest_of_the_website]
 with RM instructions for building the online docs ASAP, so that 
[~jim.ferenczi] knows what to do for the 6.5 release.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9450:
--

[~thetaphi], please update 
[https://wiki.apache.org/lucene-java/ReleaseTodo#Update_the_rest_of_the_website]
 with RM instructions for building the online docs ASAP, so that 
[~jim.ferenczi] knows what to do for the 6.5 release.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Uwe Schindler
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch, 
> SOLR-9450.patch, SOLR-9450.patch, SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testCompact

Error Message:
Memory Pool not found

Stack Trace:
java.lang.InternalError: Memory Pool not found
at 
__randomizedtesting.SeedInfo.seed([8F4813A324434093:A1485FF45CBE4A6C]:0)
at sun.management.MemoryPoolImpl.getUsage0(Native Method)
at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:96)
at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:177)
at 
com.codahale.metrics.jvm.MemoryUsageGaugeSet$18.getValue(MemoryUsageGaugeSet.java:174)
at 
org.apache.solr.util.stats.MetricUtils.convertGauge(MetricUtils.java:215)
at 
org.apache.solr.util.stats.MetricUtils.lambda$toMaps$4(MetricUtils.java:142)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at 
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at 
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at org.apache.solr.util.stats.MetricUtils.toMaps(MetricUtils.java:135)
at 
org.apache.solr.util.stats.MetricUtils.toNamedList(MetricUtils.java:117)
at 
org.apache.solr.handler.admin.MetricsHandler.handleRequestBody(MetricsHandler.java:85)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testCompact(MetricsHandlerTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at