[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 847 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/847/

1 tests failed.
FAILED:  
org.apache.solr.cloud.LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR

Error Message:
Captured an uncaught exception in thread: Thread[id=5532, 
name=coreZkRegister-1177-thread-1, state=RUNNABLE, 
group=TGRP-LeaderInitiatedRecoveryOnShardRestartTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=5532, name=coreZkRegister-1177-thread-1, 
state=RUNNABLE, group=TGRP-LeaderInitiatedRecoveryOnShardRestartTest]
at 
__randomizedtesting.SeedInfo.seed([C18643A00F840DE6:1F0C2DDD34266F15]:0)
Caused by: java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([C18643A00F840DE6]:0)
at 
org.apache.solr.cloud.ZkController.updateLeaderInitiatedRecoveryState(ZkController.java:2126)
at 
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:451)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:197)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:157)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:346)
at 
org.apache.solr.cloud.ZkController.joinElection(ZkController.java:1113)
at org.apache.solr.cloud.ZkController.register(ZkController.java:926)
at org.apache.solr.cloud.ZkController.register(ZkController.java:881)
at org.apache.solr.core.ZkContainer$2.run(ZkContainer.java:183)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:231)
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)




Build Log:
[...truncated 10073 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.LeaderInitiatedRecoveryOnShardRestartTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J2/temp/solr.cloud.LeaderInitiatedRecoveryOnShardRestartTest_C18643A00F840DE6-001/init-core-data-001
   [junit4]   2> 516930 INFO  
(SUITE-LeaderInitiatedRecoveryOnShardRestartTest-seed#[C18643A00F840DE6]-worker)
 [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system 
property: /aw_/
   [junit4]   2> 516933 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 516934 INFO  (Thread-3513) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 516934 INFO  (Thread-3513) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 517034 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.ZkTestServer start zk server on port:38041
   [junit4]   2> 517034 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 517035 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 517038 INFO  (zkCallback-456-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@3765e6c3 
name:ZooKeeperConnection Watcher:127.0.0.1:38041 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 517038 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 517038 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 517038 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 517040 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 517041 INFO  
(TEST-LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR-seed#[C18643A00F840DE6])
 [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 517042 INFO  (zkCallback-457-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@13ea22fd 
name:ZooKeeperConnection Watcher:127.0.0.1:38041/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   

[jira] [Created] (SOLR-8258) Change default hdfs tlog replication factor from 1 to 3 in 6x.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8258:
-

 Summary: Change default hdfs tlog replication factor from 1 to 3 
in 6x.
 Key: SOLR-8258
 URL: https://issues.apache.org/jira/browse/SOLR-8258
 Project: Solr
  Issue Type: Improvement
  Components: hdfs
Reporter: Mark Miller
Assignee: Mark Miller


Some HDFS features, such as lease recovery, really don't like a replication 
factor of 1. We have found that it is best to default this to 3.



--
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-8253) AbstractDistribZkTestBase can fail to shutdown its ZkServer

[ASF subversion and git services (JIRA)]

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

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

Commit 1713443 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713443 ]

SOLR-8253: Ensure ZK server is always shutdown in AbstractDistribZkTestBase

> AbstractDistribZkTestBase can fail to shutdown its ZkServer
> ---
>
> Key: SOLR-8253
> URL: https://issues.apache.org/jira/browse/SOLR-8253
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> If there's an error shutting down the jetty servers, then zkServer.shutdown() 
> won't get called.  This ends up hiding actual errors from test failures with 
> thread-leak messages.



--
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-8253) AbstractDistribZkTestBase can fail to shutdown its ZkServer

[ASF subversion and git services (JIRA)]

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

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

Commit 1713444 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713444 ]

SOLR-8253: Ensure ZK server is always shutdown in AbstractDistribZkTestBase

> AbstractDistribZkTestBase can fail to shutdown its ZkServer
> ---
>
> Key: SOLR-8253
> URL: https://issues.apache.org/jira/browse/SOLR-8253
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> If there's an error shutting down the jetty servers, then zkServer.shutdown() 
> won't get called.  This ends up hiding actual errors from test failures with 
> thread-leak messages.



--
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-8253) AbstractDistribZkTestBase can fail to shutdown its ZkServer

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8253.
-
Resolution: Fixed

> AbstractDistribZkTestBase can fail to shutdown its ZkServer
> ---
>
> Key: SOLR-8253
> URL: https://issues.apache.org/jira/browse/SOLR-8253
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> If there's an error shutting down the jetty servers, then zkServer.shutdown() 
> won't get called.  This ends up hiding actual errors from test failures with 
> thread-leak messages.



--
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-6679) Filter's Weight.explain returns an explanation with isMatch==true even on documents that don't match

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6679:
--

5.x and trunk are indeed different, mainly because of backward compatibility 
for FilteredQuery (which is gone in trunk but still exists in 5.x): since 
FilteredQuery has an option that lets control whether the filter should be 
executed before or after the query, Filter had to diverge a bit from trunk so 
that this would remain possible (while in trunk all decisions are made 
automatically now).

Terry, please let us know if you need help fixing the tests that fail with your 
patch. I'd be happy to help.

> Filter's Weight.explain returns an explanation with isMatch==true even on 
> documents that don't match
> 
>
> Key: LUCENE-6679
> URL: https://issues.apache.org/jira/browse/LUCENE-6679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-6679.patch
>
>
> This was reported by Trejkaz on the java-user list: 
> http://search-lucene.com/m/l6pAi19h4Y3DclgB1=Re+What+on+earth+is+FilteredQuery+explain+doing+



--
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-5.x-Java7 - Build # 3737 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3737/

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

Error Message:
Error from server at http://127.0.0.1:56139/u_ab/v/awholynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 500HTTP ERROR: 500 Problem 
accessing /u_ab/v/awholynewcollection_0/select. Reason: 
{trace=java.lang.NullPointerException  at 
org.apache.solr.servlet.HttpSolrCall.getCoreByCollection(HttpSolrCall.java:786) 
 at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:270)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:415)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)  
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)  
at org.eclipse.jetty.server.Server.handle(Server.java:499)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)  at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
 at java.lang.Thread.run(Thread.java:745) ,code=500} Powered by Jetty://   

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


Error 500 


HTTP ERROR: 500
Problem accessing /u_ab/v/awholynewcollection_0/select. Reason:
{trace=java.lang.NullPointerException
at 
org.apache.solr.servlet.HttpSolrCall.getCoreByCollection(HttpSolrCall.java:786)
at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:270)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:415)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:109)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at 

[jira] [Closed] (LUCENE-6631) Lucene Document Classification

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti closed LUCENE-6631.


> Lucene Document Classification
> --
>
> Key: LUCENE-6631
> URL: https://issues.apache.org/jira/browse/LUCENE-6631
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/classification
>Affects Versions: 5.2.1
>Reporter: Alessandro Benedetti
>Assignee: Tommaso Teofili
>  Labels: classification
> Fix For: 6.0
>
> Attachments: LUCENE-6631.patch, LUCENE-6631.patch
>
>
> Currently the Lucene Classification module supports the classification for an 
> input text using the Lucene index as a trained model.
> This improvement is adding to the module a set of components to provide 
> Document classification ( where the Document is a Lucene document ).
> All selected fields from the Document will have their part in the 
> classification ( including the use of the proper Analyzer per field).



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8254:


bq. The leaderProps null check should be part of the outer if statement
Can static analysis of code help here uncover such bugs? I mean tools like 
FindBugs or the one from JetBrains etc.?

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8254:
---

+1, I hit this working on SOLR-6237 as well. Same fix.

