[jira] [Commented] (LUCENE-6939) BlendedInfixSuggester to support exponential reciprocal BlenderType

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on LUCENE-6939:


Hello  [~erickerickson]

I can see you have updated the wiki with {{linear}}->{{position_linear}} and 
{{reciprocal}}->{{position_reciprocal}} 

Thank you very much for that  [~erickerickson] 

We need a new bullet point for the new blenderType, just below 
{{position_reciprocal}} at the same level: 

{quote}
{{position_exponential_reciprocal}}:  weightFieldValue/Math.pow(1+position, 
exponent). This is a more aggressive and more configurable version of the 
{{position_reciprocal}} with a configurable variable {{exponent}}. When 
{{exponent}}==1.0, then both {{position_exponential_reciprocal}} and 
{{position_reciprocal}} are equivalent and lead to the same result. 

{quote}

Then, we will need a new bullet point outside of the BlenderType and just above 
numFactor:
{quote}
{{exponent}}: an optional configuration variable for the 
{{position_exponential_reciprocal}} blenderType. It is a decimal number used to 
control how fast the score will grow or decrease. Its default value 2.0
{quote}

Many thanks

> BlendedInfixSuggester to support exponential reciprocal BlenderType
> ---
>
> Key: LUCENE-6939
> URL: https://issues.apache.org/jira/browse/LUCENE-6939
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spellchecker
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Priority: Minor
>  Labels: suggester
> Fix For: 5.5, 6.0
>
> Attachments: LUCENE-6939.patch
>
>
> The orignal BlendedInfixSuggester introduced in LUCENE-5354 has support for:
> - {{BlenderType.POSITION_LINEAR}} and 
> - {{BlenderType.POSITION_RECIPROCAL}} .
> These are used to score documents based on the position of the matched token 
> i.e the closer is the matched term to the beginning, the higher score you get.
> In some use cases, we need a more aggressive scoring based on the position.
> That's where the exponential reciprocal comes into play 
> i.e 
> {{coef = 1/Math.pow(position+1, exponent)}}
> where the {{exponent}} is a configurable variable.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_92) - Build # 177 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/177/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 8 object(s) that were not released!!! 
[MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([368FFBE3CD192F42]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_368FFBE3CD192F42-001\tempDir-001\node2\testschemaapi_shard1_replica2\data

Re: Lucene/Solr 6.0.1

[David Smiley]

Oh right, of course :-)  So I cherry picked those over to the 6.0 branch.
The Lucene one is strictly speaking a "new feature" but it's to make the
GCD configurable necessary to enable the Solr-side to use it without a
GCD.  At some point after the release I presume you'll sync up the
CHANGES.txt on master & 6x?  That'd be easier than trying to make that
change for each cherry picked commit.  It's too bad this
conundrum/annoyance exists.

~ David

On Fri, May 13, 2016 at 8:11 PM Steve Rowe  wrote:

> David,
>
> Since it’s a bugfix release, the branch is already cut: branch_6_0.
>
> Please go ahead and start backporting whenever you’re ready.
>
> --
> Steve
> www.lucidworks.com
>
> > On May 13, 2016, at 12:24 PM, David Smiley 
> wrote:
> >
> > When you cut the branch, I'll port the "gregorian change date"
> bugs/issues (2 Solr, 1 Lucene).
> >
> > On Fri, May 13, 2016 at 12:06 PM Steve Rowe  wrote:
> > I’d like to make a 6.0.1 release, and I volunteer to be RM.
> >
> > I propose to cut the first RC in one week: next Friday.
> >
> > --
> > Steve
> > www.lucidworks.com
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-9085) DateRangeField is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale
(cherry picked from commit 4193e60)
(cherry picked from commit 9d826ff)


> DateRangeField is broken before the year 1582
> -
>
> Key: SOLR-9085
> URL: https://issues.apache.org/jira/browse/SOLR-9085
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR-9085.patch
>
>
> DateRangeField has some issues for dates before 1582 (the Gregorian Change 
> Date), following Solr 6.  The main problem is that it uses DateMathParser 
> which no longer observes a GCD and then it converts that Date to a Calendar 
> using Calendar.setTime(date) which considers the GCD.  We can't altogether 
> avoid Calendar.java as in SOLR-9080 because DateRangePrefixTree currently 
> fundamentally depends on it.  However I recently learned we can simply change 
> the GCD like so: {{cal.setGregorianChange(new Date(Long.MIN_VALUE));}} 
> beforehand.  DateRangeField also calls Calendar.getTime as well, which is 
> affected by GCD considerations.
> For users that use DateRangeField but do *not* use "Date Math" and do not 
> have 'Z' in their date strings then date strings are completely parsed by 
> DateRangePrefixTree and there should be no issue.
> DateRangePrefixTree ought to be improved a bit too (in a separate issue)... 
> like making the GCD configurable, and setting using 
> SimpleDateFormatter.setCalendar it uses to format.



--
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-9080) DateMath is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale
(cherry picked from commit 4193e60)
(cherry picked from commit 9d826ff)


> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch, 
> SOLR_9080_DateMath_should_not_use_Calendar_API.patch
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



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

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

[jira] [Commented] (LUCENE-7278) Make template Calendar configurable in DateRangePrefixTree

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7278: DateRangePrefixTree's Calendar is now configurable.
(cherry picked from commit 1f6487a and 32e16cb0e60cba8057d47be45ab022ba92e254ad)


> Make template Calendar configurable in DateRangePrefixTree
> --
>
> Key: LUCENE-7278
> URL: https://issues.apache.org/jira/browse/LUCENE-7278
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: LUCENE_7278.patch, LUCENE_7278.patch
>
>
> DateRangePrefixTree (a SpatialPrefixTree designed for dates and date ranges) 
> currently uses a hard-coded Calendar template for making new instances.  This 
> ought to be configurable so that, for example, the Gregorian change date can 
> be configured.  This is particularly important for compatibility with Java 
> 8's java.time API which uses the Gregorian calendar for all time (there is no 
> use of Julian prior to 1582).



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/646/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 52400 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] javadoc: warning - No source files for package 
org.apache.lucene.codecs
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0_92
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build/docs/backward-codecs/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:101: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:138: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/build.xml:246: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2187: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/module-build.xml:65: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/module-build.xml:78: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:2163: 
Javadocs warnings were found!

Total time: 67 minutes 8 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 130 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/130/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch

Error Message:
 Expected: is <3>  got: <4> 

Stack Trace:
java.lang.AssertionError: 
Expected: is <3>
 got: <4>

at 
__randomizedtesting.SeedInfo.seed([5F36DD2E780EA866:20D125E3F033758]:0)
at org.junit.Assert.assertThat(Assert.java:780)
at org.junit.Assert.assertThat(Assert.java:738)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testSimpleCollectionWatch(TestCollectionStateWatchers.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12855 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating dataDir: 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+116) - Build # 16736 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16736/
Java: 64bit/jdk-9-ea+116 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:44554/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:44554/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([1E30BB4E7C3058D0:96648494D2CC3528]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 578 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/578/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=704, 
name=SocketProxy-Response-37981:54818, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=704, name=SocketProxy-Response-37981:54818, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([379F45FB17BC5B2:8B2DCB851F87A84A]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([379F45FB17BC5B2]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1137)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)




Build Log:
[...truncated 10512 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_379F45FB17BC5B2-001/init-core-data-001
   [junit4]   2> 59262 INFO  
(SUITE-HttpPartitionTest-seed#[379F45FB17BC5B2]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 59269 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 59269 INFO  (Thread-61) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 59269 INFO  (Thread-61) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 59370 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.ZkTestServer start zk server on port:46389
   [junit4]   2> 59370 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 59370 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 59378 INFO  (zkCallback-38-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@5ac3af9a 
name:ZooKeeperConnection Watcher:127.0.0.1:46389 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 59379 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 59379 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 59379 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 59392 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 59393 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 59400 INFO  (zkCallback-39-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@8d5dfce name:ZooKeeperConnection 
Watcher:127.0.0.1:46389/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2> 59400 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 59400 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 59400 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 59412 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 59414 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 59416 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 59418 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.AbstractZkTestCase put 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 59418 INFO  
(TEST-HttpPartitionTest.test-seed#[379F45FB17BC5B2]) [] 
o.a.s.c.c.SolrZkClient makePath: 

Re: Lucene/Solr 6.0.1

[Steve Rowe]

Progress:

I added the 6.0.1 version where it should be, and I checked in backcompat 
indexes for 6.0.0, so the smoke checker should now succeed.

I’ve re-enabled the 6.0 branch jobs on ASF Jenkins and on my Jenkins.

Uwe, would you please re-enable the Policeman Jenkins 6.0 release branch jobs?

Thanks.

--
Steve
www.lucidworks.com

> On May 13, 2016, at 12:05 PM, Steve Rowe  wrote:
> 
> I’d like to make a 6.0.1 release, and I volunteer to be RM.
> 
> I propose to cut the first RC in one week: next Friday.
> 
> --
> Steve
> www.lucidworks.com


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

Re: Lucene/Solr 6.0.1

[Steve Rowe]

David,

Since it’s a bugfix release, the branch is already cut: branch_6_0.

Please go ahead and start backporting whenever you’re ready.

--
Steve
www.lucidworks.com

> On May 13, 2016, at 12:24 PM, David Smiley  wrote:
> 
> When you cut the branch, I'll port the "gregorian change date" bugs/issues (2 
> Solr, 1 Lucene).
> 
> On Fri, May 13, 2016 at 12:06 PM Steve Rowe  wrote:
> I’d like to make a 6.0.1 release, and I volunteer to be RM.
> 
> I propose to cut the first RC in one week: next Friday.
> 
> --
> Steve
> www.lucidworks.com
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
> http://www.solrenterprisesearchserver.com


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

Re: [JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 136 - Still Failing!

[Michael McCandless]

I'll fix.

Mike McCandless

http://blog.mikemccandless.com

On Fri, May 13, 2016 at 7:02 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/136/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
>
> All tests passed
>
> Build Log:
> [...truncated 52324 lines...]
>   [javadoc] Generating Javadoc
>   [javadoc] Javadoc execution
>   [javadoc] Loading source files for package org.apache.lucene.codecs...
>   [javadoc] Loading source files for package
> org.apache.lucene.codecs.lucene50...
>   [javadoc] javadoc: warning - No source files for package
> org.apache.lucene.codecs
>   [javadoc] Loading source files for package
> org.apache.lucene.codecs.lucene53...
>   [javadoc] Loading source files for package
> org.apache.lucene.codecs.lucene54...
>   [javadoc] Constructing Javadoc information...
>   [javadoc] Standard Doclet version 1.8.0_72
>   [javadoc] Building tree for all the packages and classes...
>   [javadoc] Building index for all the packages and classes...
>   [javadoc] Building index for all classes...
>   [javadoc] Generating
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build/docs/backward-codecs/help-doc.html...
>   [javadoc] Note: Custom tags that were not seen:  @lucene.internal
>   [javadoc] 1 warning
>
> BUILD FAILED
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:740: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:101: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:138: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:246: The
> following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2187:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/module-build.xml:65:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/module-build.xml:78:
> The following error occurred while executing this line:
> /Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2163:
> Javadocs warnings were found!
>
> Total time: 105 minutes 30 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> [WARNINGS] Skipping publisher since build result is FAILURE
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

[jira] [Resolved] (LUCENE-7265) Pull change id related code out of addVersion.py, since it's no longer used

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-7265.

Resolution: Fixed

I tested these changes by adding 6.0.2 on branch_6_0, 6.0.1 and 6.2.0 on 
branch_6x, and 6.0.1, 6.2.0 and 8.0.0 on master.  All seemed to do the right 
thing.

> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265-drop-changeid.patch, LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 52324 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] javadoc: warning - No source files for package 
org.apache.lucene.codecs
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0_72
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build/docs/backward-codecs/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:740: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:138: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:246: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2187: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/module-build.xml:65: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/module-build.xml:78: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2163: 
Javadocs warnings were found!

Total time: 105 minutes 30 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (LUCENE-7265) Pull change id related code out of addVersion.py, since it's no longer used

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7265: Pull change id related code out of addVersion.py; rename 'major' 
BranchType to 'unstable'


> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265-drop-changeid.patch, LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-7265) Pull change id related code out of addVersion.py, since it's no longer used

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7265: Pull change id related code out of addVersion.py; rename 'major' 
BranchType to 'unstable'

Conflicts:
dev-tools/scripts/addVersion.py


> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265-drop-changeid.patch, LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-9058) hashJoin does not work when "on" maps fields with "="

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-9058.
-
Resolution: Fixed

Closing this. The fix will appear in 6.1. Thanks everyone for the help.

> hashJoin does not work when "on" maps fields with "="
> -
>
> Key: SOLR-9058
> URL: https://issues.apache.org/jira/browse/SOLR-9058
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Stephan Osthold
>Assignee: Dennis Gove
>Priority: Minor
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9058.patch
>
>
> hashJoin does not work when "on" maps fields with "="
> eg.
> hashJoin(
>  ...
>  on="field1=field2"
> )
> See link for fix.



--
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-7265) Pull change id related code out of addVersion.py, since it's no longer used

[ASF subversion and git services (JIRA)]

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

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

Commit 21433af4029de39f905a243b1bb6f19985708d22 in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=21433af ]

LUCENE-7265: Pull change id related code out of addVersion.py; rename 'major' 
BranchType to 'unstable'


> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265-drop-changeid.patch, LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-9101) introduce SolrRequestInfo.doInSuspension(Callable). make SolrRequestInfo final

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9101:
---
Attachment: SOLR-9101.patch

