date:20161129

[jira] [Created] (SOLR-9814) Solr 6.2.1 is starting very slow

2016-11-29 Thread Monti Chandra (JIRA)

Monti Chandra created SOLR-9814:
---

 Summary: Solr 6.2.1 is starting very slow
 Key: SOLR-9814
 URL: https://issues.apache.org/jira/browse/SOLR-9814
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: logging, Server
Affects Versions: 6.2.1
 Environment: Linux version 3.10.0-327.el7.x86_64 
(buil...@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) 
(GCC) )
Reporter: Monti Chandra
Priority: Blocker


Hello team,
I am working on solr version to 6.2.1. It was working so nice for the first 20 
days and now the server is restarting very slow(15-20 min).  

Please get the hardware specs of my system below:

Linux version 3.10.0-327.el7.x86_64 (buil...@kbuilder.dev.centos.org) (gcc 
version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) )

kernel-3.10.0-327.el7.x86_64

It is working fine when i am taking solr directory to another server of same 
configuartion. Is there any H/w, OS or kernel level threat caused by running 
solr?

Please help, i got stuck in.




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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Mikhail Khludnev

Welcome, Ishan!

On Tue, Nov 29, 2016 at 9:17 PM, Mark Miller  wrote:

> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller
>



-- 
Sincerely yours
Mikhail Khludnev

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Christian Moen

Congratulations, Ishan!

Best,
Christian

On Wed, Nov 30, 2016 at 3:17 AM Mark Miller  wrote:

> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller
>

[jira] [Commented] (SOLR-7282) Cache config or index schema objects by configset and share them across cores

2016-11-29 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-7282:
--

The idea of sharing collections that are named differently but happen to be 
exactly the same strikes me as added complexity for very little gain. And 
tracking down errors in that world would be...interesting. 

+1 to reusing the same objects if possible for configsets that have the same 
znode (assuming it handles the mutable issue)
-1 to using a configset other than the one specified by the user when the 
collection was created because we think it's the same based on the hash.



> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



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

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

[jira] [Commented] (SOLR-7282) Cache config or index schema objects by configset and share them across cores

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum commented on SOLR-7282:
--

Keep a separate map of znode + version -> content hash?

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



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

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

[jira] [Commented] (SOLR-7282) Cache config or index schema objects by configset and share them across cores

2016-11-29 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-7282:
--

How do we compute the hash w/o downloading the content? Doesn't it mean that we 
have to fetch the whole file every time? The only savings that we get, in that 
case, is the cost of parsing

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



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

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

[jira] [Commented] (SOLR-7282) Cache config or index schema objects by configset and share them across cores

2016-11-29 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-7282:
--

How do we compute the hash w/o downloading the content? Doesn't it mean that we 
have to fetch the whole file every time? The only savings that we get, in that 
case, is the cost of parsing

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



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

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

[jira] [Updated] (LUCENE-7570) Tragic events during merges can lead to deadlock

2016-11-29 Thread AMIRAULT Martin (JIRA)


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

AMIRAULT Martin updated LUCENE-7570:

Attachment: thread_dump.txt

Reproduced in production with Lucene 6.1
Attaching extract from thread dump when it reproduced

> Tragic events during merges can lead to deadlock
> 
>
> Key: LUCENE-7570
> URL: https://issues.apache.org/jira/browse/LUCENE-7570
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 5.5, master (7.0)
>Reporter: Joey Echeverria
> Attachments: thread_dump.txt
>
>
> When an {{IndexWriter#commit()}} is stalled due to too many pending merges, 
> you can get a deadlock if the currently active merge thread hits a tragic 
> event.
> # The thread performing the commit synchronizes on the the {{commitLock}} in 
> {{commitInternal}}.
> # The thread goes on to to call {{ConcurrentMergeScheduler#doStall()}} which 
> {{waits()}} on the {{ConcurrentMergeScheduler}} object. This release the 
> merge scheduler's monitor lock, but not the {{commitLock}} in {{IndexWriter}}.
> # Sometime after this wait begins, the merge thread gets a tragic exception 
> can calls {{IndexWriter#tragicEvent()}} which in turn calls 
> {{IndexWriter#rollbackInternal()}}.
> # The {{IndexWriter#rollbackInternal()}} synchronizes on the {{commitLock}} 
> which is still held by the committing thread from (1) above which is waiting 
> on the merge(s) to complete. Hence, deadlock.
> We hit this bug with Lucene 5.5, but I looked at the code in the master 
> branch and it looks like the deadlock still exists there as well.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Shai Erera

Congratulations!

On Wed, Nov 30, 2016, 01:02 Alexandre Rafalovitch 
wrote:

> Congratulations and welcome Ishan.
>
> I am happy to stop being the "new boy" of this distinguished club :-)
>
> Regards,
>Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 30 November 2016 at 05:17, Mark Miller  wrote:
> > I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> > invitation to become a committer.
> >
> > Ishan, it's tradition that you introduce yourself with a brief bio /
> > origin story, explaining how you arrived here.
> >
> > Your handle "ishan" has already added to the “lucene" LDAP group, so
> > you now have commit privileges.
> >
> > Please celebrate this rite of passage, and confirm that the right
> > karma has in fact enabled, by embarking on the challenge of adding
> > yourself to the committers section of the Who We Are page on the
> > website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> > bookmarklet
> > at the bottom of the page here: https://cms.apache.org/#bookmark -
> > more info here http://www.apache.org/dev/cms.html).
> >
> > Congratulations and welcome!
> > --
> > - Mark
> > about.me/markrmiller
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-7282) Cache config or index schema objects by configset and share them across cores

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum commented on SOLR-7282:
--

Could we cache by content hash?  Then even collections that physically don't 
share the same configset but whose contents are identical could share config.

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



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

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

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

2016-11-29 Thread Apache Jenkins Server

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

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, RawDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:434)  
at org.apache.solr.core.SolrCore.(SolrCore.java:841)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:775)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:842)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498)  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  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:332)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:641)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:847)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:775)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:842)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498)  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  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.core.SolrCore.(SolrCore.java:798)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:775)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:842)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498)  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  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:66)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:673)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:847)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:775)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:842)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498)  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  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:43)
  at org.apache.solr.core.SolrCore.(SolrCore.java:937)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:775)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:842)  at 
org.apache.solr.core.CoreContainer.lambda$load$0(CoreContainer.java:498)  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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread Jeff Wartes (JIRA)


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

Jeff Wartes commented on SOLR-4735:
---

Heh, I wondered whether something like that would happen if I commented on 
github. Should I constrain myself to talking in Jira?

> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
> getSource() seems pretty useless), but maybe that's for another issue.



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

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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-4735:
--

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

https://github.com/apache/lucene-solr/pull/120#discussion_r90144072
  
