[jira] [Commented] (SOLR-7468) Kerberos authentication module

[ASF subversion and git services (JIRA)]

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

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

Commit 1681001 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1681001 ]

SOLR-7468: Kerberos plugin for authentication framework. This will enable using 
Kerberos for authentication in Solr.

> Kerberos authentication module
> --
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Ishan Chattopadhyaya
>Assignee: Anshum Gupta
> Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue 
> provides a Kerberos plugin implementation.



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

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

[jira] [Commented] (SOLR-1672) RFE: facet reverse sort count

[Romain MERESSE (JIRA)]

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

Romain MERESSE commented on SOLR-1672:
--

I need this feature too. Resorting to client-side sorting is not a good 
solution.
Any news ?

> RFE: facet reverse sort count
> -
>
> Key: SOLR-1672
> URL: https://issues.apache.org/jira/browse/SOLR-1672
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
> Environment: Java, Solrj, http
>Reporter: Peter Sturge
>Priority: Minor
> Attachments: SOLR-1672.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As suggested by Chris Hosstetter, I have added an optional Comparator to the 
> BoundedTreeSet in the UnInvertedField class.
> This optional comparator is used when a new (and also optional) field facet 
> parameter called 'facet.sortorder' is set to the string 'dsc' 
> (e.g. &f..facet.sortorder=dsc for per field, or 
> &facet.sortorder=dsc for all facets).
> Note that this parameter has no effect if facet.method=enum.
> Any value other than 'dsc' (including no value) reverts the BoundedTreeSet to 
> its default behaviour.
>  
> This change affects 2 source files:
> > UnInvertedField.java
> [line 438] The getCounts() method signature is modified to add the 
> 'facetSortOrder' parameter value to the end of the argument list.
>  
> DIFF UnInvertedField.java:
> - public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int 
> offset, int limit, Integer mincount, boolean missing, String sort, String 
> prefix) throws IOException {
> + public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int 
> offset, int limit, Integer mincount, boolean missing, String sort, String 
> prefix, String facetSortOrder) throws IOException {
> [line 556] The getCounts() method is modified to create an overridden 
> BoundedTreeSet(int, Comparator) if the 'facetSortOrder' parameter 
> equals 'dsc'.
> DIFF UnInvertedField.java:
> - final BoundedTreeSet queue = new BoundedTreeSet(maxsize);
> + final BoundedTreeSet queue = (sort.equals("count") || 
> sort.equals("true")) ? (facetSortOrder.equals("dsc") ? new 
> BoundedTreeSet(maxsize, new Comparator()
> { @Override
> public int compare(Object o1, Object o2)
> {
>   if (o1 == null || o2 == null)
> return 0;
>   int result = ((Long) o1).compareTo((Long) o2);
>   return (result != 0 ? result > 0 ? -1 : 1 : 0); //lowest number first sort
> }}) : new BoundedTreeSet(maxsize)) : null;
> > SimpleFacets.java
> [line 221] A getFieldParam(field, "facet.sortorder", "asc"); is added to 
> retrieve the new parameter, if present. 'asc' used as a default value.
> DIFF SimpleFacets.java:
> + String facetSortOrder = params.getFieldParam(field, "facet.sortorder", 
> "asc");
>  
> [line 253] The call to uif.getCounts() in the getTermCounts() method is 
> modified to pass the 'facetSortOrder' value string.
> DIFF SimpleFacets.java:
> - counts = uif.getCounts(searcher, base, offset, limit, 
> mincount,missing,sort,prefix);
> + counts = uif.getCounts(searcher, base, offset, limit, 
> mincount,missing,sort,prefix, facetSortOrder);
> Implementation Notes:
> I have noted in testing that I was not able to retrieve any '0' counts as I 
> had expected.
> I believe this could be because there appear to be some optimizations in 
> SimpleFacets/count caching such that zero counts are not iterated (at least 
> not by default)
> as a performance enhancement.
> I could be wrong about this, and zero counts may appear under some other as 
> yet untested circumstances. Perhaps an expert familiar with this part of the 
> code can clarify.
> In fact, this is not such a bad thing (at least for my requirements), as a 
> whole bunch of zero counts is not necessarily useful (for my requirements, 
> starting at '1' is just right).
>  
> There may, however, be instances where someone *will* want zero counts - e.g. 
> searching for zero product stock counts (e.g. 'what have we run out of'). I 
> was envisioning the facet.mincount field
> being the preferred place to set where the 'lowest value' begins (e.g. 0 or 1 
> or possibly higher), but because of the caching/optimization, the behaviour 
> is somewhat different than expected.



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

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

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12601 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls

Error Message:
Shard split did not complete. Last recorded state: running 
expected:<[completed]> but was:<[running]>

Stack Trace:
org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: 
running expected:<[completed]> but was:<[running]>
at 
__randomizedtesting.SeedInfo.seed([E0E9B997E726BCA7:B88D35F6E14C1473]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java: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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b12) - Build # 12775 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12775/
Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseSerialGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest

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

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


FAILED:  
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest.testMergeIndexesByCoreName

Error Message:
Test abandoned because suite timeout was reached.

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




Build Log:
[...truncated 11624 lines...]
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.MergeIndexesEmbeddedTest
 976BA2FE66231023-001/init-core-data-001
   [junit4]   2> 41424 T191 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2> 41426 T191 oas.SolrTestCaseJ4.setUp ###Starting 
testMergeIndexesByCoreName
   [junit4]   2> 41427 T191 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/'
   [junit4]   2> 41439 T191 oasc.SolrXmlConfig.fromFile Loading container 
configuration from 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/solr.xml
   [junit4]   2> 41450 T191 oasc.CorePropertiesLocator. Config-defined 
core root directory: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore
   [junit4]   2> 41451 T191 oasc.CoreContainer. New CoreContainer 2521533
   [junit4]   2> 41451 T191 oasc.CoreContainer.load Loading cores into 
CoreContainer 
[instanceDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/]
   [junit4]   2> 41452 T191 oasc.CoreContainer.load loading shared library: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/lib
   [junit4]   2> 41452 T191 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: lib (resolved as: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/lib).
   [junit4]   2> 41460 T191 oashc.HttpShardHandlerFactory.init created with 
socketTimeout : 60,connTimeout : 6,maxConnectionsPerHost : 
20,maxConnections : 1,corePoolSize : 0,maximumPoolSize : 
2147483647,maxThreadIdleTime : 5,sizeOfQueue : -1,fairnessPolicy : 
false,useRetries : false,
   [junit4]   2> 41464 T191 oasu.UpdateShardHandler. Creating 
UpdateShardHandler HTTP client with params: 
socketTimeout=60&connTimeout=6&retry=true
   [junit4]   2> 41465 T191 oasl.LogWatcher.createWatcher SLF4J impl is 
org.slf4j.impl.Log4jLoggerFactory
   [junit4]   2> 41465 T191 oasl.LogWatcher.newRegisteredLogWatcher Registering 
Log Listener [Log4j (org.slf4j.impl.Log4jLoggerFactory)]
   [junit4]   2> 41465 T191 oasc.CoreContainer.load Node Name: null
   [junit4]   2> 41466 T191 oasc.CoreContainer.initializeAuthenticationPlugin 
No authentication plugin used.
   [junit4]   2> 41466 T191 oasc.CorePropertiesLocator.discover Looking for 
core definitions underneath 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore
   [junit4]   2> 41468 T191 oasc.CoreDescriptor. CORE DESCRIPTOR: 
{name=core1, config=solrconfig.xml, 
instanceDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core1,
 loadOnStartup=true, 
absoluteInstDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core1/,
 schema=schema.xml, transient=false, dataDir=data/}
   [junit4]   2> 41468 T191 oasc.CorePropertiesLocator.discoverUnder Found core 
core1 in 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core1/
   [junit4]   2> 41469 T191 oasc.CoreDescriptor. CORE DESCRIPTOR: 
{name=core0, config=solrconfig.xml, 
instanceDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core0,
 loadOnStartup=true, 
absoluteInstDir=/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core0/,
 schema=schema.xml, transient=false, dataDir=data/}
   [junit4]   2> 41469 T191 oasc.CorePropertiesLocator.discoverUnder Found core 
core0 in 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/solrj/src/test-files/solrj/solr/multicore/core0/
   [junit4]   2> 41470 T191 oasc.CorePropertiesLocator.discover Found 2 core 
definitions
   [junit4]   2> 41473 T192 oasc.SolrR

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7465:


[~ehatcher] Don't bother. After I didn't see anything fail on Jenkins for 
hours.. I tried a fresh checkout and that seems to work fine.
False alarm!

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7465:


Hi [~ehatcher], seems like this broke the build. I'm not sure but I see a lot 
of 500s while running {{ant clean test}}

{code}
   [junit4] ERROR   14.5s J1 | DistributedSpellCheckComponentTest.test <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:61796//collection1: Expected mime type 
application/octet-stream but got text/html. 
   [junit4]> 
   [junit4]> 
   [junit4]> Error 500 
   [junit4]> 
   [junit4]> 
   [junit4]> HTTP ERROR: 500
   [junit4]> Problem accessing /collection1/update. Reason:
   [junit4]> java.lang.NoSuchFieldError: totalTermCount
   [junit4]> Powered by Jetty://
   [junit4]> 
   [junit4]> 
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([7E4E19F8673A0649:F61A2622C9C66BB1]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:529)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:896)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:859)
{code}

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

I beasted spans tests 100 times with the change after doing the usual checks.

Here is the command to restore that code to branch_5x (e.g. to make it easy to 
commit changes here):
{{branch_5x# svn merge -c -1680978 .}}

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[ASF subversion and git services (JIRA)]

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

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

Commit 1680978 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680978 ]

LUCENE-6371, LUCENE-6466: back out from 5.2, see 
https://issues.apache.org/jira/browse/LUCENE-6494

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (SOLR-7579) Angular admin UI core analysis screen field name/type dropdown issues

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7579:


Looking into this further to see if I spot any errors.  I do see 
"verboxe_output" as a likely typo ({code}$scope.verbose = 
params["verboxe_output"]=="1";{code}) but probably isn't related to this 
problem.  I do see errors in the network console that three *.min.js.map files 
are 404; this is an Angular source code thing that can be ignored though?

Not seeing any other errors in the loading of the page, though if I do try to 
select something from the narrow drop-down and analyze a string, I get this 
error: 
{code}
TypeError: Cannot read property 'join' of null
at getShortComponentName (analysis.js:74)
at mangle (analysis.js:119)
at processAnalysisData (analysis.js:133)
at analysis.js:163
at angular-resource.min.js:32
at processQueue (angular.js:13193)
at angular.js:13209
at Scope.$get.Scope.$eval (angular.js:14406)
at Scope.$get.Scope.$digest (angular.js:14222)
at Scope.$get.Scope.$apply (angular.js:14511)
{code}

> Angular admin UI core analysis screen field name/type dropdown issues
> -
>
> Key: SOLR-7579
> URL: https://issues.apache.org/jira/browse/SOLR-7579
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Erik Hatcher
>Assignee: Upayavira
> Fix For: 5.2
>
> Attachments: SOLR-7579-schema.json, screenshot-1.png
>
>
> field name/type drop-down too narrow and unusable



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

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

[jira] [Commented] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[ASF subversion and git services (JIRA)]

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

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

Commit 1680978 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680978 ]