{noformat}
Index: solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
===
--- solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
(revision 1712839)
+++ solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
(working copy)
@@ -783,12 +783,12 @@
 for (Map.Entry entry : entries) {
   // first see if we have the leader
   Replica leaderProps = clusterState.getLeader(collection, entry.getKey());
-  if (liveNodes.contains(leaderProps.getNodeName()) && 
leaderProps.getState() == Replica.State.ACTIVE) {
-if (leaderProps != null) {
+  if (leaderProps != null) {
+if (liveNodes.contains(leaderProps.getNodeName()) && 
leaderProps.getState() == Replica.State.ACTIVE) {
   core = checkProps(leaderProps);
-}
-if (core != null) {
-  return core;
+  if (core != null) {
+return core;
+  }
 }
   }
{noformat}

bq. It also strikes me that this method probably belongs on CoreContainer, 
rather than as a private method in HttpSolrCall?

I don't know, we do not tend to put a lot of SolrCloud specific methods on 
CoreContainer.

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8257) DELETEREPLICA command shouldn't delete de last replica of a shard

[Yago Riveiro (JIRA)]

Yago Riveiro created SOLR-8257:
--

 Summary: DELETEREPLICA command shouldn't delete de last replica of 
a shard
 Key: SOLR-8257
 URL: https://issues.apache.org/jira/browse/SOLR-8257
 Project: Solr
  Issue Type: Bug
Reporter: Yago Riveiro
Priority: Minor


The DELETEREPLICA command shouldn't remove the last replica of a shard.

The original thread in the mailing list 
http://lucene.472066.n3.nabble.com/DELETEREPLICA-command-shouldn-t-delete-de-last-replica-of-a-shard-td4239054.html



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

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

[jira] [Commented] (LUCENE-6679) Filter's Weight.explain returns an explanation with isMatch==true even on documents that don't match

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6679:
-

Thanks Adrien, I'll give it a shot this morning and reach out as needed.

As a reminder, my patch only checks hits and the bug reports are for misses. 
I'll need to expand upon it to get better coverage for those also.

If I can't turn something around early this week I'll backup a little and at 
least get direct test for the underlying bug behind SOLR-8245 to go with it's 
fix.

> Filter's Weight.explain returns an explanation with isMatch==true even on 
> documents that don't match
> 
>
> Key: LUCENE-6679
> URL: https://issues.apache.org/jira/browse/LUCENE-6679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-6679.patch
>
>
> This was reported by Trejkaz on the java-user list: 
> http://search-lucene.com/m/l6pAi19h4Y3DclgB1=Re+What+on+earth+is+FilteredQuery+explain+doing+



--
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-6818) Implementing Divergence from Independence (DFI) Term-Weighting for Lucene/Solr

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan updated LUCENE-6818:
-
Attachment: LUCENE-6818.patch

Patch updated to current trunk (revision 1713433)

> Implementing Divergence from Independence (DFI) Term-Weighting for Lucene/Solr
> --
>
> Key: LUCENE-6818
> URL: https://issues.apache.org/jira/browse/LUCENE-6818
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/query/scoring
>Affects Versions: 5.3
>Reporter: Ahmet Arslan
>Assignee: Robert Muir
>Priority: Minor
>  Labels: similarity
> Fix For: Trunk
>
> Attachments: LUCENE-6818.patch, LUCENE-6818.patch, LUCENE-6818.patch, 
> LUCENE-6818.patch, LUCENE-6818.patch
>
>
> As explained in the 
> [write-up|http://lucidworks.com/blog/flexible-ranking-in-lucene-4], many 
> state-of-the-art ranking model implementations are added to Apache Lucene. 
> This issue aims to include DFI model, which is the non-parametric counterpart 
> of the Divergence from Randomness (DFR) framework.
> DFI is both parameter-free and non-parametric:
> * parameter-free: it does not require any parameter tuning or training.
>  * non-parametric: it does not make any assumptions about word frequency 
> distributions on document collections.
> It is highly recommended *not* to remove stopwords (very common terms: the, 
> of, and, to, a, in, for, is, on, that, etc) with this similarity.
> For more information see: [A nonparametric term weighting method for 
> information retrieval based on measuring the divergence from 
> independence|http://dx.doi.org/10.1007/s10791-013-9225-4]



--
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-6881) Cutover all BKD tree implementations to the codec

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6881:
--

These are incredible numbers [~mikemccand]; bravo!

Curious; do you imagine that BKD might one day be modified to differentiate the 
indexed cells by two types -- what I call a "leaf" and a non-leaf"?  So in this 
way, a document could have BKD cells that are leaves and non-leaves which refer 
to indexing non-point shapes in which the inner cells entirely contained by 
some indexed shape have leaf cells and the non-leaf cells are those at the edge?

> Cutover all BKD tree implementations to the codec
> -
>
> Key: LUCENE-6881
> URL: https://issues.apache.org/jira/browse/LUCENE-6881
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6881.patch, LUCENE-6881.patch
>
>
> This is phase 4 for enabling indexing dimensional values in Lucene
> ... follow-on from LUCENE-6861.
> This issue removes the 3 pre-existing specialized experimental BKD
> implementations (BKD* in sandbox module for 2D lat/lon geo, BKD3D* in
> spatial3d module for 3D x/y/z geo, and range tree in sandbox module)
> and instead switches over to having the codec index the dimensional
> values.



--
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-8256) Remove cluster setting 'legacy cloud' in 6x.

[Mark Miller (JIRA)]

Mark Miller created SOLR-8256:
-

 Summary: Remove cluster setting 'legacy cloud' in 6x.
 Key: SOLR-8256
 URL: https://issues.apache.org/jira/browse/SOLR-8256
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
 Fix For: Trunk


We don't have the old back compat concerns anymore. It's time to remove this 
mostly unknown setting and start defaulting to this behavior that starts us 
down the path of zk=truth.



--
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-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2804 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2804/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E63050CDCB505F80:61B1ED60CF702584]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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 1155 lines...]
   [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMergeSchedulerExternal 
-Dtests.method=testSubclassConcurrentMergeScheduler 
-Dtests.seed=E63050CDCB505F80 -Dtests.slow=true -Dtests.locale=fi 
-Dtests.timezone=Asia/Sakhalin -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.50s J1 | 
TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 

[jira] [Commented] (SOLR-8264) Date boosting losing to constant value in min function when date value is null

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8264:


This sounds like the correct behavior since Lucene/Solr 5.0 fixed bugs in 
several value sources.

As noted in the 5.0 upgrade instructions...

{noformat}
* Bugs fixed in several ValueSource functions may result in different behavior 
in 
  situations where some documents do not have values for fields wrapped in 
other value 
  sources.  Users who want to preserve the previous behavior may need to wrap 
fields
  in the "def()" function. Example: changing "fl=sum(fieldA,fieldB)" to 
  "fl=sum(def(fieldA,0.0),def(fieldB,0.0))".  See LUCENE-5961 for more details.
{noformat}

bq. And so the following boost works even though date_s doesn't exist for the 
particular record:

...that's because when not wrapped in a function like min or max, recip 
(wrapping ms) gives you a "fake" value based on the implicit assumption that a 
missing value should be treated a certain way ... but the "exists/missing" 
metadata is propagated up, and min/max know to choose "real" values when 
available.

Wrapping your "ms" in a "def()" call with a default of "0" should give you what 
you're looking for.

> Date boosting losing to constant value in min function when date value is null
> --
>
> Key: SOLR-8264
> URL: https://issues.apache.org/jira/browse/SOLR-8264
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Charles Draper
>Priority: Minor
>
> I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
> date boosting. This works great except when the date field is non-existent 
> and I attempt to set a maximum value. As I understand it, a non-existent date 
> field will default to the start of the epoch for functions. And so the 
> following boost works even though date_s doesn't exist for the particular 
> record:
> {code}
> recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
> 0.021798734 = 
> 1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
> {code}
> However, when I try to apply a min function, the constant value is always 
> selected whether it is greater or less than the recip calculation: 
> {code}
> min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
> 1.0 = 
> min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
> {code}
> I am currently getting around the issue by supplying a default value for the 
> field in my schema.xml.



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[ASF subversion and git services (JIRA)]

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

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

Commit 1713547 from [~joel.bernstein] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713547 ]

SOLR-8262: Comment out /stream handler from sample solrconfig.xml's for 
security reasons

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-6276) Add matchCost() api to TwoPhaseDocIdSetIterator

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6276:
--

I went over the patch and the earlier posts to get an overview of open points, 
TODO's, etc.
There are quite a lot of them, so we'll need to prioritize and/or move/defer to 
other issues.

lucene core:

ConjunctionDISI matchCost(): give the lower matchCosts a higher weight

PhraseQuery:
TERM_POSNS_SEEK_OPS_PER_DOC = 128, guess
PHRASE_TO_SPAN_TERM_POSITIONS_COST = 4, guess

TwoPhaseIterator: Return value of matchCost(): long instead of float?

RandomAccessWeight matchCost(): 10, use cost of matchingDocs.get()

ReqExclScorer matchCost(): also use cost of exclApproximation.advance()

SpanTermQuery: termPositionsCost is copy of PhraseQuery termPositionsCost

SpanOrQuery: add cost of balancing priority queues for positions?


facet module (defer to other issue):

DoubleRange matchCost(): 100, use cost of range.accept()
LongRange matchCost(): 100, use cost of range.accept()


join module (defer to other issue ?):

GlobalOrdinals(WithScore)Query matchCost(): 100, use cost of values.getOrd() 
and foundOrds.get()
GlobalOrdinals(WithScore)Query 2nd matchCost(): 100, use cost of 
values.getOrd() and foundOrds.get()


queries module (defer to other issue):

ValueSourceScorer matchCost(): 100, use cost of 
ValueSourceScorer.this.matches()ValueSourceScorer matchCost(): 100, use cost of 


spatial module (defer to other issue)::

CompositeVerifyQuery matchCost(): 100, use cost of predFuncValues.boolVal()
IntersectsRPTVerifyQuery matchCost(): 100, use cost of exactIterator.advance() 
and predFuncValues.boolVal()

test-framework module:

RandomApproximationQuery randomMatchCost: between 0 and 200: ok?

solr core:

Filter matchCost(): 10, use cost of bits.get() ?


At this issue:

Performance test based on Wikipedia to estimate guessed values.

tests for matchCost() ?

Check result of ConjunctionSpans.asTwoPhaseIterator: more similar to 
TwoPhaseConjunctionDISI ?


For other issues:

At LUCENE-6871 remove copy of SpanTermQuery.termPositionsCost(). 

SpanOrQuery is getting too big, split off DisjunctionSpans.

cost() implementation of conjunctions and disjunctions could improve: add use 
of indepence assumption.
The result of cost() is used here for weighting, so it should be good as 
possible.