> introduce SolrRequestInfo.doInSuspension(Callable). make SolrRequestInfo 
> final
> -
>
> Key: SOLR-9101
> URL: https://issues.apache.org/jira/browse/SOLR-9101
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Mikhail Khludnev
> Attachments: SOLR-9101.patch
>
>
> During work on SOLR-8208 I fortunately hacked this.  I propose changes in the 
> subj which make SolrRequestInfo more powerful and protected. 
> [~ysee...@gmail.com], I need your opinion regarding it.



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3268 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:51952/_q/tt","node_name":"127.0.0.1:51952__q%2Ftt","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   
"core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:51959/_q/tt;,   
"node_name":"127.0.0.1:51959__q%2Ftt",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:51973/_q/tt;,   
"core":"c8n_1x3_lf_shard1_replica1",   
"node_name":"127.0.0.1:51973__q%2Ftt"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:51952/_q/tt;,   
"node_name":"127.0.0.1:51952__q%2Ftt",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica3","base_url":"http://127.0.0.1:51952/_q/tt","node_name":"127.0.0.1:51952__q%2Ftt","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:51959/_q/tt;,
  "node_name":"127.0.0.1:51959__q%2Ftt",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:51973/_q/tt;,
  "core":"c8n_1x3_lf_shard1_replica1",
  "node_name":"127.0.0.1:51973__q%2Ftt"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:51952/_q/tt;,
  "node_name":"127.0.0.1:51952__q%2Ftt",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([9B04DE1CCAF9B313:1350E1C66405DEEB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 

[jira] [Commented] (SOLR-9106) Cache cluster properties in ZkStateReader

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-9106:
--

LGTM

> Cache cluster properties in ZkStateReader
> -
>
> Key: SOLR-9106
> URL: https://issues.apache.org/jira/browse/SOLR-9106
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9106.patch, SOLR-9106.patch
>
>
> ZkStateReader currently makes calls into ZK every time getClusterProps() is 
> called.  Instead we should keep the data locally and use a Watcher to update 
> it.



--
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-9109) Add support for custom ivysettings.xml

[Misha Dmitriev (JIRA)]

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

Misha Dmitriev updated SOLR-9109:
-
Attachment: SOLR-9109.patch
0001-Support-for-custom-ivysettings.xml.patch

> Add support for custom ivysettings.xml
> --
>
> Key: SOLR-9109
> URL: https://issues.apache.org/jira/browse/SOLR-9109
> Project: Solr
>  Issue Type: Improvement
>Reporter: Misha Dmitriev
> Attachments: 0001-Support-for-custom-ivysettings.xml.patch, 
> SOLR-9109.patch
>
>
> Currently solr/lucene/common-build.xml hardcodes file ivy-settings.xml in the 
> ivy.configure task. It means that, unlike all other CDH components that use 
> Ant, Solr does not allow the user to provide a custom ivysettings.xml.
> In the Cauldron CDH build, we need to make some adjustments in the build 
> process to satisfy CDH-internal build dependencies with artifacts generated 
> locally, rather than download them from repo1.maven.org etc. E.g. all 
> component should use locally-generated avro-snapshot jars instead of publicly 
> released ones, etc. For Ant, we achieve that by giving it a special 
> ivysettings.xml file, that limits artifact downloading to the local on-disk 
> maven repository and Cloudera artifactory server.
> All CDH components except Solr allow the user to specify a custom 
> ivysettings.xml file by overriding -Divysettings.xml property. We need to add 
> the same feature to Solr. It can be easily achieved by changing several lines 
> in solr/lucene/common-build.xml.



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

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

[jira] [Updated] (LUCENE-7265) Pull change id related code out of addVersion.py, since it's no longer used

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7265:
---
Attachment: LUCENE-7265-drop-changeid.patch

I've renamed this issue to do some cleanup on the addVersion.py script, here's 
the patch.  The patch also renames the "major" BranchType to "unstable", to fit 
better with the other types: "release" and "stable".

Committing shortly.

> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265-drop-changeid.patch, LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-7265) Pull change id related code out of addVersion.py, since it's no longer used

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7265:
---
Summary: Pull change id related code out of addVersion.py, since it's no 
longer used  (was: Fix addVersion to merge downstream changes by using the 
change id)

> Pull change id related code out of addVersion.py, since it's no longer used
> ---
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



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

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

[GitHub] lucene-solr pull request: SOLR-8323

[romseygeek]

Github user romseygeek closed the pull request at:

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


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

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

[jira] [Commented] (LUCENE-7265) Fix addVersion to merge downstream changes by using the change id

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-7265:
--

Sure, but there'd be some fix required to the script. This would require more 
changes for the addVersion to work for all kinds of releases.

> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 644 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/644/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader

Error Message:
The request took too long to iterate over terms. Timeout: timeoutAt: 
630063179252163 (System.nanoTime(): 630063780028938), 
TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@1cc8ad4

Stack Trace:
org.apache.lucene.index.ExitableDirectoryReader$ExitingReaderException: The 
request took too long to iterate over terms. Timeout: timeoutAt: 
630063179252163 (System.nanoTime(): 630063780028938), 
TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@1cc8ad4
at 
__randomizedtesting.SeedInfo.seed([D6EF1155738BC28C:6E8ABC1418514B75]:0)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.checkAndThrow(ExitableDirectoryReader.java:173)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.(ExitableDirectoryReader.java:163)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTerms.iterator(ExitableDirectoryReader.java:147)
at 
org.apache.lucene.index.FilterLeafReader$FilterTerms.iterator(FilterLeafReader.java:113)
at 
org.apache.lucene.index.TestExitableDirectoryReader$TestReader$TestTerms.iterator(TestExitableDirectoryReader.java:58)
at org.apache.lucene.index.Terms.intersect(Terms.java:72)
at 
org.apache.lucene.util.automaton.CompiledAutomaton.getTermsEnum(CompiledAutomaton.java:336)
at 
org.apache.lucene.search.AutomatonQuery.getTermsEnum(AutomatonQuery.java:107)
at 
org.apache.lucene.search.MultiTermQuery.getTermsEnum(MultiTermQuery.java:304)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite(MultiTermQueryConstantScoreWrapper.java:148)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.bulkScorer(MultiTermQueryConstantScoreWrapper.java:201)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:666)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:592)
at 
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:450)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:461)
at 
org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader(TestExitableDirectoryReader.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Resolved] (SOLR-8323) Add CollectionWatcher API to ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-8323.
-
   Resolution: Fixed
Fix Version/s: 6.1

Thanks for all the reviewing Scott!  Now on to SOLR-9056 :)

> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch, SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
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-8323) Add CollectionWatcher API to ZkStateReader

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8323: Add CollectionStateWatcher API


> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch, SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
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-8208) DocTransformer executes sub-queries

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8208: fixing TestSubQueryTransformerDistrib by passing reasonable numbers 
in creatCollection()


> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8208-distrib-test-fix.patch, SOLR-8208.diff, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..=name_s:john=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}=text_t,dept_id_s_dv=12=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave=true=*,depts:[subquery]=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16734 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16734/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:40428/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:40428/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([72A75C0F2C8035C3:FAF363D5827C583B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (LUCENE-7265) Fix addVersion to merge downstream changes by using the change id

[ASF subversion and git services (JIRA)]

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

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

Commit 75aabbc06163c80fc71a0bc8cc9411ae0ddd2999 in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=75aabbc ]

Revert "LUCENE-7265: Fix addVersion to cherry-pick downstream changes by using 
the change id"

This reverts commit 1af681b05d88c1655956d4776a708fb58f7f7738.


> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-7265) Fix addVersion to merge downstream changes by using the change id

[ASF subversion and git services (JIRA)]

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

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

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

