date:20140722


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

Shalin Shekhar Mangar updated SOLR-6231:


Attachment: SOLR-6231.patch

The good thing about this failure is that in all instances I've seen, we always 
have an overseer. It's just that the overseer is not one of the designates. I 
looked at the logs of a few failures and it seemed like the re-prioritization 
was in process and we timed out early.

Here's a patch to harden the process. We have a max timeout of 300 seconds and 
a smaller 60 second timeout for finding designates which is adjusted further 
and further ahead as we find new overseers being elected. The idea is that if 
within 60 seconds, the overseer hasn't changed, then we're likely not going to 
find a new overseer and we should stop. But if the overseer changed then 
re-prioritization is in progress and we should wait more.

 RollingRestartTest failures on jenkins
 --

 Key: SOLR-6231
 URL: https://issues.apache.org/jira/browse/SOLR-6231
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10

 Attachments: SOLR-6231.patch


 A somewhat rare fail on jenkins. An overseer was available to service 
 requests but even after waiting for 60 seconds, none of the designates were 
 the overseer.
 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
 Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.RollingRestartTest.testDistribSearch
 Error Message:
 No overseer designate as leader found after restart #3: 127.0.0.1:60996_
 Stack Trace:
 java.lang.AssertionError: No overseer designate as leader found after restart 
 #3: 127.0.0.1:60996_
 at 
 __randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
 at 
 org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6265) core errors on startup are not showing up in the log until attempts to use the core?


[ 
https://issues.apache.org/jira/browse/SOLR-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069898#comment-14069898
 ] 

Shalin Shekhar Mangar commented on SOLR-6265:
-

This may be related to SOLR-6232

 core errors on startup are not showing up in the log until attempts to use 
 the core?
 

 Key: SOLR-6265
 URL: https://issues.apache.org/jira/browse/SOLR-6265
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Blocker
 Fix For: 4.10


 As of r1612418, both the 4x and trunk svn trees seem to have a bug where any 
 core specific init errors that occur on startup don't show up in the log 
 until/unless someone attempts to access that core via HTTP.
 i'm not sure when exactly this bug was introduced, but it definitely isn't in 
 4.9.
 The impact on users, particularly new users, is that starting up solr with a 
 mistake in your configs appears to work fine until you actually try to use 
 solr and then you get ugly errors.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6231) RollingRestartTest failures on jenkins

2014-07-22 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069916#comment-14069916
 ] 

Noble Paul commented on SOLR-6231:
--

Yeah, 
the timeout has to take into account if the leader has changed in between . 


 RollingRestartTest failures on jenkins
 --

 Key: SOLR-6231
 URL: https://issues.apache.org/jira/browse/SOLR-6231
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10

 Attachments: SOLR-6231.patch


 A somewhat rare fail on jenkins. An overseer was available to service 
 requests but even after waiting for 60 seconds, none of the designates were 
 the overseer.
 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
 Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.RollingRestartTest.testDistribSearch
 Error Message:
 No overseer designate as leader found after restart #3: 127.0.0.1:60996_
 Stack Trace:
 java.lang.AssertionError: No overseer designate as leader found after restart 
 #3: 127.0.0.1:60996_
 at 
 __randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
 at 
 org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6231) RollingRestartTest failures on jenkins


[ 
https://issues.apache.org/jira/browse/SOLR-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069966#comment-14069966
 ] 

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

Commit 1612499 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1612499 ]

SOLR-6231: Harden the RollingRestartTest

 RollingRestartTest failures on jenkins
 --

 Key: SOLR-6231
 URL: https://issues.apache.org/jira/browse/SOLR-6231
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10

 Attachments: SOLR-6231.patch


 A somewhat rare fail on jenkins. An overseer was available to service 
 requests but even after waiting for 60 seconds, none of the designates were 
 the overseer.
 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
 Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.RollingRestartTest.testDistribSearch
 Error Message:
 No overseer designate as leader found after restart #3: 127.0.0.1:60996_
 Stack Trace:
 java.lang.AssertionError: No overseer designate as leader found after restart 
 #3: 127.0.0.1:60996_
 at 
 __randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
 at 
 org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6231) RollingRestartTest failures on jenkins

2014-07-22 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069968#comment-14069968
 ] 

Shalin Shekhar Mangar commented on SOLR-6231:
-

Thanks for reviewing, Noble!

 RollingRestartTest failures on jenkins
 --

 Key: SOLR-6231
 URL: https://issues.apache.org/jira/browse/SOLR-6231
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10

 Attachments: SOLR-6231.patch


 A somewhat rare fail on jenkins. An overseer was available to service 
 requests but even after waiting for 60 seconds, none of the designates were 
 the overseer.
 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
 Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.RollingRestartTest.testDistribSearch
 Error Message:
 No overseer designate as leader found after restart #3: 127.0.0.1:60996_
 Stack Trace:
 java.lang.AssertionError: No overseer designate as leader found after restart 
 #3: 127.0.0.1:60996_
 at 
 __randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
 at 
 org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6231) RollingRestartTest failures on jenkins


[ 
https://issues.apache.org/jira/browse/SOLR-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069967#comment-14069967
 ] 

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

Commit 1612500 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612500 ]

SOLR-6231: Harden the RollingRestartTest

 RollingRestartTest failures on jenkins
 --

 Key: SOLR-6231
 URL: https://issues.apache.org/jira/browse/SOLR-6231
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10

 Attachments: SOLR-6231.patch


 A somewhat rare fail on jenkins. An overseer was available to service 
 requests but even after waiting for 60 seconds, none of the designates were 
 the overseer.
 {code}
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/4081/
 Java: 32bit/jdk1.8.0_20-ea-b21 -client -XX:+UseSerialGC
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.RollingRestartTest.testDistribSearch
 Error Message:
 No overseer designate as leader found after restart #3: 127.0.0.1:60996_
 Stack Trace:
 java.lang.AssertionError: No overseer designate as leader found after restart 
 #3: 127.0.0.1:60996_
 at 
 __randomizedtesting.SeedInfo.seed([5263BF570390CF79:D385314F74CFAF45]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:100)
 at 
 org.apache.solr.cloud.RollingRestartTest.doTest(RollingRestartTest.java:61)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6265) core errors on startup are not showing up in the log until attempts to use the core?

2014-07-22 Thread Alan Woodward (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069975#comment-14069975
 ] 

Alan Woodward commented on SOLR-6265:
-

Ah crap, I missed out a log line when moving stuff around.  Patch to fix:
{code}
diff --git a/solr/core/src/java/org/apache/solr/core/CoreContainer.java 
b/solr/core/src/java/org/apache/solr/core/CoreContainer.java
index f82a713..93aeff4 100644
--- a/solr/core/src/java/org/apache/solr/core/CoreContainer.java
+++ b/solr/core/src/java/org/apache/solr/core/CoreContainer.java
@@ -499,6 +499,7 @@ public class CoreContainer {
 }
 catch (Exception e) {
   coreInitFailures.put(dcore.getName(), new CoreLoadFailure(dcore, e));
+  log.error(Error creating core [{}]: {}, dcore.getName(), e);
   throw new SolrException(ErrorCode.SERVER_ERROR, Unable to create core 
[ + dcore.getName() + ], e);
 }
{code}