--- Diff: solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java 
---
@@ -0,0 +1,216 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.metrics;
+
+import java.util.Set;
+
+import com.codahale.metrics.Counter;
+import com.codahale.metrics.Histogram;
+import com.codahale.metrics.Meter;
+import com.codahale.metrics.MetricFilter;
+import com.codahale.metrics.MetricRegistry;
+import com.codahale.metrics.SharedMetricRegistries;
+import com.codahale.metrics.Snapshot;
+import com.codahale.metrics.Timer;
+import org.apache.solr.common.util.NamedList;
+
+/**
+ *
+ */
+public class SolrMetricManager {
+
+  public static final String REGISTRY_NAME_PREFIX = "solr";
+  public static final String DEFAULT_REGISTRY = 
MetricRegistry.name(REGISTRY_NAME_PREFIX, "default");
+
+  // don't create instances of this class
+  private SolrMetricManager() { }
+
+
+  /**
+   * Return a set of existing registry names.
+   */
+  public static Set registryNames() {
+return SharedMetricRegistries.names();
+  }
+
+  /**
+   * Get (or create if not present) a named registry
+   * @param registry name of the registry
+   * @return existing or newly created registry
+   */
+  public static MetricRegistry registryFor(String registry) {
+return 
SharedMetricRegistries.getOrCreate(overridableRegistryName(registry));
+  }
+
+  /**
+   * Remove all metrics from a specified registry.
+   * @param registry registry name
+   */
+  public static void clearRegistryFor(String registry) {
+
SharedMetricRegistries.getOrCreate(overridableRegistryName(registry)).removeMatching(MetricFilter.ALL);
--- End diff --

This, and several other places below could delegate to 
`registryFor(registry)`


> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly

[GitHub] lucene-solr pull request #120: SOLR-4735 Improve Solr metrics reporting

2016-11-29 Thread randomstatistic

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

https://github.com/apache/lucene-solr/pull/120#discussion_r90144072
  
--- Diff: solr/core/src/java/org/apache/solr/metrics/SolrMetricManager.java 
---
@@ -0,0 +1,216 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.metrics;
+
+import java.util.Set;
+
+import com.codahale.metrics.Counter;
+import com.codahale.metrics.Histogram;
+import com.codahale.metrics.Meter;
+import com.codahale.metrics.MetricFilter;
+import com.codahale.metrics.MetricRegistry;
+import com.codahale.metrics.SharedMetricRegistries;
+import com.codahale.metrics.Snapshot;
+import com.codahale.metrics.Timer;
+import org.apache.solr.common.util.NamedList;
+
+/**
+ *
+ */
+public class SolrMetricManager {
+
+  public static final String REGISTRY_NAME_PREFIX = "solr";
+  public static final String DEFAULT_REGISTRY = 
MetricRegistry.name(REGISTRY_NAME_PREFIX, "default");
+
+  // don't create instances of this class
+  private SolrMetricManager() { }
+
+
+  /**
+   * Return a set of existing registry names.
+   */
+  public static Set registryNames() {
+return SharedMetricRegistries.names();
+  }
+
+  /**
+   * Get (or create if not present) a named registry
+   * @param registry name of the registry
+   * @return existing or newly created registry
+   */
+  public static MetricRegistry registryFor(String registry) {
+return 
SharedMetricRegistries.getOrCreate(overridableRegistryName(registry));
+  }
+
+  /**
+   * Remove all metrics from a specified registry.
+   * @param registry registry name
+   */
+  public static void clearRegistryFor(String registry) {
+
SharedMetricRegistries.getOrCreate(overridableRegistryName(registry)).removeMatching(MetricFilter.ALL);
--- End diff --

This, and several other places below could delegate to 
`registryFor(registry)`


---
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-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

2016-11-29 Thread Damien Kamerman (JIRA)


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

Damien Kamerman commented on SOLR-8297:
---

The use case is not narrow in my view. I have a sharded collection holding 
multiple data-sets that I wish to join on. I'm joining on the same collection.

Will this patch be applied to 6.x?

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
> Attachments: SOLR-8297.patch
>
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



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

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

[jira] [Updated] (SOLR-9813) Scale function returns NaN

2016-11-29 Thread David Johnson (JIRA)


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

David Johnson updated SOLR-9813:

Attachment: ScaleFloatFunction.java.patch

Proposed patch for issue

> Scale function returns NaN
> --
>
> Key: SOLR-9813
> URL: https://issues.apache.org/jira/browse/SOLR-9813
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.2.1
>Reporter: David Johnson
>Priority: Minor
> Attachments: ScaleFloatFunction.java.patch
>
>
> If the scale function is passed in NaN (scale(log(0),1,5), it will return 
> NaN, rather than something within the scale.
> This should be detected and the minimum value returned instead.



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

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

[jira] [Created] (SOLR-9813) Scale function returns NaN

2016-11-29 Thread David Johnson (JIRA)

David Johnson created SOLR-9813:
---

 Summary: Scale function returns NaN
 Key: SOLR-9813
 URL: https://issues.apache.org/jira/browse/SOLR-9813
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: query parsers
Affects Versions: 6.2.1
Reporter: David Johnson
Priority: Minor


If the scale function is passed in NaN (scale(log(0),1,5), it will return NaN, 
rather than something within the scale.
This should be detected and the minimum value returned instead.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Alexandre Rafalovitch

Congratulations and welcome Ishan.

I am happy to stop being the "new boy" of this distinguished club :-)

Regards,
   Alex.

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 30 November 2016 at 05:17, Mark Miller  wrote:
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Michael McCandless

Welcome Ishan.

Mike McCandless

http://blog.mikemccandless.com


On Tue, Nov 29, 2016 at 1:17 PM, Mark Miller  wrote:
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller

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

[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping

2016-11-29 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-6203:
---

Just a quick note for the log here to say that SOLR-9660 and SOLR-9783 have 
been committed to master, the former includes step (1) from Judith's README 
file and the latter should help with step (2) i.e. passing around SortSpecs 
rather than plain Sorts.

I myself at the moment don't have a chunk of time to continue with the next 
logical part of step (2) but if I had time then I would next go and change 
signatures where needed (and only where needed) so that the SortSpecs become 
available where they will be used later (signature changes only for now, actual 
use would be a subsequent step). And if there's obvious non-trivial code 
duplication (in the code that will need to be changed later) then I would 
factor out utility methods to reduce the duplication. In case anyone else wants 
to pursue the same incremental approach in the meantime, I've started 
[jira/solr-6203|https://github.com/apache/lucene-solr/tree/jira/solr-6203] 
working branch (with one small 
[commit|https://github.com/apache/lucene-solr/commit/859eb0837f52d131924ce8401c4ae1dc3056b7de])
 for which pull requests could be opened or alternatively if preferred then i'd 
be happy to review any new patch files attached to this ticket.

> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203-unittest.patch, 
> SOLR-6203-unittest.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic 
> field as text gets a cast exception when using a sort function and result 
> grouping.  
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
> 
> {noformat}
> #  Create  sharded collection
> {noformat}
> curl 
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
>   "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
>   "sort": "sqrt(popularity) desc",
>   "indent": "true",
>   "q": "*:*",
>   "_": "1403709010008",
>   "group.field": "manu",
>   "group": "true",
>   "wt": "json"
> }
>   },
>   "error": {
> "msg": "java.lang.Double cannot be cast to 
> org.apache.lucene.util.BytesRef",
> "code": 500
>   }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException; 
> java.lang.ClassCastException: java.lang.Double cannot be cast to 
> org.apache.lucene.util.BytesRef
> at 
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at 
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>   ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the 
> {{"*"}} dynamic field, which is a TextField in the repro.



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

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

[jira] [Commented] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)

2016-11-29 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-9660:
---

Hi Judith. Thanks for indirectly reminding me to return to this ticket here. 
I've committed to master branch and will backport to branch_6x tomorrow or so, 
SOLR-9783 is also committed, they both hopefully will help with SOLR-6203 
itself. Replied to your 26Oct16 question above, also will add note to SOLR-6203 
next.


> in GroupingSpecification factor [group](sort|offset|limit) into 
> [group](sortSpec)
> -
>
> Key: SOLR-9660
> URL: https://issues.apache.org/jira/browse/SOLR-9660
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, 
> SOLR-9660.patch
>
>
> This is split out and adapted from and towards the SOLR-6203 changes.



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

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

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

2016-11-29 Thread Policeman Jenkins Server

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

1 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
timed out waiting for collection1 startAt time to exceed: Tue Nov 29 16:42:43 
AST 2016

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Tue Nov 29 16:42:43 AST 2016
at 
__randomizedtesting.SeedInfo.seed([7FC99266A7F8801B:88BA7C3E61102FFD]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1508)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1314)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11123 lines...]
   [junit4]

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Anshum Gupta

Congratulations and welcome Ishan!

On Tue, Nov 29, 2016 at 1:05 PM Yonik Seeley  wrote:

> Congrats Ishan!
>
> -Yonik
>
>
> On Tue, Nov 29, 2016 at 1:17 PM, Mark Miller 
> wrote:
> > I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> > invitation to become a committer.
> >
> > Ishan, it's tradition that you introduce yourself with a brief bio /
> > origin story, explaining how you arrived here.
> >
> > Your handle "ishan" has already added to the “lucene" LDAP group, so
> > you now have commit privileges.
> >
> > Please celebrate this rite of passage, and confirm that the right
> > karma has in fact enabled, by embarking on the challenge of adding
> > yourself to the committers section of the Who We Are page on the
> > website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> > bookmarklet
> > at the bottom of the page here: https://cms.apache.org/#bookmark -
> > more info here http://www.apache.org/dev/cms.html).
> >
> > Congratulations and welcome!
> > --
> > - Mark
> > about.me/markrmiller
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-9810) Implement a globally shared cache option

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum updated SOLR-9810:
-
Summary: Implement a globally shared cache option  (was: Implement a 
globally shared cache implementations)

> Implement a globally shared cache option
> 
>
> Key: SOLR-9810
> URL: https://issues.apache.org/jira/browse/SOLR-9810
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Assignee: Scott Blum
>
> When a Solr instance is serving many indices, there is no way to coordinate 
> cache usage across cores, and pinned heap becomes a tragedy of the commons.  
> We should implement cache classes that form a facade around a global shared 
> cache so that resource use can be managed VM wide.



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

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

[jira] [Updated] (SOLR-9810) Implement a globally shared cache implementations

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum updated SOLR-9810:
-
   Assignee: Scott Blum
Description: 
When a Solr instance is serving many indices, there is no way to coordinate 
cache usage across cores, and pinned heap becomes a tragedy of the commons.  We 
should implement cache classes that form a facade around a global shared cache 
so that resource use can be managed VM wide.


  was:When a Solr instance is serving many indices, it could be more efficient 
to use a single larger field cache instead of per-core caches. We should make 
this possible.

Summary: Implement a globally shared cache implementations  (was: 
Implement a global field cache)

> Implement a globally shared cache implementations
> -
>
> Key: SOLR-9810
> URL: https://issues.apache.org/jira/browse/SOLR-9810
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Assignee: Scott Blum
>
> When a Solr instance is serving many indices, there is no way to coordinate 
> cache usage across cores, and pinned heap becomes a tragedy of the commons.  
> We should implement cache classes that form a facade around a global shared 
> cache so that resource use can be managed VM wide.



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

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

[jira] [Comment Edited] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum edited comment on SOLR-9811 at 11/29/16 9:46 PM:


I've had cases where a single replica ended up stuck in the DOWN state, but all 
the other replicas on that machine were fine, and the replica itself was 
physically present and able to serve queries.  The only 'fix' in that situation 
is to reboot the node, but then you're interrupting service for collections 
that have no problems.

In those cases I've manually shoved a state update operation into ZK like this.

{code:title=From zk-shell}
create /solr/overseer/queue/qn- 
'{"core":"FOO_shard1_replica1","core_node_name":"core_node1","base_url":"http://1.1.1.1:8983/solr","node_name":"1.1.1.1:8983_solr","state":"active","shard":"shard1","collection":"FOO","operation":"state"}'
 false true
{code}

The correct values can be filled in from the result of querying CLUSTERSTATE on 
the affected collection.  Would be nice to have a tool for this.


was (Author: dragonsinth):
I've had cases where a single replica ended up stuck in the DOWN state, but all 
the other replicas on that machine were fine, and the replica itself was 
physically present and able to serve queries.  The only 'fix' in that situation 
is to reboot the node, but then you're interrupting service for collections 
that have no problems.

In those cases I've manually shoved a state update operation into ZK like this.

{code:title=From zk-shell}
create /solr/overseer/queue/qn- 
'\{"core":"FOO_shard1_replica1","core_node_name":"core_node1","base_url":"http://1.1.1.1:8983/solr","node_name":"1.1.1.1:8983_solr","state":"active","shard":"shard1","collection":"FOO","operation":"state"}'
 false true
{code}

The correct values can be filled in from the result of querying CLUSTERSTATE on 
the affected collection.  Would be nice to have a tool for this.

> Make it easier to manually execute overseer commands
> 
>
> Key: SOLR-9811
> URL: https://issues.apache.org/jira/browse/SOLR-9811
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>
> Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
> it would be useful to have the ability to manually publish a node as active 
> or leader. This would be an alternative to some current ops practices of 
> restarting services, which may take a while to complete given many cores 
> hosted on a single server.
> This is an expert operator technique and readers should be made aware of 
> this, a.k.a. the "I don't care, just get it running" approach.



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

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

[jira] [Commented] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Scott Blum (JIRA)


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

Scott Blum commented on SOLR-9811:
--

I've had cases where a single replica ended up stuck in the DOWN state, but all 
the other replicas on that machine were fine, and the replica itself was 
physically present and able to serve queries.  The only 'fix' in that situation 
is to reboot the node, but then you're interrupting service for collections 
that have no problems.

In those cases I've manually shoved a state update operation into ZK like this.

{code:title=From zk-shell}
create /solr/overseer/queue/qn- 
'\{"core":"FOO_shard1_replica1","core_node_name":"core_node1","base_url":"http://1.1.1.1:8983/solr","node_name":"1.1.1.1:8983_solr","state":"active","shard":"shard1","collection":"FOO","operation":"state"}'
 false true
{code}

The correct values can be filled in from the result of querying CLUSTERSTATE on 
the affected collection.  Would be nice to have a tool for this.

> Make it easier to manually execute overseer commands
> 
>
> Key: SOLR-9811
> URL: https://issues.apache.org/jira/browse/SOLR-9811
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>
> Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
> it would be useful to have the ability to manually publish a node as active 
> or leader. This would be an alternative to some current ops practices of 
> restarting services, which may take a while to complete given many cores 
> hosted on a single server.
> This is an expert operator technique and readers should be made aware of 
> this, a.k.a. the "I don't care, just get it running" approach.



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 214 - Failure

2016-11-29 Thread Apache Jenkins Server

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

7 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexingSequenceNumbers.testStressConcurrentCommit

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([F4B4D882044ABC97]:0)


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexingSequenceNumbers

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

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexingSequenceNumbers

Error Message:
Captured an uncaught exception in thread: Thread[id=1997, name=Thread-1939, 
state=RUNNABLE, group=TGRP-TestIndexingSequenceNumbers]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1997, name=Thread-1939, state=RUNNABLE, 
group=TGRP-TestIndexingSequenceNumbers]
Caused by: java.lang.RuntimeException: 
org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed
at __randomizedtesting.SeedInfo.seed([F4B4D882044ABC97]:0)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers$2.run(TestIndexingSequenceNumbers.java:218)
Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter is 
closed
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:748)
at org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:762)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1566)
at 
org.apache.lucene.index.TestIndexingSequenceNumbers$2.run(TestIndexingSequenceNumbers.java:210)
Caused by: java.lang.OutOfMemoryError: Java heap space