Revert "LUCENE-7265: Fix addVersion to cherry-pick downstream changes by using 
the change id"

This reverts commit 3ad0201e3ec6e3e4a509f566383f36493d7ad902.


> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-8323) Add CollectionWatcher API to ZkStateReader

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8323: Add CollectionStateWatcher API


> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch, SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
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-7265) Fix addVersion to merge downstream changes by using the change id

[ASF subversion and git services (JIRA)]

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

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

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

Revert "LUCENE-7265: Fix addVersion to cherry-pick downstream changes by using 
the change id"

This reverts commit 54b873c2f9b401687c18010aee31c35bcab9660e.


> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-7265) Fix addVersion to merge downstream changes by using the change id

[Steve Rowe (JIRA)]

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

Steve Rowe reopened LUCENE-7265:

  Assignee: Steve Rowe  (was: Anshum Gupta)

Anshum, I know I +1'd this, but was I smoking crack???

I mean, the original code did a {{svn --record-only merge}}, which is useful 
only as metadata to link commits across branches - no actual changes were 
pulled in.

But with the change on this issue, addVersion.py tries to pull in 
version-related changes from another branch that are almost certain to conflict 
... and then (in case of success) the script goes and makes all the appropriate 
changes.

So this change should be reverted.  I'm going to do that now, so that I can 
successfully run addVersion.py on branch_6x and master for the 6.0.1 release.

> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Steve Rowe
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-8208) DocTransformer executes sub-queries

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8208: fixing TestSubQueryTransformerDistrib by passing reasonable numbers 
in creatCollection()


> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8208-distrib-test-fix.patch, SOLR-8208.diff, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..=name_s:john=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}=text_t,dept_id_s_dv=12=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave=true=*,depts:[subquery]=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-8208:
---
Attachment: SOLR-8208-distrib-test-fix.patch

seting resonable numbers for {{createCollection(people, 2, 1, 10);}}
[^SOLR-8208-distrib-test-fix.patch]

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8208-distrib-test-fix.patch, SOLR-8208.diff, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..=name_s:john=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}=text_t,dept_id_s_dv=12=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave=true=*,depts:[subquery]=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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-8323) Add CollectionWatcher API to ZkStateReader

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8323:
--

I already LGTM'd the github PR, I don't think I need to look at the patch file?

> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch, SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 176 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/176/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

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

Error Message:
Error from server at http://127.0.0.1:55277/solr: Backup directory already 
exists: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudBackupRestore_96B9F7D731B2ADF5-001\tempDir-002\mytestbackup

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:55277/solr: Backup directory already exists: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudBackupRestore_96B9F7D731B2ADF5-001\tempDir-002\mytestbackup
at 
__randomizedtesting.SeedInfo.seed([96B9F7D731B2ADF5:1EEDC80D9F4EC00D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestCloudBackupRestore.testBackupAndRestore(TestCloudBackupRestore.java:153)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Created] (SOLR-9109) Add support for custom ivysettings.xml

[Misha Dmitriev (JIRA)]

Misha Dmitriev created SOLR-9109:


 Summary: Add support for custom ivysettings.xml
 Key: SOLR-9109
 URL: https://issues.apache.org/jira/browse/SOLR-9109
 Project: Solr
  Issue Type: Improvement
Reporter: Misha Dmitriev


Currently solr/lucene/common-build.xml hardcodes file ivy-settings.xml in the 
ivy.configure task. It means that, unlike all other CDH components that use 
Ant, Solr does not allow the user to provide a custom ivysettings.xml.

In the Cauldron CDH build, we need to make some adjustments in the build 
process to satisfy CDH-internal build dependencies with artifacts generated 
locally, rather than download them from repo1.maven.org etc. E.g. all component 
should use locally-generated avro-snapshot jars instead of publicly released 
ones, etc. For Ant, we achieve that by giving it a special ivysettings.xml 
file, that limits artifact downloading to the local on-disk maven repository 
and Cloudera artifactory server.

All CDH components except Solr allow the user to specify a custom 
ivysettings.xml file by overriding -Divysettings.xml property. We need to add 
the same feature to Solr. It can be easily achieved by changing several lines 
in solr/lucene/common-build.xml.



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

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

[jira] [Closed] (SOLR-6498) LeaderElector sometimes will appear multiple ephemeral nodes in the zookeeper

[Scott Blum (JIRA)]

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

Scott Blum closed SOLR-6498.

   Resolution: Duplicate
 Assignee: Scott Blum
Fix Version/s: 6.0
   5.5.1

Closing this as a duplicate, I assume this was fixed in SOLR-8697.  Feel free 
to re-open if this crops up again.

> LeaderElector sometimes will appear multiple ephemeral nodes in the zookeeper
> -
>
> Key: SOLR-6498
> URL: https://issues.apache.org/jira/browse/SOLR-6498
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.6.1
> Environment: linux
>Reporter: Raintung Li
>Assignee: Scott Blum
> Fix For: 5.5.1, 6.0
>
> Attachments: SOLR-6498.txt
>
>
> Sometimes overseer_elect/collection_shard_leader_elect election path will 
> appear multiple same node different sessionid ephemeral nodes.
> ex.
> 92427566579253248-core_node1-n_32
> 92427566579253249-core_node1-n_33
> I can't trace what it happen. But if that, the result will be the new 
> register node can't be elect the leader, we also know the old sessionid 
> ephemeral node is invalid, but don't know why it is exist.
> And the other issue :
> joinElection method:
> try {
> leaderSeqPath = zkClient.create(shardsElectZkPath + "/" + id + "-n_", 
> null,
> CreateMode.EPHEMERAL_SEQUENTIAL, false);
> context.leaderSeqPath = leaderSeqPath;
> cont = false;
>   } catch (ConnectionLossException e) {
> // we don't know if we made our node or not...
> List entries = zkClient.getChildren(shardsElectZkPath, null, 
> true);
> 
> boolean foundId = false;
> for (String entry : entries) {
>   String nodeId = getNodeId(entry);
>   if (id.equals(nodeId)) {
> // we did create our node...
> foundId  = true;
> break;
>   }
> }
> if (!foundId) {
>   cont = true;
>   if (tries++ > 20) {
> throw new ZooKeeperException(SolrException.ErrorCode.SERVER_ERROR,
> "", e);
>   }
>   try {
> Thread.sleep(50);
>   } catch (InterruptedException e2) {
> Thread.currentThread().interrupt();
>   }
> }
>   } 
> If meet the ConnectionLossException status, maybe will double create the 
> ephemeral sequential node.
> For my suggestion, can't trace why create the two ephemeral nodes for the 
> same server, but can protect it.



--
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-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8697:
--

Probably so.  I think we should close that one and assume it's fixed.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: 5.5.1, 6.0
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5839 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5839/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([B380E078D33A685B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11931 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrVersionReplicationTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.CdcrVersionReplicationTest_B380E078D33A685B-001\init-core-data-001
   [junit4]   2> 2095659 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[B380E078D33A685B]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 2095665 INFO  
(SUITE-CdcrVersionReplicationTest-seed#[B380E078D33A685B]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 2095668 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[B380E078D33A685B]) [ 
   ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2095669 INFO  (Thread-5390) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2095669 INFO  (Thread-5390) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2095768 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[B380E078D33A685B]) [ 
   ] o.a.s.c.ZkTestServer start zk server on port:60143
   [junit4]   2> 2095768 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[B380E078D33A685B]) [ 
   ] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2095769 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[B380E078D33A685B]) [ 
   ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2095774 INFO  (zkCallback-2257-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@2fba71 name:ZooKeeperConnection 
Watcher:127.0.0.1:60143 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 2095774 INFO  
(TEST-CdcrVersionReplicationTest.testCdcrDocVersions-seed#[B380E078D33A685B]) [ 
   ] 

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Jeff Wartes (JIRA)]

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

Jeff Wartes commented on SOLR-8697:
---

Does this fix SOLR-6498?

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: 5.5.1, 6.0
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



--
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-9092) Add safety checks to delete replica/shard/collection commands

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet commented on SOLR-9092:


We do want to delete the replica from cluster state even if the node doesn't 
appear under live_nodes, but it shouldn't send the core admin UNLOAD to the 
node unless it's appearing under live_nodes. In the situation where the node is 
down and we want to remove it from the cluster state, we would rely on the 
deleteCoreNode call to have it removed: 
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/OverseerCollectionMessageHandler.java#L634

> Add safety checks to delete replica/shard/collection commands
> -
>
> Key: SOLR-9092
> URL: https://issues.apache.org/jira/browse/SOLR-9092
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
>
> We should verify the delete commands against live_nodes to make sure the API 
> can atleast be executed correctly
> If we have a two node cluster, a collection with 1 shard 2 replica. Call the 
> delete replica command against for the replica whose node is currently down.
> You get an exception:
> {code}
> 
>
>   0
>   5173
>
>
>name="192.168.1.101:7574_solr">org.apache.solr.client.solrj.SolrServerException:Server
>  refused connection at: http://192.168.1.101:7574/solr
>
> 
> {code}
> At this point the entry for the replica is gone from state.json . The client 
> application retries since an error was thrown but the delete command will 
> never succeed now and an error like this will be seen-
> {code}
> 
>
>   400
>   137
>
>org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  Invalid replica : core_node3 in shard/collection : shard1/gettingstarted 
> available replicas are core_node1
>
>   Invalid replica : core_node3 in shard/collection : 
> shard1/gettingstarted available replicas are core_node1
>   400
>
>
>   
>  org.apache.solr.common.SolrException
>   name="root-error-class">org.apache.solr.common.SolrException
>   
>   Invalid replica : core_node3 in shard/collection : 
> shard1/gettingstarted available replicas are core_node1
>   400
>
> 
> {code}
> For create collection/add-replica we check the "createNodeSet" and "node" 
> params respectively against live_nodes to make sure it has a chance of 
> succeeding.
> We should add a check against live_nodes for the delete commands as well.
> Another situation where I saw this can be a problem - A second solr cluster 
> cloned from the first but the script didn't correctly change the hostnames in 
> the state.json file. When a delete command was issued against the second 
> cluster Solr deleted the replica from the first cluster.
> In the above case the script was buggy obviously but if we verify against 
> live_nodes then Solr wouldn't have gone ahead and deleted replicas not 
> belonging to its cluster.



--
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-7265) Fix addVersion to merge downstream changes by using the change id

[ASF subversion and git services (JIRA)]

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

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

Commit 1af681b05d88c1655956d4776a708fb58f7f7738 in lucene-solr's branch 
refs/heads/branch_6_0 from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1af681b ]

LUCENE-7265: Fix addVersion to cherry-pick downstream changes by using the 
change id