> Add matchCost() api to TwoPhaseDocIdSetIterator
> ---
>
> Key: LUCENE-6276
> URL: https://issues.apache.org/jira/browse/LUCENE-6276
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6276-ExactPhraseOnly.patch, 
> LUCENE-6276-NoSpans.patch, LUCENE-6276-NoSpans2.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, LUCENE-6276.patch, 
> LUCENE-6276.patch, LUCENE-6276.patch
>
>
> We could add a method like TwoPhaseDISI.matchCost() defined as something like 
> estimate of nanoseconds or similar. 
> ConjunctionScorer could use this method to sort its 'twoPhaseIterators' array 
> so that cheaper ones are called first. Today it has no idea if one scorer is 
> a simple phrase scorer on a short field vs another that might do some geo 
> calculation or more expensive stuff.
> PhraseScorers could implement this based on index statistics (e.g. 
> totalTermFreq/maxDoc)



--
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-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7915:


I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*=celeritas=foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}


> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {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] [Comment Edited] (SOLR-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher edited comment on SOLR-7915 at 11/9/15 9:19 PM:
-

I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*=celeritas=foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}

The example really is a glorified version of outputting, through a Velocity 
template (provided in the request, and enabled by params resource loader), 
$just_a_string.class, showing that the tool $just_a_string was created and 
methods can be called on it.


was (Author: ehatcher):
I just tested this, thanks for asking [~arafalov] (on a clean branch_5x 
checkout) - 

{code}
bin/solr create -c files -d example/files
bin/post -c files ~/Documents/TestDocs
curl http://localhost:8983/solr/files/config -H 'Content-type:application/json' 
-d '{
  "add-queryresponsewriter":{
"name":"celeritas",
"class":"solr.VelocityResponseWriter",
"params.resource.loader.enabled": "true",
"tools":{
  "just_a_string":"java.lang.String"
}
  }
}'
{code}

It modifies configoverlay.json with:
{code}
{"queryResponseWriter":{"celeritas":{
  "name":"celeritas",
  "class":"solr.VelocityResponseWriter",
  "params.resource.loader.enabled":"true",
  "tools":{"just_a_string":"java.lang.String"
{code}

And that behaves as expected leveraging the new tool, 
http://localhost:8983/solr/files/select?q=*:*=celeritas=foo=$response.results.numFound:%20(and%20btw:%20just_a_string.class%20=%20$just_a_string.class)
 responds with:

{code}
328: (and btw: just_a_string.class = class java.lang.String)
{code}


> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {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] [Resolved] (SOLR-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8261.

Resolution: Fixed

I couldn't find anything else that seemed necessary to update for this change, 
other then fixing the test to use a Version.\* constant instead of a magic 
string.

> Change the wrapped per-field default in SchemaSimilarityFactory to BM25 
> (conditional on luceneMatchVersion for backcompat)
> --
>
> Key: SOLR-8261
> URL: https://issues.apache.org/jira/browse/SOLR-8261
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8261.patch
>
>
> As outlined in parent issue...
> * use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
> * use BM25Similarity as per-field default when luceneMatchVersion < 6.0



--
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-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2856 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2856/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:4 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:4 vs 3
at 
__randomizedtesting.SeedInfo.seed([C9B6AA7DEBFD66E3:41E295A745010B1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:4 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:4 vs 3
at 
__randomizedtesting.SeedInfo.seed([C9B6AA7DEBFD66E3:41E295A745010B1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
   

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b90) - Build # 14852 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14852/
Java: 64bit/jdk1.9.0-ea-b90 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=2951, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=2955, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)3) Thread[id=2953, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=2954, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)5) Thread[id=2952, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=2951, name=apacheds, state=WAITING, 
group=TGRP-SaslZkACLProviderTest]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=2955, name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at sun.misc.Unsafe.park(Native Method)
at 

[jira] [Created] (SOLR-8264) Date boosting losing to constant value in min function when date value is null

[Charles Draper (JIRA)]

Charles Draper created SOLR-8264:


 Summary: Date boosting losing to constant value in min function 
when date value is null
 Key: SOLR-8264
 URL: https://issues.apache.org/jira/browse/SOLR-8264
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.3
Reporter: Charles Draper
Priority: Minor


I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8260.
-
Resolution: Fixed

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs 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] [Updated] (SOLR-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

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

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

attaching proposed patch against trunk

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-8265) tweak election related trace (ElectionContext.java)

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8265:


Can we better leverage the MDC here for such logging as node name, replica 
name, core name etc.?

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8262:
-
Description: 
Solr has apache commons-collections in it's classpath. 

*This makes it vulnerable to this security issue 
https://issues.apache.org/jira/browse/COLLECTIONS-580. 
*The /stream handler uses Java serialization for RPC since Solr 5.1. 

These two combined leave a security hole in Solr that allows arbitrary code to 
be executed on the server.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning to explain the vulnerability.

  was:
The /stream handler uses Java serialization for RPC. This presents a security 
risk because it allows anyone with access to the Solr ip/port to send arbitrary 
serialized objects to Solr.

This should not be on by default.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning stating that this feature relies on Java 
serialization for RPC.


> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8255) MiniSolrCloudCluster doesn't use a thread-safe list for its jetties

[ASF subversion and git services (JIRA)]

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

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

Commit 1713458 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713458 ]

SOLR-8255: MiniSolrCloudCluster should use a thread-safe list to hold its child 
nodes

> MiniSolrCloudCluster doesn't use a thread-safe list for its jetties
> ---
>
> Key: SOLR-8255
> URL: https://issues.apache.org/jira/browse/SOLR-8255
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> MiniSolrCloudCluster uses a LinkedList<> to hold its jetties.  However, 
> multi-threaded startup can break this because the list isn't thread safe.  We 
> should use CopyOnWriteArrayList instead.
> See for example 
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14819/, which starts 
> up 5 nodes but then only has 4 entries in its jetty list, causing assertion 
> errors and thread leaks.



--
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-5.x-Solaris (multiarch/jdk1.7.0) - Build # 176 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/176/
Java: multiarch/jdk1.7.0 -d32 -client -XX:+UseSerialGC

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

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:51396 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:51396 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([93B6D69FB1B9C1F4:C9B7B3739F834C2D]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.printLayout(AbstractDistribZkTestBase.java:280)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribTearDown(AbstractFullDistribZkTestBase.java:1475)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)
Caused by: java.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:51396 within 3 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:208)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:173)
... 37 more


FAILED:  

[jira] [Created] (SOLR-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

Hoss Man created SOLR-8261:
--

 Summary: Change the wrapped per-field default in 
SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for 
backcompat)
 Key: SOLR-8261
 URL: https://issues.apache.org/jira/browse/SOLR-8261
 Project: Solr
  Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: Trunk


As outlined in parent issue...

* use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
* use BM25Similarity as per-field default when luceneMatchVersion < 6.0





--
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-8249) OverseerTest failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8249:
--

I've been running the following, over 5000 iterations each for patched and 
unpatched trunk, and only had one failure on unpatched - I'll include the log 
below.  Here's the cmdline I'm using:

{noformat}
(for a in {1..1000} ; do ant test -Dtestcase=OverseerTest 
-Dtests.method=testOverseerStatsReset -Dtests.dups=10 -Dtests.jvms=10 ; done) 
2>&1 | tee ../../test.output
{noformat}

Here's the failure from unpatched trunk:

{noformat}
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 
/home/sarowe/svn/lucene/dev/trunk/solr/build/solr-core/test/J3/temp/solr.cloud.OverseerTest_D0EFDBDB7BF104A-001/init-core-data-001
   [junit4]   2> 0INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 69   INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 72   INFO  (SUITE-OverseerTest-seed#[D0EFDBDB7BF104A]-worker) 
[] o.a.s.SolrTestCaseJ4 initCore end
   [junit4]   2> 83   INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testOverseerStatsReset
   [junit4]   2> 92   INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 105  INFO  (Thread-1) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 106  INFO  (Thread-1) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 194  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.ZkTestServer start zk server on port:36981
   [junit4]   2> 213  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 245  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 384  INFO  (zkCallback-1-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@121063b4 
name:ZooKeeperConnection Watcher:127.0.0.1:36981 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 385  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 386  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 414  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 415  WARN  (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] 
o.a.z.s.NIOServerCnxn caught end of stream exception
   [junit4]   2> EndOfStreamException: Unable to read additional data from 
client sessionid 0x150ed0c2d8d, likely client has closed socket
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
   [junit4]   2>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> 454  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 457  INFO  (zkCallback-2-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@4c1e7367 
name:ZooKeeperConnection Watcher:127.0.0.1:36981 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 457  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 457  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 458  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 467  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 468  INFO  
(TEST-OverseerTest.testOverseerStatsReset-seed#[D0EFDBDB7BF104A]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 470  INFO  (zkCallback-3-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@485ae506 

[jira] [Commented] (SOLR-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713498 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713498 ]

SOLR-8260: Use nio2 API in core discovery

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs 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] [Updated] (SOLR-8255) MiniSolrCloudCluster doesn't use a thread-safe list for its jetties

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8255:

Fix Version/s: 5.4

> MiniSolrCloudCluster doesn't use a thread-safe list for its jetties
> ---
>
> Key: SOLR-8255
> URL: https://issues.apache.org/jira/browse/SOLR-8255
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
>
> MiniSolrCloudCluster uses a LinkedList<> to hold its jetties.  However, 
> multi-threaded startup can break this because the list isn't thread safe.  We 
> should use CopyOnWriteArrayList instead.
> See for example 
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14819/, which starts 
> up 5 nodes but then only has 4 entries in its jetty list, causing assertion 
> errors and thread leaks.



--
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: Next release...

[Upayavira]

I would love to see a 5.4 release. All the tasks I had planned for the
admin UI are done, so, barring any unforseen and as yet unreported bugs,
it is ready to go.

How much time commitment does it typically take to make a release? I'd
consider volunteering, but may not have sufficient time to carry it all
the way.

Upayavira

On Mon, Nov 9, 2015, at 04:10 PM, Erick Erickson wrote:
> Adrien:
> 
> I can certainly wait for a while to commit CDCR to 5.4, there's no
> huge need to rush 5.4 out the door, particularly not just to
> accommodate me! After all, let's just say it's been a while that we've
> been working on this, a bit more time isn't critical
> 
> I don't want to wait a month though, so if someone is already thinking
> of branching for 5.4 anyway so I asked to I can plan around it.
> 
> Erick
> 
> On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> > Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
> > écrit :
> >>
> >> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> >> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> >> push it into 5x just before we cut the next release. So if 5.4 is
> >> imminent I'd like to know for my planning.
> >
> >
> > I think that we should release Lucene 5.4 soon indeed! Maybe we could create
> > a 5.4 branch today already so that you can commit the CDCR changes. This
> > will also help make sure that the 5.4 branch only gets bug fixes as of today
> > and then we have one week to make sure things are stable and we can start
> > the release process next week?
> 
> -
> 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] [Updated] (SOLR-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8254:

Fix Version/s: 5.4

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8253) AbstractDistribZkTestBase can fail to shutdown its ZkServer

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8253:

Fix Version/s: 5.4

> AbstractDistribZkTestBase can fail to shutdown its ZkServer
> ---
>
> Key: SOLR-8253
> URL: https://issues.apache.org/jira/browse/SOLR-8253
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
> Fix For: 5.4
>
>
> If there's an error shutting down the jetty servers, then zkServer.shutdown() 
> won't get called.  This ends up hiding actual errors from test failures with 
> thread-leak messages.



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8260:

Fix Version/s: 5.4

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs 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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8262:


 Summary: Comment out /stream handler from sample solrconfig.xml's 
for security reasons
 Key: SOLR-8262
 URL: https://issues.apache.org/jira/browse/SOLR-8262
 Project: Solr
  Issue Type: Bug
Reporter: Joel Bernstein


The /stream handler uses Java serialization for RPC. This presents a security 
risk because it allows anyone with access to the Solr ip/port to send arbitrary 
serialized objects to Solr.

This should not be on by default.

This ticket will comment out the /stream handler from the sample 
solrconfig.xml's and add a warning stating that this feature relies on Java 
serialization for RPC.



--
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-8260) Use NIO2 APIs in core discovery

[ASF subversion and git services (JIRA)]

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

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

Commit 1713490 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713490 ]

SOLR-8260: Use nio2 API in core discovery

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs 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] [Updated] (SOLR-8261) Change the wrapped per-field default in SchemaSimilarityFactory to BM25 (conditional on luceneMatchVersion for backcompat)

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-8261:
---
Attachment: SOLR-8261.patch

Quick patch extracted from my older patch in SOLR-8057 ...

* SchemaSimilarityFactory udpated to use BM25 if luceneMatchVersion >= 6
* cloned TestPerFieldSimilarity as TestPerFieldSimilarityClassic
** TestPerFieldSimilarityClassic set's older luceneMatchVersion
** TestPerFieldSimilarity updated to account for new BM25 defaults

...tests & precommit currently pass, but I want to re-review more closely in 
isolation and think about any other tests that should be added before 
committing.



> Change the wrapped per-field default in SchemaSimilarityFactory to BM25 
> (conditional on luceneMatchVersion for backcompat)
> --
>
> Key: SOLR-8261
> URL: https://issues.apache.org/jira/browse/SOLR-8261
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: Trunk
>
> Attachments: SOLR-8261.patch
>
>
> As outlined in parent issue...
> * use ClassicSimilarity as per-field default when luceneMatchVersion < 6.0
> * use BM25Similarity as per-field default when luceneMatchVersion < 6.0



--
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-8260) Use NIO2 APIs in core discovery

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8260:
-

Thanks Alan! I like this very much. We should on working to disallow 
java.io.File throughout Solr! :-)

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs 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] [Updated] (SOLR-8264) Date boosting losing to constant value in min function when date value is null

[Charles Draper (JIRA)]

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

Charles Draper updated SOLR-8264:
-
Description: 
I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)

0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))

1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.

  was:
I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
date boosting. This works great except when the date field is non-existent and 
I attempt to set a maximum value. As I understand it, a non-existent date field 
will default to the start of the epoch for functions. And so the following 
boost works even though date_s doesn't exist for the particular record:

{code}
recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
0.021798734 = 
1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
{code}

However, when I try to apply a min function, the constant value is always 
selected whether it is greater or less than the recip calculation: 

{code}
min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
1.0 = 
min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
{code}

I am currently getting around the issue by supplying a default value for the 
field in my schema.xml.


> Date boosting losing to constant value in min function when date value is null
> --
>
> Key: SOLR-8264
> URL: https://issues.apache.org/jira/browse/SOLR-8264
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.3
>Reporter: Charles Draper
>Priority: Minor
>
> I am following https://wiki.apache.org/solr/FunctionQuery#Date_Boosting for 
> date boosting. This works great except when the date field is non-existent 
> and I attempt to set a maximum value. As I understand it, a non-existent date 
> field will default to the start of the epoch for functions. And so the 
> following boost works even though date_s doesn't exist for the particular 
> record:
> {code}
> recip(ms(NOW/YEAR,date_s),3.16e-11,1,1)
> 0.021798734 = 
> 1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0)
> {code}
> However, when I try to apply a min function, the constant value is always 
> selected whether it is greater or less than the recip calculation: 
> {code}
> min(1,recip(ms(NOW/YEAR,date_s),3.16e-11,1,1))
> 1.0 = 
> min(const(1),1.0/(3.16E-11*float(ms(const(142007040),date(date_s)=null))+1.0))
> {code}
> I am currently getting around the issue by supplying a default value for the 
> field in my schema.xml.



--
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-5409) core.properties file is not removed.

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-5409.
-
   Resolution: Fixed
 Assignee: Alan Woodward
Fix Version/s: (was: 4.9)
   5.4

Fixed by SOLR-8260

> core.properties file is not removed.
> 
>
> Key: SOLR-5409
> URL: https://issues.apache.org/jira/browse/SOLR-5409
> Project: Solr
>  Issue Type: Bug
>Reporter: Doug Ericson
>Assignee: Alan Woodward
> Fix For: 5.4, Trunk
>
>
> The core.properties file is renamed to core.properties.unloaded when a core 
> is unloaded. However if the core is reloaded a new core.properties file is 
> created. This can put a core in a state where it cannot be re-loaded without 
> removing the core.properties file.
> Steps to reproduce using the web admin UI:
> # Create a core
> # Unload the core
> # Create the core again
> # Unload the core
> # Create the core again
> Expected Results:
> The core should be created after the last step.
> Observed Results:
> The last step fails because core.properties already exists and has not been 
> renamed to core.properties.unloaded since that file already exists. This puts 
> the core in a between state of being unloaded but unable to be re-loaded.



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8260:
-

bq. We should on working to disallow java.io.File throughout Solr!

That would be great, but I think it might take a while!

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

[jira] [Commented] (LUCENE-6874) WhitespaceTokenizer should tokenize on NBSP

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6874:
--

Sorry, I really disagree with you on this.  I don't think this 
WhitespaceTokenizerFactory is hard to maintain at all.  It's true that it's 
harder only because it was a trivial factory before but so what?  Most 
importantly, I think it's a better user experience -- nobody should care what 
the specific Java Tokenizer implementation class will be coming out of the 
factory -- it's a tokenizer on whitespace using whatever definition/rule of 
whitespace they configured.  That could hypothetically be implemented using one 
Java Tokenizer implementing class or multiple but that's an implementation 
detail.

bq. Why is the ICUWhitespace being added?

I'll remove that in a new patch; I wasn't sure what to do but it's redundant so 
no need for it.



> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-8263) Tlog replication could interfere with the replay of buffered updates

[Renaud Delbru (JIRA)]

Renaud Delbru created SOLR-8263:
---

 Summary: Tlog replication could interfere with the replay of 
buffered updates
 Key: SOLR-8263
 URL: https://issues.apache.org/jira/browse/SOLR-8263
 Project: Solr
  Issue Type: Sub-task
Reporter: Renaud Delbru


The current implementation of the tlog replication might interfere with the 
replay of the buffered updates. The current tlog replication works as follow:
1) Fetch the the tlog files from the master
2) reset the update log before switching the tlog directory
3) switch the tlog directory and re-initialise the update log with the new 
directory.
Currently there is no logic to keep "buffered updates" while resetting and 
reinitializing the update log.