I'm not near a machine that has commit access for the next couple of weeks, so 
feel free to commit this Hoss.

 core errors on startup are not showing up in the log until attempts to use 
 the core?
 

 Key: SOLR-6265
 URL: https://issues.apache.org/jira/browse/SOLR-6265
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Blocker
 Fix For: 4.10


 As of r1612418, both the 4x and trunk svn trees seem to have a bug where any 
 core specific init errors that occur on startup don't show up in the log 
 until/unless someone attempts to access that core via HTTP.
 i'm not sure when exactly this bug was introduced, but it definitely isn't in 
 4.9.
 The impact on users, particularly new users, is that starting up solr with a 
 mistake in your configs appears to work fine until you actually try to use 
 solr and then you get ugly errors.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-6262) Make the name attribute optional for components in solrconfig.xml


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

Noble Paul updated SOLR-6262:
-

Attachment: SOLR-6262.patch

Changes w/o testcase

Well known RequestHandlers and Query response writers are tagged with a name.

We will allow their names to be overridden by keeping a 'name' attribute in the 
tags. In the future we must disallow them to be named anything else. 

 Make the name attribute optional for components in solrconfig.xml
 ---

 Key: SOLR-6262
 URL: https://issues.apache.org/jira/browse/SOLR-6262
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
 Attachments: SOLR-6262.patch


 It is not a good idea to let people decide the names of our standard 
 components such as update, replication, /get etc. These names can be hard 
 coded in the Java file itself. and let us remove the names from 
 solrconfig.xml. 
 However it should be possible to override the name by specifying the 'name' 
 attribute



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively

2014-07-22 Thread Alan Woodward (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070182#comment-14070182
 ] 

Alan Woodward commented on SOLR-5473:
-

Sure, but there's no abstraction here.  Overseer has a bunch of methods that 
say if the collection state version is  1, do this, otherwise do that, when 
really it shouldn't have to know or care about that.  It should get a 
Collection object from the state reader and tell it to update itself, and then 
we have different classes that know to either edit the master clusterstate.json 
or the collection's state.json.  And then if we add a third collection type 
that's implemented in a completely different way, we just add a new Collection 
implementation, and you don't have to pick through everywhere where you're 
checking the state version and add a new branch.

Java gives us classes and interfaces, it makes sense to use them.

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070202#comment-14070202
 ] 

Shalin Shekhar Mangar commented on SOLR-5473:
-

bq.  It should get a Collection object from the state reader and tell it to 
update itself, and then we have different classes that know to either edit the 
master clusterstate.json or the collection's state.json. And then if we add a 
third collection type that's implemented in a completely different way, we just 
add a new Collection implementation, and you don't have to pick through 
everywhere where you're checking the state version and add a new branch.

I don't like that idea for three reasons:
# If a collection object knows how to update itself, I don't see how batching 
of state updates can be supported inside Overseer.
# We don't plan to have multiple versions or collection types. This will be the 
only format eventually and we just need to keep this around for 4.x. We 
shouldn't be designing to optimize for multiple versions.
# The ClusterState/DocCollection right now are just data objects and the only 
place where you need to save them to ZK is Overseer so keeping that logic 
inside Overseer makes sense to me.

Therefore I think abstraction isn't going to help if no other component needs 
it.

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1171: POMs out of sync

2014-07-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1171/

3 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandlerBackup.org.apache.solr.handler.TestReplicationHandlerBackup

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.TestReplicationHandlerBackup: 
   1) Thread[id=47828, name=Thread-7787, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.URL.openStream(URL.java:1037)
at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestReplicationHandlerBackup: 
   1) Thread[id=47828, name=Thread-7787, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.URL.openStream(URL.java:1037)
at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314)
at __randomizedtesting.SeedInfo.seed([4BCCBD2ACF23D62E]:0)


FAILED:  
org.apache.solr.handler.TestReplicationHandlerBackup.org.apache.solr.handler.TestReplicationHandlerBackup

Error Message:
There are still zombie threads that couldn't be terminated:
   1) Thread[id=47828, name=Thread-7787, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.URL.openStream(URL.java:1037)
at 
org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=47828, name=Thread-7787, state=RUNNABLE, 
group=TGRP-TestReplicationHandlerBackup]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070307#comment-14070307
 ] 

Mark Miller commented on SOLR-5473:
---

bq. Sure, but there's no abstraction here.

I largely agree with you. A plan like that would help prevent abuse of whatever 
we do here. That is my largest concern left - when you put in tmp stuff that is 
not designed with solid abstractions, it generally leads to bad places as devs 
leave, fall off, change, other devs start cranking on that code, etc.

That's why, even if we don't do abstractions because we decide they are too 
expensive given our future plans or something, we need to document the hell out 
of in between code to protect it and guide it.

The nice thing about abstractions is that it's easier to document, its harder 
for others to screw up, and it's easier to do proper deprecation and removal.

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Issue Comment Deleted] (SOLR-6227) ChaosMonkeySafeLeaderTest failures on jenkins


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

Mark Miller updated SOLR-6227:
--

Comment: was deleted

(was: Hello all,

While invoking 
http://localhost:9090/solr/admin/collections?action=CREATEname=corenumShards=1replicationFactor=1collection.configName=coreconf
 I am getting below exception, this has been happening consistently for 4.7.2 
and 4.7.1 version, please help me understand if its the very same thing:

-- solr.log --

[ERROR] [2014-07-21 18:06:20,960] 
[Overseer-92140072928280576-localhost:9090_solr-n_03] 
[cloud.OverseerCollectionProcessor] - [Collection createcollection of 
createcollection failed:org.apache.solr.common.SolrException
at 
org.apache.solr.cloud.OverseerCollectionProcessor.createCollection(OverseerCollectionProcessor.java:1687)
at 
org.apache.solr.cloud.OverseerCollectionProcessor.processMessage(OverseerCollectionProcessor.java:387)
at 
org.apache.solr.cloud.OverseerCollectionProcessor.run(OverseerCollectionProcessor.java:200)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.zookeeper.KeeperException$NodeExistsException: 
KeeperErrorCode = NodeExists for /collections/usersearches
at org.apache.zookeeper.KeeperException.create(KeeperException.java:119)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
at 
org.apache.solr.common.cloud.SolrZkClient$10.execute(SolrZkClient.java:429)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:426)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:383)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:370)
at 
org.apache.solr.common.cloud.SolrZkClient.makePath(SolrZkClient.java:357)
at 
org.apache.solr.cloud.OverseerCollectionProcessor.createConfNode(OverseerCollectionProcessor.java:1711)
at 
org.apache.solr.cloud.OverseerCollectionProcessor.createCollection(OverseerCollectionProcessor.java:1624)
... 3 more
]

[ERROR] [2014-07-21 16:39:55,906] [http-9090-1] [servlet.SolrDispatchFilter] - 
[null:org.apache.solr.common.SolrException

at 
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:248)
at 
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:233)
at 
org.apache.solr.handler.admin.CollectionsHandler.handleCreateAction(CollectionsHandler.java:368)
at 
org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:141)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at 
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:720)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:265)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:205)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)

]

-- SOLR http response --
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status500/intint 
name=QTime210/int/lststr name=Operation createcollection caused 
exception:org.apache.solr.common.SolrException:org.apache.solr.common.SolrException/strlst
 name=exceptionnull name=msg/int name=rspCode500/int/lstlst 
name=errorstr name=traceorg.apache.solr.common.SolrException
at 
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:248)
at 
org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:233)
at

[jira] [Issue Comment Deleted] (SOLR-6227) ChaosMonkeySafeLeaderTest failures on jenkins


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

Mark Miller updated SOLR-6227:
--