LUCENE-6371, LUCENE-6466: back out from 5.2, see 
https://issues.apache.org/jira/browse/LUCENE-6494

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

[jira] [Commented] (LUCENE-6371) Improve Spans payload collection

[ASF subversion and git services (JIRA)]

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

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

Commit 1680978 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680978 ]

LUCENE-6371, LUCENE-6466: back out from 5.2, see 
https://issues.apache.org/jira/browse/LUCENE-6494

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Commented] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6466:
-

Also its wierd it only reproduces on java 7. Maybe some hash ordering issue?

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

[jira] [Reopened] (LUCENE-6371) Improve Spans payload collection

[Robert Muir (JIRA)]

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

Robert Muir reopened LUCENE-6371:
-

Reopening, see LUCENE-6494

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Updated] (LUCENE-6371) Improve Spans payload collection

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6371:

Fix Version/s: (was: 5.2)
   5.3
   Trunk

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Commented] (LUCENE-6490) TestPayloadNearQuery fails with NPE

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6490:
-

I marked this one 5.3, i dont think we need to reopen it, as there is already a 
better solution for this on LUCENE-6494

> TestPayloadNearQuery fails with NPE
> ---
>
> Key: LUCENE-6490
> URL: https://issues.apache.org/jira/browse/LUCENE-6490
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Alan Woodward
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6490.patch
>
>
> ant test  -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {noformat}
>[junit4] Started J0 PID(19895@localhost).
>[junit4] Suite: org.apache.lucene.search.payloads.TestPayloadNearQuery
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.09s | TestPayloadNearQuery.test <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([24743B1132665845:AC2004CB9C9A35BD]:0)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:353)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:382)
>[junit4]>  at 
> org.apache.lucene.search.payloads.TestPayloadNearQuery.test(TestPayloadNearQuery.java:144)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:665)
>[junit4]>  ... 39 more
>[junit4]> Caused by: java.lang.NullPointerException
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.processPayloads(PayloadNearQuery.java:202)
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.setFreqCurrentDoc(PayloadNearQuery.java:223)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.ensureFreq(SpanScorer.java:65)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.score(SpanScorer.java:118)
>[junit4]>  at 
> org.apache.lucene.search.AssertingScorer.score(AssertingScorer.java:67)
>[junit4]>  at 
> org.apache.lucene.search.TopScoreDocCollector$SimpleTopScoreDocCollector$1.collect(TopScoreDocCollector.java:64)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:57)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:203)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:174)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:714)
>[junit4]>  at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:656)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:653)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:265)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]   2> NOTE: test params are: 
> codec=FastDecompressionCompressingStored

[jira] [Updated] (LUCENE-6490) TestPayloadNearQuery fails with NPE

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6490:

Fix Version/s: 5.3
   Trunk

> TestPayloadNearQuery fails with NPE
> ---
>
> Key: LUCENE-6490
> URL: https://issues.apache.org/jira/browse/LUCENE-6490
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Alan Woodward
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6490.patch
>
>
> ant test  -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {noformat}
>[junit4] Started J0 PID(19895@localhost).
>[junit4] Suite: org.apache.lucene.search.payloads.TestPayloadNearQuery
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.09s | TestPayloadNearQuery.test <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([24743B1132665845:AC2004CB9C9A35BD]:0)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:353)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:382)
>[junit4]>  at 
> org.apache.lucene.search.payloads.TestPayloadNearQuery.test(TestPayloadNearQuery.java:144)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:665)
>[junit4]>  ... 39 more
>[junit4]> Caused by: java.lang.NullPointerException
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.processPayloads(PayloadNearQuery.java:202)
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.setFreqCurrentDoc(PayloadNearQuery.java:223)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.ensureFreq(SpanScorer.java:65)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.score(SpanScorer.java:118)
>[junit4]>  at 
> org.apache.lucene.search.AssertingScorer.score(AssertingScorer.java:67)
>[junit4]>  at 
> org.apache.lucene.search.TopScoreDocCollector$SimpleTopScoreDocCollector$1.collect(TopScoreDocCollector.java:64)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:57)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:203)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:174)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:714)
>[junit4]>  at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:656)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:653)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:265)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]   2> NOTE: test params are: 
> codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=FAST_DECOMPRESSION,
>  chunkSize=25825, maxDocsPerChunk=709

[jira] [Reopened] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[Robert Muir (JIRA)]

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

Robert Muir reopened LUCENE-6466:
-

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

[jira] [Updated] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6466:

Fix Version/s: Trunk
   5.3

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Fix For: Trunk, 5.3
>
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

[jira] [Commented] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6466:
-

I tried looking into this patch to see why it causes test failures with scoring 
changes (https://issues.apache.org/jira/browse/LUCENE-6495), but its hard to 
see with the indentation changes from various code being shuffled around. 

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-7465:


Basically done enough for 5.2, but going to leave this ticket open until 5.2 is 
done as I think we will fiddle with config and /browse UI bits until the final 
release is cut.

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

Thanks [~rcmuir]. Looks good to me. I'll be creating the branch and bumping the 
revision late tonight.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[ASF subversion and git services (JIRA)]

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

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

Commit 1680977 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680977 ]

SOLR-7465: New file indexing example, under example/files

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[ASF subversion and git services (JIRA)]

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

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

Commit 1680976 from [~ehatcher] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680976 ]

SOLR-7465: New file indexing example, under example/files

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

here is my proposed command:

{{branch_5x# svn merge -c -1680607 -c -1680604 -c -1680569 -c -1680514 -c 
-1680208 -c -1680220 .}}

Tests and both failing seeds from LUCENE-6495 pass after this.

After [~anshumg] creates a 5.2 branch and switches branch_5x to 5.3, we can use 
one command to restore everything. But i would prefer if we do not actually 
commit that until LUCENE-6495 has been looked into. Something is not right that 
scoring has changed.


> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6495) TestBasics and TestSpanExplanations branch5x failures

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6495:
-

Both of these test failures are from LUCENE-6466.

> TestBasics and TestSpanExplanations branch5x failures
> -
>
> Key: LUCENE-6495
> URL: https://issues.apache.org/jira/browse/LUCENE-6495
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> I'm seeing these recent failures on branch 5x:
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3159/
> https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3158/
> They reproduce on java 7, but not on java 8. I will try to track down at 
> least which change started triggering the failures.



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

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

[jira] [Commented] (SOLR-7465) Flesh out solr/example/files

[ASF subversion and git services (JIRA)]

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

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

Commit 1680973 from [~ehatcher] in branch 'dev/trunk'
[ https://svn.apache.org/r1680973 ]

SOLR-7465: New file indexing example, under example/files

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

Possibly related: https://issues.apache.org/jira/browse/LUCENE-6495

I want to get tests stable here too so I will investigate.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Created] (LUCENE-6495) TestBasics and TestSpanExplanations branch5x failures

[Robert Muir (JIRA)]

Robert Muir created LUCENE-6495:
---

 Summary: TestBasics and TestSpanExplanations branch5x failures
 Key: LUCENE-6495
 URL: https://issues.apache.org/jira/browse/LUCENE-6495
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


I'm seeing these recent failures on branch 5x:

https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3159/
https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3158/

They reproduce on java 7, but not on java 8. I will try to track down at least 
which change started triggering the failures.



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

OK with me, give me some time and I'll straighten it out.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 4716 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4716/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
Some resources were not closed, shutdown, or released.

Stack Trace:
java.lang.AssertionError: Some resources were not closed, shutdown, or released.
at __randomizedtesting.SeedInfo.seed([AFC1F4C965F8BAFE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:234)
at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java: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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog\tlog.000:
 java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog\tlog.000:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data\tlog

C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2\data

C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1F4C965F8BAFE-001\shard-3-001\cores\c8n_1x2_leader_session_loss_shard1_replica2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 
AFC1

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

[~rcmuir] if you have time, can you handle reverting the changes? If not, I'll 
do it.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3159 - Still Failing

[Apache Jenkins Server]

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

7 tests failed.
REGRESSION:  org.apache.lucene.search.spans.TestSpanExplanations.testSNear7

Error Message:
score=1093.4878, scorerScore=1093.4879

Stack Trace:
junit.framework.AssertionFailedError: score=1093.4878, scorerScore=1093.4879
at 
__randomizedtesting.SeedInfo.seed([F215753CE99A9BAD:271FFA1A02E38AA3]:0)
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at org.apache.lucene.search.QueryUtils$3.collect(QueryUtils.java:371)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:57)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:205)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:63)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:714)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:428)
at org.apache.lucene.search.QueryUtils.checkSkipTo(QueryUtils.java:335)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:129)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:132)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:122)
at 
org.apache.lucene.search.CheckHits.checkHitCollector(CheckHits.java:99)
at 
org.apache.lucene.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:100)
at 
org.apache.lucene.search.spans.TestSpanExplanations.testSNear7(TestSpanExplanations.java:125)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:3

[jira] [Comment Edited] (SOLR-7584) Add Joins to the Streaming API and Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-7584 at 5/22/15 12:27 AM:
-

Adds abstract JoinStream to support joins of N sub-streams.
Adds abstract BiJoinStream to limit JoinStream to 2 sub-streams, left and right.
Adds concrete InnerJoinStream with support for merge join.

Does not handle hash joins.
Uses aliasing concept already available in CloudSolrStream.

Still work to be done.


was (Author: dpgove):
Adds JoinStream to support joins of N sub-streams.
Adds BiJoinStream to limit JoinStream to 2 sub-streams, left and right.
Adds InnerJoinStream with support for merge join.