FAILED:  org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([DCA615E72434105B:54F22A3D8AC87DA3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.testBasics(SharedFSAutoReplicaFailoverTest.java:309)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test(SharedFSAutoReplicaFailoverTest.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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

[jira] [Commented] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9660: in GroupingSpecification factor [group](sort|offset|limit) into 
[group](sortSpec) (Judith Silverman, Christine Poerschke)


> in GroupingSpecification factor [group](sort|offset|limit) into 
> [group](sortSpec)
> -
>
> Key: SOLR-9660
> URL: https://issues.apache.org/jira/browse/SOLR-9660
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, 
> SOLR-9660.patch
>
>
> This is split out and adapted from and towards the SOLR-6203 changes.



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

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

[jira] [Updated] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)

2016-11-29 Thread Christine Poerschke (JIRA)


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

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

Attaching final patch, precommit and solr/core tests pass, commit to follow 
shortly.

Compared to the previous patch this patch pushes the new accessors to the end 
of the file to make for an easier-to-read diff and also having yet again gotten 
myself confused by {{getGroupLimit}} (is it "within group limit" or "between 
groups limit"?) and its colleague {{getGroupOffset}} - the two methods have 
been renamed to {{getWithinGroup...}} to better reflect their meaning.



> in GroupingSpecification factor [group](sort|offset|limit) into 
> [group](sortSpec)
> -
>
> Key: SOLR-9660
> URL: https://issues.apache.org/jira/browse/SOLR-9660
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, 
> SOLR-9660.patch
>
>
> This is split out and adapted from and towards the SOLR-6203 changes.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Yonik Seeley

Congrats Ishan!

-Yonik


On Tue, Nov 29, 2016 at 1:17 PM, Mark Miller  wrote:
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller

-
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 (64bit/jdk1.8.0_102) - Build # 2300 - Unstable!

2016-11-29 Thread Policeman Jenkins Server

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

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

Error Message:
expected:<0> but was:<1>

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([4274C50A5D7B82C8:CA20FAD0F387EF30]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Commented] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)

2016-11-29 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-9660:
---

bq. ... we set something related to groupOffset to 0 if group.format == simple 
or groupingSpec.isMain() ...

Hi Judith, sorry I missed this part of your comment at the time. I also don't 
quite see the whole picture w.r.t. how the group.format==simple is implemented. 
It seemed quite subtle though i.e. maybe it would be trickier to happen 
elsewhere and in fewer places. Drilling into the history of the code might help 
understand the implementation but I haven't gone looking and so can't say.

> in GroupingSpecification factor [group](sort|offset|limit) into 
> [group](sortSpec)
> -
>
> Key: SOLR-9660
> URL: https://issues.apache.org/jira/browse/SOLR-9660
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch
>
>
> This is split out and adapted from and towards the SOLR-6203 changes.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Stefan Matheis

Welcome Ishan!

-Stefan


On November 29, 2016 at 7:18:00 PM, Mark Miller (markrmil...@gmail.com) wrote:
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>  
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>  
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>  
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>  
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller
>  


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

[jira] [Created] (SOLR-9812) Implement a /admin/metrics API

2016-11-29 Thread Shalin Shekhar Mangar (JIRA)

Shalin Shekhar Mangar created SOLR-9812:
---

 Summary: Implement a /admin/metrics API
 Key: SOLR-9812
 URL: https://issues.apache.org/jira/browse/SOLR-9812
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: master (7.0), 6.4


We added a bare bones metrics API in SOLR-9788 but due to limitations with the 
metrics servlet supplied by the metrics library, it can show statistics from 
only one metric registry. SOLR-4735 has added a hierarchy of metric registries 
and the /admin/metrics API should support showing all of them as well as be 
able to filter metrics from a given registry name.

In this issue we will implement the improved /admin/metrics API.



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

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

[jira] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-9783:
---

Thanks David for the suggestion to use asserts - that being an alternative to 
removal of the check had not occurred to me.

> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

[jira] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-9783:
---

bq. ... to interpret a null Sort value in a SortSpec as ...

Yes, that's a good question as to if/how/why/when the Sort value in a SortSpec 
might be null and if it is null, how to interpret that.

Within this change/ticket here I was just specifically looking at whether or 
not the sortWithinGroup within a GroupingSpecification could ever be null at 
the point at which the ...ShardResponseProcessor is using it. From my reading 
of the code I concluded that it would never be null because of the 
[QueryComponent.java#L249-L269|https://github.com/apache/lucene-solr/blob/bf9db95f218f49bac8e7971eb953a9fd9d13a2f0/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L249-L269]
 logic.

bq. ... I'm wondering whether newEmptySortSpec() could send Sort.RELEVANCE 
instead and/or the SortSpec constructors could be modified to replace nulls 
with Sort.RELEVANCE ...

newEmptySortSpec() sending Sort.RELEVANCE instead of null sounds an interesting 
idea. I wonder where else apart from QueryComponent.java#L249-L269 there is 
"null means Sort.RELEVANCE" logic (or indeed "null means SomethingElse" logic) 
that would go away if newEmptySortSpec() stopped sending null.



> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

[jira] [Updated] (SOLR-9805) Use metrics-jvm library to instrument jvm internals

2016-11-29 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-9805:

Attachment: SOLR-9805.patch

Patch which applies to the features/metrics branch. We add all jvm metric sets 
from metrics-jvm library to a shared metric registry named "/jvm". Following 
are the metrics collected:
{code}
{
  "version" : "3.0.0",
  "gauges" : {
"ConcurrentMarkSweep.count" : {
  "value" : 0
},
"ConcurrentMarkSweep.time" : {
  "value" : 6
},
"ParNew.count" : {
  "value" : 1
},
"ParNew.time" : {
  "value" : 10
},
"blocked.count" : {
  "value" : 0
},
"count" : {
  "value" : 21
},
"daemon.count" : {
  "value" : 7
},
"deadlock.count" : {
  "value" : 0
},
"deadlocks" : {
  "value" : [ ]
},
"direct.capacity" : {
  "value" : 57344
},
"direct.count" : {
  "value" : 4
},
"direct.used" : {
  "value" : 57344
},
"fileDescriptorRatio" : {
  "value" : 0.0037841796875
},
"heap.committed" : {
  "value" : 514523136
},
"heap.init" : {
  "value" : 536870912
},
"heap.max" : {
  "value" : 514523136
},
"heap.usage" : {
  "value" : 0.07437098416503471
},
"heap.used" : {
  "value" : 38265592
},
"loaded" : {
  "value" : 4179
},
"mapped.capacity" : {
  "value" : 0
},
"mapped.count" : {
  "value" : 0
},
"mapped.used" : {
  "value" : 0
},
"new.count" : {
  "value" : 0
},
"non-heap.committed" : {
  "value" : 34381824
},
"non-heap.init" : {
  "value" : 2555904
},
"non-heap.max" : {
  "value" : -1
},
"non-heap.usage" : {
  "value" : -3.3637024E7
},
"non-heap.used" : {
  "value" : 33637024
},
"pools.CMS-Old-Gen.committed" : {
  "value" : 402653184
},
"pools.CMS-Old-Gen.init" : {
  "value" : 402653184
},
"pools.CMS-Old-Gen.max" : {
  "value" : 402653184
},
"pools.CMS-Old-Gen.usage" : {
  "value" : 0.0
},
"pools.CMS-Old-Gen.used" : {
  "value" : 0
},
"pools.Code-Cache.committed" : {
  "value" : 6160384
},
"pools.Code-Cache.init" : {
  "value" : 2555904
},
"pools.Code-Cache.max" : {
  "value" : 251658240
},
"pools.Code-Cache.usage" : {
  "value" : 0.024188232421875
},
"pools.Code-Cache.used" : {
  "value" : 6087872
},
"pools.Compressed-Class-Space.committed" : {
  "value" : 3092480
},
"pools.Compressed-Class-Space.init" : {
  "value" : 0
},
"pools.Compressed-Class-Space.max" : {
  "value" : 1073741824
},
"pools.Compressed-Class-Space.usage" : {
  "value" : 0.0027397125959396362
},
"pools.Compressed-Class-Space.used" : {
  "value" : 2941744
},
"pools.Metaspace.committed" : {
  "value" : 25128960
},
"pools.Metaspace.init" : {
  "value" : 0
},
"pools.Metaspace.max" : {
  "value" : -1
},
"pools.Metaspace.usage" : {
  "value" : 0.9796426115525673
},
"pools.Metaspace.used" : {
  "value" : 24617400
},
"pools.Par-Eden-Space.committed" : {
  "value" : 89522176
},
"pools.Par-Eden-Space.init" : {
  "value" : 89522176
},
"pools.Par-Eden-Space.max" : {
  "value" : 89522176
},
"pools.Par-Eden-Space.usage" : {
  "value" : 0.2822161963534041
},
"pools.Par-Eden-Space.used" : {
  "value" : 25264608
},
"pools.Par-Survivor-Space.committed" : {
  "value" : 22347776
},
"pools.Par-Survivor-Space.init" : {
  "value" : 22347776
},
"pools.Par-Survivor-Space.max" : {
  "value" : 22347776
},
"pools.Par-Survivor-Space.usage" : {
  "value" : 0.581757397246151
},
"pools.Par-Survivor-Space.used" : {
  "value" : 13000984
},
"runnable.count" : {
  "value" : 9
},
"terminated.count" : {
  "value" : 0
},
"timed_waiting.count" : {
  "value" : 9
},
"total.committed" : {
  "value" : 548904960
},
"total.init" : {
  "value" : 539426816
},
"total.max" : {
  "value" : 514523135
},
"total.used" : {
  "value" : 71930344
},
"unloaded" : {
  "value" : 0
},
"waiting.count" : {
  "value" : 3
}
  },
  "counters" : { },
  "histograms" : { },
  "meters" : { },
  "timers" : { }
}
{code}

Since the /admin/metrics endpoint is constrained to show only one metric 
registry at a time, it does not show the JVM metrics. I'll fix the metrics API 
in a separate issue.

> Use metrics-jvm library to instrument jvm internals
> ---
>
> Key: SOLR-9805
> URL: https://issues.apache.org/jira/browse/SOLR-9805
>

[jira] [Commented] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Mike Drob (JIRA)


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

Mike Drob commented on SOLR-9811:
-

I was thinking also that when you have a leader and one of the shards is stuck 
in a recovery loop of some kind, it would be good to be able to clear out only 
that replica's state instead of having to restart the whole server that it is 
on. Maybe you can do that through existing core admin commands?

> Make it easier to manually execute overseer commands
> 
>
> Key: SOLR-9811
> URL: https://issues.apache.org/jira/browse/SOLR-9811
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>
> Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
> it would be useful to have the ability to manually publish a node as active 
> or leader. This would be an alternative to some current ops practices of 
> restarting services, which may take a while to complete given many cores 
> hosted on a single server.
> This is an expert operator technique and readers should be made aware of 
> this, a.k.a. the "I don't care, just get it running" approach.



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

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

[jira] [Commented] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-9811:
---

I don't think this will really add anything on top of the force leader api - if 
you cannot force a leader (already a data loss dangerous last resort 
operation), something like this has extremely little, if any, chance of helping 
the situation.

Regardless, rather than exposing something so internal, the force leader api 
should probably be bulked up to try even more than it does now if something is 
missing.

> Make it easier to manually execute overseer commands
> 
>
> Key: SOLR-9811
> URL: https://issues.apache.org/jira/browse/SOLR-9811
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>
> Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
> it would be useful to have the ability to manually publish a node as active 
> or leader. This would be an alternative to some current ops practices of 
> restarting services, which may take a while to complete given many cores 
> hosted on a single server.
> This is an expert operator technique and readers should be made aware of 
> this, a.k.a. the "I don't care, just get it running" approach.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Shalin Shekhar Mangar

Congratulations and welcome Ishan!

On Tue, Nov 29, 2016 at 11:47 PM, Mark Miller  wrote:
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Issue Comment Deleted] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread Judith Silverman (JIRA)


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

Judith Silverman updated SOLR-9783:
---
Comment: was deleted

(was: Hello, is there any context in which we *don't* want to interpret a null 
Sort value in a SortSpec as Sort.RELEVANCE?  I ask because I just had a test 
fail because sortWithinGroup was null. (My code is highly experimental, so this 
failure doesn't prove anything about the master.)  My investigation led me to 
SortSpecParsing's newEmptySortSpec(), which feeds a null Sort value to a 
SortSpec constructor.  I'm wondering whether newEmptySortSpec() could send 
Sort.RELEVANCE instead and/or the SortSpec constructors could be modified to 
replace nulls with Sort.RELEVANCE (and to adjust whatever else would need 
adjusting).  Apologies if this idea is impractical or has already been 
considered and dismissed.)

> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

[jira] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread Judith Silverman (JIRA)


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

Judith Silverman commented on SOLR-9783:


Hello, is there any context in which we *don't* want to interpret a null Sort 
value in a SortSpec as Sort.RELEVANCE? I ask because I just had a test fail 
because sortWithinGroup was null. (My code is highly experimental, so this 
failure doesn't prove anything about the master.) My investigation led me to 
SortSpecParsing's newEmptySortSpec(), which feeds a null Sort value to a 
SortSpec constructor. I'm wondering whether newEmptySortSpec() could send 
Sort.RELEVANCE instead and/or the SortSpec constructors could be modified to 
replace nulls with Sort.RELEVANCE (and to adjust whatever else would need 
adjusting). Apologies if this idea is impractical or has already been 
considered and dismissed.

> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

[jira] [Commented] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Kevin Risden (JIRA)


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

Kevin Risden commented on SOLR-9811:


Just curious how this is different than something like:

SOLR-7569
https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-ForceLeader

> Make it easier to manually execute overseer commands
> 
>
> Key: SOLR-9811
> URL: https://issues.apache.org/jira/browse/SOLR-9811
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Mike Drob
>
> Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
> it would be useful to have the ability to manually publish a node as active 
> or leader. This would be an alternative to some current ops practices of 
> restarting services, which may take a while to complete given many cores 
> hosted on a single server.
> This is an expert operator technique and readers should be made aware of 
> this, a.k.a. the "I don't care, just get it running" approach.



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

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

[jira] [Commented] (SOLR-9768) RecordingJsonParser produces incomplete json when updated document stream is larger than input parser's buffer size

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9768 RecordingJsonParser produces incomplete json (Wojciech Stryszyk via 
ab)


> RecordingJsonParser produces incomplete json when updated document stream is 
> larger than input parser's buffer size
> ---
>
> Key: SOLR-9768
> URL: https://issues.apache.org/jira/browse/SOLR-9768
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 6.1, 6.2, 6.3
>Reporter: Wojciech Stryszyk
>Assignee: Andrzej Bialecki 
>Priority: Minor
>  Labels: json, parsing, update_request_handler
> Attachments: SOLR_9768_RecordingJsonParser_fix.patch, 
> SOLR_9768_RecordingJsonParser_test.patch
>
>
> While using srcField, RecordingJsonParser produce incomplete json when 
> updated document stream is larger than buffer size (8192). 
> Fast fix is to align all documents in stream to buffer size. Another is 
> attached in patch bellow.



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

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

[jira] [Created] (SOLR-9811) Make it easier to manually execute overseer commands

2016-11-29 Thread Mike Drob (JIRA)

Mike Drob created SOLR-9811:
---

 Summary: Make it easier to manually execute overseer commands
 Key: SOLR-9811
 URL: https://issues.apache.org/jira/browse/SOLR-9811
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: Mike Drob


Sometimes solrcloud will get into a bad state w.r.t. election or recovery and 
it would be useful to have the ability to manually publish a node as active or 
leader. This would be an alternative to some current ops practices of 
restarting services, which may take a while to complete given many cores hosted 
on a single server.

This is an expert operator technique and readers should be made aware of this, 
a.k.a. the "I don't care, just get it running" approach.



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

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

[jira] [Created] (SOLR-9810) Implement a global field cache

2016-11-29 Thread Mike Drob (JIRA)

Mike Drob created SOLR-9810:
---

 Summary: Implement a global field cache
 Key: SOLR-9810
 URL: https://issues.apache.org/jira/browse/SOLR-9810
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mike Drob


When a Solr instance is serving many indices, it could be more efficient to use 
a single larger field cache instead of per-core caches. We should make this 
possible.



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

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

[jira] [Commented] (SOLR-9707) DeleteByQuery forward requests to down replicas and set it in LiR

2016-11-29 Thread Varun Thacker (JIRA)


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

Varun Thacker commented on SOLR-9707:
-

Its still a good idea to filter out down replica before sending the update. 
There might be edge cases / bugs which could lead to a replica being in down 
state even on a live node.

The tests pass with Jessica's original patch. 
[~markrmil...@gmail.com] or [~ysee...@gmail.com] any suggestions on how we can 
add a test case for this or is it just safe to commit the patch without an 
explicit test case for it?

> DeleteByQuery forward requests to down replicas and set it in LiR
> -
>
> Key: SOLR-9707
> URL: https://issues.apache.org/jira/browse/SOLR-9707
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>Assignee: Varun Thacker
>  Labels: solrcloud
> Attachments: SOLR-9707.diff, SOLR-9707.patch
>
>
> DeleteByQuery, unlike other requests, does not filter out the down replicas. 
> Thus, the update is still forwarded to the down replica and fails, and the 
> leader then sets the replica in LiR. In a cluster where there are lots of 
> deleteByQuery requests, this can flood the /overseer/queue.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Varun Thacker

Congratulations and welcome Ishan!

On Tue, Nov 29, 2016 at 11:14 AM, Timothy Potter 
wrote:

> Congrats and welcome!
>
> On Tue, Nov 29, 2016 at 12:02 PM, Alan Woodward  wrote:
> > Welcome Ishan!
> >
> > Alan Woodward
> > www.flax.co.uk
> >
> >
> > On 29 Nov 2016, at 18:17, Mark Miller  wrote:
> >
> > I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> > invitation to become a committer.
> >
> > Ishan, it's tradition that you introduce yourself with a brief bio /
> > origin story, explaining how you arrived here.
> >
> > Your handle "ishan" has already added to the “lucene" LDAP group, so
> > you now have commit privileges.
> >
> > Please celebrate this rite of passage, and confirm that the right
> > karma has in fact enabled, by embarking on the challenge of adding
> > yourself to the committers section of the Who We Are page on the
> > website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> > bookmarklet
> > at the bottom of the page here: https://cms.apache.org/#bookmark -
> > more info here http://www.apache.org/dev/cms.html).
> >
> > Congratulations and welcome!
> > --
> > - Mark
> > about.me/markrmiller
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Timothy Potter

Congrats and welcome!

On Tue, Nov 29, 2016 at 12:02 PM, Alan Woodward  wrote:
> Welcome Ishan!
>
> Alan Woodward
> www.flax.co.uk
>
>
> On 29 Nov 2016, at 18:17, Mark Miller  wrote:
>
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller
>
>

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

[jira] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread Judith Silverman (JIRA)


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

Judith Silverman commented on SOLR-9783:


Hello, is there any context in which we *don't* want to interpret a null Sort 
value in a SortSpec as Sort.RELEVANCE?  I ask because I just had a test fail 
because sortWithinGroup was null. (My code is highly experimental, so this 
failure doesn't prove anything about the master.)  My investigation led me to 
SortSpecParsing's newEmptySortSpec(), which feeds a null Sort value to a 
SortSpec constructor.  I'm wondering whether newEmptySortSpec() could send 
Sort.RELEVANCE instead and/or the SortSpec constructors could be modified to 
replace nulls with Sort.RELEVANCE (and to adjust whatever else would need 
adjusting).  Apologies if this idea is impractical or has already been 
considered and dismissed.

> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

[jira] [Commented] (LUCENE-7575) UnifiedHighlighter: add requireFieldMatch=false support

2016-11-29 Thread Ferenczi Jim (JIRA)


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

Ferenczi Jim commented on LUCENE-7575:
--

Hi [~dsmiley],
I've attached a patch based on the comment above. I did not find a clean way to 
detect duplicates in the span queries extracted by the PhraseHelper when 
requireFieldMatch=false. I agree that it's not essential so I pushed the patch 
as is. Could you please take a look ?

> UnifiedHighlighter: add requireFieldMatch=false support
> ---
>
> Key: LUCENE-7575
> URL: https://issues.apache.org/jira/browse/LUCENE-7575
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: David Smiley
> Attachments: LUCENE-7575.patch
>
>
> The UnifiedHighlighter (like the PostingsHighlighter) only supports 
> highlighting queries for the same fields that are being highlighted.  The 
> original Highlighter and FVH support loosening this, AKA 
> requireFieldMatch=false.



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

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

[jira] [Updated] (LUCENE-7575) UnifiedHighlighter: add requireFieldMatch=false support

2016-11-29 Thread Ferenczi Jim (JIRA)


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

Ferenczi Jim updated LUCENE-7575:
-
Attachment: LUCENE-7575.patch

Patch for requireFieldMatch

> UnifiedHighlighter: add requireFieldMatch=false support
> ---
>
> Key: LUCENE-7575
> URL: https://issues.apache.org/jira/browse/LUCENE-7575
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: David Smiley
> Attachments: LUCENE-7575.patch
>
>
> The UnifiedHighlighter (like the PostingsHighlighter) only supports 
> highlighting queries for the same fields that are being highlighted.  The 
> original Highlighter and FVH support loosening this, AKA 
> requireFieldMatch=false.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Alan Woodward

Welcome Ishan!

Alan Woodward
www.flax.co.uk


> On 29 Nov 2016, at 18:17, Mark Miller  wrote:
> 
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
> 
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
> 
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
> 
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html 
>  (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark 
>  -
> more info here http://www.apache.org/dev/cms.html 
> ).
> 
> Congratulations and welcome!
> -- 
> - Mark 
> about.me/markrmiller

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Joel Bernstein

Welcome Ishan!

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, Nov 29, 2016 at 1:44 PM, Scott Blum  wrote:

> Welcome, Ishan, congrats!
>
> On Tue, Nov 29, 2016 at 1:40 PM, Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> Welcome Ishan!
>>
>> On Tue, Nov 29, 2016 at 10:39 AM, Tommaso Teofili <
>> tommaso.teof...@gmail.com> wrote:
>>
>>> Welcome Ishan!
>>>
>>> Regards,
>>> Tommaso
>>>
>>> Il giorno mar 29 nov 2016 alle ore 19:33 Christine Poerschke (BLOOMBERG/
>>> LONDON)  ha scritto:
>>>
 Welcome Ishan!

 - Original Message -
 From: dev@lucene.apache.org
 To: dev@lucene.apache.org
 At: 11/29/16 18:29:43

 Welcome Ishan!

 On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss 
 wrote:
 > Welcome Ishan and congratulations!
 >
 > Dawid
 >
 > On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden <
 compuwizard...@gmail.com> wrote:
 >> Welcome Ishan! Congrats!
 >>
 >> Kevin Risden
 >>
 >> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley <
 david.w.smi...@gmail.com>
 >> wrote:
 >>>
 >>> Welcome Ishan!  This is long overdue.
 >>>
 >>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller 
 wrote:

  I'm pleased to announce that Ishan Chattopadhyaya has accepted the
 PMC's
  invitation to become a committer.

  Ishan, it's tradition that you introduce yourself with a brief bio
 /
  origin story, explaining how you arrived here.

  Your handle "ishan" has already added to the “lucene" LDAP group,
 so
  you now have commit privileges.

  Please celebrate this rite of passage, and confirm that the right
  karma has in fact enabled, by embarking on the challenge of adding
  yourself to the committers section of the Who We Are page on the
  website: http://lucene.apache.org/whoweare.html (use the ASF CMS
  bookmarklet
  at the bottom of the page here: https://cms.apache.org/#bookmark -
  more info here http://www.apache.org/dev/cms.html).

  Congratulations and welcome!
  --
  - Mark
  about.me/markrmiller
 >>>
 >>> --
 >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 >>> http://www.solrenterprisesearchserver.com
 >>
 >>
 >
 > -
 > 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] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9783: (Search|Top)Group[s]ShardResponseProcessor.process: turned 
sortWithinGroup null check into assert.
Also sort.equals tweak in (grouping) QueryCommand.create method.


> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Scott Blum

Welcome, Ishan, congrats!

On Tue, Nov 29, 2016 at 1:40 PM, Tomás Fernández Löbbe <
tomasflo...@gmail.com> wrote:

> Welcome Ishan!
>
> On Tue, Nov 29, 2016 at 10:39 AM, Tommaso Teofili <
> tommaso.teof...@gmail.com> wrote:
>
>> Welcome Ishan!
>>
>> Regards,
>> Tommaso
>>
>> Il giorno mar 29 nov 2016 alle ore 19:33 Christine Poerschke (BLOOMBERG/
>> LONDON)  ha scritto:
>>
>>> Welcome Ishan!
>>>
>>> - Original Message -
>>> From: dev@lucene.apache.org
>>> To: dev@lucene.apache.org
>>> At: 11/29/16 18:29:43
>>>
>>> Welcome Ishan!
>>>
>>> On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss 
>>> wrote:
>>> > Welcome Ishan and congratulations!
>>> >
>>> > Dawid
>>> >
>>> > On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden <
>>> compuwizard...@gmail.com> wrote:
>>> >> Welcome Ishan! Congrats!
>>> >>
>>> >> Kevin Risden
>>> >>
>>> >> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley <
>>> david.w.smi...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> Welcome Ishan!  This is long overdue.
>>> >>>
>>> >>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller 
>>> wrote:
>>> 
>>>  I'm pleased to announce that Ishan Chattopadhyaya has accepted the
>>> PMC's
>>>  invitation to become a committer.
>>> 
>>>  Ishan, it's tradition that you introduce yourself with a brief bio /
>>>  origin story, explaining how you arrived here.
>>> 
>>>  Your handle "ishan" has already added to the “lucene" LDAP group, so
>>>  you now have commit privileges.
>>> 
>>>  Please celebrate this rite of passage, and confirm that the right
>>>  karma has in fact enabled, by embarking on the challenge of adding
>>>  yourself to the committers section of the Who We Are page on the
>>>  website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>>>  bookmarklet
>>>  at the bottom of the page here: https://cms.apache.org/#bookmark -
>>>  more info here http://www.apache.org/dev/cms.html).
>>> 
>>>  Congratulations and welcome!
>>>  --
>>>  - Mark
>>>  about.me/markrmiller
>>> >>>
>>> >>> --
>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >>> http://www.solrenterprisesearchserver.com
>>> >>
>>> >>
>>> >
>>> > -
>>> > 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
>>>
>>>
>>>
>

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Tomás Fernández Löbbe

Welcome Ishan!

On Tue, Nov 29, 2016 at 10:39 AM, Tommaso Teofili  wrote:

> Welcome Ishan!
>
> Regards,
> Tommaso
>
> Il giorno mar 29 nov 2016 alle ore 19:33 Christine Poerschke (BLOOMBERG/
> LONDON)  ha scritto:
>
>> Welcome Ishan!
>>
>> - Original Message -
>> From: dev@lucene.apache.org
>> To: dev@lucene.apache.org
>> At: 11/29/16 18:29:43
>>
>> Welcome Ishan!
>>
>> On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss 
>> wrote:
>> > Welcome Ishan and congratulations!
>> >
>> > Dawid
>> >
>> > On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden 
>> wrote:
>> >> Welcome Ishan! Congrats!
>> >>
>> >> Kevin Risden
>> >>
>> >> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley <
>> david.w.smi...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Welcome Ishan!  This is long overdue.
>> >>>
>> >>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller 
>> wrote:
>> 
>>  I'm pleased to announce that Ishan Chattopadhyaya has accepted the
>> PMC's
>>  invitation to become a committer.
>> 
>>  Ishan, it's tradition that you introduce yourself with a brief bio /
>>  origin story, explaining how you arrived here.
>> 
>>  Your handle "ishan" has already added to the “lucene" LDAP group, so
>>  you now have commit privileges.
>> 
>>  Please celebrate this rite of passage, and confirm that the right
>>  karma has in fact enabled, by embarking on the challenge of adding
>>  yourself to the committers section of the Who We Are page on the
>>  website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>>  bookmarklet
>>  at the bottom of the page here: https://cms.apache.org/#bookmark -
>>  more info here http://www.apache.org/dev/cms.html).
>> 
>>  Congratulations and welcome!
>>  --
>>  - Mark
>>  about.me/markrmiller
>> >>>
>> >>> --
>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> >>> http://www.solrenterprisesearchserver.com
>> >>
>> >>
>> >
>> > -
>> > 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
>>
>>
>>

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Tommaso Teofili

Welcome Ishan!

Regards,
Tommaso

Il giorno mar 29 nov 2016 alle ore 19:33 Christine Poerschke (BLOOMBERG/
LONDON)  ha scritto:

> Welcome Ishan!
>
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: 11/29/16 18:29:43
>
> Welcome Ishan!
>
> On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss 
> wrote:
> > Welcome Ishan and congratulations!
> >
> > Dawid
> >
> > On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden 
> wrote:
> >> Welcome Ishan! Congrats!
> >>
> >> Kevin Risden
> >>
> >> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley <
> david.w.smi...@gmail.com>
> >> wrote:
> >>>
> >>> Welcome Ishan!  This is long overdue.
> >>>
> >>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller 
> wrote:
> 
>  I'm pleased to announce that Ishan Chattopadhyaya has accepted the
> PMC's
>  invitation to become a committer.
> 
>  Ishan, it's tradition that you introduce yourself with a brief bio /
>  origin story, explaining how you arrived here.
> 
>  Your handle "ishan" has already added to the “lucene" LDAP group, so
>  you now have commit privileges.
> 
>  Please celebrate this rite of passage, and confirm that the right
>  karma has in fact enabled, by embarking on the challenge of adding
>  yourself to the committers section of the Who We Are page on the
>  website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>  bookmarklet
>  at the bottom of the page here: https://cms.apache.org/#bookmark -
>  more info here http://www.apache.org/dev/cms.html).
> 
>  Congratulations and welcome!
>  --
>  - Mark
>  about.me/markrmiller
> >>>
> >>> --
> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >>> http://www.solrenterprisesearchserver.com
> >>
> >>
> >
> > -
> > 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
>
>
>

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Christine Poerschke (BLOOMBERG/ LONDON)

Welcome Ishan!

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: 11/29/16 18:29:43

Welcome Ishan!

On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss  wrote:
> Welcome Ishan and congratulations!
>
> Dawid
>
> On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden  
> wrote:
>> Welcome Ishan! Congrats!
>>
>> Kevin Risden
>>
>> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley 
>> wrote:
>>>
>>> Welcome Ishan!  This is long overdue.
>>>
>>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller  wrote:

 I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
 invitation to become a committer.

 Ishan, it's tradition that you introduce yourself with a brief bio /
 origin story, explaining how you arrived here.

 Your handle "ishan" has already added to the “lucene" LDAP group, so
 you now have commit privileges.

 Please celebrate this rite of passage, and confirm that the right
 karma has in fact enabled, by embarking on the challenge of adding
 yourself to the committers section of the Who We Are page on the
 website: http://lucene.apache.org/whoweare.html (use the ASF CMS
 bookmarklet
 at the bottom of the page here: https://cms.apache.org/#bookmark -
 more info here http://www.apache.org/dev/cms.html).

 Congratulations and welcome!
 --
 - Mark
 about.me/markrmiller
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>
>>
>
> -
> 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] [Commented] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9783: (Search|Top)Group[s]ShardResponseProcessor.process: turned 
sortWithinGroup null check into assert.
Also sort.equals tweak in (grouping) QueryCommand.create method.


> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



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

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Erick Erickson

Welcome Ishan!

On Tue, Nov 29, 2016 at 10:25 AM, Dawid Weiss  wrote:
> Welcome Ishan and congratulations!
>
> Dawid
>
> On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden  
> wrote:
>> Welcome Ishan! Congrats!
>>
>> Kevin Risden
>>
>> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley 
>> wrote:
>>>
>>> Welcome Ishan!  This is long overdue.
>>>
>>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller  wrote:

 I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
 invitation to become a committer.

 Ishan, it's tradition that you introduce yourself with a brief bio /
 origin story, explaining how you arrived here.

 Your handle "ishan" has already added to the “lucene" LDAP group, so
 you now have commit privileges.

 Please celebrate this rite of passage, and confirm that the right
 karma has in fact enabled, by embarking on the challenge of adding
 yourself to the committers section of the Who We Are page on the
 website: http://lucene.apache.org/whoweare.html (use the ASF CMS
 bookmarklet
 at the bottom of the page here: https://cms.apache.org/#bookmark -
 more info here http://www.apache.org/dev/cms.html).

 Congratulations and welcome!
 --
 - Mark
 about.me/markrmiller
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>
>>
>
> -
> 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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Dawid Weiss

Welcome Ishan and congratulations!

Dawid

On Tue, Nov 29, 2016 at 7:21 PM, Kevin Risden  wrote:
> Welcome Ishan! Congrats!
>
> Kevin Risden
>
> On Tue, Nov 29, 2016 at 12:19 PM, David Smiley 
> wrote:
>>
>> Welcome Ishan!  This is long overdue.
>>
>> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller  wrote:
>>>
>>> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
>>> invitation to become a committer.
>>>
>>> Ishan, it's tradition that you introduce yourself with a brief bio /
>>> origin story, explaining how you arrived here.
>>>
>>> Your handle "ishan" has already added to the “lucene" LDAP group, so
>>> you now have commit privileges.
>>>
>>> Please celebrate this rite of passage, and confirm that the right
>>> karma has in fact enabled, by embarking on the challenge of adding
>>> yourself to the committers section of the Who We Are page on the
>>> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>>> bookmarklet
>>> at the bottom of the page here: https://cms.apache.org/#bookmark -
>>> more info here http://www.apache.org/dev/cms.html).
>>>
>>> Congratulations and welcome!
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>
>

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

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Kevin Risden

Welcome Ishan! Congrats!

Kevin Risden

On Tue, Nov 29, 2016 at 12:19 PM, David Smiley 
wrote:

> Welcome Ishan!  This is long overdue.
>
> On Tue, Nov 29, 2016 at 1:17 PM Mark Miller  wrote:
>
>> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
>> invitation to become a committer.
>>
>> Ishan, it's tradition that you introduce yourself with a brief bio /
>> origin story, explaining how you arrived here.
>>
>> Your handle "ishan" has already added to the “lucene" LDAP group, so
>> you now have commit privileges.
>>
>> Please celebrate this rite of passage, and confirm that the right
>> karma has in fact enabled, by embarking on the challenge of adding
>> yourself to the committers section of the Who We Are page on the
>> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
>> bookmarklet
>> at the bottom of the page here: https://cms.apache.org/#bookmark -
>> more info here http://www.apache.org/dev/cms.html).
>>
>> Congratulations and welcome!
>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread David Smiley

Welcome Ishan!  This is long overdue.

On Tue, Nov 29, 2016 at 1:17 PM Mark Miller  wrote:

> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
>
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Steve Rowe

Congrats and welcome, Ishan!

—-
Steve
www.lucidworks.com

> On Nov 29, 2016, at 1:17 PM, Mark Miller  wrote:
> 
> I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
> invitation to become a committer.
> 
> Ishan, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
> 
> Your handle "ishan" has already added to the “lucene" LDAP group, so
> you now have commit privileges.
> 
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
> 
> Congratulations and welcome!
> -- 
> - Mark 
> about.me/markrmiller


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

Welcome Ishan Chattopadhyaya as Lucene/Solr committer

2016-11-29 Thread Mark Miller

I'm pleased to announce that Ishan Chattopadhyaya has accepted the PMC's
invitation to become a committer.

Ishan, it's tradition that you introduce yourself with a brief bio /
origin story, explaining how you arrived here.

Your handle "ishan" has already added to the “lucene" LDAP group, so
you now have commit privileges.

Please celebrate this rite of passage, and confirm that the right
karma has in fact enabled, by embarking on the challenge of adding
yourself to the committers section of the Who We Are page on the
website: http://lucene.apache.org/whoweare.html (use the ASF CMS
bookmarklet
at the bottom of the page here: https://cms.apache.org/#bookmark -
more info here http://www.apache.org/dev/cms.html).

Congratulations and welcome!
-- 
- Mark
about.me/markrmiller

[jira] [Assigned] (SOLR-9768) RecordingJsonParser produces incomplete json when updated document stream is larger than input parser's buffer size

2016-11-29 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  reassigned SOLR-9768:
---

Assignee: Andrzej Bialecki 

> RecordingJsonParser produces incomplete json when updated document stream is 
> larger than input parser's buffer size
> ---
>
> Key: SOLR-9768
> URL: https://issues.apache.org/jira/browse/SOLR-9768
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Affects Versions: 6.1, 6.2, 6.3
>Reporter: Wojciech Stryszyk
>Assignee: Andrzej Bialecki 
>Priority: Minor
>  Labels: json, parsing, update_request_handler
> Attachments: SOLR_9768_RecordingJsonParser_fix.patch, 
> SOLR_9768_RecordingJsonParser_test.patch
>
>
> While using srcField, RecordingJsonParser produce incomplete json when 
> updated document stream is larger than buffer size (8192). 
> Fast fix is to align all documents in stream to buffer size. Another is 
> attached in patch bellow.



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

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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

Commit f027098b4c0a27c70c7cb33dc80492a199bc44cf in lucene-solr's branch 
refs/heads/feature/metrics from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f027098 ]

SOLR-4735 Cleanup and fix lint errors.


> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
> getSource() seems pretty useless), but maybe that's for another issue.



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

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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

Commit db1339ff622cc73871897f8b345a9be19134a95e in lucene-solr's branch 
refs/heads/feature/metrics from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=db1339f ]