--
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-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8265:
-

 Summary: tweak election related trace (ElectionContext.java)
 Key: SOLR-8265
 URL: https://issues.apache.org/jira/browse/SOLR-8265
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


Tweak some trace to make it easier to identify (especially in a multi-shard 
JVM) what the core or shard concerned is.




--
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-trunk-Windows (64bit/jdk1.8.0_66) - Build # 5386 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5386/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
ERROR: SolrIndexSearcher opens=51 closes=50

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50
at __randomizedtesting.SeedInfo.seed([682B6DB98C986A08]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:468)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:234)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:829)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=12948, name=searcherExecutor-6031-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=12948, name=searcherExecutor-6031-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([682B6DB98C986A08]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=12948, 

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b90) - Build # 14846 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14846/
Java: 64bit/jdk1.9.0-ea-b90 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=9962, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)2) Thread[id=9966, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)3) Thread[id=9965, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)4) Thread[id=9964, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)5) Thread[id=9963, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1136)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:853)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1083)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1143) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:632) 
at java.lang.Thread.run(Thread.java:747)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=9962, name=apacheds, state=WAITING, 
group=TGRP-SaslZkACLProviderTest]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:516)
at java.util.TimerThread.mainLoop(Timer.java:526)
at java.util.TimerThread.run(Timer.java:505)
   2) Thread[id=9966, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at sun.misc.Unsafe.park(Native Method)
  

Re: Next release...

[Adrien Grand]

Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
écrit :

> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> push it into 5x just before we cut the next release. So if 5.4 is
> imminent I'd like to know for my planning.
>

I think that we should release Lucene 5.4 soon indeed! Maybe we could
create a 5.4 branch today already so that you can commit the CDCR changes.
This will also help make sure that the 5.4 branch only gets bug fixes as of
today and then we have one week to make sure things are stable and we can
start the release process next week?

[jira] [Commented] (SOLR-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[ASF subversion and git services (JIRA)]

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

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

Commit 1713468 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713468 ]

SOLR-8254: HttpSolrCore.getCoreByCollection() can throw NPE

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-trunk-Solaris (64bit/jdk1.8.0) - Build # 176 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 10 
seconds
at 
__randomizedtesting.SeedInfo.seed([30A6C9E7769FB0A6:7E05BC346744A1B6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:836)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest(TestAuthorizationFramework.java:60)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 

[jira] [Commented] (SOLR-7219) Access filter cache from lucene query syntax

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7219:
-

Could we add this to the Changes file or somewhere else as an example then. It 
is both super cool and completely non-intuitive. 

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



--
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

Next release...

[Erick Erickson]

What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
is about ready to rock-n-roll. It's a lot of code, and I don't want to
push it into 5x just before we cut the next release. So if 5.4 is
imminent I'd like to know for my planning.

Thanks!
Erick

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

[jira] [Created] (SOLR-8259) Add getCoreContainer() method to SolrJettyRunner

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-8259:
---

 Summary: Add getCoreContainer() method to SolrJettyRunner
 Key: SOLR-8259
 URL: https://issues.apache.org/jira/browse/SOLR-8259
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward


We have this all over our tests:
{code}
CoreContainer cores = ((SolrDispatchFilter) 
jetty.getDispatchFilter().getFilter()).getCores();
{code}

We should add a sugar method explicitly for doing this.



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

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

Re: Next release...

[Erick Erickson]

Adrien:

I can certainly wait for a while to commit CDCR to 5.4, there's no
huge need to rush 5.4 out the door, particularly not just to
accommodate me! After all, let's just say it's been a while that we've
been working on this, a bit more time isn't critical

I don't want to wait a month though, so if someone is already thinking
of branching for 5.4 anyway so I asked to I can plan around it.

Erick

On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> Le lun. 9 nov. 2015 à 16:32, Erick Erickson  a
> écrit :
>>
>> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
>> is about ready to rock-n-roll. It's a lot of code, and I don't want to
>> push it into 5x just before we cut the next release. So if 5.4 is
>> imminent I'd like to know for my planning.
>
>
> I think that we should release Lucene 5.4 soon indeed! Maybe we could create
> a 5.4 branch today already so that you can commit the CDCR changes. This
> will also help make sure that the 5.4 branch only gets bug fixes as of today
> and then we have one week to make sure things are stable and we can start
> the release process next week?

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

[jira] [Resolved] (SOLR-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8254.
-
Resolution: Fixed
  Assignee: Alan Woodward

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[ASF subversion and git services (JIRA)]

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

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

Commit 1713471 from [~romseygeek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1713471 ]

SOLR-8254: HttpSolrCore.getCoreByCollection() can throw NPE

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-7915) Provide pluggable Velocity context tool facility

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7915:
-

Will this also be configurable through the other ways we do it? paramsets, 
REST, etc? Not sure if  ** would cause issues. [~noble.paul]?

> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {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-8251) MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8251:


Does the queryResultCache successfully mitigate this performance regression 
while the query is in the cache?  This might explain some long cache warming 
times I am seeing in 5.2.1 which I do not recall ever seeing in any 4.x 
versions.

> MatchAllDocsQuery is much slower in solr5.3.1 compare to solr4.7
> 
>
> Key: SOLR-8251
> URL: https://issues.apache.org/jira/browse/SOLR-8251
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 5.3
>Reporter: wei shen
>
> I am trying to upgrade our production solr instance from 4.7 to 5.3.1. 
> Unfortunately when I do load testing I find the MatchAllDocsQuery is much 
> slower in solr 5.3.1 compare to 4.7. (solr 5.3.1 is faster in load test with 
> queries other than MatchAllDocsQuery). I asked solr-user and discussed with 
> Yonik Seeley. He confirmed that he can see the problem too comparing solr 
> 5.3.1 and 4.10.
> here is the query I use:
> {code}
> q={!cache=false}*:*=+categoryIdsPath:1001=id=0=2=true
> {code}
> for me the query is consistently about 60-70% slower on solr5 than solr4.
> Yonik mentioned in his email "For me, 5.3.1
> is about 5x slower than 4.10 for this particular query."



--
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-8255) MiniSolrCloudCluster doesn't use a thread-safe list for its jetties

[ASF subversion and git services (JIRA)]

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

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

Commit 1713457 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1713457 ]

SOLR-8255: MiniSolrCloudCluster should use a thread-safe list to hold its child 
nodes

> MiniSolrCloudCluster doesn't use a thread-safe list for its jetties
> ---
>
> Key: SOLR-8255
> URL: https://issues.apache.org/jira/browse/SOLR-8255
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> MiniSolrCloudCluster uses a LinkedList<> to hold its jetties.  However, 
> multi-threaded startup can break this because the list isn't thread safe.  We 
> should use CopyOnWriteArrayList instead.
> See for example 
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14819/, which starts 
> up 5 nodes but then only has 4 entries in its jetty list, causing assertion 
> errors and thread leaks.



--
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: Next release...

[Jack Krupansky]

Bummer... the prospect of Credence Clearwater Revival having a new release
had me going there.

-- Jack Krupansky

On Mon, Nov 9, 2015 at 10:35 AM, Erick Erickson 
wrote:

> Make that CDCR
>
> On Mon, Nov 9, 2015 at 7:32 AM, Erick Erickson 
> wrote:
> > What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> > is about ready to rock-n-roll. It's a lot of code, and I don't want to
> > push it into 5x just before we cut the next release. So if 5.4 is
> > imminent I'd like to know for my planning.
> >
> > Thanks!
> > Erick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-8259) Add getCoreContainer() method to JettySolrRunner

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8259:

Summary: Add getCoreContainer() method to JettySolrRunner  (was: Add 
getCoreContainer() method to SolrJettyRunner)

> Add getCoreContainer() method to JettySolrRunner
> 
>
> Key: SOLR-8259
> URL: https://issues.apache.org/jira/browse/SOLR-8259
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8259.patch
>
>
> We have this all over our tests:
> {code}
> CoreContainer cores = ((SolrDispatchFilter) 
> jetty.getDispatchFilter().getFilter()).getCores();
> {code}
> We should add a sugar method explicitly for doing this.



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

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

[jira] [Updated] (SOLR-6406) ConcurrentUpdateSolrServer hang in blockUntilFinished.

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated SOLR-6406:
---
Fix Version/s: (was: 5.0)
   5.4

> ConcurrentUpdateSolrServer hang in blockUntilFinished.
> --
>
> Key: SOLR-6406
> URL: https://issues.apache.org/jira/browse/SOLR-6406
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 5.4, Trunk
>
> Attachments: CPU Sampling.png, SOLR-6406.patch, SOLR-6406.patch, 
> SOLR-6406.patch
>
>
> Not sure what is causing this, but SOLR-6136 may have taken us a step back 
> here. I see this problem occasionally pop up in ChaosMonkeyNothingIsSafeTest 
> now - test fails because of a thread leak, thread leak is due to a 
> ConcurrentUpdateSolrServer hang in blockUntilFinished. Only started popping 
> up recently.



--
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-trunk-Java8 - Build # 600 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/600/

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