> Fix addVersion to merge downstream changes by using the change id
> -
>
> Key: LUCENE-7265
> URL: https://issues.apache.org/jira/browse/LUCENE-7265
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: LUCENE-7265.patch
>
>
> LUCENE-6938 led to the remove of code that merges the downstream changes for 
> addition of a new version. That seems like an accidental removal and we 
> should add it back with a few changes so that it now uses git instead of svn.



--
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-6637) Solr should have a way to restore a core

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-6637:


[~varunthacker] [~shalinmangar]

Please take a look at this code snippet,

https://github.com/apache/lucene-solr/blob/4193e60b9fc1ff12df2267778213ae3b0f04fb84/solr/core/src/java/org/apache/solr/handler/IndexFetcher.java#L605-L617

Is there a specific reason why we have used "SegmentInfos.readCommit(...)" 
method instead of just using "commit.getFileNames()" ? It seems equivalent as 
per my code understanding but not sure if I have missed anything...


> Solr should have a way to restore a core
> 
>
> Key: SOLR-6637
> URL: https://issues.apache.org/jira/browse/SOLR-6637
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
> SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, 
> SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch
>
>
> We have a core backup command which backs up the index. We should have a 
> restore command too. 
> This would restore any named snapshots created by the replication handlers 
> backup command.
> While working on this patch right now I realized that during backup we only 
> backup the index. Should we backup the conf files also? Any thoughts? I could 
> separate Jira for this.



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

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

Re: Lucene/Solr 6.0.1

[Upayavira]

There are a collection of minor UI patches languishing in JIRA that it
would be good to get out there too. I will endeavour to get them into
Git before Friday.

Upayavira

On Fri, 13 May 2016, at 06:07 PM, Steve Rowe wrote:
> Good idea, Adrien, but: I want to include SOLR-8992 in a 6.0.x release -
> it restores functionality unintentionally removed in 6.0.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On May 13, 2016, at 12:53 PM, Adrien Grand  wrote:
> > 
> > Hi Steve,
> > 
> > I think it is about time to do a 6.1 release as well since we have some 
> > nice pending improvements. So if that would cover your needs too, maybe we 
> > could skip 6.0.1 and do a 6.1 directly to save some work?
> > 
> > This is not an objection to doing a 6.0.1 release, I just wanted to throw 
> > out the idea of releasing 6.1 instead.
> > 
> > Le ven. 13 mai 2016 à 18:06, Steve Rowe  a écrit :
> > I’d like to make a 6.0.1 release, and I volunteer to be RM.
> > 
> > I propose to cut the first RC in one week: next Friday.
> > 
> > --
> > Steve
> > www.lucidworks.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

[jira] [Closed] (SOLR-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[David Smiley (JIRA)]

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

David Smiley closed SOLR-9069.
--
Resolution: Won't Fix

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



--
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: Lucene/Solr 6.0.1

[Steve Rowe]

Good idea, Adrien, but: I want to include SOLR-8992 in a 6.0.x release - it 
restores functionality unintentionally removed in 6.0.

--
Steve
www.lucidworks.com

> On May 13, 2016, at 12:53 PM, Adrien Grand  wrote:
> 
> Hi Steve,
> 
> I think it is about time to do a 6.1 release as well since we have some nice 
> pending improvements. So if that would cover your needs too, maybe we could 
> skip 6.0.1 and do a 6.1 directly to save some work?
> 
> This is not an objection to doing a 6.0.1 release, I just wanted to throw out 
> the idea of releasing 6.1 instead.
> 
> Le ven. 13 mai 2016 à 18:06, Steve Rowe  a écrit :
> I’d like to make a 6.0.1 release, and I volunteer to be RM.
> 
> I propose to cut the first RC in one week: next Friday.
> 
> --
> Steve
> www.lucidworks.com
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: lucene-solr:master: remove unnecessary Placeholder and mark old codec deprecated

[Chris Hostetter]

I don't have git repo handy to verify, but I think this may have broken 
precommit and be causing some recent jenkins failures?

http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/576/consoleText
:  [copy] Copying 1 file to 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/build/docs/backward-codecs
...
:   [javadoc] Loading source files for package org.apache.lucene.codecs...
:   [javadoc] javadoc: warning - No source files for package 
org.apache.lucene.codecs
...
: 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2163:
 Javadocs warnings were found!






On Fri, 13 May 2016, rm...@apache.org wrote:

: Date: Fri, 13 May 2016 01:13:45 + (UTC)
: From: rm...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr:master: remove unnecessary Placeholder and mark old codec
:  deprecated
: 
: Repository: lucene-solr
: Updated Branches:
:   refs/heads/master 062869626 -> 06034c247
: 
: 
: remove unnecessary Placeholder and mark old codec deprecated
: 
: 
: Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/06034c24
: Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/06034c24
: Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/06034c24
: 
: Branch: refs/heads/master
: Commit: 06034c247499f50b228dc86445bc8b4725016ca5
: Parents: 0628696
: Author: Robert Muir 
: Authored: Thu May 12 21:13:26 2016 -0400
: Committer: Robert Muir 
: Committed: Thu May 12 21:13:26 2016 -0400
: 
: --
:  .../org/apache/lucene/codecs/Placeholder.java   | 23 
:  .../lucene/codecs/lucene54/Lucene54Codec.java   |  2 ++
:  2 files changed, 2 insertions(+), 23 deletions(-)
: --
: 
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/06034c24/lucene/backward-codecs/src/java/org/apache/lucene/codecs/Placeholder.java
: --
: diff --git 
a/lucene/backward-codecs/src/java/org/apache/lucene/codecs/Placeholder.java 
b/lucene/backward-codecs/src/java/org/apache/lucene/codecs/Placeholder.java
: deleted file mode 100644
: index b0c292b..000
: --- 
a/lucene/backward-codecs/src/java/org/apache/lucene/codecs/Placeholder.java
: +++ /dev/null
: @@ -1,23 +0,0 @@
: -/*
: - * Licensed to the Apache Software Foundation (ASF) under one or more
: - * contributor license agreements.  See the NOTICE file distributed with
: - * this work for additional information regarding copyright ownership.
: - * The ASF licenses this file to You under the Apache License, Version 2.0
: - * (the "License"); you may not use this file except in compliance with
: - * the License.  You may obtain a copy of the License at
: - *
: - * http://www.apache.org/licenses/LICENSE-2.0
: - *
: - * Unless required by applicable law or agreed to in writing, software
: - * distributed under the License is distributed on an "AS IS" BASIS,
: - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
: - * See the License for the specific language governing permissions and
: - * limitations under the License.
: - */
: -package org.apache.lucene.codecs;
: -
: -
: -/** Remove this file when adding back compat codecs */
: -public class Placeholder {
: -  
: -}
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/06034c24/lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene54/Lucene54Codec.java
: --
: diff --git 
a/lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene54/Lucene54Codec.java
 
b/lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene54/Lucene54Codec.java
: index 2dde0cf..d982d3b 100644
: --- 
a/lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene54/Lucene54Codec.java
: +++ 
b/lucene/backward-codecs/src/java/org/apache/lucene/codecs/lucene54/Lucene54Codec.java
: @@ -51,7 +51,9 @@ import 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat;
:   *
:   * @see org.apache.lucene.codecs.lucene54 package documentation for file 
format details.
:   * @lucene.experimental
: + * @deprecated Only for 5.x back compat
:   */
: +@Deprecated
:  public class Lucene54Codec extends Codec {
:private final TermVectorsFormat vectorsFormat = new 
Lucene50TermVectorsFormat();
:private final FieldInfosFormat fieldInfosFormat = new 
Lucene50FieldInfosFormat();
: 
: 

-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-8323) Add CollectionWatcher API to ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-8323:

Attachment: SOLR-8323.patch

Final patch.  I think this is ready!

> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch, SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
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-9106) Cache cluster properties in ZkStateReader

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9106:

Attachment: SOLR-9106.patch

Hm, so a couple of the tests complicate this a bit by calling ZkStateReader 
*without* setting up all the watches, etc (something that I want to make not 
possible in SOLR-9056).  To get around this, I've introduced a 
ClusterProperties class that will read and write properties in real-time, if 
need be.

I've also had to make the ZkController baseURL non-final, because it needs to 
be set *after* the state reader watches are created, and that isn't done in the 
constructor.  Which is annoying, but again SOLR-9056 cleans that up so I'm not 
too concerned.

All tests pass with this patch.

> Cache cluster properties in ZkStateReader
> -
>
> Key: SOLR-9106
> URL: https://issues.apache.org/jira/browse/SOLR-9106
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9106.patch, SOLR-9106.patch
>
>
> ZkStateReader currently makes calls into ZK every time getClusterProps() is 
> called.  Instead we should keep the data locally and use a Watcher to update 
> it.



--
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: Lucene/Solr 6.0.1

[Adrien Grand]

Hi Steve,

I think it is about time to do a 6.1 release as well since we have some
nice pending improvements. So if that would cover your needs too, maybe we
could skip 6.0.1 and do a 6.1 directly to save some work?

This is not an objection to doing a 6.0.1 release, I just wanted to throw
out the idea of releasing 6.1 instead.

Le ven. 13 mai 2016 à 18:06, Steve Rowe  a écrit :

> I’d like to make a 6.0.1 release, and I volunteer to be RM.
>
> I propose to cut the first RC in one week: next Friday.
>
> --
> Steve
> 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-6.x-Solaris (64bit/jdk1.8.0) - Build # 129 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/129/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 52323 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] javadoc: warning - No source files for package 
org.apache.lucene.codecs
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0_92
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/build/docs/backward-codecs/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:740: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/build.xml:101: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/build.xml:138: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/build.xml:246: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/module-build.xml:65:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/module-build.xml:78:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/lucene/common-build.xml:2163:
 Javadocs warnings were found!

Total time: 102 minutes 59 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

Re: Lucene/Solr 6.0.1

[David Smiley]

When you cut the branch, I'll port the "gregorian change date" bugs/issues
(2 Solr, 1 Lucene).

On Fri, May 13, 2016 at 12:06 PM Steve Rowe  wrote:

> I’d like to make a 6.0.1 release, and I volunteer to be RM.
>
> I propose to cut the first RC in one week: next Friday.
>
> --
> Steve
> www.lucidworks.com
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Lucene/Solr 6.0.1

[Steve Rowe]

I’d like to make a 6.0.1 release, and I volunteer to be RM.

I propose to cut the first RC in one week: next Friday.

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

[jira] [Commented] (SOLR-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8208:


I.ll fix it in a few hours. Is there a quick hint, how to ? I remember 
something about setting numShards.. But appreciate a suggestion.

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in =\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..=name_s:john=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}=text_t,dept_id_s_dv=12=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave=true=*,depts:[subquery]=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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: Solr distributed tests