SOLR-4735 Improve Solr metric reporting (Alan Woodward, Kelvin Wong,
Christine Poerschke, Jeff Wartes, ab)


> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
> getSource() seems pretty useless), but maybe that's for another issue.



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

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

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

2016-11-29 Thread Apache Jenkins Server

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([1CE688F6FD496B81:2B7D7CE8C585B625]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:130)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:315)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:332)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Updated] (SOLR-9727) solr.in.sh properties does not set the correct values.

2016-11-29 Thread Kevin Risden (JIRA)


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

Kevin Risden updated SOLR-9727:
---
Fix Version/s: 6.4
   master (7.0)

> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Kevin Risden
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or 
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false. 
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.



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

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

[jira] [Updated] (SOLR-9727) solr.in.sh properties does not set need/want client auth values.

2016-11-29 Thread Kevin Risden (JIRA)


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

Kevin Risden updated SOLR-9727:
---
Summary: solr.in.sh properties does not set need/want client auth values.  
(was: solr.in.sh properties does not set the correct values.)

> solr.in.sh properties does not set need/want client auth values.
> 
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Kevin Risden
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or 
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false. 
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.



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

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

[jira] [Resolved] (SOLR-9727) solr.in.sh properties does not set the correct values.

2016-11-29 Thread Kevin Risden (JIRA)


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