Does not handle hash joins.
Uses aliasing concept already available in CloudSolrStream.

Still work to be done.

> Add Joins to the Streaming API and Streaming Expressions
> 
>
> Key: SOLR-7584
> URL: https://issues.apache.org/jira/browse/SOLR-7584
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: Streaming
> Attachments: SOLR-7584.patch
>
>
> Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
> Streaming API to allow for joining between sub-streams.
> At its basic, it would look something like this
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA"
> )
> {code}
> or with multi-field on clauses
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA, fieldB=fieldD"
> )
> {code}
> I'd also like to support the option of doing a hash join instead of the 
> default merge join but I haven't yet figured out the best way to express 
> that. I'd like to let the user tell us which sub-stream should be hashed (the 
> least-cost one).
> Also, I've been thinking about field aliasing and might want to add a 
> SelectStream which serves the purpose of allowing us to limit the fields 
> coming out and rename fields.
> Depends on SOLR-7554



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

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

[jira] [Updated] (SOLR-7584) Add Joins to the Streaming API and Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-7584:
--
Attachment: SOLR-7584.patch

Adds JoinStream to support joins of N sub-streams.
Adds BiJoinStream to limit JoinStream to 2 sub-streams, left and right.
Adds InnerJoinStream with support for merge join.

Does not handle hash joins.
Uses aliasing concept already available in CloudSolrStream.

Still work to be done.

> Add Joins to the Streaming API and Streaming Expressions
> 
>
> Key: SOLR-7584
> URL: https://issues.apache.org/jira/browse/SOLR-7584
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: Streaming
> Attachments: SOLR-7584.patch
>
>
> Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
> Streaming API to allow for joining between sub-streams.
> At its basic, it would look something like this
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA"
> )
> {code}
> or with multi-field on clauses
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA, fieldB=fieldD"
> )
> {code}
> I'd also like to support the option of doing a hash join instead of the 
> default merge join but I haven't yet figured out the best way to express 
> that. I'd like to let the user tell us which sub-stream should be hashed (the 
> least-cost one).
> Also, I've been thinking about field aliasing and might want to add a 
> SelectStream which serves the purpose of allowing us to limit the fields 
> coming out and rename fields.
> Depends on SOLR-7554



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

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

Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Brian Burkhalter]

Hi Uwe,

You’re welcome!

Brian

On May 21, 2015, at 4:45 PM, Uwe Schindler  wrote:

> Hi Brian,
>  
> the patch looks fine to me! Many thanks.
>  
> Uwe
>  
> -
> Uwe Schindler
> uschind...@apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

Seems like we'd also need to revert LUCENE-6466.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

Re: Configsets and Config APIs in Solr

[Gregory Chanan]

I'm +1 on the general idea, but I'm not convinced about the
mutable/immutable separation.

Do we not think it is valid to modify a single config(set) that affects
multiple collections?  I can imagine a case where my data with the same
config(set) is partitioned into many different collections, whether by
date, sorted order, etc. that all use the same underlying config(set).
Let's say I have collections partitioned by month and I decide I want to
add another field; I don't want to have to modify
jan/schema
feb/schema
mar/schema
etc.

I just want to modify the single underlying config(set).  You can imagine
having a configset API that let's me do that, so if I wanted to modify a
single collection's config I would call:
jan/schema
but if i wanted to modify the underlying config(set) I would call:
configset/month_partitioned_config

My point is this: if the problem is that it is confusing to have configsets
modified when you make collection-level calls, then we should fix that (I'm
100% in agreement with that, btw).  You can fix that by having a configset
and a per-collection diff; defining the configset as immutable doesn't
solve the problem, only locks us into a implementation that doesn't support
the use case above.  I'm not even saying we should implement a configset
API, only that defining this as an immutable vs mutable implementation
blocks us from doing that.

TLDR: we should think about this as configset base vs per-collection diff,
not as immutable base vs per-collection mutable.

Thoughts?
Greg


On Tue, May 19, 2015 at 10:52 AM, Tomás Fernández Löbbe <
tomasflo...@gmail.com> wrote:

> I created https://issues.apache.org/jira/browse/SOLR-7570
>
> On Fri, May 15, 2015 at 10:31 AM, Alan Woodward  wrote:
>
>> +1
>>
>> A nice way of doing it would be to make it part of the SolrResourceLoader
>> interface.  The ZK resource loader could check in the collection-specific
>> zknode first, and then under configs/, and we could add a writeResource()
>> method that writes to the collection-specific node as well.  Then all
>> config I/O goes via the resource loader, and we have a way of keeping
>> certain parts immutable.
>>
>> On 15 May 2015, at 17:39, Tomás Fernández Löbbe 
>> wrote:
>>
>> I agree about differentiating the mutable part (configoverlay, generated
>> schema, etc) and the immutable (the configset) , but I think it would be
>> better if the mutable part is placed under /collections/x/..., otherwise
>> "/configs" would have a mix of ConfigSets and collection-specific
>> configuration.
>>
>> On Fri, May 15, 2015 at 6:38 AM, Noble Paul  wrote:
>>
>>> I think this needs more discussion
>>>
>>> When a collection is created we should have two things
>>>
>>> an immutable part and a mutable part
>>>
>>> for instance my collection name is "x" and it uses schemaless example
>>> conf
>>>
>>> I must now have two conf dirs
>>>
>>> configs/schemaless and
>>> configs/x
>>>
>>> all the mutable stuff goes to configs/x
>>>
>>> and config/schemaless remains immutable
>>>
>>>
>>>
>>> On Tue, May 12, 2015 at 2:23 AM, Tomás Fernández Löbbe <
>>> tomasflo...@gmail.com> wrote:
>>>
 I think this is fine.I don't think we need a new concept of "config
 templates", we just need to make it clear that the configset used to create
 the collection is not modified by Solr, and that any change done via API
 only affects the single collection where the config command is issued.

 I guess the schema API should start using something like configoverlay,
 or maybe persist the updated schema to this new path?

 Tomás

 On Fri, May 8, 2015 at 10:28 PM, Noble Paul 
 wrote:

> I agree with you on the point that it causes confusion.
>
> My suggestion would be to have something called "config templates" and
> they are immutable . So , we don't need a configset API
> each collection have it's own conf folder .
>
> So, when a collection is created we should go ahead and create a
> corresponding conf dir.
>
> Ideally, it should not copy over all configs from it's template. It
> should just store the configoverlay.json, params.json in the collection's
> conf directory and inherit the rest from the template
>
>
>
>
>
> On Sat, May 9, 2015 at 9:35 AM, Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> I think the concept of ConfigSets has become a bit confusing with the
>> Config APIs (I'm thinking in SolrCloud mode here). Solr requires that a
>> configset is pushed to ZooKeeper before creating a collection that uses 
>> it.
>> It supports multiple collections using the same configset, which I think 
>> is
>> great. You could also have a couple of configsets that no collection is
>> currently using (who knows, maybe one that was recently deprecated, or 
>> that
>> will be used soon, etc). This gives me the idea that configsets are a
>> separate entity than the colle

[jira] [Updated] (SOLR-7584) Add Joins to the Streaming API and Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-7584:
--
Description: 
Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
Streaming API to allow for joining between sub-streams.

At its basic, it would look something like this
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA"
)
{code}
or with multi-field on clauses
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA, fieldB=fieldD"
)
{code}

I'd also like to support the option of doing a hash join instead of the default 
merge join but I haven't yet figured out the best way to express that. I'd like 
to let the user tell us which sub-stream should be hashed (the least-cost one).

Also, I've been thinking about field aliasing and might want to add a 
SelectStream which serves the purpose of allowing us to limit the fields coming 
out and rename fields.

Depends on SOLR-7554

  was:
Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
Streaming API to allow for joining between sub-streams.

At its basic, it would look something like this
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA"
)
{code}
or with multi-field on clauses
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA, fieldB=fieldD"
)
{code}

I'd also like to support the option of doing a hash join instead of the default 
merge join but I haven't yet figured out the best way to express that. I'd like 
to let the user tell us which sub-stream should be hashed (the least-cost one).

Also, I've been thinking about field aliasing and might want to add a 
SelectStream which serves the purpose of allowing us to limit the fields coming 
out and rename fields.


> Add Joins to the Streaming API and Streaming Expressions
> 
>
> Key: SOLR-7584
> URL: https://issues.apache.org/jira/browse/SOLR-7584
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: Streaming
>
> Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
> Streaming API to allow for joining between sub-streams.
> At its basic, it would look something like this
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA"
> )
> {code}
> or with multi-field on clauses
> {code}
> innerJoin(
>   search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
>   search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
>   on="fieldA=fieldA, fieldB=fieldD"
> )
> {code}
> I'd also like to support the option of doing a hash join instead of the 
> default merge join but I haven't yet figured out the best way to express 
> that. I'd like to let the user tell us which sub-stream should be hashed (the 
> least-cost one).
> Also, I've been thinking about field aliasing and might want to add a 
> SelectStream which serves the purpose of allowing us to limit the fields 
> coming out and rename fields.
> Depends on SOLR-7554



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

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

[jira] [Commented] (LUCENE-6371) Improve Spans payload collection

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6371:
--

I'll revert r1680208 and r1680220 from branch_5x and change the fix version to 
5.3 for this.

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 5.2
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Created] (SOLR-7584) Add Joins to the Streaming API and Streaming Expressions

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-7584:
-

 Summary: Add Joins to the Streaming API and Streaming Expressions
 Key: SOLR-7584
 URL: https://issues.apache.org/jira/browse/SOLR-7584
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Reporter: Dennis Gove
Priority: Minor


Add InnerJoinStream, LeftOuterJoinStream, and supporting classes to the 
Streaming API to allow for joining between sub-streams.

At its basic, it would look something like this
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA"
)
{code}
or with multi-field on clauses
{code}
innerJoin(
  search(collection1, q=*:*, fl="fieldA, fieldB, fieldC", ...),
  search(collection2, q=*:*, fl="fieldA, fieldD, fieldE", ...),
  on="fieldA=fieldA, fieldB=fieldD"
)
{code}

I'd also like to support the option of doing a hash join instead of the default 
merge join but I haven't yet figured out the best way to express that. I'd like 
to let the user tell us which sub-stream should be hashed (the least-cost one).

Also, I've been thinking about field aliasing and might want to add a 
SelectStream which serves the purpose of allowing us to limit the fields coming 
out and rename fields.



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

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