[Erick Erickson]

"Tread on the toes"? Not in my book!

Go Alan! Go!

On Fri, May 13, 2016 at 7:25 AM, Varun Thacker
 wrote:
> This should reduce the runtime of the tests by quite a bit as well :)
>
> On Fri, May 13, 2016 at 7:50 PM, David Smiley 
> wrote:
>>
>> Thanks for doing this!
>>
>> On Fri, May 13, 2016 at 5:36 AM Alan Woodward  wrote:
>>>
>>> Hi all,
>>>
>>> We currently have 109 tests in solr that extend
>>> AbstractDistribZkTestBase.  These all rely on 'legacy cloud' behaviour - the
>>> test creates a bunch of core directories and properties files, which then
>>> automagically instantiate a collection when they are loaded.  This is
>>> behaviour that ideally we want to deprecate and remove, migrating everything
>>> to a 'ZK is truth' mode; the fact that almost all our cloud-based tests rely
>>> on this behaviour is a bit of a hindrance here.
>>>
>>> Starting next week, I'd like to migrate as many of these tests as
>>> possible to using SolrCloudTestCase instead.  I'll move them in groups,
>>> creating individual JIRAs for each group, to break things down a bit.  A lot
>>> of these tests are from the very early days of Solr Cloud, before many of
>>> the APIs were added, so they can probably be simplified at the same time.
>>>
>>> I migrated the SolrJ tests last week in SOLR-9065, and managed to tread
>>> on the toes of a bunch of people already working on them, so this is a
>>> heads-up to try and avoid that happening again.  If anybody is actively
>>> working on a test that's derived from AbstractDistribZkTestBase, please let
>>> me know, and I can either hold off on migrating that test, or help out with
>>> moving it across.  And of course, if anybody else wants to join in, then
>>> feel free :)
>>>
>>> Alan Woodward
>>> www.flax.co.uk
>>>
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>
>
>
>
> --
>
>
> Regards,
> Varun Thacker

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

[jira] [Comment Edited] (SOLR-8492) Add LogisticRegressionQuery and LogitStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8492 at 5/13/16 2:57 PM:
---

[~teofili], I'd like to get another set of eyes on this. I've been looking at 
this for a while but I'm still not comfortable enough with the math to commit. 
If you're comfortable reviewing the math, I can work on reworking tests for the 
new SolrCloud testing framework.


was (Author: joel.bernstein):
[~teofili], I'd like to get another set of eyes on this. I've been looking at 
this for a while but I'm still not comfortable enough with the math to commit. 
I'm your comfortable reviewing the math, I can work on reworking tests for the 
new SolrCloud testing framework.

> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
> Fix For: 6.1
>
> Attachments: SOLR-8492.diff, SOLR-8492.diff, SOLR-8492.patch, 
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, 
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, logit.csv
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery 
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
>  and returns a DelegatingCollector that implements a Stochastic Gradient 
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions 
> to provide iteration over the shards. Each call to LogitStream.read() calls 
> down to the shards and executes the LogisticRegressionQuery. The model data 
> is collected from the shards and the weights are averaged and sent back to 
> the shards with the next iteration. Each call to read() returns a Tuple with 
> the averaged weights and error from the shards. With this approach the 
> LogitStream streams the changing model back to the client after each 
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined 
> maxIterations. When sent as a Streaming Expression to the Stream handler this 
> provides parallel iterative behavior. This same approach can be used to 
> implement other parallel iterative algorithms.
> The initial patch has  a test which simply tests the mechanics of the 
> iteration. More work will need to be done to ensure the SGD is properly 
> implemented. The distributed approach of the SGD will also need to be 
> reviewed.  
> This implementation is designed for use cases with a small number of features 
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be 
> possible by packing features into a byte array and storing as binary 
> DocValues.
> This implementation is designed to support a large sample set. With a large 
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {code}



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

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

[jira] [Commented] (SOLR-8492) Add LogisticRegressionQuery and LogitStream

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8492:
--

[~teofili], I'd like to get another set of eyes on this. I've been looking at 
this for a while but I'm still not comfortable enough with the math to commit. 
I'm your comfortable reviewing the math, I can work on reworking tests for the 
new SolrCloud testing framework.

> Add LogisticRegressionQuery and LogitStream
> ---
>
> Key: SOLR-8492
> URL: https://issues.apache.org/jira/browse/SOLR-8492
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
> Fix For: 6.1
>
> Attachments: SOLR-8492.diff, SOLR-8492.diff, SOLR-8492.patch, 
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, 
> SOLR-8492.patch, SOLR-8492.patch, SOLR-8492.patch, logit.csv
>
>
> This ticket is to add a new query called a LogisticRegressionQuery (LRQ).
> The LRQ extends AnalyticsQuery 
> (http://joelsolr.blogspot.com/2015/12/understanding-solrs-analyticsquery.html)
>  and returns a DelegatingCollector that implements a Stochastic Gradient 
> Descent (SGD) optimizer for Logistic Regression.
> This ticket also adds the LogitStream which leverages Streaming Expressions 
> to provide iteration over the shards. Each call to LogitStream.read() calls 
> down to the shards and executes the LogisticRegressionQuery. The model data 
> is collected from the shards and the weights are averaged and sent back to 
> the shards with the next iteration. Each call to read() returns a Tuple with 
> the averaged weights and error from the shards. With this approach the 
> LogitStream streams the changing model back to the client after each 
> iteration.
> The LogitStream will return the EOF Tuple when it reaches the defined 
> maxIterations. When sent as a Streaming Expression to the Stream handler this 
> provides parallel iterative behavior. This same approach can be used to 
> implement other parallel iterative algorithms.
> The initial patch has  a test which simply tests the mechanics of the 
> iteration. More work will need to be done to ensure the SGD is properly 
> implemented. The distributed approach of the SGD will also need to be 
> reviewed.  
> This implementation is designed for use cases with a small number of features 
> because each feature is it's own discreet field.
> An implementation which supports a higher number of features would be 
> possible by packing features into a byte array and storing as binary 
> DocValues.
> This implementation is designed to support a large sample set. With a large 
> number of shards, a sample set into the billions may be possible.
> sample Streaming Expression Syntax:
> {code}
> logit(collection1, features="a,b,c,d,e,f" outcome="x" maxIterations="80")
> {code}



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

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

[jira] [Updated] (LUCENE-6438) Improve clean-jars when dealing with symbolic links.

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-6438:
---
Attachment: LUCENE-6438.patch

Patch that fixed the problem for me, from last year, but the idea will still 
apply even if the patch won't.

I haven't run into this problem recently, so I can't say for sure whether the 
sync-hack removal fixed all of the problems.

> Improve clean-jars when dealing with symbolic links.
> 
>
> Key: LUCENE-6438
> URL: https://issues.apache.org/jira/browse/LUCENE-6438
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: LUCENE-6438.patch
>
>
> Ever since I started seeing jars in the lib folders use symbolic links on 
> linux I've run into jar problems when working with an old checkout or 
> switching branches on a git checkout. You would normally expect ant 
> clean-jars to help, but it didn't and led to some headaches and random bs.
> Turns out, clean-jars is not properly removing all symbolic links for me. 
> I've seen two cases - symbolic links to jars that are not removed and broken 
> symbolic links to jars.
> I can get rid of the symbolic links with the following:
> {code}
>   
> 
>   
> {code}
> But that doesn't work with the broken links.
> I guess you can remove those with the Ant Symlink task, but it seems only 
> specifically one at a time which is not that useful.



--
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: Solr distributed tests

[Varun Thacker]

This should reduce the runtime of the tests by quite a bit as well :)

On Fri, May 13, 2016 at 7:50 PM, David Smiley 
wrote:

> Thanks for doing this!
>
> On Fri, May 13, 2016 at 5:36 AM Alan Woodward  wrote:
>
>> Hi all,
>>
>> We currently have 109 tests in solr that extend
>> AbstractDistribZkTestBase.  These all rely on 'legacy cloud' behaviour -
>> the test creates a bunch of core directories and properties files, which
>> then automagically instantiate a collection when they are loaded.  This is
>> behaviour that ideally we want to deprecate and remove, migrating
>> everything to a 'ZK is truth' mode; the fact that almost all our
>> cloud-based tests rely on this behaviour is a bit of a hindrance here.
>>
>> Starting next week, I'd like to migrate as many of these tests as
>> possible to using SolrCloudTestCase instead.  I'll move them in groups,
>> creating individual JIRAs for each group, to break things down a bit.  A
>> lot of these tests are from the very early days of Solr Cloud, before many
>> of the APIs were added, so they can probably be simplified at the same time.
>>
>> I migrated the SolrJ tests last week in SOLR-9065, and managed to tread
>> on the toes of a bunch of people already working on them, so this is a
>> heads-up to try and avoid that happening again.  If anybody is actively
>> working on a test that's derived from AbstractDistribZkTestBase, please let
>> me know, and I can either hold off on migrating that test, or help out with
>> moving it across.  And of course, if anybody else wants to join in, then
>> feel free :)
>>
>> Alan Woodward
>> www.flax.co.uk
>>
>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>



-- 


Regards,
Varun Thacker

Re: Solr distributed tests

[Joel Bernstein]

The refactoring of the Solrj tests made things much cleaner and faster.
Nice work!

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

On Fri, May 13, 2016 at 10:20 AM, David Smiley 
wrote:

> Thanks for doing this!
>
> On Fri, May 13, 2016 at 5:36 AM Alan Woodward  wrote:
>
>> Hi all,
>>
>> We currently have 109 tests in solr that extend
>> AbstractDistribZkTestBase.  These all rely on 'legacy cloud' behaviour -
>> the test creates a bunch of core directories and properties files, which
>> then automagically instantiate a collection when they are loaded.  This is
>> behaviour that ideally we want to deprecate and remove, migrating
>> everything to a 'ZK is truth' mode; the fact that almost all our
>> cloud-based tests rely on this behaviour is a bit of a hindrance here.
>>
>> Starting next week, I'd like to migrate as many of these tests as
>> possible to using SolrCloudTestCase instead.  I'll move them in groups,
>> creating individual JIRAs for each group, to break things down a bit.  A
>> lot of these tests are from the very early days of Solr Cloud, before many
>> of the APIs were added, so they can probably be simplified at the same time.
>>
>> I migrated the SolrJ tests last week in SOLR-9065, and managed to tread
>> on the toes of a bunch of people already working on them, so this is a
>> heads-up to try and avoid that happening again.  If anybody is actively
>> working on a test that's derived from AbstractDistribZkTestBase, please let
>> me know, and I can either hold off on migrating that test, or help out with
>> moving it across.  And of course, if anybody else wants to join in, then
>> feel free :)
>>
>> Alan Woodward
>> www.flax.co.uk
>>
>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Solr distributed tests