Kevin Risden resolved SOLR-9727.

Resolution: Fixed

After SOLR-9801 or SOLR-9728, need and want client auth values are being set 
properly.

> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Kevin Risden
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or 
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false. 
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.



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

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

[jira] [Resolved] (SOLR-9512) CloudSolrClient's cluster state cache can break direct updates to leaders

2016-11-29 Thread Noble Paul (JIRA)


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

Noble Paul resolved SOLR-9512.
--
   Resolution: Fixed
Fix Version/s: 6.4

> CloudSolrClient's cluster state cache can break direct updates to leaders
> -
>
> Key: SOLR-9512
> URL: https://issues.apache.org/jira/browse/SOLR-9512
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Noble Paul
> Fix For: 6.4
>
> Attachments: SOLR-9512.patch, SOLR-9512.patch, SOLR-9512.patch
>
>
> This is the root cause of SOLR-9305 and (at least some of) SOLR-9390.  The 
> process goes something like this:
> Documents are added to the cluster via a CloudSolrClient, with 
> directUpdatesToLeadersOnly set to true.  CSC caches its view of the 
> DocCollection.  The leader then goes down, and is reassigned.  Next time 
> documents are added, CSC checks its cache again, and gets the old view of the 
> DocCollection.  It then tries to send the update directly to the old, now 
> down, leader, and we get ConnectionRefused.



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

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

[jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions

2016-11-29 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-3284:


It's telling that nowadays, internally in Solr there are actually 2 subclasses 
of ConcurrentUpdateSolrClient who both exist to handle errors:  
SafeConcurrentUpdateSolrClient (in morphlines) and 
ErrorReportingConcurrentUpdateSolrClient (defined within and returned by  
StreamingSolrClients, used by SolrCmdDistributor used by 
DistributedUpdateProcessor).  And note also that all constructors are of CUSC 
are deprecated even though the only way to actually implement handleError by a 
user implies you need to use them since the Builder doesn't expose configuring 
error handling.

IMO the default behavior of CUSC should be basically just like 
SafeConcurrentUpdateSolrClient so that users see problems readily.  Perhaps 
also check & throw in request().  StreamingSolrClients can override to do it's 
special handling.

> StreamingUpdateSolrServer swallows exceptions
> -
>
> Key: SOLR-3284
> URL: https://issues.apache.org/jira/browse/SOLR-3284
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 3.5, 4.0-ALPHA
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Attachments: SOLR-3284.patch
>
>
> StreamingUpdateSolrServer eats exceptions thrown by lower level code, such as 
> HttpClient, when doing adds.  It may happen with other methods, though I know 
> that query and deleteByQuery will throw exceptions.  I believe that this is a 
> result of the queue/Runner design.  That's what makes SUSS perform better, 
> but it means you sacrifice the ability to programmatically determine that 
> there was a problem with your update.  All errors are logged via slf4j, but 
> that's not terribly helpful except with determining what went wrong after the 
> fact.
> When using CommonsHttpSolrServer, I've been able to rely on getting an 
> exception thrown by pretty much any error, letting me use try/catch to detect 
> problems.
> There's probably enough dependent code out there that it would not be a good 
> idea to change the design of SUSS, unless there were alternate constructors 
> or additional methods available to configure new/old behavior.  Fixing this 
> is probably not trivial, so it's probably a better idea to come up with a new 
> server object based on CHSS.  This is outside my current skillset.



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

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

[jira] [Commented] (SOLR-7280) Load cores in sorted order and tweak coreLoadThread counts to improve cluster stability on restarts

2016-11-29 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-7280:
---

It would seem the next step is probably to make the ZkController#preRegister 
phase more efficient. We would want to try and avoid all the individual down 
publish calls. This is what initially populates those entries in ZK though, 
which is why this was not simply switched to a more efficient 'down' node 
Overseer action like some other places. We may need another bulk Overseer 
command or perhaps we can expand the 'down' node one.

> Load cores in sorted order and tweak coreLoadThread counts to improve cluster 
> stability on restarts
> ---
>
> Key: SOLR-7280
> URL: https://issues.apache.org/jira/browse/SOLR-7280
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.5.3, 6.2
>
> Attachments: SOLR-7280-5x.patch, SOLR-7280-5x.patch, 
> SOLR-7280-5x.patch, SOLR-7280-test.patch, SOLR-7280.patch, SOLR-7280.patch
>
>
> In SOLR-7191, Damien mentioned that by loading solr cores in a sorted order 
> and tweaking some of the coreLoadThread counts, he was able to improve the 
> stability of a cluster with thousands of collections. We should explore some 
> of these changes and fold them into Solr.



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

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

[jira] [Commented] (SOLR-7280) Load cores in sorted order and tweak coreLoadThread counts to improve cluster stability on restarts

2016-11-29 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-7280:
---

Hey [~dk], could you file a new JIRA issue with this info and link it to this 
one?

Sounds like you are probably correct, but this issue has already been released 
so any further changes or improvements needs a fresh issue on top of notifying 
the original issue.

> Load cores in sorted order and tweak coreLoadThread counts to improve cluster 
> stability on restarts
> ---
>
> Key: SOLR-7280
> URL: https://issues.apache.org/jira/browse/SOLR-7280
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Fix For: 5.5.3, 6.2
>
> Attachments: SOLR-7280-5x.patch, SOLR-7280-5x.patch, 
> SOLR-7280-5x.patch, SOLR-7280-test.patch, SOLR-7280.patch, SOLR-7280.patch
>
>
> In SOLR-7191, Damien mentioned that by loading solr cores in a sorted order 
> and tweaking some of the coreLoadThread counts, he was able to improve the 
> stability of a cluster with thousands of collections. We should explore some 
> of these changes and fold them into Solr.



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

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

[jira] [Commented] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9546: remove unnecessary boxing


> There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
> --
>
> Key: SOLR-9546
> URL: https://issues.apache.org/jira/browse/SOLR-9546
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-9546.patch, SOLR-9546_CloudMLTQParser.patch
>
>
> Here is an excerpt 
> {code}
>   public Long getLong(String param, Long def) {
> String val = get(param);
> try {
>   return val== null ? def : Long.parseLong(val);
> }
> catch( Exception ex ) {
>   throw new SolrException( SolrException.ErrorCode.BAD_REQUEST, 
> ex.getMessage(), ex );
> }
>   }
> {code}
> {{Long.parseLong()}} returns a primitive type but since method expect to 
> return a {{Long}}, it needs to be wrapped. There are many more method like 
> that. We might be creating a lot of unnecessary objects here.
> I am not sure if JVM catches upto it and somehow optimizes it if these 
> methods are called enough times (or may be compiler does some modifications 
> at compile time)
> Let me know if I am thinking of some premature optimization



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

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

[jira] [Commented] (SOLR-9728) Ability to specify Key Store type in solr.in.sh file for SSL

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

Commit bf424d1ec1602dffeb33ab0acc8f470e351a6959 in lucene-solr's branch 
refs/heads/feature/metrics from [~risdenk]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bf424d1 ]