[jira] [Commented] (LUCENE-6490) TestPayloadNearQuery fails with NPE

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6490:
--

I'll revert r1680514 from branch_5x and change the fix version on this to be 
5.3.

> TestPayloadNearQuery fails with NPE
> ---
>
> Key: LUCENE-6490
> URL: https://issues.apache.org/jira/browse/LUCENE-6490
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Alan Woodward
> Attachments: LUCENE-6490.patch
>
>
> ant test  -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {noformat}
>[junit4] Started J0 PID(19895@localhost).
>[junit4] Suite: org.apache.lucene.search.payloads.TestPayloadNearQuery
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestPayloadNearQuery -Dtests.method=test 
> -Dtests.seed=24743B1132665845 -Dtests.slow=true -Dtests.locale=es_NI 
> -Dtests.timezone=Israel -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] ERROR   0.09s | TestPayloadNearQuery.test <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([24743B1132665845:AC2004CB9C9A35BD]:0)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:353)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:382)
>[junit4]>  at 
> org.apache.lucene.search.payloads.TestPayloadNearQuery.test(TestPayloadNearQuery.java:144)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.util.concurrent.ExecutionException: 
> java.lang.NullPointerException
>[junit4]>  at 
> java.util.concurrent.FutureTask.report(FutureTask.java:122)
>[junit4]>  at 
> java.util.concurrent.FutureTask.get(FutureTask.java:192)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:665)
>[junit4]>  ... 39 more
>[junit4]> Caused by: java.lang.NullPointerException
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.processPayloads(PayloadNearQuery.java:202)
>[junit4]>  at 
> org.apache.lucene.search.payloads.PayloadNearQuery$PayloadNearSpanScorer.setFreqCurrentDoc(PayloadNearQuery.java:223)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.ensureFreq(SpanScorer.java:65)
>[junit4]>  at 
> org.apache.lucene.search.spans.SpanScorer.score(SpanScorer.java:118)
>[junit4]>  at 
> org.apache.lucene.search.AssertingScorer.score(AssertingScorer.java:67)
>[junit4]>  at 
> org.apache.lucene.search.TopScoreDocCollector$SimpleTopScoreDocCollector$1.collect(TopScoreDocCollector.java:64)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:57)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:203)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:174)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:714)
>[junit4]>  at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:656)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher$4.call(IndexSearcher.java:653)
>[junit4]>  at 
> java.util.concurrent.FutureTask.run(FutureTask.java:265)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>[junit4]>  at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>[junit4]>  ... 1 more
>[junit4]   2> NOTE: test params are: 
> codec=FastDecompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=

[jira] [Commented] (LUCENE-6466) Move SpanQuery.getSpans() to SpanWeight

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6466:
-

Do we really need to expose SpanSimilarity as a separate class here? I find it 
confusing (e.g. no-op method that returns a null scorer), and its a lot of 
plumbing. I think instead of this class, there could just be a final method on 
SpanWeight base-class, to retrieve the appropriate Similarity, and impls of 
normalization and so on like any other Weights.

> Move SpanQuery.getSpans() to SpanWeight
> ---
>
> Key: LUCENE-6466
> URL: https://issues.apache.org/jira/browse/LUCENE-6466
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-6466.patch, LUCENE-6466.patch, LUCENE-6466.patch, 
> LUCENE-6466.patch, LUCENE-6466.patch
>
>
> SpanQuery.getSpans() should only be called on rewritten queries, so it seems 
> to make more sense to have this being called from SpanWeight



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

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

RE: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Uwe Schindler]

Hi Brian,

 

the patch looks fine to me! Many thanks.

 

Uwe

 

-

Uwe Schindler

uschind...@apache.org 

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany

http://lucene.apache.org/

 

From: Brian Burkhalter [mailto:brian.burkhal...@oracle.com] 
Sent: Thursday, May 21, 2015 7:32 PM
To: nio-dev
Cc: dev@lucene.apache.org; rory.odonn...@oracle.com; Balchandra Vaidya; Robert 
Muir
Subject: Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

 

Status update …

 

On May 18, 2015, at 12:04 PM, Brian Burkhalter  
wrote:





2. Work on a fix for   
https://bugs.openjdk.java.net/browse/JDK-8080589, (fc) FileChannel.force should 
use fcntl(F_FULLFSYNC) instead of fsync on OS X.

 

Please note that this patch has been pushed:

 

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e08b856baa26

 

Brian

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_45) - Build # 4839 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4839/
Java: 32bit/jdk1.8.0_45 -server -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.schema.DateRangeFieldTest.test

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.DateRangeFieldTest

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

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




Build Log:
[...truncated 10605 lines...]
   [junit4] Suite: org.apache.solr.schema.DateRangeFieldTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.schema.DateRangeFieldTest
 4424EACF98CF0408-001\init-core-data-001
   [junit4]   2> 64016 T433 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2> 64016 T433 oas.SolrTestCaseJ4.initCore initCore
   [junit4]   2> 64017 T433 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\'
   [junit4]   2> 64019 T433 oasc.SolrResourceLoader.replaceClassLoader Adding 
'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/core/src/test-files/solr/collection1/lib/classes/'
 to classloader
   [junit4]   2> 64019 T433 oasc.SolrResourceLoader.replaceClassLoader Adding 
'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/core/src/test-files/solr/collection1/lib/README'
 to classloader
   [junit4]   2> 64063 T433 oasc.SolrConfig.refreshRequestParams current 
version of requestparams : -1
   [junit4]   2> 64078 T433 oasc.SolrConfig. Using Lucene MatchVersion: 
6.0.0
   [junit4]   2> 64125 T433 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig.xml
   [junit4]   2> 64125 T433 oass.IndexSchema.readSchema Reading Solr Schema 
from 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
   [junit4]   2> 64132 T433 oass.IndexSchema.readSchema [null] Schema name=test
   [junit4]   2> 64352 T433 oass.OpenExchangeRatesOrgProvider.init Initialized 
with rates=open-exchange-rates.json, refreshInterval=1440.
   [junit4]   2> 64365 T433 oass.IndexSchema.readSchema default search field in 
schema is text
   [junit4]   2> 64368 T433 oass.IndexSchema.readSchema unique key field: id
   [junit4]   2> 64378 T433 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2> 64384 T433 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2> 64387 T433 oass.OpenExchangeRatesOrgProvider.reload Reloading 
exchange rates from open-exchange-rates.json
   [junit4]   2> 64387 T433 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2> 64388 T433 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Expected key, 
got STRING
   [junit4]   2> 64389 T433 oass.OpenExchangeRatesOrgProvider.reload Reloading 
exchange rates from open-exchange-rates.json
   [junit4]   2> 64389 T433 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2> 64390 T433 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Expected key, 
got STRING
   [junit4]   2> 64390 T433 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2> 64390 T433 oasc.SolrResourceLoader.locateSolrHome using system 
property solr.solr.home: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr
   [junit4]   2> 64390 T433 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\'
   [junit4]   2> 64404 T433 oasc.CoreContainer. New CoreContainer 8513751
   [junit4]   2> 64405 T433 oasc.CoreContainer.load Loading cores into 
CoreContainer 
[instanceDir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\]
   [junit4]   2> 64405 T433 oasc.CoreContainer.load loading shared library: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\lib
   [junit4]   2> 64405 T433 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: lib (resolved as: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\lib).
   [junit4]   2> 64415 T433 oashc.HttpShardHandlerFactory.init created with 
socketTimeout : 60,connTimeout : 6,maxConnectionsPerHost : 
20,maxConnections : 1,corePoolSize : 0,maximumPoolSize : 
2147483647,maxThreadIdleTime : 

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

yes, lets leave trunk alone and work out the kinks here.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

Sure, I can revert this. Shouldn't we just revert it from 5x instead and 
iterate on trunk instead?

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-6494:
---

bq. I personally think it makes sense for this to not be a blocker for 5.2 and 
shipping this with 5.3 instead. Do you think that makes sense?
+1

I'm not sure I'll have svn access for the next couple of days, will you be able 
to back this out of the 5.2 branch Anshum?  If not, I can probably get to it on 
Monday UK time (so before the release).

Regarding Rob's concerns:
* javadocs and commented out code I can sort out asap, the API sort of kept 
changing every time I typed this afternoon so I didn't get round to getting 
this into precommit-passing shape.
* I'll replace the no-op collector with null checks, that's a leftover from the 
generics stuff
* MatchDataIterator and MatchDataCollector can be moved to the highlighter 
package, I think (or sandbox initially, but the idea is to eventually build a 
highlighter from them)
* I'll add stuff to AssertingSpans to enforce the contracts
* I think the boolean works best ('enablePositionCollection' maybe?) - will see 
what works

Sorry about the timing here, I don't want to mess the release of 5.2 up!

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6494:


+1 to make the recent span improvements in 5.3 instead!

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Comment Edited] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir edited comment on LUCENE-6494 at 5/21/15 11:08 PM:
---

I think what is in branch_5x (LUCENE-6371 and LUCENE-6490) should not be 
released in its current state. 

All of this was added in the last 2 days and I think its too close to the 
release.

IMO this patch simplifies things a lot. But this patch needs maybe 2 or 3 days 
work, and a few weeks baking (maybe with followup issues/improvements) and it 
would be really good. 

A 5.3 doesn't have to be months after a 5.2...

edit: trunk->branch_5x because we can just iterate from trunk (we have a patch 
here doing just exactly that), my concerns are only about the release.


was (Author: rcmuir):
I think what is in trunk (LUCENE-6371 and LUCENE-6490) should not be released 
in its current state. 

All of this was added in the last 2 days and I think its too close to the 
release.

IMO this patch simplifies things a lot. But this patch needs maybe 2 or 3 days 
work, and a few weeks baking (maybe with followup issues/improvements) and it 
would be really good. 

A 5.3 doesn't have to be months after a 5.2...


> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

I think what is in trunk (LUCENE-6371 and LUCENE-6490) should not be released 
in its current state. 

All of this was added in the last 2 days and I think its too close to the 
release.

IMO this patch simplifies things a lot. But this patch needs maybe 2 or 3 days 
work, and a few weeks baking (maybe with followup issues/improvements) and it 
would be really good. 

A 5.3 doesn't have to be months after a 5.2...


> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

bq. From my perspective that would be ideal, because it would give time to 
evolve the api properly.
Hold it back and release it with 5.3? If you think it's invasive and needs 
time, that should be the case. To me it looks like that but I'd let you take a 
call on that as you understand it better.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (SOLR-7468) Kerberos authentication module

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7468:


Both me and Ishan have spent more than some time trying to fix this. The test 
passes by itself (with the same seed). We also tried comparing the System props 
that are set at the start of this test in both the cases and there wasn't 
anything that stood out other than {{-flush}} being adding during the 
standalone run to the {{sun.java.command}} property. I intend to add a 
@SuppressSSL to this test now and document it.

> Kerberos authentication module
> --
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Ishan Chattopadhyaya
>Assignee: Anshum Gupta
> Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue 
> provides a Kerberos plugin implementation.



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

>From my perspective that would be ideal, because it would give time to evolve 
>the api properly. 

So to me that just means backing out LUCENE-6371 and LUCENE-6490 from 5.2 
(because everything is already completely rewritten and better here, and this 
has all been all right-before-a-release IMO).

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-6494:
--

I didn't really look at the patch but it seems a rather big patch that evolved 
in a few hours. I personally think it makes sense for this to not be a blocker 
for 5.2 and shipping this with 5.3 instead. Do you think that makes sense?

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6371) Improve Spans payload collection

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6371:
-

Adrien, I have similar concerns. Actually Alan cleaned things up quite a bit on 
LUCENE-6494, so I left my comments there.

I think it should either be a blocker, or we back out this change from just the 
5.x branch and do it for 5.3 so it has time to iterate and get better. 

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 5.2
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6494:
-

First of all: thank you very much for simplifying the APIs like you did!

And the idea is good, for many reasons. I still think our 
Collection-collecting payload queries should get out of town and be 
moved to sandbox. This is a good step towards allowing some of the crazier 
stuff to be e.g. refactored out of lucene-core and I really like that. And i 
like a different api for the "expert stuff" (payloads and offsets) because it 
still gives us a chance to look at cleanly integrating spans with other queries 
in the future. 

I am just super-worried about timing and stability.

There is a lot to do it seems, when i look at it, can we please mark this issue 
a blocker? Timing is not good here because [~anshumg] is planning to build a 
release.

* TermSpans still has commented out payload handling code.
* In NearSpansOrdered, I don't understand why we are doing various 
calculations, when you are not using the API (The no-op buffered stuff). Why 
not just have a null-check instead of that?
* There should be javadocs (e.g. explaining various integer parameters like 
requiredPostings)
* Should MatchDataIterator and MatchDataCollector really need to be in core 
lucene? (fwiw, i dont know how that PayloadSpanUtil survived so long).
* What is the semantics of Spans.collect(SpanCollector) in terms of lifecycle? 
I mean, i assume it shouldnt be called when doc = NO_MORE_DOCS, or when doc = 
-1, and so forth. And I also assume it shouldnt be called when position = -1 or 
position = NO_MORE_POSITIONS.  Ideally these rules are not just in the javadoc 
but also encoded in the state machine of AssertingSpans.
* I don't like 'requiredPostings' as the way this API is "enabled" in 
createWeight. There are two use-cases, expert payload use-cases, and retrieving 
offsets for e.g. highlighting. But as you see from NearSpansOrdered, these use 
cases can interfere with scoring algorithms. So I think its important that the 
use of this API is explicit, up-front, so it won't hinder scoring algorithms. 
Can we have a boolean instead that is more explicit ("expert proximity mode" or 
whatever we can come up with)? Alternatively a different-named method instead 
of createWeight, like createDebuggingWeight or whatever you want. Basically its 
kinda like explain() to me, except its still a per-segment search and not dog 
slow.


> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6371) Improve Spans payload collection

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6371:
--

I was just trying to update some Spans code and had some compile errors because 
of this new span collection API. Nothing bad so far but this made me read more 
about the new APIs and I'm a bit worried about the introduced complexity 
(SpanCollector, buffer(), bufferedCollector(), etc.). Maybe that's just me not 
being familiar enough with spans but is the introduced complexity worth the 
improvements? I have not looked into details yet but if we need more complex 
handling for only some queries maybe this should move to sandbox as suggested 
above to keep at least core simple?

> Improve Spans payload collection
> 
>
> Key: LUCENE-6371
> URL: https://issues.apache.org/jira/browse/LUCENE-6371
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 5.2
>
> Attachments: LUCENE-6371.patch, LUCENE-6371.patch, LUCENE-6371.patch
>
>
> Spin off from LUCENE-6308, see the comments there from around 23 March 2015.



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

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

[jira] [Commented] (SOLR-7581) Function 'sub' can return invalid date subtraction due to long/float conversion and precision loss

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7581:
--

Please close this JIRA if that fixes your problem...



> Function 'sub' can return invalid date subtraction due to long/float 
> conversion and precision loss
> --
>
> Key: SOLR-7581
> URL: https://issues.apache.org/jira/browse/SOLR-7581
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.1
> Environment: Linux-x64
>Reporter: Gene Sawyer
>Priority: Minor
> Attachments: functionquery_subtraction_bug.png
>
>
> Use of Function 'sub' to determine millis difference between two 
> TrieDateFields returns invalid value.  The determined value appears to be the 
> same, regardless of the true delta in the TrieDates



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

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

[jira] [Created] (SOLR-7583) API to download a snapshot by name

[Greg Solovyev (JIRA)]

Greg Solovyev created SOLR-7583:
---

 Summary: API to download a snapshot by name
 Key: SOLR-7583
 URL: https://issues.apache.org/jira/browse/SOLR-7583
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Greg Solovyev


What we are looking for:
SolrCloud and Solr should have APIs to download a snapshot via HTTP. 
For single node Solr, this API will find a snapshot and stream it back over 
HTTP. For SolrCloud, this API will find a Replica that has the snapshot with 
requested name and stream the snapshot from that replica. Since there are 
multiple files inside a snapshot, the API should probably zip the snapshot 
folder before sending it back to the client.

Why we need this:
this will allow us to create and fetch fully contained archives of customer 
data where each backup archive will contain Solr index as well as other 
customer data (DB, metadata, files, etc).



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

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

TermsQuery in ‘join’ module redundant?

[david.w.smi...@gmail.com]

Today I noticed org.apache.lucene.search.join.TermsQuery (package access)
in the join module that is functionally equivalent to one by the same name
in the queries module.  It may be a bit historical since the one in the
queries module until recently was a Filter, not a Query.  But now there is
redundancy.  Based on recent changes in Lucene 5.2 done by Adrien to
TermsQuery; I suspect both implementations would perform about the same.
Thus, I think the one in the ‘join’ module should be deleted.

Note the ‘join’ module does not yet depends on the ‘queries’ module. I
think the TermsQuery is of such broad general utility that it should go
into Lucene core.

~ David

Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Dawid Weiss]

On this note it'd be great if you guys could at least revisit the
subject of some kind of open feedback from the bug tracker -- just a
way to subscribe to updates ("watch") on a particular issue would be
awesome.

Dawid

On Thu, May 21, 2015 at 9:55 PM, Brian Burkhalter
 wrote:
>
> On May 21, 2015, at 12:54 PM, Robert Muir  wrote:
>
> Please note that this patch has been pushed:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e08b856baa26
>
>
> I just tested this with lucene's test suite without any issues.
>
>
> Fantastic! Thanks for the testing corroboration: that is very good to know.

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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3158 - Failure

[Apache Jenkins Server]

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

2 tests failed.
REGRESSION:  org.apache.lucene.search.spans.TestBasics.testSpanExactNested

Error Message:
score=166.45572, scorerScore=166.45573

Stack Trace:
junit.framework.AssertionFailedError: score=166.45572, scorerScore=166.45573
at 
__randomizedtesting.SeedInfo.seed([CABA90B3633EE756:51E85AF4332AA7E4]:0)
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at org.apache.lucene.search.QueryUtils$3.collect(QueryUtils.java:371)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:57)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:53)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:205)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:63)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:714)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:93)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:428)
at org.apache.lucene.search.QueryUtils.checkSkipTo(QueryUtils.java:335)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:129)
at org.apache.lucene.search.CheckHits.checkHits(CheckHits.java:184)
at 
org.apache.lucene.search.spans.TestBasics.checkHits(TestBasics.java:408)
at 
org.apache.lucene.search.spans.TestBasics.testSpanExactNested(TestBasics.java:370)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java: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.evalua

[jira] [Resolved] (LUCENE-6360) TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when there are few terms

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6360.
--
   Resolution: Fixed
Fix Version/s: 5.2
   Trunk

Thanks again David!

> TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when 
> there are few terms
> --
>
> Key: LUCENE-6360
> URL: https://issues.apache.org/jira/browse/LUCENE-6360
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6360.patch, LUCENE-6360.patch, LUCENE-6360.patch
>
>
> TermsQuery helps when there are lot of terms from which you would like to 
> compute the union, but it is a bit harmful when you have few terms since it 
> cannot really skip: it always consumes all documents matching the underlying 
> terms.
> It would certainly help to rewrite this query to a ConstantScoreQuery over a 
> BooleanQuery when there are few terms in order to have actual skip support.
> As usual the hard part is probably to figure out the threshold. :)



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

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

[jira] [Commented] (LUCENE-6360) TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when there are few terms

[ASF subversion and git services (JIRA)]

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

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

Commit 1680948 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680948 ]

LUCENE-6360: Make TermsQuery rewrite as a disjunction when there are few terms.

> TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when 
> there are few terms
> --
>
> Key: LUCENE-6360
> URL: https://issues.apache.org/jira/browse/LUCENE-6360
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6360.patch, LUCENE-6360.patch, LUCENE-6360.patch
>
>
> TermsQuery helps when there are lot of terms from which you would like to 
> compute the union, but it is a bit harmful when you have few terms since it 
> cannot really skip: it always consumes all documents matching the underlying 
> terms.
> It would certainly help to rewrite this query to a ConstantScoreQuery over a 
> BooleanQuery when there are few terms in order to have actual skip support.
> As usual the hard part is probably to figure out the threshold. :)



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

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

[jira] [Created] (SOLR-7582) The SolrCloud example (bin/solr -e cloud) should have soft auto-commits enabled by default.

[Timothy Potter (JIRA)]

Timothy Potter created SOLR-7582:


 Summary: The SolrCloud example (bin/solr -e cloud) should have 
soft auto-commits enabled by default.
 Key: SOLR-7582
 URL: https://issues.apache.org/jira/browse/SOLR-7582
 Project: Solr
  Issue Type: New Feature
Affects Versions: 5.1
Reporter: Timothy Potter
Assignee: Timothy Potter
 Fix For: 5.2