Comment: was deleted

(was: The above has been happening because of the 'linkconfig' command being 
used on ZooKeeper side which further prevents SOLR admin api to create a valid 
ZK node path therefore failing this way.

I got over it by just uploading the SOLR configurations and then using the 
action=CREATE http command and it works.

However, are there some documentation which lists down such changes across 
versions?

--Deepak)

 ChaosMonkeySafeLeaderTest failures on jenkins
 -

 Key: SOLR-6227
 URL: https://issues.apache.org/jira/browse/SOLR-6227
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10


 This is happening very frequently.
 {code}
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
 Error Message:
 shard1 is not consistent.  Got 143 from 
 https://127.0.0.1:36610/xvv/collection1lastClient and got 142 from 
 https://127.0.0.1:33168/xvv/collection1
 Stack Trace:
 java.lang.AssertionError: shard1 is not consistent.  Got 143 from 
 https://127.0.0.1:36610/xvv/collection1lastClient and got 142 from 
 https://127.0.0.1:33168/xvv/collection1
 at 
 __randomizedtesting.SeedInfo.seed([3C1FB6EAFE71:BDF938F2AA829E4D]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1139)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1118)
 at 
 org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:150)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6227) ChaosMonkeySafeLeaderTest failures on jenkins

2014-07-22 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070340#comment-14070340
 ] 

Mark Miller commented on SOLR-6227:
---

Yeah, that failure has been around - I get it occasionally. Just means there 
was a fail when you wouldn't expect it - we expect 0 to fail because we don't 
kill leaders - seems one can occasionally fail with:  
org.apache.http.NoHttpResponseException: The target server failed to respond. 
It's not necessarily illegal behavior, it just shouldn't really happen.

Anyway, a much less concerning issue. As far as the inconsistency, which is 
totally illegal, like your report, I no longer see in my local jenkins jobs. 
Fantastic. Always a scary fail.

 ChaosMonkeySafeLeaderTest failures on jenkins
 -

 Key: SOLR-6227
 URL: https://issues.apache.org/jira/browse/SOLR-6227
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, Tests
Reporter: Shalin Shekhar Mangar
 Fix For: 4.10


 This is happening very frequently.
 {code}
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
 Error Message:
 shard1 is not consistent.  Got 143 from 
 https://127.0.0.1:36610/xvv/collection1lastClient and got 142 from 
 https://127.0.0.1:33168/xvv/collection1
 Stack Trace:
 java.lang.AssertionError: shard1 is not consistent.  Got 143 from 
 https://127.0.0.1:36610/xvv/collection1lastClient and got 142 from 
 https://127.0.0.1:33168/xvv/collection1
 at 
 __randomizedtesting.SeedInfo.seed([3C1FB6EAFE71:BDF938F2AA829E4D]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1139)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1118)
 at 
 org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:150)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865)
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime


[ 
https://issues.apache.org/jira/browse/SOLR-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070346#comment-14070346
 ] 

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

Commit 1612585 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1612585 ]

SOLR-3345: BaseDistributedSearchTestCase should always ignore QTime.

 BaseDistributedSearchTestCase should always ignore QTime
 

 Key: SOLR-3345
 URL: https://issues.apache.org/jira/browse/SOLR-3345
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-ALPHA
Reporter: Benson Margulies
Assignee: Mark Miller
 Attachments: SOLR-3345-SVN.patch, SOLR-3345.patch


 The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I 
 can't see any way in which those numbers will ever match. Why not make this 
 the default, or only, behavior?
 (This is really a question, in that I will provide a patch if no one tells me 
 that it is a bad idea.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-6252) A couple of small improvements to UnInvertedField class.


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

Mark Miller updated SOLR-6252:
--

Fix Version/s: 4.10
   5.0
  Summary: A couple of small improvements to UnInvertedField class.  
(was: Simplify UnInvertedField#getUnInvertedField synchronization module)

 A couple of small improvements to UnInvertedField class.
 

 Key: SOLR-6252
 URL: https://issues.apache.org/jira/browse/SOLR-6252
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch


 Looks like UnInvertedField#getUnInvertedField has implemented a bit 
 additional synchronization module rather than what is required, and thereby 
 increasing the complexity.
 https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667
 As pointed out in the above link, as the synchronization is performed on the 
 cache variable(which itself will protect the threads from obtaining access to 
 the cache), we can safely remove all the placeholder flags. As long as 
 cache.get() is in synchronized block, we can simply populate the cache with 
 new entries and other threads will be able to see the changes.
 This change has been introduced in 
 https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (SOLR-6252) A couple of small improvements to UnInvertedField class.


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

Mark Miller resolved SOLR-6252.
---

Resolution: Fixed

Thanks Vamsee and Greg!

 A couple of small improvements to UnInvertedField class.
 

 Key: SOLR-6252
 URL: https://issues.apache.org/jira/browse/SOLR-6252
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 5.0
Reporter: Vamsee Yarlagadda
Assignee: Mark Miller
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: SOLR-6252-v3.patch, SOLR-6252.patch, SOLR-6252v2.patch


 Looks like UnInvertedField#getUnInvertedField has implemented a bit 
 additional synchronization module rather than what is required, and thereby 
 increasing the complexity.
 https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/request/UnInvertedField.java#L667
 As pointed out in the above link, as the synchronization is performed on the 
 cache variable(which itself will protect the threads from obtaining access to 
 the cache), we can safely remove all the placeholder flags. As long as 
 cache.get() is in synchronized block, we can simply populate the cache with 
 new entries and other threads will be able to see the changes.
 This change has been introduced in 
 https://issues.apache.org/jira/browse/SOLR-2548 (Multithreaded faceting)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070375#comment-14070375
 ] 

Noble Paul commented on SOLR-5473:
--

Abstractions are definitely good. But here it is an overkill

There is only one entity which should ever construct and persist a clusterstate 
(that is the overseer). And going forward we don't need these multiple 
'stateFormat' things. 

I don't agree with the idea of a data object being responsible for its 
persistence. This is a typical ORM thing where the data object offers just a 
structure and the ORM framework worries about how/where the persistence is done

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6265) core errors on startup are not showing up in the log until attempts to use the core?

2014-07-22 Thread Erick Erickson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070376#comment-14070376
 ] 

Erick Erickson commented on SOLR-6265:
--

Hmmm, that shows an error, it's just not a horribly informative one, certainly 
not the full stack trace...

Don't really have time to pursue this now though.

 core errors on startup are not showing up in the log until attempts to use 
 the core?
 

 Key: SOLR-6265
 URL: https://issues.apache.org/jira/browse/SOLR-6265
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Priority: Blocker
 Fix For: 4.10


 As of r1612418, both the 4x and trunk svn trees seem to have a bug where any 
 core specific init errors that occur on startup don't show up in the log 
 until/unless someone attempts to access that core via HTTP.
 i'm not sure when exactly this bug was introduced, but it definitely isn't in 
 4.9.
 The impact on users, particularly new users, is that starting up solr with a 
 mistake in your configs appears to work fine until you actually try to use 
 solr and then you get ugly errors.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6261) Run checkIfIamLeader in a separate thread

2014-07-22 Thread Ramkumar Aiyengar (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070379#comment-14070379
 ] 

Ramkumar Aiyengar commented on SOLR-6261:
-

Alternative approach using an executor, just a sketch at this point (still 
fails a few tests). It has an `instanceof` which is a bit ugly, but any other 
method to maintain existing behaviour when needed can be used, this was just 
the simplest.. Once we are settled on the approach, we can hunt down other 
stuff using the event thread..