[David Smiley]

Thanks for doing this!

On Fri, May 13, 2016 at 5:36 AM Alan Woodward  wrote:

> Hi all,
>
> We currently have 109 tests in solr that extend
> AbstractDistribZkTestBase.  These all rely on 'legacy cloud' behaviour -
> the test creates a bunch of core directories and properties files, which
> then automagically instantiate a collection when they are loaded.  This is
> behaviour that ideally we want to deprecate and remove, migrating
> everything to a 'ZK is truth' mode; the fact that almost all our
> cloud-based tests rely on this behaviour is a bit of a hindrance here.
>
> Starting next week, I'd like to migrate as many of these tests as possible
> to using SolrCloudTestCase instead.  I'll move them in groups, creating
> individual JIRAs for each group, to break things down a bit.  A lot of
> these tests are from the very early days of Solr Cloud, before many of the
> APIs were added, so they can probably be simplified at the same time.
>
> I migrated the SolrJ tests last week in SOLR-9065, and managed to tread on
> the toes of a bunch of people already working on them, so this is a
> heads-up to try and avoid that happening again.  If anybody is actively
> working on a test that's derived from AbstractDistribZkTestBase, please let
> me know, and I can either hold off on migrating that test, or help out with
> moving it across.  And of course, if anybody else wants to join in, then
> feel free :)
>
> Alan Woodward
> www.flax.co.uk
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Resolved] (SOLR-9085) DateRangeField is broken before the year 1582

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-9085.

Resolution: Fixed

> DateRangeField is broken before the year 1582
> -
>
> Key: SOLR-9085
> URL: https://issues.apache.org/jira/browse/SOLR-9085
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR-9085.patch
>
>
> DateRangeField has some issues for dates before 1582 (the Gregorian Change 
> Date), following Solr 6.  The main problem is that it uses DateMathParser 
> which no longer observes a GCD and then it converts that Date to a Calendar 
> using Calendar.setTime(date) which considers the GCD.  We can't altogether 
> avoid Calendar.java as in SOLR-9080 because DateRangePrefixTree currently 
> fundamentally depends on it.  However I recently learned we can simply change 
> the GCD like so: {{cal.setGregorianChange(new Date(Long.MIN_VALUE));}} 
> beforehand.  DateRangeField also calls Calendar.getTime as well, which is 
> affected by GCD considerations.
> For users that use DateRangeField but do *not* use "Date Math" and do not 
> have 'Z' in their date strings then date strings are completely parsed by 
> DateRangePrefixTree and there should be no issue.
> DateRangePrefixTree ought to be improved a bit too (in a separate issue)... 
> like making the GCD configurable, and setting using 
> SimpleDateFormatter.setCalendar it uses to format.



--
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-7283) Move SlowCompositeReaderWrapper to solr sources

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7283:
--

Maybe it's worth asking on java-u...@lucene.apache.org to get a sense from the 
community what they think?  I have no idea if it's used or not outside of Solr. 
 It's already outside core, which is good.

> Move SlowCompositeReaderWrapper to solr sources
> ---
>
> Key: LUCENE-7283
> URL: https://issues.apache.org/jira/browse/LUCENE-7283
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>
> Spinoff from LUCENE-6766, where we fixed index-time sorting to have first 
> class support in Lucene's ore, and no longer use 
> {{SlowCompositeReaderWrapper}}.
> This is a dangerous, long living class, that tries to pretend a set of N 
> segments is actually just a single segment.  It's a leaky abstraction, has 
> poor performance, and puts undue pressure on the APIs of new Lucene features 
> to try to keep up this illusion.
> With LUCENE-6766, finally all usage of this class (except for 
> {{UninvertedReader}} tests, which should maybe also move out?) has been 
> removed from Lucene, so I think we should move it to Solr.  This may also 
> lead to a solution for LUCENE-7086 since e.g. the class could tap into solr's 
> schema to "know" how to handle points fields properly.



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

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

[jira] [Resolved] (SOLR-9080) DateMath is broken before the year 1582

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-9080.

Resolution: Fixed

> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch, 
> SOLR_9080_DateMath_should_not_use_Calendar_API.patch
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



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

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

[jira] [Commented] (SOLR-9080) DateMath is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale
(cherry picked from commit 4193e60)


> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch, 
> SOLR_9080_DateMath_should_not_use_Calendar_API.patch
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



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

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

[jira] [Commented] (SOLR-9085) DateRangeField is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale
(cherry picked from commit 4193e60)


> DateRangeField is broken before the year 1582
> -
>
> Key: SOLR-9085
> URL: https://issues.apache.org/jira/browse/SOLR-9085
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR-9085.patch
>
>
> DateRangeField has some issues for dates before 1582 (the Gregorian Change 
> Date), following Solr 6.  The main problem is that it uses DateMathParser 
> which no longer observes a GCD and then it converts that Date to a Calendar 
> using Calendar.setTime(date) which considers the GCD.  We can't altogether 
> avoid Calendar.java as in SOLR-9080 because DateRangePrefixTree currently 
> fundamentally depends on it.  However I recently learned we can simply change 
> the GCD like so: {{cal.setGregorianChange(new Date(Long.MIN_VALUE));}} 
> beforehand.  DateRangeField also calls Calendar.getTime as well, which is 
> affected by GCD considerations.
> For users that use DateRangeField but do *not* use "Date Math" and do not 
> have 'Z' in their date strings then date strings are completely parsed by 
> DateRangePrefixTree and there should be no issue.
> DateRangePrefixTree ought to be improved a bit too (in a separate issue)... 
> like making the GCD configurable, and setting using 
> SimpleDateFormatter.setCalendar it uses to format.



--
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-9080) DateMath is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale


> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR_9080_DateMath_should_not_use_Calendar_API.patch, 
> SOLR_9080_DateMath_should_not_use_Calendar_API.patch
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



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

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

[jira] [Commented] (SOLR-9085) DateRangeField is broken before the year 1582

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9080 SOLR-9085: Fix date math before the year 1582.
note: DateMathParser no longer needs a Locale


> DateRangeField is broken before the year 1582
> -
>
> Key: SOLR-9085
> URL: https://issues.apache.org/jira/browse/SOLR-9085
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.1
>
> Attachments: SOLR-9085.patch
>
>
> DateRangeField has some issues for dates before 1582 (the Gregorian Change 
> Date), following Solr 6.  The main problem is that it uses DateMathParser 
> which no longer observes a GCD and then it converts that Date to a Calendar 
> using Calendar.setTime(date) which considers the GCD.  We can't altogether 
> avoid Calendar.java as in SOLR-9080 because DateRangePrefixTree currently 
> fundamentally depends on it.  However I recently learned we can simply change 
> the GCD like so: {{cal.setGregorianChange(new Date(Long.MIN_VALUE));}} 
> beforehand.  DateRangeField also calls Calendar.getTime as well, which is 
> affected by GCD considerations.
> For users that use DateRangeField but do *not* use "Date Math" and do not 
> have 'Z' in their date strings then date strings are completely parsed by 
> DateRangePrefixTree and there should be no issue.
> DateRangePrefixTree ought to be improved a bit too (in a separate issue)... 
> like making the GCD configurable, and setting using 
> SimpleDateFormatter.setCalendar it uses to format.



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

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

[jira] [Comment Edited] (SOLR-8208) DocTransformer executes sub-queries

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-8208 at 5/13/16 1:54 PM:
---

Here's a reproducible failure of TestSubQueryTransformerDistrib on my Jenkins:

{noformat}
Checking out Revision 9d5b834b09d4ff23e89755e5d1af407a2bd96c16 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSubQueryTransformerDistrib -Dtests.method=test 
-Dtests.seed=A6B6D43AC01C202D -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=de-LU -Dtests.timezone=Pacific/Tongatapu -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   55.9s J7 | TestSubQueryTransformerDistrib.test <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54181: Cannot create collection departments. 
Value of maxShardsPerNode is 12, and the number of nodes currently live or live 
and part of your createNodeSet is 5. This allows a maximum of 60 to be created. 
Value of numShards is 6 and value of replicationFactor is 12. This requires 72 
shards to be created (higher than the allowed number)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A6B6D43AC01C202D:2EE2EBE06EE04DD5]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1592)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1549)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1604)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1545)
   [junit4]>at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:64)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> 743644 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[A6B6D43AC01C202D]-worker) [] 
o.a.s.SolrTestCaseJ4 ###deleteCore
   [junit4]   2> NOTE: leaving temporary files on disk at: 
/var/lib/jenkins/jobs/Lucene-Solr-Nightly-master/workspace/solr/build/solr-core/test/J7/temp/solr.response.transform.TestSubQueryTransformerDistrib_A6B6D43AC01C202D-001
   [junit4]   2> May 13, 2016 7:06:27 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=772, maxMBSortInHeap=6.297414713628615, 
sim=RandomSimilarity(queryNorm=true,coord=no): {}, locale=de-LU, 
timezone=Pacific/Tongatapu
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=267803120,total=527433728
   [junit4]   2> NOTE: All tests run in this JVM: 
[CoreMergeIndexesAdminHandlerTest, TestIBSimilarityFactory, 
AnalyticsMergeStrategyTest, SolrIndexSplitterTest, SolrPluginUtilsTest, 
DocumentBuilderTest, TestQueryTypes, BlockJoinFacetDistribTest, 
TestReplicationHandlerBackup, BadIndexSchemaTest, DistanceUnitsTest, 
CleanupOldIndexTest, OverseerRolesTest, DocValuesTest, 
DistributedFacetPivotSmallAdvancedTest, TestReloadAndDeleteDocs, TestSolrJ, 
TestPHPSerializedResponseWriter, TlogReplayBufferedWhileIndexingTest, 
TestSha256AuthenticationProvider, TestFaceting, DeleteStatusTest, 
TestSubQueryTransformerDistrib]
   [junit4] Completed [218/597 (3!)] on J7 in 56.17s, 1 test, 1 error <<< 
FAILURES!
{noformat}

and another one from ASFJenkins a few days back 
[https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1011/]:

{noformat}
Checking out Revision 470ba0794ecddd6375db3da521272dde46ed6761 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  

[jira] [Commented] (SOLR-8208) DocTransformer executes sub-queries

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8208:
--

Here's a reproducible failure of TestSubQueryTransformerDistrib on my Jenkins:

{noformat}
Checking out Revision 9d5b834b09d4ff23e89755e5d1af407a2bd96c16 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSubQueryTransformerDistrib -Dtests.method=test 
-Dtests.seed=A6B6D43AC01C202D -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=de-LU -Dtests.timezone=Pacific/Tongatapu -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   55.9s J7 | TestSubQueryTransformerDistrib.test <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:54181: Cannot create collection departments. 
Value of maxShardsPerNode is 12, and the number of nodes currently live or live 
and part of your createNodeSet is 5. This allows a maximum of 60 to be created. 
Value of numShards is 6 and value of replicationFactor is 12. This requires 72 
shards to be created (higher than the allowed number)
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A6B6D43AC01C202D:2EE2EBE06EE04DD5]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1592)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1549)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1604)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1545)
   [junit4]>at 
org.apache.solr.response.transform.TestSubQueryTransformerDistrib.test(TestSubQueryTransformerDistrib.java:64)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> 743644 INFO  
(SUITE-TestSubQueryTransformerDistrib-seed#[A6B6D43AC01C202D]-worker) [] 
o.a.s.SolrTestCaseJ4 ###deleteCore
   [junit4]   2> NOTE: leaving temporary files on disk at: 
/var/lib/jenkins/jobs/Lucene-Solr-Nightly-master/workspace/solr/build/solr-core/test/J7/temp/solr.response.transform.TestSubQueryTransformerDistrib_A6B6D43AC01C202D-001
   [junit4]   2> May 13, 2016 7:06:27 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
docValues:{}, maxPointsInLeafNode=772, maxMBSortInHeap=6.297414713628615, 
sim=RandomSimilarity(queryNorm=true,coord=no): {}, locale=de-LU, 
timezone=Pacific/Tongatapu
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=267803120,total=527433728
   [junit4]   2> NOTE: All tests run in this JVM: 
[CoreMergeIndexesAdminHandlerTest, TestIBSimilarityFactory, 
AnalyticsMergeStrategyTest, SolrIndexSplitterTest, SolrPluginUtilsTest, 
DocumentBuilderTest, TestQueryTypes, BlockJoinFacetDistribTest, 
TestReplicationHandlerBackup, BadIndexSchemaTest, DistanceUnitsTest, 
CleanupOldIndexTest, OverseerRolesTest, DocValuesTest, 
DistributedFacetPivotSmallAdvancedTest, TestReloadAndDeleteDocs, TestSolrJ, 
TestPHPSerializedResponseWriter, TlogReplayBufferedWhileIndexingTest, 
TestSha256AuthenticationProvider, TestFaceting, DeleteStatusTest, 
TestSubQueryTransformerDistrib]
   [junit4] Completed [218/597 (3!)] on J7 in 56.17s, 1 test, 1 error <<< 
FAILURES!
{noformat}

and another one from Policeman Jenkins a few days back:

{noformat}
Checking out Revision 470ba0794ecddd6375db3da521272dde46ed6761 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSubQueryTransformerDistrib -Dtests.method=test 
-Dtests.seed=594D23296C3F97B8 -Dtests.multiplier=2 -Dtests.nightly=true 

[jira] [Resolved] (SOLR-9072) Move morphline zk tests to SolrCloudTestCase

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-9072.
-
   Resolution: Fixed
Fix Version/s: (was: 6.0)
   master (7.0)

> Move morphline zk tests to SolrCloudTestCase
> 
>
> Key: SOLR-9072
> URL: https://issues.apache.org/jira/browse/SOLR-9072
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-9072.patch
>
>
> Three tests need moving here.



--
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-9072) Move morphline zk tests to SolrCloudTestCase

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9072: Move morphline-core zk tests to SolrCloudTestCase


> Move morphline zk tests to SolrCloudTestCase
> 
>
> Key: SOLR-9072
> URL: https://issues.apache.org/jira/browse/SOLR-9072
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.0, 6.1
>
> Attachments: SOLR-9072.patch
>
>
> Three tests need moving here.



--
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-9072) Move morphline zk tests to SolrCloudTestCase

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9072: Move morphline-core zk tests to SolrCloudTestCase


> Move morphline zk tests to SolrCloudTestCase
> 
>
> Key: SOLR-9072
> URL: https://issues.apache.org/jira/browse/SOLR-9072
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.0, 6.1
>
> Attachments: SOLR-9072.patch
>
>
> Three tests need moving here.



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

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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([CAE3BB163F7C34BF:3D90554EF9949B59]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1329)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11085 lines...]
   [junit4] Suite: 

[jira] [Commented] (LUCENE-4702) Terms dictionary compression

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-4702:
--

I've had interest in this patch again for compression of uid fields. For 
instance if you are using flake ids (https://github.com/boundary/flake 16 
bytes: 8 bytes for the timestamp, 6 for the mac address and 2 for a counter), 
there is a lot of redundancy in the suffixes due to the mac address component. 
It is possible to help compression by moving the mac address closer to the 
beginning of the id (so that the prefix compression that the terms dict 
performs helps, and since Lucene does not need ids to be sortable) but then 
this makes lookups slower since we need to walk more bytes of the id before 
realizing it does not belong to a segment. 

For instance I simulated a 100 docs/s indexing rate with 4 unique mac 
addresses, and the size of the terms dictionary decreased from 16.4 bytes per 
id to ~13 bytes per id (-20%) with the patch. Maybe we could fold it into the 
block tree terms dict but only enable it on unique fields and/or if the codec 
is configured with BEST_COMPRESSION.

> Terms dictionary compression
> 
>
> Key: LUCENE-4702
> URL: https://issues.apache.org/jira/browse/LUCENE-4702
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Trivial
> Attachments: LUCENE-4702.patch, LUCENE-4702.patch
>
>
> I've done a quick test with the block tree terms dictionary by replacing a 
> call to IndexOutput.writeBytes to write suffix bytes with a call to 
> LZ4.compressHC to test the peformance hit. Interestingly, search performance 
> was very good (see comparison table below) and the tim files were 14% smaller 
> (from 150432 bytes overall to 129516).
> {noformat}
> TaskQPS baseline  StdDevQPS compressed  StdDev
> Pct diff
>   Fuzzy1  111.50  (2.0%)   78.78  (1.5%)  
> -29.4% ( -32% -  -26%)
>   Fuzzy2   36.99  (2.7%)   28.59  (1.5%)  
> -22.7% ( -26% -  -18%)
>  Respell  122.86  (2.1%)  103.89  (1.7%)  
> -15.4% ( -18% -  -11%)
> Wildcard  100.58  (4.3%)   94.42  (3.2%)   
> -6.1% ( -13% -1%)
>  Prefix3  124.90  (5.7%)  122.67  (4.7%)   
> -1.8% ( -11% -9%)
>OrHighLow  169.87  (6.8%)  167.77  (8.0%)   
> -1.2% ( -15% -   14%)
>  LowTerm 1949.85  (4.5%) 1929.02  (3.4%)   
> -1.1% (  -8% -7%)
>   AndHighLow 2011.95  (3.5%) 1991.85  (3.3%)   
> -1.0% (  -7% -5%)
>   OrHighHigh  155.63  (6.7%)  154.12  (7.9%)   
> -1.0% ( -14% -   14%)
>  AndHighHigh  341.82  (1.2%)  339.49  (1.7%)   
> -0.7% (  -3% -2%)
>OrHighMed  217.55  (6.3%)  216.16  (7.1%)   
> -0.6% ( -13% -   13%)
>   IntNRQ   53.10 (10.9%)   52.90  (8.6%)   
> -0.4% ( -17% -   21%)
>  MedTerm  998.11  (3.8%)  994.82  (5.6%)   
> -0.3% (  -9% -9%)
>  MedSpanNear   60.50  (3.7%)   60.36  (4.8%)   
> -0.2% (  -8% -8%)
> HighSpanNear   19.74  (4.5%)   19.72  (5.1%)   
> -0.1% (  -9% -9%)
>  LowSpanNear  101.93  (3.2%)  101.82  (4.4%)   
> -0.1% (  -7% -7%)
>   AndHighMed  366.18  (1.7%)  366.93  (1.7%)
> 0.2% (  -3% -3%)
> PKLookup  237.28  (4.0%)  237.96  (4.2%)
> 0.3% (  -7% -8%)
>MedPhrase  173.17  (4.7%)  174.69  (4.7%)
> 0.9% (  -8% -   10%)
>  LowSloppyPhrase  180.91  (2.6%)  182.79  (2.7%)
> 1.0% (  -4% -6%)
>LowPhrase  374.64  (5.5%)  379.11  (5.8%)
> 1.2% (  -9% -   13%)
> HighTerm  253.14  (7.9%)  256.97 (11.4%)
> 1.5% ( -16% -   22%)
>   HighPhrase   19.52 (10.6%)   19.83 (11.0%)
> 1.6% ( -18% -   25%)
>  MedSloppyPhrase  141.90  (2.6%)  144.11  (2.5%)
> 1.6% (  -3% -6%)
> HighSloppyPhrase   25.26  (4.8%)   25.97  (5.0%)
> 2.8% (  -6% -   13%)
> {noformat}
> Only queries which are very terms-dictionary-intensive got a performance hit 
> (Fuzzy, Fuzzy2, Respell, Wildcard), other queries including Prefix3 behaved 
> (surprisingly) well.
> Do you think of it as something worth exploring?



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

[jira] [Updated] (SOLR-8806) NPE Exporting request handler

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-8806:

Fix Version/s: master (7.0)

> NPE Exporting request handler
> -
>
> Key: SOLR-8806
> URL: https://issues.apache.org/jira/browse/SOLR-8806
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5
>Reporter: Markus Jelsma
> Fix For: master (7.0)
>
>
> Tried exporting request handler for dumping an entire index (which wasn't 
> going to work because of docValues not on all fields, too bad). Got two 
> distinct NPE's in SortingResponseWriter for sort by int and sort by string.
> Sort by int:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at 
> org.apache.solr.response.SortingResponseWriter$IntValue.setCurrentValue(SortingResponseWriter.java:797)
> at 
> org.apache.solr.response.SortingResponseWriter$SingleValueSortDoc.setValues(SortingResponseWriter.java:472)
> at 
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:141)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:52)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:743)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:467)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183)
> {code}
> Sort by string, which is a bit different:
> {code}
> o.a.s.s.HttpSolrCall null:java.io.IOException: java.lang.NullPointerException
> at 
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:185)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:52)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:743)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:467)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.solr.response.SortingResponseWriter$StringFieldWriter.write(SortingResponseWriter.java:1289)
> at 
> org.apache.solr.response.SortingResponseWriter.writeDoc(SortingResponseWriter.java:222)
> at 
> org.apache.solr.response.SortingResponseWriter.write(SortingResponseWriter.java:167)
> ... 25 more
> {code}



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

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