I think the SolrCloud example (bin/solr -e cloud) should enable soft- 
auto-commits by default. The script should enable soft-commits using the Config 
API, which will give a good example of using the Config API for new users.

Also, the data_driven configs should allow setting the auto-commit values using 
-D sys props as in the techproducts solrconfig.xml.

I'd like to get this into 5.2 as I've run into several people that send data 
into their collection only and don't see any docs (because soft-commits are 
disabled). So this is a usability issue for new users.



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

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

Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Brian Burkhalter]

On May 21, 2015, at 12:54 PM, Robert Muir  wrote:

>> Please note that this patch has been pushed:
>> 
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e08b856baa26
>> 
> 
> I just tested this with lucene's test suite without any issues.

Fantastic! Thanks for the testing corroboration: that is very good to know.

[jira] [Resolved] (SOLR-7565) Adding new Manning Publications MEAP "Relevant Search" to official Solr website book section and news

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-7565.

Resolution: Later

please re-open (or just create a new jira) once the book is finalized and 
available for purchase.

> Adding new Manning Publications MEAP "Relevant Search" to official Solr 
> website book section and news
> -
>
> Key: SOLR-7565
> URL: https://issues.apache.org/jira/browse/SOLR-7565
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Reporter: Nicole Butterfield
>Priority: Minor
>  Labels: documentation, easyfix, patch
> Attachments: Turnbull-RS-HI.jpg
>
>
> Doug Turnbull, John Berryman and Manning Publications are proud to announce 
> the new MEAP Relevant Search.
> Relevant Search demystifies relevance work. It teaches you how to return 
> engaging search results to your users, helping you understand and leverage 
> the internals of Lucene-based search engines. Relevant Search walks through 
> several real-world problems using a cohesive philosophy that combines text 
> analysis, query building, and score shaping to express business ranking rules 
> to the search engine. It outlines how to guide the engineering process by 
> monitoring search user behavior and shifting the enterprise to a search-first 
> culture focused on humans, not computers. You'll see how the search engine 
> provides a deeply pluggable platform for integrating search ranking with 
> machine learning, ontologies, personalization, domain-specific expertise, and 
> other enriching sources.



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

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

Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Robert Muir]

On Thu, May 21, 2015 at 1:31 PM, Brian Burkhalter
 wrote:
>
> 2. Work on a fix for https://bugs.openjdk.java.net/browse/JDK-8080589, (fc)
> FileChannel.force should use fcntl(F_FULLFSYNC) instead of fsync on OS X.
>
>
> Please note that this patch has been pushed:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e08b856baa26
>

I just tested this with lucene's test suite without any issues.

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

[jira] [Commented] (LUCENE-6360) TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when there are few terms

[ASF subversion and git services (JIRA)]

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

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

Commit 1680947 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1680947 ]

LUCENE-6360: Add CHANGES entry.

> TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when 
> there are few terms
> --
>
> Key: LUCENE-6360
> URL: https://issues.apache.org/jira/browse/LUCENE-6360
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6360.patch, LUCENE-6360.patch, LUCENE-6360.patch
>
>
> TermsQuery helps when there are lot of terms from which you would like to 
> compute the union, but it is a bit harmful when you have few terms since it 
> cannot really skip: it always consumes all documents matching the underlying 
> terms.
> It would certainly help to rewrite this query to a ConstantScoreQuery over a 
> BooleanQuery when there are few terms in order to have actual skip support.
> As usual the hard part is probably to figure out the threshold. :)



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

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

[jira] [Commented] (LUCENE-6360) TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when there are few terms

[ASF subversion and git services (JIRA)]

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

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

Commit 1680946 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1680946 ]

LUCENE-6360: Make TermsQuery rewrite as a disjunction when there are few terms.

> TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when 
> there are few terms
> --
>
> Key: LUCENE-6360
> URL: https://issues.apache.org/jira/browse/LUCENE-6360
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6360.patch, LUCENE-6360.patch, LUCENE-6360.patch
>
>
> TermsQuery helps when there are lot of terms from which you would like to 
> compute the union, but it is a bit harmful when you have few terms since it 
> cannot really skip: it always consumes all documents matching the underlying 
> terms.
> It would certainly help to rewrite this query to a ConstantScoreQuery over a 
> BooleanQuery when there are few terms in order to have actual skip support.
> As usual the hard part is probably to figure out the threshold. :)



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

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

Re: 5.2 Release branch

[Chris Hostetter]

: I am fairly new to Solr development, so apologies for an obvious 
: question. Do you cut 5.x releases from trunk or some other branch/tag? 
: The reason I am asking is that trunk currently builds as 6.0.0 snapshots 
: and there are a bunch of Lucene and Solr API differences between 5.1 and 
: trunk.

it's cut from branch_5x ... lots of details for new contributors on the 
development processes can be found here...

https://wiki.apache.org/solr/HowToContribute


-Hoss
http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-7468) Kerberos authentication module

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-7468:
---
Attachment: SOLR-7468.patch

A few changes.
TestSolrCloudWithKerberos fails when running the entire test suite but passes 
everytime when running alone, even with the same seed + locale + ... 
combination. Here's the seed and other info to re-run:

ant test  -Dtestcase=TestSolrCloudWithKerberos 
-Dtests.method=testKerberizedSolr -Dtests.seed=BAEC87E7FCC3630 
-Dtests.slow=true -Dtests.locale=is -Dtests.timezone=America/St_Johns 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

I'm assuming some other test is tripping something here. Looking at how to fix 
this.

> Kerberos authentication module
> --
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Ishan Chattopadhyaya
>Assignee: Anshum Gupta
> Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue 
> provides a Kerberos plugin implementation.



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

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

Re: 5.2 Release branch

[Greg Solovyev]

I am fairly new to Solr development, so apologies for an obvious question. Do 
you cut 5.x releases from trunk or some other branch/tag? The reason I am 
asking is that trunk currently builds as 6.0.0 snapshots and there are a bunch 
of Lucene and Solr API differences between 5.1 and trunk. 

Thanks, 
Greg 


From: "Anshum Gupta"  
To: dev@lucene.apache.org 
Sent: Thursday, May 21, 2015 12:27:27 PM 
Subject: 5.2 Release branch 

Hi, 
Just a reminder, I plan to cut the release branch for 5.2 later tonight. 

-- 
Anshum Gupta 

5.2 Release branch

[Anshum Gupta]

Hi,

Just a reminder, I plan to cut the release branch for 5.2 later tonight.

-- 
Anshum Gupta

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!

[Robert Muir]

On Thu, May 21, 2015 at 8:53 AM, Yonik Seeley  wrote:
> On Thu, May 21, 2015 at 12:55 AM, Robert Muir  wrote:
>> Honestly yonik: this is an API bug. If you have a public method, that
>> refers to a package-private class, nobody can really use that public
>> method you exposed.
>
> It's temporary - package private stuff will migrate to public.  It's
> not in it's final form and not meant to be a public API, but some
> things have to be public for internal cross-package use.
>
> My point is that javadoc shouldn't fail stuff that java is happy with.
>

But it is broken. The checker just tells you reality. If users click
that package-private parameter link in the javadocs, they will get a
404 not found.
And they wont be able to use the public method, because even though
its public, it has a package-private class as parameter.

The build did completely the right thing to fail here.

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2330 - Failure!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.testPivotFacetsMissing

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest

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

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