Error Message:
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210523,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210628]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210523,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_5A1D3AAAECC2027-001/solr-instance-028/./collection1/data/index.20151109075210628]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([5A1D3AAAECC2027:F2D23DF268248FC1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:813)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1243)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 

[jira] [Commented] (SOLR-8257) DELETEREPLICA command shouldn't delete de last replica of a shard

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8257:
---

I'm sure this is a duplicate. Don't know the issue number offhand.

> DELETEREPLICA command shouldn't delete de last replica of a shard
> -
>
> Key: SOLR-8257
> URL: https://issues.apache.org/jira/browse/SOLR-8257
> Project: Solr
>  Issue Type: Bug
>Reporter: Yago Riveiro
>Priority: Minor
>
> The DELETEREPLICA command shouldn't remove the last replica of a shard.
> The original thread in the mailing list 
> http://lucene.472066.n3.nabble.com/DELETEREPLICA-command-shouldn-t-delete-de-last-replica-of-a-shard-td4239054.html



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

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

[jira] [Updated] (SOLR-8259) Add getCoreContainer() method to SolrJettyRunner

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8259:

Attachment: SOLR-8259.patch

Patch removing JettySolrRunner.getDispatchFilter() and adding 
.getCoreContainer() and .getSolrDispatchFilter() methods.  In 5.x I'll just 
deprecate .getDispatchFilter().

> Add getCoreContainer() method to SolrJettyRunner
> 
>
> Key: SOLR-8259
> URL: https://issues.apache.org/jira/browse/SOLR-8259
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8259.patch
>
>
> We have this all over our tests:
> {code}
> CoreContainer cores = ((SolrDispatchFilter) 
> jetty.getDispatchFilter().getFilter()).getCores();
> {code}
> We should add a sugar method explicitly for doing this.



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

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

[jira] [Commented] (SOLR-8254) HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8254:
-

bq. I don't know, we do not tend to put a lot of SolrCloud specific methods on 
CoreContainer.

Fair enough, I'll leave it where it is.

bq. Can static analysis of code help here uncover such bugs?

Almost certainly - IntelliJ showed me the error immediately when I looked at 
the code.  I have a feeling that this has come up before, but getting the whole 
codebase to pass will be a pretty big job.

> HttpSolrCall.getCoreByCollection can throw NPE if there are no leaders up
> -
>
> Key: SOLR-8254
> URL: https://issues.apache.org/jira/browse/SOLR-8254
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>
> See http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5254/



--
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-7219) Access filter cache from lucene query syntax

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7219:


bq. Does this allow to OR the filter queries efficiently?

Yep,
fq=filter(foo) filter(bar) filter(baz)

Although we could prob do it more efficiently in the future.  The current 
solution will use lucene's disjunction scorer, but we can get more efficient 
than that if we know we are dealing with DocSets.

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



--
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-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-8260:
---

 Summary: Use NIO2 APIs in core discovery
 Key: SOLR-8260
 URL: https://issues.apache.org/jira/browse/SOLR-8260
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward


CorePropertiesLocator currently does all its file system interaction using 
java.io.File and friends, which have all sorts of drawbacks with regard to 
error handling and reporting.  We've been on java 7 for a while now, so we 
should use the nio2 Path APIs 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] [Updated] (SOLR-8260) Use NIO2 APIs in core discovery

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8260:

Attachment: SOLR-8260.patch

Patch.  Tests pass, running precommit now.

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

[jira] [Commented] (SOLR-7915) Provide pluggable Velocity context tool facility

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7915:


paramsets are for search handlers, so doesn't relate to this.  But definitely 
the REST API should be able to handle this.  I've not tested that, but it is 
legitimate response writer configuration capabilities being used here.  

> Provide pluggable Velocity context tool facility
> 
>
> Key: SOLR-7915
> URL: https://issues.apache.org/jira/browse/SOLR-7915
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Velocity
>Affects Versions: 5.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-7915.patch
>
>
> Currently the "tools" placed in the VelocityResponseWriter's context are 
> hard-coded.  It can be very handy to be able to plug in 3rd party or custom 
> tools (just any ol' Java object a "tool" can be).
> Here's a list of the currently hard-coded tools: 
> https://github.com/apache/lucene-solr/blob/trunk/solr/contrib/velocity/src/java/org/apache/solr/response/VelocityResponseWriter.java#L189-L199
> 
> The implementation committed allows custom tools to be registered as part of 
> the VelocityResponseWriter definition in solrconfig.xml like this:
> {code}
>  class="solr.VelocityResponseWriter">
>   
> com.example.solr.velocity.MyTool
> 
>   
> 
> {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] [Resolved] (SOLR-8255) MiniSolrCloudCluster doesn't use a thread-safe list for its jetties

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8255.
-
Resolution: Fixed

> MiniSolrCloudCluster doesn't use a thread-safe list for its jetties
> ---
>
> Key: SOLR-8255
> URL: https://issues.apache.org/jira/browse/SOLR-8255
> Project: Solr
>  Issue Type: Bug
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>
> MiniSolrCloudCluster uses a LinkedList<> to hold its jetties.  However, 
> multi-threaded startup can break this because the list isn't thread safe.  We 
> should use CopyOnWriteArrayList instead.
> See for example 
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14819/, which starts 
> up 5 nodes but then only has 4 entries in its jetty list, causing assertion 
> errors and thread leaks.



--
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-7219) Access filter cache from lucene query syntax

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-7219:
-

Does this allow to OR the filter queries efficiently? That was always the 
limitation of **fq** that you could only effectively AND them.

If it does, we should document that rather prominently to make people happy.

> Access filter cache from lucene query syntax
> 
>
> Key: SOLR-7219
> URL: https://issues.apache.org/jira/browse/SOLR-7219
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 5.4
>
> Attachments: SOLR-7219.patch
>
>
> A filter query retrieves a set of documents matching a query from the filter 
> cache. Since scores are not cached, all documents that match the filter 
> produce the same score. Cached filters will be extremely fast when they are 
> used again in another query.
> Filter Query Example:
> {code}
> description:HDTV OR filter(+promotion:tv +promotion_date:[NOW/DAY-7DAYS TO 
> NOW/DAY+1DAY])
> {code}
> The power of the filter() syntax is that it may be used anywhere within a 
> lucene/solr query syntax. Normal fq support is limited to top-level 
> conjunctions. 



--
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-8257) DELETEREPLICA command shouldn't delete de last replica of a shard

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8257:
---

I was thinking of SOLR-5209. Perhaps this is a little different actually.


> DELETEREPLICA command shouldn't delete de last replica of a shard
> -
>
> Key: SOLR-8257
> URL: https://issues.apache.org/jira/browse/SOLR-8257
> Project: Solr
>  Issue Type: Bug
>Reporter: Yago Riveiro
>Priority: Minor
>
> The DELETEREPLICA command shouldn't remove the last replica of a shard.
> The original thread in the mailing list 
> http://lucene.472066.n3.nabble.com/DELETEREPLICA-command-shouldn-t-delete-de-last-replica-of-a-shard-td4239054.html



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

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

Re: Next release...

[Erick Erickson]

Make that CDCR

On Mon, Nov 9, 2015 at 7:32 AM, Erick Erickson  wrote:
> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> push it into 5x just before we cut the next release. So if 5.4 is
> imminent I'd like to know for my planning.
>
> Thanks!
> Erick

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

[jira] [Commented] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8262:
-

+1 please disable this like the remote input streaming apis (stream.body, 
stream.url & Co.)

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8265) tweak election related trace (ElectionContext.java)

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8265:
---

Yeah, I think we are trying to take these out of logging. We already have this 
in MDC and it just adds redundant info.

Some logging might be missing MDC injection or something, but in that case, 
that is probably what should be fixed.

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8262 at 11/9/15 8:09 PM:
---

The next step is to remove Java serialization from the Streaming API entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.


was (Author: joel.bernstein):
The next step in this is to remove Java serialization from the Streaming API 
entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-trunk-Java8 - Build # 601 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/601/

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testOverseerStatsReset

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

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([79AB6D6C1EBA782:ACCE51EA5431048C]: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.OverseerTest.testOverseerStatsReset(OverseerTest.java:741)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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 9967 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8262:
--

The next step in this is to remove Java serialization from the Streaming API 
entirely.

The Streaming API will use only the Streaming Expression language for RPC going 
forward.

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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-8260) Use NIO2 APIs in core discovery

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8260:


bq. We should on working to disallow java.io.File throughout Solr!

I thought this had already been added to the forbidden apis config in the build 
system, but it seems that was only for Lucene.  I'm guessing that if we move it 
from the lucene config to the base config, Solr will pick it up as well.