SOLR-9728: Ability to specify Key Store type in solr.in file for SSL


> Ability to specify Key Store type in solr.in.sh file for SSL
> 
>
> Key: SOLR-9728
> URL: https://issues.apache.org/jira/browse/SOLR-9728
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Kevin Risden
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9728.patch, SOLR-9728.patch, SOLR-9728.patch
>
>
> At present when ssl is enabled we can't set the SSL type. It currently 
> defaults to JCK.
> As a user I would like to configure the SSL type via the solr.in file.
> For instance "JCEKS" would be configured as:
> {code}
> SOLR_SSL_KEYSTORE_TYPE=JCEKS
> SOLR_SSL_TRUSTSTORE_TYPE=JCEKS
> {code}



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

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

[jira] [Commented] (SOLR-9784) Refactor CloudSolrClient to eliminate direct dependency on ZK

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9784: added deprecation javadocs


> Refactor CloudSolrClient to eliminate direct dependency on ZK
> -
>
> Key: SOLR-9784
> URL: https://issues.apache.org/jira/browse/SOLR-9784
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Noble Paul
>Assignee: Noble Paul
> Attachments: SOLR-9584.patch
>
>
> CloudSolrClient should decouple itself from the ZK reading/write. This will 
> help us provide alternate implementations w/o direct ZK dependency



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

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

[jira] [Commented] (LUCENE-7572) Cache the hashcode of the doc values terms queries

2016-11-29 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-7572:
--

bq. Would you mind adding some JavaDocs to PrefixCodedTerms to say this?

I will do that.

bq.  The presence of "delGen" seems out of place having nothing directly to do 
with this utility class's job

Agreed. If something needs a delGen, it should create another object that wraps 
a PrefixCodedTerms instance and the delGen.

bq. And RAMFile shouldn't depend on RAMDirectory

Agreed too, even though that one is a bit less annoying to me since the RAMDir 
and the constructor that sets it are both pkg-private.

> Cache the hashcode of the doc values terms queries
> --
>
> Key: LUCENE-7572
> URL: https://issues.apache.org/jira/browse/LUCENE-7572
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7572.patch
>
>
> DocValuesNumbersQuery and DocValuesTermsQuery can potentially wrap a large 
> number of terms so it would help if we cached their hashcode.



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

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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-4735:
--

GitHub user sigram opened a pull request:

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

SOLR-4735 Improve Solr metrics reporting



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

$ git pull https://github.com/sigram/lucene-solr jira/solr-4735

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

https://github.com/apache/lucene-solr/pull/120.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 #120


commit dba0663c79f7b27d4626152d36f8d6d4c62a878d
Author: Andrzej Bialecki 
Date:   2016-11-23T12:48:26Z

Initial patch from Jira.

commit 1ade9c443dbd5b9eae2ec5208b233d28fb20a8cb
Author: Andrzej Bialecki 
Date:   2016-11-24T10:45:20Z

Merge branch 'master' into jira/solr-4735

commit ba2a94fb52d21ed05053a098c8fb9919a469e5b3
Author: Andrzej Bialecki 
Date:   2016-11-24T15:32:04Z

Use SharedMetricRegistries for managing per-core metrics.

commit 7199e818da503bc0e8a40fed7d6a1f742ecbae55
Author: Andrzej Bialecki 
Date:   2016-11-24T15:44:55Z

Revert accidental changes to this file.

commit a4514638df8a2528f339107869b03fe568856fd9
Author: Andrzej Bialecki 
Date:   2016-11-28T14:01:42Z

SOLR-4735 Use separate registries for core and other stuff. Use collapsible 
and
configurable namespace.

commit bf424d1ec1602dffeb33ab0acc8f470e351a6959
Author: Kevin Risden 
Date:   2016-11-22T19:22:16Z

SOLR-9728: Ability to specify Key Store type in solr.in file for SSL

commit 5b2594350df11ef54d52f417b34c6d082ad85e89
Author: Noble Paul 
Date:   2016-11-29T02:35:47Z

SOLR-9784: added deprecation javadocs

commit 32c4bd7cc0ac2e93e833f5fe84be4ff69f0b7aeb
Author: Noble Paul 
Date:   2016-11-29T02:36:26Z

Merge remote-tracking branch 'origin/master'

commit 9b4f99c1b351b1401e2dd5922a06d79a809332fb
Author: Andrzej Bialecki 
Date:   2016-11-29T10:37:14Z

SOLR-4735 Reorder args from top level to bottom.

commit 70b358960dfe8a6da35991b2a84c93cc9370c3d8
Author: Noble Paul 
Date:   2016-11-29T12:32:59Z

SOLR-9546: remove unnecessary boxing

commit 2af8ec2689610f4dfb1f5d87b069b0eb54f72155
Author: Andrzej Bialecki 
Date:   2016-11-29T13:48:44Z

SOLR-4735 More cleanup and generalization of JMX reporter.

commit 4b7002eae75839d2f56a17a65d7e789cb71a9b26
Author: Andrzej Bialecki 
Date:   2016-11-29T13:56:24Z