https://github.com/apache/lucene-solr/pull/66/files

(would be nice if commits to a pull showed up here..)

 Run checkIfIamLeader in a separate thread
 -

 Key: SOLR-6261
 URL: https://issues.apache.org/jira/browse/SOLR-6261
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.9
Reporter: Ramkumar Aiyengar
Assignee: Mark Miller
Priority: Minor

 Currently checking for leadership (due to the leader's ephemeral node going 
 away) happens in ZK's event thread. If there are many cores and all of them 
 are due leadership, then they would have to serially go through the two-way 
 sync and leadership takeover.
 For tens of cores, this could mean 30-40s without leadership before the last 
 in the list even gets to start the leadership process. If the leadership 
 process happens in a separate thread, then the cores could all take over in 
 parallel.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively

2014-07-22 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070388#comment-14070388
 ] 

Mark Miller commented on SOLR-5473:
---

bq. But here it is an overkill

I think that may be a fine argument to make, but then I wish you would address: 
when you put in tmp stuff that is not designed with solid abstractions, it 
generally leads to bad places as devs leave, fall off, change, other devs start 
cranking on that code, etc.

You can read through my comments above for more details, but this has been my 
main concern. Putting in a bunch of stuff that is hard for new devs to 
understand, that's half way between two worlds, that counts on the same devs 
coming back and finishing later, that tends to be a red flag to me.

The commenting, the plan for deprecation, comments to make new devs able to 
understand any of this, that seems really lacking. Currently, I think 
abstractions is the best way to solve a lot of that. I'm willing to be shown it 
can be done without that though.

My feeling is that it's currently implemented like one organization or entity 
owns the code, and not like it's going into a melting pot with an extremely 
unpredictable future, as it is.

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime


[ 
https://issues.apache.org/jira/browse/SOLR-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070389#comment-14070389
 ] 

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

Commit 1612593 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612593 ]

SOLR-3345: BaseDistributedSearchTestCase should always ignore QTime.

 BaseDistributedSearchTestCase should always ignore QTime
 

 Key: SOLR-3345
 URL: https://issues.apache.org/jira/browse/SOLR-3345
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-ALPHA
Reporter: Benson Margulies
Assignee: Mark Miller
 Attachments: SOLR-3345-SVN.patch, SOLR-3345.patch


 The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I 
 can't see any way in which those numbers will ever match. Why not make this 
 the default, or only, behavior?
 (This is really a question, in that I will provide a patch if no one tells me 
 that it is a bad idea.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6261) Run checkIfIamLeader in a separate thread


[ 
https://issues.apache.org/jira/browse/SOLR-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070397#comment-14070397
 ] 

Mark Miller commented on SOLR-6261:
---

Hmm...that is a very interesting approach. I'll have to spend some time 
thinking about this one.

 Run checkIfIamLeader in a separate thread
 -

 Key: SOLR-6261
 URL: https://issues.apache.org/jira/browse/SOLR-6261
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.9
Reporter: Ramkumar Aiyengar
Assignee: Mark Miller
Priority: Minor

 Currently checking for leadership (due to the leader's ephemeral node going 
 away) happens in ZK's event thread. If there are many cores and all of them 
 are due leadership, then they would have to serially go through the two-way 
 sync and leadership takeover.
 For tens of cores, this could mean 30-40s without leadership before the last 
 in the list even gets to start the leadership process. If the leadership 
 process happens in a separate thread, then the cores could all take over in 
 parallel.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime


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

Mark Miller resolved SOLR-3345.
---

   Resolution: Fixed
Fix Version/s: 4.10
   5.0

Thanks Vamsee and Benson!

 BaseDistributedSearchTestCase should always ignore QTime
 

 Key: SOLR-3345
 URL: https://issues.apache.org/jira/browse/SOLR-3345
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.0-ALPHA
Reporter: Benson Margulies
Assignee: Mark Miller
 Fix For: 5.0, 4.10

 Attachments: SOLR-3345-SVN.patch, SOLR-3345.patch


 The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I 
 can't see any way in which those numbers will ever match. Why not make this 
 the default, or only, behavior?
 (This is really a question, in that I will provide a patch if no one tells me 
 that it is a bad idea.)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6264) optimize with waitSearcher=true leads to serial execution across all replicas

2014-07-22 Thread Timothy Potter (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070415#comment-14070415
 ] 

Timothy Potter commented on SOLR-6264:
--

Patch looks good and I ran it through my scenario (described above ^) and the 
optimize was definitely sent to all replicas in parallel and finished in less 
than half the runtime previously.

 optimize with waitSearcher=true leads to serial execution across all replicas
 -

 Key: SOLR-6264
 URL: https://issues.apache.org/jira/browse/SOLR-6264
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Timothy Potter
 Attachments: SOLR-6264.patch


 Regardless of whether one agrees with optimizing, when you execute an 
 optimize request using waitSearcher=true, the requests from the controller 
 node are sent to each replica in the collection serially. 
 You can send the optimize command to the update handler for a collection to 
 any node in the cluster. For instance, if I had a collection named foo:
 curl -i -v http://localhost:8984/solr/foo/update --data-binary 'optimize 
 maxSegments=1 waitSearcher=true/' -H 'Content-type:application/xml'
 The node that receives this request will collect the URL for all live 
 replicas in the collection (not just leaders) (see 
 DistributedUpdateProcessor#getCollectionUrls) and then forward the commit 
 request to each of them. On the surface, the code looks like it forwards the 
 request asynchronously to all replicas. However, this is not actually what 
 happens; the commit requests to each replica in the collection will be 
 processed serially when using waitSearcher=true (because 
 ConcurrentUpdateSolrServer's background queue processing is by-passed for 
 commits).
 Bottom-line, if you request the collection to be optimized, the request gets 
 forwarded around as you'd expect but is done synchronously so can take a long 
 time. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6216) Better faceting for multiple intervals on DV fields


[ 
https://issues.apache.org/jira/browse/SOLR-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070457#comment-14070457
 ] 

Tomás Fernández Löbbe commented on SOLR-6216:
-

Great, thanks Erick. I'll create a Jira for the LocalParam behavior I mentioned 
before (override the interval key)

 Better faceting for multiple intervals on DV fields
 ---

 Key: SOLR-6216
 URL: https://issues.apache.org/jira/browse/SOLR-6216
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
Assignee: Erick Erickson
 Attachments: SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch, 
 SOLR-6216.patch, SOLR-6216.patch, SOLR-6216.patch


 There are two ways to have faceting on values ranges in Solr right now: 
 “Range Faceting” and “Query Faceting” (doing range queries). They both end up 
 doing something similar:
 {code:java}
 searcher.numDocs(rangeQ , docs)
 {code}
 The good thing about this implementation is that it can benefit from caching. 
 The bad thing is that it may be slow with cold caches, and that there will be 
 a query for each of the ranges.
 A different implementation would be one that works similar to regular field 
 faceting, using doc values and validating ranges for each value of the 
 matching documents. This implementation would sometimes be faster than Range 
 Faceting / Query Faceting, specially on cases where caches are not very 
 effective, like on a high update rate, or where ranges change frequently.
 Functionally, the result should be exactly the same as the one obtained by 
 doing a facet query for every interval



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070478#comment-14070478
 ] 

Noble Paul commented on SOLR-5473:
--

bq.My feeling is that it's currently implemented like one organization or 
entity owns the code