Build Log:
[...truncated 11462 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/init-core-data-001
   [junit4]   2> 2644 T17 oas.SolrTestCaseJ4.initCore initCore
   [junit4]   2> 3225 T17 oasc.SolrResourceLoader. new SolrResourceLoader 
for directory: 
'/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/'
   [junit4]   2> 4219 T17 oasc.SolrConfig.refreshRequestParams current version 
of requestparams : -1
   [junit4]   2> 4268 T17 oasc.SolrConfig.initLibs Adding specified lib dirs to 
ClassLoader
   [junit4]   2> 4273 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: 
../../../../contrib/extraction/lib (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 
E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../contrib/extraction/lib).
   [junit4]   2> 4275 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: ../../../../dist/ (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../dist).
   [junit4]   2> 4276 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: 
../../../../contrib/clustering/lib/ (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 
E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../contrib/clustering/lib).
   [junit4]   2> 4276 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: ../../../../dist/ (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../dist).
   [junit4]   2> 4277 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: ../../../../contrib/langid/lib/ 
(resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../contrib/langid/lib).
   [junit4]   2> 4278 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: ../../../../dist/ (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../dist).
   [junit4]   2> 4279 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: 
../../../../contrib/velocity/lib (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../contrib/velocity/lib).
   [junit4]   2> 4279 T17 oasc.SolrResourceLoader.addToClassLoader WARN Can't 
find (or read) directory to add to classloader: ../../../../dist/ (resolved as: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.solrj.embedded.SolrExampleEmbeddedTest
 E5C3C2DD133EE105-001/tempDir-001/collection1/../../../../dist).
   [junit4]   2> 4421 T17 oasu.SolrIndexConfig. IndexWriter infoStream 
solr logging is enabled
   [junit4]   2> 4426 T17 oasc.SolrConfig. Using Lucene MatchVersion: 
6.0.0
   [junit4]   2> 5038 T17 oasc.SolrConfig. Loaded SolrConfig: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-solrj/test/J0/temp/solr.client.s

[jira] [Commented] (SOLR-7579) Angular admin UI core analysis screen field name/type dropdown issues

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-7579:
-

Hmmm, I see nothing untowards there. Do you see any errors in the web 
developer/javascript console?

> Angular admin UI core analysis screen field name/type dropdown issues
> -
>
> Key: SOLR-7579
> URL: https://issues.apache.org/jira/browse/SOLR-7579
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Erik Hatcher
>Assignee: Upayavira
> Fix For: 5.2
>
> Attachments: SOLR-7579-schema.json, screenshot-1.png
>
>
> field name/type drop-down too narrow and unusable



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

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

[jira] [Updated] (SOLR-7465) Flesh out solr/example/files

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-7465:
---
Attachment: SOLR-7465.patch

checkpoint handoff to Esther: needs some styling work for the phrase cloud and 
a general touch up.   i'll get this committed to 5x/trunk later tonight before 
the 5.2 cutoff in whatever state is in - README is most important to start with.

> Flesh out solr/example/files
> 
>
> Key: SOLR-7465
> URL: https://issues.apache.org/jira/browse/SOLR-7465
> Project: Solr
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, SOLR-7465.patch, 
> SOLR-7465.patch, SOLR-7465.patch
>
>
> this README.txt file that's actually some sort of bizare shell script exists 
> on trunk in an otherwise empty directory...
> https://svn.apache.org/viewvc/lucene/dev/trunk/solr/example/files/README.txt?view=markup
> filed added by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652721
> all of hte other files in this directory removed by this commit: 
> https://svn.apache.org/viewvc?view=revision&revision=1652759



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

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

[jira] [Closed] (SOLR-7581) Function 'sub' can return invalid date subtraction due to long/float conversion and precision loss

[Gene Sawyer (JIRA)]

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

Gene Sawyer closed SOLR-7581.
-
Resolution: Invalid

Based on response, modifying date subtraction to use ms in lieu of sub

> Function 'sub' can return invalid date subtraction due to long/float 
> conversion and precision loss
> --
>
> Key: SOLR-7581
> URL: https://issues.apache.org/jira/browse/SOLR-7581
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.1
> Environment: Linux-x64
>Reporter: Gene Sawyer
>Priority: Minor
> Attachments: functionquery_subtraction_bug.png
>
>
> Use of Function 'sub' to determine millis difference between two 
> TrieDateFields returns invalid value.  The determined value appears to be the 
> same, regardless of the true delta in the TrieDates



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

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

[jira] [Updated] (SOLR-7581) Function 'sub' can return invalid date subtraction due to long/float conversion and precision loss

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-7581:
---
Summary: Function 'sub' can return invalid date subtraction due to 
long/float conversion and precision loss  (was: Function 'sub' returning 
invalid date subtraction)

> Function 'sub' can return invalid date subtraction due to long/float 
> conversion and precision loss
> --
>
> Key: SOLR-7581
> URL: https://issues.apache.org/jira/browse/SOLR-7581
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.1
> Environment: Linux-x64
>Reporter: Gene Sawyer
>Priority: Minor
> Attachments: functionquery_subtraction_bug.png
>
>
> Use of Function 'sub' to determine millis difference between two 
> TrieDateFields returns invalid value.  The determined value appears to be the 
> same, regardless of the true delta in the TrieDates



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

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

new uima annotator for solr

[hossmaa]

Hi everyone 

I've posted thus to the user forum, but it's probably more appropriate here:

I'm trying to plug in a new UIMA annotator into solr. What is necessary for
this? Is it enough to build a Jar similarly to the ones from the uima-addons
package? More specifically, are the uima-addons annotator Jars identical to
the ones found in solr's contrib folder? 

Thanks! 
Andreea



--
View this message in context: 
http://lucene.472066.n3.nabble.com/new-uima-annotator-for-solr-tp4206909.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Commented] (SOLR-7581) Function 'sub' returning invalid date subtraction

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7581:


Functions in solr generally operate on "float" values, and there can be 
precision loss as a result.

This is the exact reason why the "ms()" function supports a 2 argument form for 
subtracting dates more accurately then using the "sub()" function...

https://cwiki.apache.org/confluence/display/solr/Function+Queries

> Function 'sub' returning invalid date subtraction
> -
>
> Key: SOLR-7581
> URL: https://issues.apache.org/jira/browse/SOLR-7581
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.1
> Environment: Linux-x64
>Reporter: Gene Sawyer
>Priority: Minor
> Attachments: functionquery_subtraction_bug.png
>
>
> Use of Function 'sub' to determine millis difference between two 
> TrieDateFields returns invalid value.  The determined value appears to be the 
> same, regardless of the true delta in the TrieDates



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

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

[jira] [Updated] (SOLR-7581) Function 'sub' returning invalid date subtraction

[Gene Sawyer (JIRA)]

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

Gene Sawyer updated SOLR-7581:
--
Attachment: functionquery_subtraction_bug.png

> Function 'sub' returning invalid date subtraction
> -
>
> Key: SOLR-7581
> URL: https://issues.apache.org/jira/browse/SOLR-7581
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.1
> Environment: Linux-x64
>Reporter: Gene Sawyer
>Priority: Minor
> Attachments: functionquery_subtraction_bug.png
>
>
> Use of Function 'sub' to determine millis difference between two 
> TrieDateFields returns invalid value.  The determined value appears to be the 
> same, regardless of the true delta in the TrieDates



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

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

[jira] [Created] (SOLR-7581) Function 'sub' returning invalid date subtraction

[Gene Sawyer (JIRA)]

Gene Sawyer created SOLR-7581:
-

 Summary: Function 'sub' returning invalid date subtraction
 Key: SOLR-7581
 URL: https://issues.apache.org/jira/browse/SOLR-7581
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 5.1
 Environment: Linux-x64
Reporter: Gene Sawyer
Priority: Minor
 Attachments: functionquery_subtraction_bug.png

Use of Function 'sub' to determine millis difference between two TrieDateFields 
returns invalid value.  The determined value appears to be the same, regardless 
of the true delta in the TrieDates



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

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

[jira] [Commented] (SOLR-7274) Pluggable authentication module in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1680940 from [~anshumg] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1680940 ]

SOLR-7274: Stop forwarding Authorization, Host, and Accept headers for SPNego 
to work. Also fixed an exception forwarding from SDF and reconfigure SDF's 
httpClient after authentication has been initialized.(merge from trunk)

> Pluggable authentication module in Solr
> ---
>
> Key: SOLR-7274
> URL: https://issues.apache.org/jira/browse/SOLR-7274
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch
>
>
> It would be good to have Solr support different authentication protocols.
> To begin with, it'd be good to have support for kerberos and basic auth.



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-6494:
---

Yeah, it's NearSpansOrdered that makes everything complicated, because by the 
time you call collect() its child Spans have moved on.  So you need to either 
have just a generic collector type, or pass the collector type to the 
NearSpansOrdered constructor and have a way of creating a buffered collector 
from that, which leads to the overcomplicated generics that Robert didn't like.

There might be a way of doing this by passing a SpanCollector to the SpanWeight 
somehow?  And just doing some ugly brute-force casting in replay(), risking the 
ire of the Generics Policeman.  But in the meantime, please do try this API out 
- feedback from people other than me who are using it will be very useful!

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6494:
--

bq. We could add a Collection to MatchData as well, to collect all terms 
from a Spans.   I'm not sure I see why you need the Term for highlighting 
though - can't you just use offsets?

You may be right about not needing the Term.  I should retract my concerns 
about this for now, as it pertains to accurate highlights.  I need to build a 
POC to understand what's really needed.  Once I saw the SpanCollector, it 
seemed very promising but I'm having second thoughts now.  When I last thought 
about this problem, I ended up wanting a Spans.getChildren() of sorts -- just 
like Scorers do.  I still think that would most likely be more elegant.  The 
tricky part of doing such a thing, I think, would be handling the buffered case 
of NearSpansOrdered such that if I get the child spans, then it would return 
cached child spans for where it matched, not where the current state of the 
child spans may have advanced to.  Alternatively SpanCollector is somewhat 
similar but it's MatchData, as written, doesn't capture each leaf state 
separately -- instead it expands the bounds.  This means currently I can't get 
the offsets of each underlying SpanTermQuery offset match, but only the 
aggregate start/end offset span which could cover a ton of text -- I don't want 
to highlight everything in-between.

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!

[Yonik Seeley]

OK Mr grumpy.

It's my opinion that it also wastes everyones time to force them to
have a pristine checkout before committing
And I know for a *fact* that a large number of committers don't run
"ant precommit" before every commit.

> If i'm working on something, and discover that a recent commit has broken
> precommit, I revert.  no discussion, no hesitation

Shrug... I've fixed a number of other peoples commits that have
inadvertently broken the build.
If it's an easy fix, I'll continue taking that path.  Seems both
easier and a bit nicer.

I'll look into the "precommit" target to see what other targets that
can be run earlier to try and catch bugs w/o forcing one to have a
pristine checkout.

-Yonik

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

[jira] [Commented] (SOLR-7468) Kerberos authentication module

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7468:


Thanks Ishan. I've been testing this too.
The .solr prefix makes sense.

I'll commit this after running the tests one last time.

> Kerberos authentication module
> --
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Ishan Chattopadhyaya
>Assignee: Anshum Gupta
> Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue 
> provides a Kerberos plugin implementation.



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

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

Re: Recent Java 9 commit (e5b66323ae45) breaks fsync on directory

[Brian Burkhalter]

Status update …

On May 18, 2015, at 12:04 PM, Brian Burkhalter  
wrote:

> 2. Work on a fix for https://bugs.openjdk.java.net/browse/JDK-8080589, (fc) 
> FileChannel.force should use fcntl(F_FULLFSYNC) instead of fsync on OS X.

Please note that this patch has been pushed:

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e08b856baa26

Brian

[jira] [Updated] (SOLR-7468) Kerberos authentication module

[Ishan Chattopadhyaya (JIRA)]

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

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

Been testing this for 1-2 days, there were minor hiccups, but all with 
SOLR-7274 and not this one. Updating the patch to rename the system properties 
needed with a "solr.kerberos" prefix.

> Kerberos authentication module
> --
>
> Key: SOLR-7468
> URL: https://issues.apache.org/jira/browse/SOLR-7468
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Ishan Chattopadhyaya
>Assignee: Anshum Gupta
> Attachments: SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, SOLR-7468.patch, 
> SOLR-7468.patch
>
>
> SOLR-7274 introduces a pluggable authentication framework. This issue 
> provides a Kerberos plugin implementation.



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

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