> Use NIO2 APIs in core discovery
> ---
>
> Key: SOLR-8260
> URL: https://issues.apache.org/jira/browse/SOLR-8260
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.4
>
> Attachments: SOLR-8260.patch
>
>
> CorePropertiesLocator currently does all its file system interaction using 
> java.io.File and friends, which have all sorts of drawbacks with regard to 
> error handling and reporting.  We've been on java 7 for a while now, so we 
> should use the nio2 Path APIs instead.



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

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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_66) - Build # 5256 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5256/
Java: 64bit/jdk1.8.0_66 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([D810BFCBBBAAA9A7:504480111556C45F]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:272)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:117)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_66) - Build # 14558 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14558/
Java: 64bit/jdk1.8.0_66 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([639D03C49CDD782B:EBC93C1E322115D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([639D03C49CDD782B:EBC93C1E322115D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_66) - Build # 14848 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14848/
Java: 32bit/jdk1.8.0_66 -client -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAliasTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([2EC0722843D9B008:A6944DF2ED25DDF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:961)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
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)


FAILED:  org.apache.solr.morphlines.solr.SolrMorphlineZkAvroTest.test

Error Message:
Shards in the state does not match what we set:0 vs 3

Stack Trace:
java.lang.AssertionError: Shards in the state does not match what we set:0 vs 3
at 
__randomizedtesting.SeedInfo.seed([2EC0722843D9B008:A6944DF2ED25DDF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:397)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:310)
at 

[jira] [Created] (SOLR-8266) Remove Java Serialization from the Streaming API

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8266:


 Summary: Remove Java Serialization from the Streaming API
 Key: SOLR-8266
 URL: https://issues.apache.org/jira/browse/SOLR-8266
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein


This is being done mainly for security reasons but it's also architecturally 
the right thing to do.

Going forward only Streaming Expressions will be used to serialize Streaming 
API Objects. 



--
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-6679) Filter's Weight.explain returns an explanation with isMatch==true even on documents that don't match

[Terry Smith (JIRA)]

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

Terry Smith updated LUCENE-6679:

Attachment: LUCENE-6679.patch

Here is an updated patch against trunk that adds hit and miss explain checks to 
AssertingLeafCollector and hooks it up with the surrounding classes.

I've also introduced a new annotation called SuppressExplainChecks that I've 
applied to the following tests that would fail without.

  * TestSortRandom
  * TestLazyProxSkipping
  * TestDrillSideways
  * TestRangeFacetCounts
  * TestJoinUtil
  * TestFieldCacheSortRandom
  * TestCustomScoreQuery
  * TestCustomScoreQueryExplanations
  * TestFunctionQueryExplanations
  * TestForTooMuchCloning
  * TestTermAutomationQuery

Once you are happy with this patch, I'd like to get it on trunk so the jenkins 
servers can shake out any more failures and we can create tickets for any 
uncovered bugs.



> Filter's Weight.explain returns an explanation with isMatch==true even on 
> documents that don't match
> 
>
> Key: LUCENE-6679
> URL: https://issues.apache.org/jira/browse/LUCENE-6679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-6679.patch, LUCENE-6679.patch
>
>
> This was reported by Trejkaz on the java-user list: 
> http://search-lucene.com/m/l6pAi19h4Y3DclgB1=Re+What+on+earth+is+FilteredQuery+explain+doing+



--
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-8265) tweak election related trace (ElectionContext.java)

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8265:
---

Good points, hadn't considered {{MDCLoggingContext}} here, will check if that 
covers things.

> tweak election related trace (ElectionContext.java)
> ---
>
> Key: SOLR-8265
> URL: https://issues.apache.org/jira/browse/SOLR-8265
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8265.patch
>
>
> Tweak some trace to make it easier to identify (especially in a multi-shard 
> JVM) what the core or shard concerned is.



--
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-8262) Comment out /stream handler from sample solrconfig.xml's for security reasons

[ASF subversion and git services (JIRA)]

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

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

Commit 1713530 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1713530 ]

SOLR-8262: Comment out /stream handler from sample solrconfig.xml's for 
security reasons

> Comment out /stream handler from sample solrconfig.xml's for security reasons
> -
>
> Key: SOLR-8262
> URL: https://issues.apache.org/jira/browse/SOLR-8262
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> Solr has apache commons-collections in it's classpath. 
> *This makes it vulnerable to this security issue 
> https://issues.apache.org/jira/browse/COLLECTIONS-580. 
> *The /stream handler uses Java serialization for RPC since Solr 5.1. 
> These two combined leave a security hole in Solr that allows arbitrary code 
> to be executed on the server.
> This ticket will comment out the /stream handler from the sample 
> solrconfig.xml's and add a warning to explain the vulnerability.



--
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: Next release...

[Susheel Kumar]

CDCR will help many of the folks who are currently trying other
alternatives. Would love to see coming this out sooner and providing
feedback.

On Mon, Nov 9, 2015 at 1:16 PM, Upayavira  wrote:

> I would love to see a 5.4 release. All the tasks I had planned for the
> admin UI are done, so, barring any unforseen and as yet unreported bugs,
> it is ready to go.
>
> How much time commitment does it typically take to make a release? I'd
> consider volunteering, but may not have sufficient time to carry it all
> the way.
>
> Upayavira
>
> On Mon, Nov 9, 2015, at 04:10 PM, Erick Erickson wrote:
> > Adrien:
> >
> > I can certainly wait for a while to commit CDCR to 5.4, there's no
> > huge need to rush 5.4 out the door, particularly not just to
> > accommodate me! After all, let's just say it's been a while that we've
> > been working on this, a bit more time isn't critical
> >
> > I don't want to wait a month though, so if someone is already thinking
> > of branching for 5.4 anyway so I asked to I can plan around it.
> >
> > Erick
> >
> > On Mon, Nov 9, 2015 at 8:00 AM, Adrien Grand  wrote:
> > > Le lun. 9 nov. 2015 à 16:32, Erick Erickson 
> a
> > > écrit :
> > >>
> > >> What is the thinking on cutting 5.4? It looks like the CCR (SOLR-6273)
> > >> is about ready to rock-n-roll. It's a lot of code, and I don't want to
> > >> push it into 5x just before we cut the next release. So if 5.4 is
> > >> imminent I'd like to know for my planning.
> > >
> > >
> > > I think that we should release Lucene 5.4 soon indeed! Maybe we could
> create
> > > a 5.4 branch today already so that you can commit the CDCR changes.
> This
> > > will also help make sure that the 5.4 branch only gets bug fixes as of
> today
> > > and then we have one week to make sure things are stable and we can
> start
> > > the release process next week?
> >
> > -
> > 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-6406) ConcurrentUpdateSolrServer hang in blockUntilFinished.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-6406:
---

Strange. I got over 300 runs without an out of sync with it originally. I have 
not tried on recent trunk or recent changes though.

> ConcurrentUpdateSolrServer hang in blockUntilFinished.
> --
>
> Key: SOLR-6406
> URL: https://issues.apache.org/jira/browse/SOLR-6406
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 5.4, Trunk
>
> Attachments: CPU Sampling.png, SOLR-6406.patch, SOLR-6406.patch, 
> SOLR-6406.patch
>
>
> Not sure what is causing this, but SOLR-6136 may have taken us a step back 
> here. I see this problem occasionally pop up in ChaosMonkeyNothingIsSafeTest 
> now - test fails because of a thread leak, thread leak is due to a 
> ConcurrentUpdateSolrServer hang in blockUntilFinished. Only started popping 
> up recently.



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

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

[jira] [Assigned] (SOLR-8263) Tlog replication could interfere with the replay of buffered updates

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-8263:


Assignee: Erick Erickson

> Tlog replication could interfere with the replay of buffered updates
> 
>
> Key: SOLR-8263
> URL: https://issues.apache.org/jira/browse/SOLR-8263
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Renaud Delbru
>Assignee: Erick Erickson
>
> The current implementation of the tlog replication might interfere with the 
> replay of the buffered updates. The current tlog replication works as follow:
> 1) Fetch the the tlog files from the master
> 2) reset the update log before switching the tlog directory
> 3) switch the tlog directory and re-initialise the update log with the new 
> directory.
> Currently there is no logic to keep "buffered updates" while resetting and 
> reinitializing the update log.



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

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

[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b90) - Build # 14563 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14563/
Java: 32bit/jdk1.9.0-ea-b90 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
There should be 3 documents because there should be two id=1 docs due to 
overwrite=false expected:<3> but was:<1>

Stack Trace:
java.lang.AssertionError: There should be 3 documents because there should be 
two id=1 docs due to overwrite=false expected:<3> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([1319076A73EAACDD:9B4D38B0DD16C125]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:174)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:120)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1660)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:866)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:902)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:916)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:777)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:822)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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:54)
at 

[jira] [Updated] (SOLR-8146) Preferred SolrCloud node for SolrJ query/read

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8146:
-
Description: 
This is a simple proposal to allow more flexibility about which node SolrJ 
queries first.
This is mainly to avoid unnecessary traffic in the network.

For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
separate racks: rack1 and rack2.

On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs 
querying solr using SolrJ.

All solr nodes are identical and have the same number of collections.

What we would like to achieve is:
- clients on rack1 will by preference query only SolrCloud nodes on rack1, and 
- clients on rack2 will by preference query only SolrCloud nodes on rack2.
- Cross-rack read will happen if and only if one of the racks has no available 
Solr node to serve a request.

In other words, we want read operations to be local to a rack whenever possible.

Note that write/update/delete/admin operations should not be affected.

Initially, I thought it may be good to have Solr nodes tagged with rackID 
(snitch?) for matching the hosts.

Note that this feature may have many usages such as SOLR-5501

Note that in our use case, we have a cross DC deployment. So, replace 
rack1/rack2 by DC1/DC2