Is this comment made after looking at the latest patch? The current system does 
not have too many changes from the old system. I know a couple a places I would 
need to add documentation (inside ClusterState) I personally don't see any 
places where devs can screw up. I'll be glad to address any shortcomings



 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070503#comment-14070503
 ] 

Mark Miller commented on SOLR-5473:
---

Yes, that comment comes after looking at the latest patch.

Let's also finally nuke all references to external, ie ExternalCollectionsTest

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5473) Split clusterstate.json per collection and watch states selectively


[ 
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070511#comment-14070511
 ] 

Mark Miller commented on SOLR-5473:
---

I'll try and do a pass of my own on the patch later this week or early next 
week.

 Split clusterstate.json per collection and watch states selectively 
 

 Key: SOLR-5473
 URL: https://issues.apache.org/jira/browse/SOLR-5473
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-5473-74 .patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch, 
 SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74_POC.patch, 
 SOLR-5473-configname-fix.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, 
 SOLR-5473_undo.patch, ec2-23-20-119-52_solr.log, ec2-50-16-38-73_solr.log


 As defined in the parent issue, store the states of each collection under 
 /collections/collectionname/state.json node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-5410) Solr wrapper for the SpanQueryParser in LUCENE-5205

2014-07-22 Thread Tim Allison (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070524#comment-14070524
 ] 

Tim Allison commented on SOLR-5410:
---

Added standalone source and jars for current latest stable version of 
Lucene/Solr (4.9.0) here:

https://github.com/tballison/tallison-lucene-addons.

I'll also try to keep my fork of lucene-solr up to date on the same site for 
integration with trunk...if there is interest.

From the README file: 
To get this to work in Solr:

1) add lucene-sandbox.jar to your Solr class path (you will need to download 
Lucene separately from Solr!)
2) add solr-5410-x.jar to your Solr class path
3) add lucene-5205-x.jar to your Solr class path
4) add the following line to your solrconfig.xml file:

  queryParser name=span class=solr.search.SpanQParserPlugin/
5) at search time, add defType=span to your query string OR q={!span}quick

 Solr wrapper for the SpanQueryParser in LUCENE-5205
 ---

 Key: SOLR-5410
 URL: https://issues.apache.org/jira/browse/SOLR-5410
 Project: Solr
  Issue Type: New Feature
Reporter: Jason R Robinson
 Attachments: SOLR-5410.patch, Solr_SpanQueryParser.zip


 This is a simple Solr wrapper around the SpanQueryParser submitted in 
 [LUCENE-5205|https://issues.apache.org/jira/i#browse/LUCENE-5205].
 Dependent on  
 [LUCENE-5205|https://issues.apache.org/jira/i#browse/LUCENE-5205]
 ***Following Yonik's Law*** 
 This is patch is more of a placeholder for a much more polished draft.  Among 
 other things, test scripts and javadocs are forthcoming!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

2014-07-22 Thread Tim Allison (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070529#comment-14070529
 ] 

Tim Allison commented on LUCENE-5205:
-

Unrelated to work on LUCENE-5758, I added a standalone package including a jar 
to track with current latest stable distro of Lucene here: 
https://github.com/tballison/tallison-lucene-addons/tree/master/lucene-5205

For trunk integration, see lucene-5205 branch of my fork on github.

 [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to 
 classic QueryParser
 ---

 Key: LUCENE-5205
 URL: https://issues.apache.org/jira/browse/LUCENE-5205
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Reporter: Tim Allison
  Labels: patch
 Fix For: 4.9

 Attachments: LUCENE-5205-cleanup-tests.patch, 
 LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
 LUCENE-5205_dateTestReInitPkgPrvt.patch, 
 LUCENE-5205_improve_stop_word_handling.patch, 
 LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
 SpanQueryParser_v1.patch.gz, patch.txt


 This parser extends QueryParserBase and includes functionality from:
 * Classic QueryParser: most of its syntax
 * SurroundQueryParser: recursive parsing for near and not clauses.
 * ComplexPhraseQueryParser: can handle near queries that include multiterms 
 (wildcard, fuzzy, regex, prefix),
 * AnalyzingQueryParser: has an option to analyze multiterms.
 At a high level, there's a first pass BooleanQuery/field parser and then a 
 span query parser handles all terminal nodes and phrases.
 Same as classic syntax:
 * term: test 
 * fuzzy: roam~0.8, roam~2
 * wildcard: te?t, test*, t*st
 * regex: /\[mb\]oat/
 * phrase: jakarta apache
 * phrase with slop: jakarta apache~3
 * default or clause: jakarta apache
 * grouping or clause: (jakarta apache)
 * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
 * multiple fields: title:lucene author:hatcher
  
 Main additions in SpanQueryParser syntax vs. classic syntax:
 * Can require in order for phrases with slop with the \~ operator: 
 jakarta apache\~3
 * Can specify not near: fever bieber!\~3,10 ::
 find fever but not if bieber appears within 3 words before or 10 
 words after it.
 * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
 apache\]~3 lucene\]\~4 :: 
 find jakarta within 3 words of apache, and that hit has to be within 
 four words before lucene
 * Can also use \[\] for single level phrasal queries instead of  as in: 
 \[jakarta apache\]
 * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 
 :: find apache and then either lucene or solr within three words.
 * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2
 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
 /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two 
 words of ap*che and that hit has to be within ten words of something like 
 solr or that lucene regex.
 * Can require at least x number of hits at boolean level: apache AND (lucene 
 solr tika)~2
 * Can use negative only query: -jakarta :: Find all docs that don't contain 
 jakarta
 * Can use an edit distance  2 for fuzzy query via SlowFuzzyQuery (beware of 
 potential performance issues!).
 Trivial additions:
 * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
 prefix =2)
 * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
 =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein)
 This parser can be very useful for concordance tasks (see also LUCENE-5317 
 and LUCENE-5318) and for analytical search.  
 Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
 Most of the documentation is in the javadoc for SpanQueryParser.
 Any and all feedback is welcome.  Thank you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6267) Let user override Interval Faceting key with LocalParams

Tomás Fernández Löbbe created SOLR-6267:
---

 Summary: Let user override Interval Faceting key with LocalParams
 Key: SOLR-6267
 URL: https://issues.apache.org/jira/browse/SOLR-6267
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe


This issue is related to Interval Faceting, being worked at SOLR-6216. Right 
now they key of each interval is the string of the interval as entered in the 
request. For example:
{noformat}
[*,20)
[20,40)
[40,*]
{noformat}
would output something like
{noformat}
facet_intervals:{
  size:{
[*,20):3,
[20,40):4,
[40,*]:9}}
{noformat}
It would be good to be able to override the key per interval using local 
params, for example:
{noformat}
{!key='small'}[,20)
{!key='medium'}[20,40)
{!key='large'}[40,]
{noformat}
Would output:
{noformat}
facet_intervals:{
  size:{
small:3,
medium:4,
large:9}}
{noformat}




--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6261) Run checkIfIamLeader in a separate thread


[ 
https://issues.apache.org/jira/browse/SOLR-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070607#comment-14070607
 ] 

Mark Miller commented on SOLR-6261:
---