[jira] [Commented] (SOLR-7274) Pluggable authentication module in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1680931 from [~anshumg] in branch 'dev/trunk'
[ https://svn.apache.org/r1680931 ]

SOLR-7274: Stop forwarding Authorization, Host, and Accept headers for SPNego 
to work. Also fixed an exception forwarding from SDF and reconfigure SDF's 
httpClient after authentication has been initialized.

> Pluggable authentication module in Solr
> ---
>
> Key: SOLR-7274
> URL: https://issues.apache.org/jira/browse/SOLR-7274
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.2
>
> Attachments: SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, 
> SOLR-7274-reconfigure-sdf-httpclient.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
> SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch
>
>
> It would be good to have Solr support different authentication protocols.
> To begin with, it'd be good to have support for kerberos and basic auth.



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

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

Re: [JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12585 - Still Failing!

[Chris Hostetter]

>> Please understand that by taking this attitude you waste everyone
>> else's time who does want to pass "ant precommit" before committing,
>> and everyone else's time to scan all these broken builds emails.

+1

personally ... i'm past the point of willing to overlook people who 
obviously break the build ... ranodmized / timing sensitive test failures 
are one thing -- but failure to compile, failure to pass precommit ... 
these are obvious mistakes that can be easily caught in advance, and 
create blocks preventing for other developers.

that's un-fucking-acceptable.  

If i'm working on something, and discover that a recent commit has broken 
precommit, I revert.  no discussion, no hesitation

: It's temporary - package private stuff will migrate to public.  It's
: not in it's final form and not meant to be a public API, but some
: things have to be public for internal cross-package use.

Then commit to a branch, or keep it in a patch, or keep it in a github 
fork.  This project has evolved to trying to have the best safe guards we 
can against broken code making it into the repo -- if people ignore those 
safe guards, they have no right to complain when the rest of us call them 
out on their bull shit and/or revert their commits.

: My point is that javadoc shouldn't fail stuff that java is happy with.

java is happy with "nocommit" in source files, and "@author" tags -- that 
doesn't mean we as a project are.  If the most efficient way to find these 
types of problems is by validating the javadocs -- as opposed to spending 
a lot of time writting some sort of justom source code analysis -- then so 
be it.


-Hoss
http://www.lucidworks.com/

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 854 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/854/

2 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Invalid content type: 

Stack Trace:
org.apache.http.ParseException: Invalid content type: 
at 
__randomizedtesting.SeedInfo.seed([790EEBB04B82A0F4:F15AD46AE57ECD0C]:0)
at org.apache.http.entity.ContentType.parse(ContentType.java:273)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:513)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:224)
at 
org.apache.solr.cloud.CloudInspectUtil.compareResults(CloudInspectUtil.java:166)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:676)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java: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.randomizedtestin

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b12) - Build # 12765 - Failure!

[Timothy Potter]

Hmmm ...

-beast:
  [beaster] Beast round: 1
  [beaster] Beast round: 2
  [beaster] Beast round: 3
  [beaster] Beast round: 4
  [beaster] Beast round: 5
  [beaster] Beast round: 6
  [beaster] Beast round: 7
  [beaster] Beast round: 8
  [beaster] Beast round: 9
  [beaster] Beast round: 10
  [beaster] Beast round: 11
  [beaster] Beast round: 12
  [beaster] Beast round: 13
  [beaster] Beast round: 14
  [beaster] Beast round: 15
  [beaster] Beast round: 16
  [beaster] Beast round: 17
  [beaster] Beast round: 18
  [beaster] Beast round: 19
  [beaster] Beast round: 20
  [beaster] Beasting finished.

On Thu, May 21, 2015 at 9:14 AM, Timothy Potter  wrote:
> I'm going to run the beast on this for a bit to see if I can reproduce ...
>
> On Thu, May 21, 2015 at 4:12 AM, Policeman Jenkins Server
>  wrote:
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12765/
>> Java: 32bit/jdk1.8.0_60-ea-b12 -server -XX:+UseSerialGC
>>
>> 1 tests failed.
>> FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
>>
>> Error Message:
>> document count mismatch.  control=358 sum(shards)=357 cloudClient=357
>>
>> Stack Trace:
>> java.lang.AssertionError: document count mismatch.  control=358 
>> sum(shards)=357 cloudClient=357
>> at 
>> __randomizedtesting.SeedInfo.seed([C3A1DDED6178C6E2:4BF5E237CF84AB1A]:0)
>> at org.junit.Assert.fail(Assert.java:93)
>> at 
>> org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1345)
>> at 
>> org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:240)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:497)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>> at 
>> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>> at 
>> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>> at 
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>> at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>> at 
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>> at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>> at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java: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:845)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>> at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
>> at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMet

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-6494:
---

We could add a Collection to MatchData as well, to collect all terms from 
a Spans.  I'm not sure I see why you need the Term for highlighting though - 
can't you just use offsets?

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

[jira] [Updated] (LUCENE-6360) TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when there are few terms

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6360:
-
Attachment: LUCENE-6360.patch

Here is an updated patch. It works in a very similar way to 
MultiTermQueryConstantScoreWrapper for BulkScorer delegation.

> TermsQuery should rewrite to a ConstantScoreQuery over a BooleanQuery when 
> there are few terms
> --
>
> Key: LUCENE-6360
> URL: https://issues.apache.org/jira/browse/LUCENE-6360
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6360.patch, LUCENE-6360.patch, LUCENE-6360.patch
>
>
> TermsQuery helps when there are lot of terms from which you would like to 
> compute the union, but it is a bit harmful when you have few terms since it 
> cannot really skip: it always consumes all documents matching the underlying 
> terms.
> It would certainly help to rewrite this query to a ConstantScoreQuery over a 
> BooleanQuery when there are few terms in order to have actual skip support.
> As usual the hard part is probably to figure out the threshold. :)



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

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

[jira] [Commented] (LUCENE-6494) Make PayloadSpanUtil apply to other postings information

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6494:
--

I'm looking over your latest patch, with an eye for it's suitability for 
accurate highlighting (aka "query debugging").  Ultimately, the "term" needs to 
be collected, and it isn't done so by MatchData/SpanCollector now.  It seems an 
approach would involve a custom SpanCollector subclass that captures the term 
-- at least it's passed in already.  But SpanCollector is instantiated 
internally by PayloadTermSpanScorer, SpanPayloadCheckQuery, and 
SpanNearPayloadCheckQuery.  I was hoping there would be some way to pass in a 
custom one into SpanWeight from the outside; that is/was the case but this API 
change removes that.  I do think this looks/feels nicer though; but it loses a 
capability -- albeit one it only had for a couple days now.   What do you think 
Alan?

> Make PayloadSpanUtil apply to other postings information
> 
>
> Key: LUCENE-6494
> URL: https://issues.apache.org/jira/browse/LUCENE-6494
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 5.2
>
> Attachments: LUCENE-6494.patch, LUCENE-6494.patch, LUCENE-6494.patch, 
> LUCENE-6494.patch
>
>
> With the addition of SpanCollectors, we can now get arbitrary postings 
> information from SpanQueries.  PayloadSpanUtil does some rewriting to convert 
> non-span queries into SpanQueries so that it can collect payloads.  It would 
> be good to make this more generic, so that we can collect any postings 
> information from any query (without having to make invasive changes to 
> already optimized Scorers, etc).



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

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

Re: 5.2 release planning

[Noble Paul]

We have  a lot of new features . It's a good time for  a release

On Thu, May 21, 2015 at 8:40 PM, Erick Erickson 
wrote:

> Don't get me wrong, good question to ask!
>
> On Thu, May 21, 2015 at 5:48 AM, Alexandre Rafalovitch
>  wrote:
> > Cool. This certainly answers my questions.
> >
> > Thank you,
> >Alex.
> > 
> > Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
> > http://www.solr-start.com/
> >
> >
> > On 21 May 2015 at 17:58, Upayavira  wrote:
> >> AngularJS 2.0 isn't fully baked yet, and is, as you suggest, a very
> >> different beast. Given that level of change, you can expect a lot of 1.x
> >> momentum once 2.0 is out.
> >>
> >> The bulk of this project wasn't AngularJS coding, rather understanding
> >> the intent of the existing code, and only then taking advantage of
> >> AngularJS to make that clearer. Thus, any migration to AngularJS 2.0
> >> should be simpler because of this work.
> >>
> >> The lines of Javascript has approximately halved in this new impl, which
> >> should make it all-round easier to maintain, in whichever way we choose
> >> to take it.
> >>
> >> Upayavira
> >>
> >> On Thu, May 21, 2015, at 03:12 AM, Alexandre Rafalovitch wrote:
> >>> My understanding was that it will be quite a bit of a pain to change.
> >>> They are rethinking the whole architecture. By the same token, there
> >>> might be quite a lot of Angular 1 momentum even after Angular 2 is
> >>> released.
> >>>
> >>> To be clear, I am not really recommending or arguing anything. It's
> >>> not my area of expertise. It just felt like there was a small pink
> >>> elephant in a room and I wanted to ask what the position on it was
> >>> from the people actually doing the work. Or be pointed at the
> >>> discussion (e.g. JIRA) where that particular elephant has already been
> >>> examined in details.
> >>>
> >>> Regards,
> >>>   Alex.
> >>> 
> >>> Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
> >>> http://www.solr-start.com/
> >>>
> >>>
> >>> On 21 May 2015 at 11:17, Erick Erickson 
> wrote:
> >>> > Well, it's all experimental at this point, I have no reservations
> >>> > about upgrading from Angular 1 to 2 between 5.2 and 5.3 so it's not
> >>> > locked in to anything. That said, what are the compelling reasons to
> >>> > go with Angular 2 that make it worth the effort? The argument that
> >>> > it'll be more supported going forward is taken as a given. Do you
> have
> >>> > any estimate how much of a pain it would be to change?
> >>> >
> >>> > On Wed, May 20, 2015 at 4:17 PM, Alexandre Rafalovitch
> >>> >  wrote:
> >>> >> On 21 May 2015 at 06:03, Erick Erickson 
> wrote:
> >>> >>> Just to be clear the new AngularJS-based admin UI will _not_ be the
> >>> >>> default for 5.2, the default in 5.2 will still be the current UI.
> The
> >>> >>> hope is to get it out there for people to experiment with/provide
> >>> >>> feedback on with an eye toward making it the default in 5.3. And
> add
> >>> >>> some nifty new features between now and 5.3 that would entice
> people
> >>> >>> to use it and thus generate feedback.
> >>> >>
> >>> >> I did not see this mentioned anywhere. Are the - significant -
> changes
> >>> >> in Angular 2 going to affect this new UI? Or do we lock in to the
> >>> >> latest Angular 1 for a while?
> >>> >>
> >>> >> Regards,
> >>> >>Alex.
> >>> >>
> >>> >> 
> >>> >> Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
> >>> >> http://www.solr-start.com/
> >>> >>
> >>> >>
> -
> >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>> >>
> >>> >
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >>> >
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
-
Noble Paul

[jira] [Resolved] (SOLR-7577) Add support for rules in CREATESHARD and ADDREPLICA

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-7577.
--
   Resolution: Fixed
Fix Version/s: 5.2
   Trunk

> Add support for rules in CREATESHARD and ADDREPLICA
> ---
>
> Key: SOLR-7577
> URL: https://issues.apache.org/jira/browse/SOLR-7577
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-7577.patch
>
>




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

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