Any comment would be very appreciated.

Thanks.


  was:

This is a simple proposal to allow more flexibility about which node SolrJ 
queries first.
This is mainly to avoid unnecessary traffic in the network.

For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
separate racks: rack1 and rack2.

On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs 
querying solr using SolrJ.

All solr nodes are identical and have the same number of collections.

What we would like to achieve is:
- clients on rack1 will by preference query only SolrCloud nodes on rack1, and 
- clients on rack2 will by preference query only SolrCloud nodes on rack2.
- Cross-rack read will happen if and only if one of the racks has no available 
Solr node to serve a request.

In other words, we want read operations to be local to a rack whenever possible.

Note that write operations should not be affected.

Attached is a patch which is a work in progress.
Initially, I thought it may be good to have Solr nodes tagged with rackID 
(snitch?) for matching the hosts.

Note that this feature may have many usages such as SOLR-5501
 
Any comment would be very appreciated.

Thanks.



> Preferred SolrCloud node for SolrJ query/read
> -
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> This is a simple proposal to allow more flexibility about which node SolrJ 
> queries first.
> This is mainly to avoid unnecessary traffic in the network.
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
> separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write/update/delete/admin operations should not be affected.
> Initially, I thought it may be good to have Solr nodes tagged with rackID 
> (snitch?) for matching the hosts.
> Note that this feature may have many usages such as SOLR-5501
> Note that in our use case, we have a cross DC deployment. So, replace 
> rack1/rack2 by DC1/DC2
> Any comment would be very appreciated.
> Thanks.



--
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-6874) WhitespaceTokenizer should tokenize on NBSP

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6874:
---

I would be fine to remove WhitespaceTokenizer in Lucene trunk. In that case I 
would also like to move the abstract CharTokenizer class out of 
oal.analysis.util to oal.analysis.core. This is not a big deal, but the util 
package is not fine for a first class citizen.

I also have another idea about this issue; I would prefer to not have the large 
java code with jflex involved. Wouldn't it be possible to save the isWhitespace 
data of Unicode in a compressible Lucene bitset and save it to disk as resource 
file? We could then load the bitset (like deleted documents) from a resource 
file and wrap a simple {{CharTokenizer.fromSeparatorCharPredicate(c -> 
compressedBitset.get(c))}} on top? The bitset could be generated from Unicode 
data on "ant regenerate".

> WhitespaceTokenizer should tokenize on NBSP
> ---
>
> Key: LUCENE-6874
> URL: https://issues.apache.org/jira/browse/LUCENE-6874
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: David Smiley
>Priority: Minor
> Attachments: LUCENE-6874-jflex.patch, LUCENE-6874.patch, 
> LUCENE_6874_jflex.patch
>
>
> WhitespaceTokenizer uses [Character.isWhitespace 
> |http://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#isWhitespace-int-]
>  to decide what is whitespace.  Here's a pertinent excerpt:
> bq. It is a Unicode space character (SPACE_SEPARATOR, LINE_SEPARATOR, or 
> PARAGRAPH_SEPARATOR) but is not also a non-breaking space ('\u00A0', 
> '\u2007', '\u202F')
> Perhaps Character.isWhitespace should have been called 
> isLineBreakableWhitespace?
> I think WhitespaceTokenizer should tokenize on this.  I am aware it's easy to 
> work around but why leave this trap in by default?



--
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-6304) Transforming and Indexing custom JSON data

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6304:
--

yes it could work w/ dynamic fields if your field names match the dynamic field 
pattern. 

eg:

{code}
f=first_s:/firstName
{code}

> Transforming and Indexing custom JSON data
> --
>
> Key: SOLR-6304
> URL: https://issues.apache.org/jira/browse/SOLR-6304
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 4.10, Trunk
>
> Attachments: SOLR-6304.patch, SOLR-6304.patch
>
>
> example
> {noformat}
> curl 
> localhost:8983/update/json/docs?split=/batters/batter=recipeId:/id=recipeType:/type=id:/batters/batter/id=type:/batters/batter/type
>  -d '
> {
>   "id": "0001",
>   "type": "donut",
>   "name": "Cake",
>   "ppu": 0.55,
>   "batters": {
>   "batter":
>   [
>   { "id": "1001", "type": 
> "Regular" },
>   { "id": "1002", "type": 
> "Chocolate" },
>   { "id": "1003", "type": 
> "Blueberry" },
>   { "id": "1004", "type": 
> "Devil's Food" }
>   ]
>   }
> }'
> {noformat}
> should produce the following output docs
> {noformat}
> { "recipeId":"001", "recipeType":"donut", "id":"1001", "type":"Regular" }
> { "recipeId":"001", "recipeType":"donut", "id":"1002", "type":"Chocolate" }
> { "recipeId":"001", "recipeType":"donut", "id":"1003", "type":"Blueberry" }
> { "recipeId":"001", "recipeType":"donut", "id":"1004", "type":"Devil's food" }
> {noformat}
> the split param is the element in the tree where it should be split into 
> multiple docs. The 'f' are field name mappings



--
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-8146) Preferred SolrCloud node for SolrJ query/read

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou updated SOLR-8146:
-
Attachment: SOLR-8146.patch

Updated with more tests.
Any comment or feedback would be most appreciated

> Preferred SolrCloud node for SolrJ query/read
> -
>
> Key: SOLR-8146
> URL: https://issues.apache.org/jira/browse/SOLR-8146
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Affects Versions: 5.3
>Reporter: Arcadius Ahouansou
> Attachments: SOLR-8146.patch, SOLR-8146.patch, SOLR-8146.patch
>
>
> This is a simple proposal to allow more flexibility about which node SolrJ 
> queries first.
> This is mainly to avoid unnecessary traffic in the network.
> For simplicity, let's say that we have  a SolrSloud cluster deployed on 2 
> separate racks: rack1 and rack2.
> On each rack, we have a set of SolrCloud VMs as well as a couple of client 
> VMs querying solr using SolrJ.
> All solr nodes are identical and have the same number of collections.
> What we would like to achieve is:
> - clients on rack1 will by preference query only SolrCloud nodes on rack1, 
> and 
> - clients on rack2 will by preference query only SolrCloud nodes on rack2.
> - Cross-rack read will happen if and only if one of the racks has no 
> available Solr node to serve a request.
> In other words, we want read operations to be local to a rack whenever 
> possible.
> Note that write operations should not be affected.
> Attached is a patch which is a work in progress.
> Initially, I thought it may be good to have Solr nodes tagged with rackID 
> (snitch?) for matching the hosts.
> Note that this feature may have many usages such as SOLR-5501
>  
> Any comment would be very appreciated.
> Thanks.



--
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-6881) Cutover all BKD tree implementations to the codec

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6881:


I re-ran the "lat/lon points in rects around London, UK" perf test from 
luceneutil ({{IndexOSM*.java}} and {{SearchOSM*.java}} sources).

This test indexes 60.8 M lat/lon points derived from Open Street Maps data and 
then runs varying regularly spaced rectangles (225 queries in all) around 
London, UK.

I used SMS and LogDocsMP to get to a 5/5/5 segment structure for all three 
tests, and so only a single thread is used throughout for fair comparison of 
indexing times:

*Spatial module, using RecursivePrefixTreeStrategy with PackedQuadPrefixTree at 
25 levels:*
  - 1,464 sec to index
  - 7.8 GB index on disk
  - 239 MB in-heap (ramBytesUsed summed across all segments)
  - 3.98 sec to run 225 searches (best of 100 iters)

*GeoPointField (sandbox)*
  - 497 sec to index
  - 3.2 GB index on disk
  - 86 MB heap (ramBytesUsed summed across all segments)
  - 4.48 sec to run 225 searches (best of 100 iters)

*Dimensional values (this patch) using default codec's dimensional format*
  - 744 sec to index
  - 704 MB index on disk
  - 2.3 MB heap (ramBytesUsed summed across all segments)
  - 2.85 sec to run 225 searches (best of 100 iters)

The spatial module is purely postings, geo point field is postings + doc 
values, and dimensional values is the new BKD tree.

Net/net indexing time for dimensional values approach is in between geo point 
field and spatial, but the resulting index as well as heap required at search 
time is much smaller, and the searching is faster.

The search time for dimensional values is a bit slower than the specialized (to 
lat/lon) doc-values based BKD from LUCENE-6477 / LUCENE-6645 (2.32 sec to run 
225 searches) but I think we can optimize things later.

I haven't tested the 1D case, and I suspect there are important specializations 
we can make there, but I'll save that for a follow-on.


> Cutover all BKD tree implementations to the codec
> -
>
> Key: LUCENE-6881
> URL: https://issues.apache.org/jira/browse/LUCENE-6881
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk
>
> Attachments: LUCENE-6881.patch, LUCENE-6881.patch
>
>
> This is phase 4 for enabling indexing dimensional values in Lucene
> ... follow-on from LUCENE-6861.
> This issue removes the 3 pre-existing specialized experimental BKD
> implementations (BKD* in sandbox module for 2D lat/lon geo, BKD3D* in
> spatial3d module for 3D x/y/z geo, and range tree in sandbox module)
> and instead switches over to having the codec index the dimensional
> values.



--
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