I really kind of like this idea of just ensuring the zk process thread is 
humming along. The more I think about it, the more I like it.

 Run checkIfIamLeader in a separate thread
 -

 Key: SOLR-6261
 URL: https://issues.apache.org/jira/browse/SOLR-6261
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 4.9
Reporter: Ramkumar Aiyengar
Assignee: Mark Miller
Priority: Minor

 Currently checking for leadership (due to the leader's ephemeral node going 
 away) happens in ZK's event thread. If there are many cores and all of them 
 are due leadership, then they would have to serially go through the two-way 
 sync and leadership takeover.
 For tens of cores, this could mean 30-40s without leadership before the last 
 in the list even gets to start the leadership process. If the leadership 
 process happens in a separate thread, then the cores could all take over in 
 parallel.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread Varun V Shenoy (JIRA)


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

Varun  V Shenoy updated LUCENE-5825:


Attachment: (was: patch_17_Jul_2014)

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread Varun V Shenoy (JIRA)


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

Varun  V Shenoy updated LUCENE-5825:


Attachment: LUCENE-5825.patch

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0

 Attachments: LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread Varun V Shenoy (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070614#comment-14070614
 ] 

Varun  V Shenoy commented on LUCENE-5825:
-

I have attached the patch and the command line I had used for creating the 
patch earlier was git diff trunk lucene-5825. For the patch that I uploaded 
now, has been created using the command git format-patch trunk --stdout  
patchFile

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0

 Attachments: LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070636#comment-14070636
 ] 

Mark Miller commented on SOLR-3619:
---

So one idea, along the lines of what Tim first proposed is to do something like:

leave example as it is for now
add the server dir and put the start scripts in it and set them up to work with 
example for now

Not very contentious, but gets us a start on pimping out a server folder?

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
 Fix For: 4.9, 5.0

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

2014-07-22 Thread Paul Elschot (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070697#comment-14070697
 ] 

Paul Elschot commented on LUCENE-5205:
--

I pulled lucene5205 again as above, and merged in current trunk (commit 
afee841220c786055d28c95945646a7737a04d2a).
The tests in the lucene/queryparser module pass now.
Could you make a pull request to here from your lucene5205 ?

 [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to 
 classic QueryParser
 ---

 Key: LUCENE-5205
 URL: https://issues.apache.org/jira/browse/LUCENE-5205
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Reporter: Tim Allison
  Labels: patch
 Fix For: 4.9

 Attachments: LUCENE-5205-cleanup-tests.patch, 
 LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
 LUCENE-5205_dateTestReInitPkgPrvt.patch, 
 LUCENE-5205_improve_stop_word_handling.patch, 
 LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
 SpanQueryParser_v1.patch.gz, patch.txt


 This parser extends QueryParserBase and includes functionality from:
 * Classic QueryParser: most of its syntax
 * SurroundQueryParser: recursive parsing for near and not clauses.
 * ComplexPhraseQueryParser: can handle near queries that include multiterms 
 (wildcard, fuzzy, regex, prefix),
 * AnalyzingQueryParser: has an option to analyze multiterms.
 At a high level, there's a first pass BooleanQuery/field parser and then a 
 span query parser handles all terminal nodes and phrases.
 Same as classic syntax:
 * term: test 
 * fuzzy: roam~0.8, roam~2
 * wildcard: te?t, test*, t*st
 * regex: /\[mb\]oat/
 * phrase: jakarta apache
 * phrase with slop: jakarta apache~3
 * default or clause: jakarta apache
 * grouping or clause: (jakarta apache)
 * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
 * multiple fields: title:lucene author:hatcher
  
 Main additions in SpanQueryParser syntax vs. classic syntax:
 * Can require in order for phrases with slop with the \~ operator: 
 jakarta apache\~3
 * Can specify not near: fever bieber!\~3,10 ::
 find fever but not if bieber appears within 3 words before or 10 
 words after it.
 * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
 apache\]~3 lucene\]\~4 :: 
 find jakarta within 3 words of apache, and that hit has to be within 
 four words before lucene
 * Can also use \[\] for single level phrasal queries instead of  as in: 
 \[jakarta apache\]
 * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 
 :: find apache and then either lucene or solr within three words.
 * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2
 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
 /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two 
 words of ap*che and that hit has to be within ten words of something like 
 solr or that lucene regex.
 * Can require at least x number of hits at boolean level: apache AND (lucene 
 solr tika)~2
 * Can use negative only query: -jakarta :: Find all docs that don't contain 
 jakarta
 * Can use an edit distance  2 for fuzzy query via SlowFuzzyQuery (beware of 
 potential performance issues!).
 Trivial additions:
 * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
 prefix =2)
 * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
 =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein)
 This parser can be very useful for concordance tasks (see also LUCENE-5317 
 and LUCENE-5318) and for analytical search.  
 Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
 Most of the documentation is in the javadoc for SpanQueryParser.
 Any and all feedback is welcome.  Thank you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-22 Thread Timothy Potter (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070700#comment-14070700
 ] 

Timothy Potter commented on SOLR-3619:
--

+1 I blocked off all day tomorrow to focus on this issue so look for a patch 
(using the scripts from SOLR-3617) later in the day tomorrow.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
 Fix For: 4.9, 5.0

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

2014-07-22 Thread Tim Allison (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070735#comment-14070735
 ] 

Tim Allison commented on LUCENE-5205:
-