[jira] [Updated] (SOLR-8969) SQLHandler causes NPE in non-cloud mode

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-8969:

Fix Version/s: master (7.0)

> SQLHandler causes NPE in non-cloud mode
> ---
>
> Key: SOLR-8969
> URL: https://issues.apache.org/jira/browse/SOLR-8969
> Project: Solr
>  Issue Type: Bug
>  Components: Parallell SQL
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (7.0)
>
>
> It should instead throw a proper error message. Stack trace:
> {code}
> 1233075 INFO  (qtp97730845-21) [   x:logs] o.a.s.c.S.Request [logs]  
> webapp=/solr path=/sql params={stmt=SELECT+uid+FROM+logs} status=0 QTime=18
> 1233095 INFO  (qtp97730845-21) [   x:logs] o.a.s.c.c.SolrZkClient Using 
> default ZkCredentialsProvider
> 1233109 ERROR (qtp97730845-21) [   x:logs] o.a.s.c.s.i.s.ExceptionStream 
> org.apache.solr.common.SolrException: java.lang.NullPointerException
> at 
> org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:169)
> at 
> org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
> at 
> org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:105)
> at 
> org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:200)
> at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:466)
> at 
> org.apache.solr.client.solrj.io.SolrClientCache.getCloudSolrClient(SolrClientCache.java:48)
> at 
> org.apache.solr.client.solrj.io.stream.CloudSolrStream.open(CloudSolrStream.java:237)
> at 
> org.apache.solr.client.solrj.io.stream.SelectStream.open(SelectStream.java:153)
> at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.open(ExceptionStream.java:47)
> at 
> org.apache.solr.handler.StreamHandler$TimerStream.open(StreamHandler.java:362)
> at 
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:301)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:95)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:60)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:725)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
> 

[jira] [Commented] (LUCENE-6438) Improve clean-jars when dealing with symbolic links.

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on LUCENE-6438:
-

LUCENE-6074 introduced symlinks to jars.

> Improve clean-jars when dealing with symbolic links.
> 
>
> Key: LUCENE-6438
> URL: https://issues.apache.org/jira/browse/LUCENE-6438
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
>
> Ever since I started seeing jars in the lib folders use symbolic links on 
> linux I've run into jar problems when working with an old checkout or 
> switching branches on a git checkout. You would normally expect ant 
> clean-jars to help, but it didn't and led to some headaches and random bs.
> Turns out, clean-jars is not properly removing all symbolic links for me. 
> I've seen two cases - symbolic links to jars that are not removed and broken 
> symbolic links to jars.
> I can get rid of the symbolic links with the following:
> {code}
>   
> 
>   
> {code}
> But that doesn't work with the broken links.
> I guess you can remove those with the Ant Symlink task, but it seems only 
> specifically one at a time which is not that useful.



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

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

[jira] [Resolved] (SOLR-9093) fix TopGroupsShardResponseProcessor.java:105 NullPointerException

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9093.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.1
   5.6

master: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/c4e8673b
branch_6x: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/574a6a9d
branch_5x: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/b0e3b13a

(Not sure why the bot didn't update this JIRA ticket for the branch commits, 
perhaps a blip.)



> fix TopGroupsShardResponseProcessor.java:105 NullPointerException
> -
>
> Key: SOLR-9093
> URL: https://issues.apache.org/jira/browse/SOLR-9093
> Project: Solr
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.1, master (7.0)
>
>
> e.g. 
> http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16693/testReport/junit/org.apache.solr/TestDistributedSearch/test/
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://127.0.0.1:44706//collection1: 
> java.lang.NullPointerException
>   at 
> org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:105)
>   at 
> org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:753)
>   at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:736)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:420)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2016)
> ...
> {code}
> A minimalistic fix would be
> {code}
> -  if (t instanceof SolrServerException) {
> +  if (t instanceof SolrServerException && t.getCause() != null) {
> {code}
> but perhaps equally valid would be to tweak the logic, similar to the 
> [SearchHandler.java#L440|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L440]
>  logic, the difference being cause vs. root-cause for SolrServerException 
> exceptions and throwable vs. throwable.cause for other exceptions.



--
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-8462) Improve error reporting for /stream handler

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8462:
---

Sure; I'll take a look at it this weekend.

> Improve error reporting for /stream handler
> ---
>
> Key: SOLR-8462
> URL: https://issues.apache.org/jira/browse/SOLR-8462
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Jason Gerlowski
>Assignee: Joel Bernstein
>Priority: Trivial
> Attachments: SOLR-8462.patch, SOLR-8462.patch
>
>
> Currently, the /stream request handler reports errors by adding an 
> "EXCEPTION" name/value pair on a tuple in the TupleStream where the error 
> arose.  The "value" in this name/value pair is the message attached to the 
> exception.
> This works well in most instances, however it could be better in a few ways:
> 1.) Not all exceptions have messages.  For instance, 
> {{NullPointerExceptions}} and other run time exceptions fall into this 
> category.  This causes the /stream handler to return the relatively unhelpful 
> value: {"EXCEPTION":null,"EOF":true}.  The /stream handler should make sure 
> the exception has a message, and if not, it should report some other 
> information about the error (exception class name?).
> 2.) There are some common error cases that can arise from mis-use of the API. 
>  For instance, if the 'expr' parameter is missing.  Detecting and handling 
> these cases specifically would allow users to get back clearer, more useful 
> error messages.



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3267 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3267/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 52291 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] javadoc: warning - No source files for package 
org.apache.lucene.codecs
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene50...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene53...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene54...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.8.0_72
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/docs/backward-codecs/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:740: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:138: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:246: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:65: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/module-build.xml:78: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2163:
 Javadocs warnings were found!

Total time: 102 minutes 57 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Created] (SOLR-9108) Improve how index time sorting is configured

[Michael McCandless (JIRA)]

Michael McCandless created SOLR-9108:


 Summary: Improve how index time sorting is configured
 Key: SOLR-9108
 URL: https://issues.apache.org/jira/browse/SOLR-9108
 Project: Solr
  Issue Type: Improvement
Reporter: Michael McCandless


Spinoff from LUCENE-6766.

We used to have a {{SortingMergePolicy}} to configure index time sorting, but 
with LUCENE-6766 you now set this on {{IndexWriterConfig}}.

Solr had exposed index time sorting, so to preserve back-compat, I kept 
{{SortingMergePolicy}} alive, moved to solr's sources, but use it simply as a 
holder to pull the index sort from and pass to IWC.

This preserves back compat, but I think it'd be cleaner going forward to just 
allow index sort to be specified somewhere in {{solrconfig.xml}} wherever other 
index writer settings are set?



--
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-7283) Move SlowCompositeReaderWrapper to solr sources

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7283:
--

 Summary: Move SlowCompositeReaderWrapper to solr sources
 Key: LUCENE-7283
 URL: https://issues.apache.org/jira/browse/LUCENE-7283
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless


Spinoff from LUCENE-6766, where we fixed index-time sorting to have first class 
support in Lucene's ore, and no longer use {{SlowCompositeReaderWrapper}}.

This is a dangerous, long living class, that tries to pretend a set of N 
segments is actually just a single segment.  It's a leaky abstraction, has poor 
performance, and puts undue pressure on the APIs of new Lucene features to try 
to keep up this illusion.

With LUCENE-6766, finally all usage of this class (except for 
{{UninvertedReader}} tests, which should maybe also move out?) has been removed 
from Lucene, so I think we should move it to Solr.  This may also lead to a 
solution for LUCENE-7086 since e.g. the class could tap into solr's schema to 
"know" how to handle points fields properly.



--
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-7282) search APIs should take advantage of index sort by default

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7282:
--

 Summary: search APIs should take advantage of index sort by default
 Key: LUCENE-7282
 URL: https://issues.apache.org/jira/browse/LUCENE-7282
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless


Spinoff from LUCENE-6766, where we made it very easy to have Lucene sort 
documents in the index (at merge time).

An index-time sort is powerful because if you then search that index by the 
same sort (or by a "prefix" of it), you can early-terminate per segment once 
you've collected enough hits.  But doing this by default would mean accepting 
an approximate hit count, and could not be used in cases that need to see every 
hit, e.g. if you are also faceting.

Separately, `TermQuery` on the leading sort field can be very fast since we can 
advance to the first docID, and only match to the last docID for the requested 
value.  This would not be approximate, and should be lower risk / easier.



--
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-7281) Can IW sort segments on flush too?

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7281:
--

 Summary: Can IW sort segments on flush too?
 Key: LUCENE-7281
 URL: https://issues.apache.org/jira/browse/LUCENE-7281
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless


Spinoff from LUCENE-6766, where we made index-time sorting first class in 
Lucene, except only merged segments get sorted.

Can we also sort flushed segments?  This would be cleaner because then 
search-time users don't need to fret about whether a given segment is sorted or 
not, and it would also improve the current "best effort" check IW does that you 
didn't try to change the index sort order, to an accurate check.

But this is tricky because e.g. at least term vectors and stored fields write 
"live" to the segment's (codec's) files as documents are being indexed...



--
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-6766) Make index sorting a first-class citizen

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6766:


I pushed this to master ... I will hold off on backporting to 6.x until we 
release 6.1, giving it time to bake.

I'll go open a bunch of followon issues now.

> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit 5fb7413ccb9c690d3a59d7227b3cb194943290ef in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5fb7413 ]

LUCENE-6766: remove leftover sop


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit e3ecc6a5361948c28679c7ac76161f167824e514 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e3ecc6a ]

LUCENE-6766: merge master


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit 9d5b834b09d4ff23e89755e5d1af407a2bd96c16 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9d5b834 ]

LUCENE-6766: put Placeholder back so javadocs are OK; deprecate Lucene60Codec


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit 87690f8b13b1def6c822ba36a42e4cb6939ab4c2 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=87690f8 ]

LUCENE-6766: add another random test case; move early terminating collector to 
core


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit 3cde9eb3d027b273a3c136e9eb284ae18f1824fe in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3cde9eb ]

LUCENE-6766: keep SortingMergePolicy for solr back-compat; fix Solr tests; fix 
precommit failures


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit e283271aaf6da3033156f36b421d3241b5499d4e in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e283271 ]

LUCENE-6766: more IW.infoStream logging around sorting; fix test bug


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit d715210467a4907ca34e7f0fe1a438908737894f in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d715210 ]

LUCENE-6766: merged


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-6766) Make index sorting a first-class citizen

[ASF subversion and git services (JIRA)]

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

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

Commit 1e82c13184621f6cefac35f8d10d8fe74d2a356c in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1e82c13 ]

LUCENE-6766: resolve remaining nocommits; add more IW infoStream logging during 
merge


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



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