Merge branch 'master' into jira/solr-4735




> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
>

[GitHub] lucene-solr pull request #120: SOLR-4735 Improve Solr metrics reporting

2016-11-29 Thread sigram

GitHub user sigram opened a pull request:

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

SOLR-4735 Improve Solr metrics reporting



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

$ git pull https://github.com/sigram/lucene-solr jira/solr-4735

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

https://github.com/apache/lucene-solr/pull/120.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 #120


commit dba0663c79f7b27d4626152d36f8d6d4c62a878d
Author: Andrzej Bialecki 
Date:   2016-11-23T12:48:26Z

Initial patch from Jira.

commit 1ade9c443dbd5b9eae2ec5208b233d28fb20a8cb
Author: Andrzej Bialecki 
Date:   2016-11-24T10:45:20Z

Merge branch 'master' into jira/solr-4735

commit ba2a94fb52d21ed05053a098c8fb9919a469e5b3
Author: Andrzej Bialecki 
Date:   2016-11-24T15:32:04Z

Use SharedMetricRegistries for managing per-core metrics.

commit 7199e818da503bc0e8a40fed7d6a1f742ecbae55
Author: Andrzej Bialecki 
Date:   2016-11-24T15:44:55Z

Revert accidental changes to this file.

commit a4514638df8a2528f339107869b03fe568856fd9
Author: Andrzej Bialecki 
Date:   2016-11-28T14:01:42Z

SOLR-4735 Use separate registries for core and other stuff. Use collapsible 
and
configurable namespace.

commit bf424d1ec1602dffeb33ab0acc8f470e351a6959
Author: Kevin Risden 
Date:   2016-11-22T19:22:16Z

SOLR-9728: Ability to specify Key Store type in solr.in file for SSL

commit 5b2594350df11ef54d52f417b34c6d082ad85e89
Author: Noble Paul 
Date:   2016-11-29T02:35:47Z

SOLR-9784: added deprecation javadocs

commit 32c4bd7cc0ac2e93e833f5fe84be4ff69f0b7aeb
Author: Noble Paul 
Date:   2016-11-29T02:36:26Z

Merge remote-tracking branch 'origin/master'

commit 9b4f99c1b351b1401e2dd5922a06d79a809332fb
Author: Andrzej Bialecki 
Date:   2016-11-29T10:37:14Z

SOLR-4735 Reorder args from top level to bottom.

commit 70b358960dfe8a6da35991b2a84c93cc9370c3d8
Author: Noble Paul 
Date:   2016-11-29T12:32:59Z

SOLR-9546: remove unnecessary boxing

commit 2af8ec2689610f4dfb1f5d87b069b0eb54f72155
Author: Andrzej Bialecki 
Date:   2016-11-29T13:48:44Z

SOLR-4735 More cleanup and generalization of JMX reporter.

commit 4b7002eae75839d2f56a17a65d7e789cb71a9b26
Author: Andrzej Bialecki 
Date:   2016-11-29T13:56:24Z

Merge branch 'master' into jira/solr-4735




---
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-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-4735:
--

Github user sigram commented on the issue:

https://github.com/apache/lucene-solr/pull/119
  
This work will be merged and continued in the `features/metrics` branch at 
ASF.


> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
> getSource() seems pretty useless), but maybe that's for another issue.



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

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

[jira] [Commented] (SOLR-4735) Improve Solr metrics reporting

2016-11-29 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SOLR-4735:
--

Github user sigram closed the pull request at:

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


> Improve Solr metrics reporting
> --
>
> Key: SOLR-4735
> URL: https://issues.apache.org/jira/browse/SOLR-4735
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Andrzej Bialecki 
>Priority: Minor
> Attachments: SOLR-4735.patch, SOLR-4735.patch, SOLR-4735.patch, 
> SOLR-4735.patch
>
>
> Following on from a discussion on the mailing list:
> http://search-lucene.com/m/IO0EI1qdyJF1/codahale=Solr+metrics+in+Codahale+metrics+and+Graphite+
> It would be good to make Solr play more nicely with existing devops 
> monitoring systems, such as Graphite or Ganglia.  Stats monitoring at the 
> moment is poll-only, either via JMX or through the admin stats page.  I'd 
> like to refactor things a bit to make this more pluggable.
> This patch is a start.  It adds a new interface, InstrumentedBean, which 
> extends SolrInfoMBean to return a 
> [[Metrics|http://metrics.codahale.com/manual/core/]] MetricRegistry, and a 
> couple of MetricReporters (which basically just duplicate the JMX and admin 
> page reporting that's there at the moment, but which should be more 
> extensible).  The patch includes a change to RequestHandlerBase showing how 
> this could work.  The idea would be to eventually replace the getStatistics() 
> call on SolrInfoMBean with this instead.
> The next step would be to allow more MetricReporters to be defined in 
> solrconfig.xml.  The Metrics library comes with ganglia and graphite 
> reporting modules, and we can add contrib plugins for both of those.
> There's some more general cleanup that could be done around SolrInfoMBean 
> (we've got two plugin handlers at /mbeans and /plugins that basically do the 
> same thing, and the beans themselves have some weirdly inconsistent data on 
> them - getVersion() returns different things for different impls, and 
> getSource() seems pretty useless), but maybe that's for another issue.



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

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

[GitHub] lucene-solr pull request #119: SOLR-4735 Improve Solr metrics

2016-11-29 Thread sigram

Github user sigram closed the pull request at:

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


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

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

[GitHub] lucene-solr issue #119: SOLR-4735 Improve Solr metrics

2016-11-29 Thread sigram

Github user sigram commented on the issue:

https://github.com/apache/lucene-solr/pull/119
  
This work will be merged and continued in the `features/metrics` branch at 
ASF.


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

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

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

2016-11-29 Thread Policeman Jenkins Server

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

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestZkChroot

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf\lang:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf\lang

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf\lang:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001\tempDir-004\collection1\conf\lang
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestZkChroot_E467A7AA0BEA360B-001

at __randomizedtesting.SeedInfo.seed([E467A7AA0BEA360B]: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

[jira] [Commented] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9546: remove unnecessary boxing


> There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
> --
>
> Key: SOLR-9546
> URL: https://issues.apache.org/jira/browse/SOLR-9546
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-9546.patch, SOLR-9546_CloudMLTQParser.patch
>
>
> Here is an excerpt 
> {code}
>   public Long getLong(String param, Long def) {
> String val = get(param);
> try {
>   return val== null ? def : Long.parseLong(val);
> }
> catch( Exception ex ) {
>   throw new SolrException( SolrException.ErrorCode.BAD_REQUEST, 
> ex.getMessage(), ex );
> }
>   }
> {code}
> {{Long.parseLong()}} returns a primitive type but since method expect to 
> return a {{Long}}, it needs to be wrapped. There are many more method like 
> that. We might be creating a lot of unnecessary objects here.
> I am not sure if JVM catches upto it and somehow optimizes it if these 
> methods are called enough times (or may be compiler does some modifications 
> at compile time)
> Let me know if I am thinking of some premature optimization



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

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

[jira] [Commented] (SOLR-9546) There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class

2016-11-29 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-9546: remove unnecessary boxing


> There is a lot of unnecessary boxing/unboxing going on in {{SolrParams}} class
> --
>
> Key: SOLR-9546
> URL: https://issues.apache.org/jira/browse/SOLR-9546
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-9546.patch, SOLR-9546_CloudMLTQParser.patch
>
>
> Here is an excerpt 
> {code}
>   public Long getLong(String param, Long def) {
> String val = get(param);
> try {
>   return val== null ? def : Long.parseLong(val);
> }
> catch( Exception ex ) {
>   throw new SolrException( SolrException.ErrorCode.BAD_REQUEST, 
> ex.getMessage(), ex );
> }
>   }
> {code}
> {{Long.parseLong()}} returns a primitive type but since method expect to 
> return a {{Long}}, it needs to be wrapped. There are many more method like 
> that. We might be creating a lot of unnecessary objects here.
> I am not sure if JVM catches upto it and somehow optimizes it if these 
> methods are called enough times (or may be compiler does some modifications 
> at compile time)
> Let me know if I am thinking of some premature optimization



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

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

[jira] [Commented] (SOLR-9727) solr.in.sh properties does not set the correct values.

2016-11-29 Thread Michael Suzuki (JIRA)


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

Michael Suzuki commented on SOLR-9727:
--

[~risdenk] , I have verified the issue and it can not be reprocuded, the values 
are now correctly set.
It seems that #SOLR-9801 has resolved the issue.


> solr.in.sh properties does not set the correct values.
> --
>
> Key: SOLR-9727
> URL: https://issues.apache.org/jira/browse/SOLR-9727
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: master (7.0)
>Reporter: Michael Suzuki
>Assignee: Kevin Risden
> Attachments: SOLR-9727.patch
>
>
> When setting values to true on SOLR_SSL_NEED_CLIENT_AUTH or 
> SOLR_SSL_WANT_CLIENT_AUTH, jetty starts with these values as set to false. 
> {code}
> SOLR_SSL_NEED_CLIENT_AUTH=true
> SOLR_SSL_WANT_CLIENT_AUTH=false
> {code}
> To recreate the issue:
> 1) Edit solr.ini.sh to enable ssl and set SOLR_SSL_NEED_CLIENT_AUTH to true.
> 2) Start solr with remote debugging.
> 3) Set a debug point in SSLContextFactory.java, on setNeedClientAuth(...)
> Expected value for needClientAuth should be true instead its false.



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

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

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

2016-11-29 Thread Policeman Jenkins Server

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=16746, name=jetty-launcher-3135-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)   
 2) Thread[id=16750, name=jetty-launcher-3135-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=16746, name=jetty-launcher-3135-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_102) - Build # 6255 - Still Unstable!

2016-11-29 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6255/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([C423C2337603F98D:AC9CF719A699EB61]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

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

2016-11-29 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2296/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([2C48E3B9841F449D:AF3EBC4B52664A3C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest(TestCloudRecovery.java:155)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12097 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestCloudRecovery
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestCloudRecovery_2C48E3B9841F449D-001/init-core-data-001
   [junit4]

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1167 - Still Unstable

2016-11-29 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1167/

8 tests failed.
FAILED:  org.apache.lucene.search.TestFuzzyQuery.testRandom

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([C2A2F06A1FDD91FD]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.search.TestFuzzyQuery

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

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


FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard2

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard2
at 
__randomizedtesting.SeedInfo.seed([8C5C8052833C397:DA3584E6769C65A5]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:795)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange(CdcrReplicationDistributedZkTest.java:306)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

96 matches

Mail list logo