Will do. I need to add the March 10 patch in as well (and remember to commit 
the changes!).  Do you mind if I roll in SOLR-5410?

 [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to 
 classic QueryParser
 ---

 Key: LUCENE-5205
 URL: https://issues.apache.org/jira/browse/LUCENE-5205
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Reporter: Tim Allison
  Labels: patch
 Fix For: 4.9

 Attachments: LUCENE-5205-cleanup-tests.patch, 
 LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
 LUCENE-5205_dateTestReInitPkgPrvt.patch, 
 LUCENE-5205_improve_stop_word_handling.patch, 
 LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
 SpanQueryParser_v1.patch.gz, patch.txt


 This parser extends QueryParserBase and includes functionality from:
 * Classic QueryParser: most of its syntax
 * SurroundQueryParser: recursive parsing for near and not clauses.
 * ComplexPhraseQueryParser: can handle near queries that include multiterms 
 (wildcard, fuzzy, regex, prefix),
 * AnalyzingQueryParser: has an option to analyze multiterms.
 At a high level, there's a first pass BooleanQuery/field parser and then a 
 span query parser handles all terminal nodes and phrases.
 Same as classic syntax:
 * term: test 
 * fuzzy: roam~0.8, roam~2
 * wildcard: te?t, test*, t*st
 * regex: /\[mb\]oat/
 * phrase: jakarta apache
 * phrase with slop: jakarta apache~3
 * default or clause: jakarta apache
 * grouping or clause: (jakarta apache)
 * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
 * multiple fields: title:lucene author:hatcher
  
 Main additions in SpanQueryParser syntax vs. classic syntax:
 * Can require in order for phrases with slop with the \~ operator: 
 jakarta apache\~3
 * Can specify not near: fever bieber!\~3,10 ::
 find fever but not if bieber appears within 3 words before or 10 
 words after it.
 * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
 apache\]~3 lucene\]\~4 :: 
 find jakarta within 3 words of apache, and that hit has to be within 
 four words before lucene
 * Can also use \[\] for single level phrasal queries instead of  as in: 
 \[jakarta apache\]
 * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 
 :: find apache and then either lucene or solr within three words.
 * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2
 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
 /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two 
 words of ap*che and that hit has to be within ten words of something like 
 solr or that lucene regex.
 * Can require at least x number of hits at boolean level: apache AND (lucene 
 solr tika)~2
 * Can use negative only query: -jakarta :: Find all docs that don't contain 
 jakarta
 * Can use an edit distance  2 for fuzzy query via SlowFuzzyQuery (beware of 
 potential performance issues!).
 Trivial additions:
 * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
 prefix =2)
 * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
 =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein)
 This parser can be very useful for concordance tasks (see also LUCENE-5317 
 and LUCENE-5318) and for analytical search.  
 Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
 Most of the documentation is in the javadoc for SpanQueryParser.
 Any and all feedback is welcome.  Thank you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5205) [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

2014-07-22 Thread Paul Elschot (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070797#comment-14070797
 ] 

Paul Elschot commented on LUCENE-5205:
--

I don't mind rolling in SOLR-5410.

 [PATCH] SpanQueryParser with recursion, analysis and syntax very similar to 
 classic QueryParser
 ---

 Key: LUCENE-5205
 URL: https://issues.apache.org/jira/browse/LUCENE-5205
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/queryparser
Reporter: Tim Allison
  Labels: patch
 Fix For: 4.9

 Attachments: LUCENE-5205-cleanup-tests.patch, 
 LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
 LUCENE-5205_dateTestReInitPkgPrvt.patch, 
 LUCENE-5205_improve_stop_word_handling.patch, 
 LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
 SpanQueryParser_v1.patch.gz, patch.txt


 This parser extends QueryParserBase and includes functionality from:
 * Classic QueryParser: most of its syntax
 * SurroundQueryParser: recursive parsing for near and not clauses.
 * ComplexPhraseQueryParser: can handle near queries that include multiterms 
 (wildcard, fuzzy, regex, prefix),
 * AnalyzingQueryParser: has an option to analyze multiterms.
 At a high level, there's a first pass BooleanQuery/field parser and then a 
 span query parser handles all terminal nodes and phrases.
 Same as classic syntax:
 * term: test 
 * fuzzy: roam~0.8, roam~2
 * wildcard: te?t, test*, t*st
 * regex: /\[mb\]oat/
 * phrase: jakarta apache
 * phrase with slop: jakarta apache~3
 * default or clause: jakarta apache
 * grouping or clause: (jakarta apache)
 * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
 * multiple fields: title:lucene author:hatcher
  
 Main additions in SpanQueryParser syntax vs. classic syntax:
 * Can require in order for phrases with slop with the \~ operator: 
 jakarta apache\~3
 * Can specify not near: fever bieber!\~3,10 ::
 find fever but not if bieber appears within 3 words before or 10 
 words after it.
 * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
 apache\]~3 lucene\]\~4 :: 
 find jakarta within 3 words of apache, and that hit has to be within 
 four words before lucene
 * Can also use \[\] for single level phrasal queries instead of  as in: 
 \[jakarta apache\]
 * Can use or grouping clauses in phrasal queries: apache (lucene solr)\~3 
 :: find apache and then either lucene or solr within three words.
 * Can use multiterms in phrasal queries: jakarta\~1 ap*che\~2
 * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
 /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like jakarta within two 
 words of ap*che and that hit has to be within ten words of something like 
 solr or that lucene regex.
 * Can require at least x number of hits at boolean level: apache AND (lucene 
 solr tika)~2
 * Can use negative only query: -jakarta :: Find all docs that don't contain 
 jakarta
 * Can use an edit distance  2 for fuzzy query via SlowFuzzyQuery (beware of 
 potential performance issues!).
 Trivial additions:
 * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
 prefix =2)
 * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
 =2: (jakarta~1 (OSA) vs jakarta~1(Levenshtein)
 This parser can be very useful for concordance tasks (see also LUCENE-5317 
 and LUCENE-5318) and for analytical search.  
 Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
 Most of the documentation is in the javadoc for SpanQueryParser.
 Any and all feedback is welcome.  Thank you.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-3881) frequent OOM in LanguageIdentifierUpdateProcessor

2014-07-22 Thread Vitaliy Zhovtyuk (JIRA)


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

Vitaliy Zhovtyuk updated SOLR-3881:
---

Attachment: SOLR-3881.patch

Added global limit to concatenated string
Added limit to detector to detector.setMaxTextLength(maxTotalAppendSize);

About moving 
org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor#concatFields 
to org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessor it's 
a bit unclear because concatFields is used in both 
org.apache.solr.update.processor.TikaLanguageIdentifierUpdateProcessor and 
org.apache.solr.update.processor.LangDetectLanguageIdentifierUpdateProcessor

 frequent OOM in LanguageIdentifierUpdateProcessor
 -

 Key: SOLR-3881
 URL: https://issues.apache.org/jira/browse/SOLR-3881
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.0
 Environment: CentOS 6.x, JDK 1.6, (java -server -Xms2G -Xmx2G 
 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=)
Reporter: Rob Tulloh
 Fix For: 4.9, 5.0

 Attachments: SOLR-3881.patch, SOLR-3881.patch, SOLR-3881.patch


 We are seeing frequent failures from Solr causing it to OOM. Here is the 
 stack trace we observe when this happens:
 {noformat}
 Caused by: java.lang.OutOfMemoryError: Java heap space
 at java.util.Arrays.copyOf(Arrays.java:2882)
 at 
 java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
 at 
 java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
 at java.lang.StringBuffer.append(StringBuffer.java:224)
 at 
 org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.concatFields(LanguageIdentifierUpdateProcessor.java:286)
 at 
 org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.process(LanguageIdentifierUpdateProcessor.java:189)
 at 
 org.apache.solr.update.processor.LanguageIdentifierUpdateProcessor.processAdd(LanguageIdentifierUpdateProcessor.java:171)
 at 
 org.apache.solr.handler.BinaryUpdateRequestHandler$2.update(BinaryUpdateRequestHandler.java:90)
 at 
 org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:140)
 at 
 org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:120)
 at 
 org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:221)
 at 
 org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:105)
 at 
 org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:186)
 at 
 org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:112)
 at 
 org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:147)
 at 
 org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:100)
 at 
 org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:47)
 at 
 org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:58)
 at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:59)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1540)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
 at 
 org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
 at 
 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6248) MoreLikeThis Query Parser

2014-07-22 Thread Anshum Gupta (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070897#comment-14070897
]

Anshum Gupta commented on SOLR-6248:

What do you mean by text that isn't in the index? If you mean pseudo-random
text to find documents similar to that? Yes, it would handle that.

MoreLikeThis Query Parser
-

Key: SOLR-6248
URL: https://issues.apache.org/jira/browse/SOLR-6248
Project: Solr
Issue Type: New Feature
Reporter: Anshum Gupta

MLT Component doesn't let people highlight/paginate and the handler comes
with an cost of maintaining another piece in the config. Also, any changes to
the default (number of results to be fetched etc.) /select handler need to be
copied/synced with this handler too.
Having an MLT QParser would let users get back docs based on a query for them
to paginate, highlight etc. It would also give them the flexibility to use
this anywhere i.e. q,fq,bq etc.
A bit of history about MLT (thanks to Hoss)
MLT Handler pre-dates the existence of QParsers and was meant to take an
arbitrary query as input, find docs that match that
query, club them together to find interesting terms, and then use those
terms as if they were my main query to generate a main result set.
This result would then be used as the set to facet, highlight etc.
The flow: Query - DocList(m) - Bag (terms) - Query - DocList\(y)
The MLT component on the other hand solved a very different purpose of
augmenting the main result set. It is used to get similar docs for each of
the doc in the main result set.
DocSet\(n) - n * Bag (terms) - n * (Query) - n * DocList(m)
The new approach:
All of this can be done better and cleaner (and makes more sense too) using
an MLT QParser.
An important thing to handle here is the case where the user doesn't have
TermVectors, in which case, it does what happens right now i.e. parsing
stored fields.
Also, in case the user doesn't have a field (to be used for MLT) indexed, the
field would need to be a TextField with an index analyzer defined. This
analyzer will then be used to extract terms for MLT.
In case of SolrCloud mode, '/get-termvectors' can be used after looking at
the schema (if TermVectors are enabled for the field). If not, a /get call
can be used to fetch the field and parse it.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6268) HdfsUpdateLog has a race condition that can expose a closed HDFS FileSystem instance and should close it's FileSystem instance if either inherited close method is called.

2014-07-22 Thread ASF subversion and git services (JIRA)

Mark Miller created SOLR-6268:
-

 Summary: HdfsUpdateLog has a race condition that can expose a 
closed HDFS FileSystem instance and should close it's FileSystem instance if 
either inherited close method is called.
 Key: SOLR-6268
 URL: https://issues.apache.org/jira/browse/SOLR-6268
 Project: Solr
  Issue Type: Bug
  Components: hdfs
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 5.0, 4.10






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3029) Poor json formatting of spelling collation info

2014-07-22 Thread Nalini Kartha (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071211#comment-14071211
 ] 

Nalini Kartha commented on SOLR-3029:
-

Hi [~jdyer],

Sorry to bug you but just wanted to check if you had a chance to look at the 
patch? 

Would appreciate your feedback. Thanks!

 Poor json formatting of spelling collation info
 ---

 Key: SOLR-3029
 URL: https://issues.apache.org/jira/browse/SOLR-3029
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 4.0-ALPHA
Reporter: Antony Stubbs
 Fix For: 4.9, 5.0

 Attachments: SOLR-3029.patch, SOLR-3029.patch


 {noformat}
 spellcheck: {
 suggestions: [
 dalllas,
 {
 snip
 {
 word: canallas,
 freq: 1
 }
 ]
 },
 correctlySpelled,
 false,
 collation,
 dallas
 ]
 }
 {noformat}
 The correctlySpelled and collation key/values are stored as consecutive 
 elements in an array - quite odd. Is there a reason isn't not a key/value map 
 like most things?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

Why does Solr binary distribution include test-framework?

2014-07-22 Thread Alexandre Rafalovitch

Hello,

What is the logic/benefit of shipping test framework with Solr
distribution? Is something actually using it outside of build/test
cycle?

It's 12Mb of libraries and documentations.

Regards,
   Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853

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

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

2014-07-22 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/10873/
Java: 32bit/jdk1.8.0_11 -server -XX:+UseG1GC

1 tests failed.
REGRESSION:  org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT

Error Message:
SOLR-5815? : wrong maxDoc: core=org.apache.solr.core.SolrCore@1fa713e 
searcher=Searcher@1e6e32[collection1] 
main{UninvertingDirectoryReader(Uninverting(_1(5.0):C1) 
Uninverting(_2(5.0):C1))} expected:3 but was:2

Stack Trace:
java.lang.AssertionError: SOLR-5815? : wrong maxDoc: 
core=org.apache.solr.core.SolrCore@1fa713e 
searcher=Searcher@1e6e32[collection1] 
main{UninvertingDirectoryReader(Uninverting(_1(5.0):C1) 
Uninverting(_2(5.0):C1))} expected:3 but was:2
at 
__randomizedtesting.SeedInfo.seed([304454EC351ECE70:85C2356B8ADF7C84]: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.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:142)
at 
org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:100)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at

[jira] [Updated] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread David Smiley (JIRA)


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

David Smiley updated LUCENE-5825:
-

Attachment: LUCENE-5825.patch

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0

 Attachments: LUCENE-5825.patch, LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071353#comment-14071353
]

David Smiley commented on LUCENE-5825:
--

I think the earlier patch was probably generated OK. The new one you posted is
definitely wrong as it only includes your last commit -- most likely because
you've been merging trunk into your branch (please don't do that next time). I
generated a diff this way:
{{git diff --no-prefix --no-color origin/trunk...shenoy/lucene-5825 --
lucene/benchmark/ LUCENE-5825.patch}}
* --no-prefix: chops off the a/ b/ git does by default on the paths.
* --no-color when I redirected stdout to a file it included the color codes
which rendered the file corrupt. I don't remember having to set this in the
past, but whatever.
* \-- lucene/benchmark: I think because you merged trunk, it included stuff
outside of the benchmark module, so this filtered it.

IntelliJ at least applied this patch fine.

I'll commit in a sec.

Allowing the benchmarking algorithm to choose PostingsFormat

Key: LUCENE-5825
URL: https://issues.apache.org/jira/browse/LUCENE-5825
Project: Lucene - Core
Issue Type: Improvement
Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun V Shenoy
Priority: Minor
Fix For: 5.0

Attachments: LUCENE-5825.patch, LUCENE-5825.patch

The algorithm file for benchmarking should allow PostingsFormat to be
configurable.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat


[ 
https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071355#comment-14071355
 ] 

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

Commit 1612765 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1612765 ]

LUCENE-5825: new benchmark codec.postingsFormat option

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0

 Attachments: LUCENE-5825.patch, LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Resolved] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread David Smiley (JIRA)


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

David Smiley resolved LUCENE-5825.
--

   Resolution: Fixed
Fix Version/s: 4.10
 Assignee: David Smiley

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Assignee: David Smiley
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5825.patch, LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5825) Allowing the benchmarking algorithm to choose PostingsFormat

2014-07-22 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071362#comment-14071362
 ] 

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

Commit 1612766 from [~dsmiley] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1612766 ]

LUCENE-5825: new benchmark codec.postingsFormat option

 Allowing the benchmarking algorithm to choose PostingsFormat
 

 Key: LUCENE-5825
 URL: https://issues.apache.org/jira/browse/LUCENE-5825
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/benchmark
Affects Versions: 5.0
Reporter: Varun  V Shenoy
Priority: Minor
 Fix For: 5.0, 4.10

 Attachments: LUCENE-5825.patch, LUCENE-5825.patch


 The algorithm file for benchmarking should allow PostingsFormat to be 
 configurable.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Updated] (SOLR-6267) Let user override Interval Faceting key with LocalParams


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

Tomás Fernández Löbbe updated SOLR-6267:


Attachment: SOLR-6267.patch

Added LocalParam parsing and some tests

 Let user override Interval Faceting key with LocalParams
 

 Key: SOLR-6267
 URL: https://issues.apache.org/jira/browse/SOLR-6267
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
 Attachments: SOLR-6267.patch


 This issue is related to Interval Faceting, being worked at SOLR-6216. Right 
 now they key of each interval is the string of the interval as entered in the 
 request. For example:
 {noformat}
 [*,20)
 [20,40)
 [40,*]
 {noformat}
 would output something like
 {noformat}
 facet_intervals:{
   size:{
 [*,20):3,
 [20,40):4,
 [40,*]:9}}
 {noformat}
 It would be good to be able to override the key per interval using local 
 params, for example:
 {noformat}
 {!key='small'}[,20)
 {!key='medium'}[20,40)
 {!key='large'}[40,]
 {noformat}
 Would output:
 {noformat}
 facet_intervals:{
   size:{
 small:3,
 medium:4,
 large:9}}
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Comment Edited] (SOLR-6267) Let user override Interval Faceting key with LocalParams