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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5323/
Java: 32bit/jdk1.8.0_66 -client -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.handler.admin.CoreAdminRequestStatusTest.testCoreAdminRequestStatus

Error Message:
The status of request was expected to be completed expected:<[completed]> but 
was:<[running]>

Stack Trace:
org.junit.ComparisonFailure: The status of request was expected to be completed 
expected:<[completed]> but was:<[running]>
at 
__randomizedtesting.SeedInfo.seed([49768613F567A88E:6F68A8174BF11C34]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.handler.admin.CoreAdminRequestStatusTest.testCoreAdminRequestStatus(CoreAdminRequestStatusTest.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.admin.CoreAdminRequestStatusTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.

[jira] [Updated] (SOLR-8373) KerberosPlugin: Using multiple nodes on same machine leads clients to fetch TGT for every request

[Ishan Chattopadhyaya (JIRA)]

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

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

Added test cases, minor refactoring here and there. I did some end to end 
testing and the changes look good to me thus far.

Was just wondering if the change to have all authentication and authorization 
plugins now accept a CoreContainer warrants a separate issue?

> KerberosPlugin: Using multiple nodes on same machine leads clients to fetch 
> TGT for every request
> -
>
> Key: SOLR-8373
> URL: https://issues.apache.org/jira/browse/SOLR-8373
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Critical
> Attachments: SOLR-8373.patch, SOLR-8373.patch, SOLR-8373.patch, 
> SOLR-8373.patch
>
>
> Kerberized solr nodes accept negotiate/spnego/kerberos requests and processes 
> them. It also passes back to the client a cookie called "hadoop.auth" (which 
> is currently unused, but will eventually be used for delegation tokens). 
> If two or more nodes are on the same machine, they all send out the cookie 
> which have the same domain (hostname) and same path, but different cookie 
> values.
> Upon receipt at the client, if a cookie is rejected (which in this case will 
> be), the client compulsorily gets a ​​*new*​​ TGT from the KDC instead of 
> reading the same ticket from the ticketcache. This is causing the heavy 
> traffic at the KDC, plus intermittent "Request is a replay" (which indicates 
> race condition at KDC while handing out the TGT for the same principal).



--
This message was sent by Atlassian 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-8378) Add upconfig and downconfig commands to the bin/solr script and managed-only schema to configsets

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8378:
-
Attachment: SOLR-8378.patch

Just had an offline chat with Varun. His work on SOLR-8131 and this one 
crossed. There's no need for a new configset, I've removed it.

WARNING: It's late and I'll be able to test this in the morning.

> Add upconfig and downconfig commands to the bin/solr script and managed-only 
> schema to configsets
> -
>
> Key: SOLR-8378
> URL: https://issues.apache.org/jira/browse/SOLR-8378
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4, Trunk
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-8378.patch, SOLR-8378.patch, SOLR-8378.patch, 
> SOLR-8378.patch, SOLR-8378.patch
>
>
> It would be convenient to be able to upload and download arbitrary configsets 
> to Zookeeper.
> This _might_ be the last thing we need before not requiring users be aware of 
> zkcli, which is awkward.



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

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

[jira] [Created] (SOLR-8387) Solr example configs should ship with managed-schema instead of schema.xml

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8387:
---

 Summary: Solr example configs should ship with managed-schema 
instead of schema.xml
 Key: SOLR-8387
 URL: https://issues.apache.org/jira/browse/SOLR-8387
 Project: Solr
  Issue Type: Improvement
Affects Versions: Trunk
Reporter: Varun Thacker


This is a followup of SOLR-8131 . In SOLR-8131 if a schema factory is not 
specified explicitly managed schema will be used.

Now since managed schema factory is the default, when a user goes to start solr 
6.0 their schema.xml file will get converted to managed-schema  . This might 
seem trappy or confusing to a user. Hence why don't we directly ship with a a 
file called {{managed-schema}} instead of {{schema.xml}} . Just a rename of the 
files in all the example configs that we ship. The data_driven config does that 
already





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

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

[jira] [Created] (SOLR-8386) The new admin UI doesn't understand that managed schemas are the default in 6.0

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-8386:


 Summary: The new admin UI doesn't understand that managed schemas 
are the default in 6.0
 Key: SOLR-8386
 URL: https://issues.apache.org/jira/browse/SOLR-8386
 Project: Solr
  Issue Type: Bug
  Components: UI
Affects Versions: 6.0
Reporter: Erick Erickson


SOLR-8131 makes managed schema the default in Solr 6.0. So the "add field" & 
etc buttons aren't being shown in the schema link as they are in 5.x (5.4+).

Note, _all_ the configsets in 5.5+ are managed, as they are in 6.x The 
difference is that you do not need to specify anything special in 6x. 

So whatever the key that determines whether the admin UI knows the schema is 
managed or not probably needs to be updated.

[~upayavira] any hints 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] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[ASF subversion and git services (JIRA)]

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

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

Commit 1718517 from m...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718517 ]

LUCENE-5868: removing Java8's parseUnsignedInt

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5868:
--

I'm going to fix it

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



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

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

Re: [JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 1040 - Still Failing

[Mikhail Khludnev]

It's mine. Looking into.

On Tue, Dec 8, 2015 at 9:35 AM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/1040/
>
> All tests passed
>
> Build Log:
> [...truncated 7450 lines...]
> [javac] Compiling 6 source files to
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build/join/classes/test
> [javac]
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
> error: cannot find symbol
> [javac] assert nextInt ==
> Integer.parseUnsignedInt(uniqueRandomValue,16);
> [javac]  ^
> [javac]   symbol:   method parseUnsignedInt(String,int)
> [javac]   location: class Integer
> [javac]
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
> error: cannot find symbol
> [javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
> [javac]^
> [javac]   symbol:   method parseUnsignedInt(String,int)
> [javac]   location: class Integer
> [javac] Note:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
> uses or overrides a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
> [javac] 2 errors
>
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:801:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:738:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:59:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build.xml:472:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:2252:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:58:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:55:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:818:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:832:
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:1968:
> Compile failed; see the compiler error output for details.
>
> Total time: 106 minutes 8 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> 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
>



-- 
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics

[jira] [Comment Edited] (LUCENE-6917) Move NumericField out of core to backwards-codecs

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-6917 at 12/8/15 7:09 AM:


bq. I could not get @link out to backward-codecs to render correctly into 
javadocs ... so I had to cutover to @code for links outside of core.

In modules you have to add {{}} elements inside {{}} of the 
{{}} Ant element (should work with any of them). Example 
from benchmark module:
{code:xml}

  






  

{code}

If the javadoc target does not exist, you have to add it first.


was (Author: thetaphi):
bq. I could not get @link out to backward-codecs to render correctly into 
javadocs ... so I had to cutover to @code for links outside of core.

In modules you have to add {{}} elements inside {{}} of the 
{{}} Ant element. Example from benchmark module:
{code:xml}

  






  

{code}

If the javadoc target does not exist, you have to add it first.

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



--
This message was sent by Atlassian 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-6917) Move NumericField out of core to backwards-codecs

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6917:
---

bq. I could not get @link out to backward-codecs to render correctly into 
javadocs ... so I had to cutover to @code for links outside of core.

In modules you have to add {{}} elements inside {{}} of the 
{{}} Ant element. Example from benchmark module:
{code:xml}

  






  

{code}

If the javadoc target does not exist, you have to add it first.

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



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

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

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

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 7450 lines...]
[javac] Compiling 6 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build/join/classes/test
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:801: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:738: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/build.xml:59: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/build.xml:472:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:2252:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:58:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/module-build.xml:55:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:818:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:832:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/lucene/common-build.xml:1968:
 Compile failed; see the compiler error output for details.

Total time: 106 minutes 8 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
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-5.x-Linux (64bit/jdk1.7.0_80) - Build # 14845 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 6842 lines...]
[javac] Compiling 6 source files to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/join/classes/test
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:794: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:738: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:472: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2252: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/module-build.xml:58: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/module-build.xml:55: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:818: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:832: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1968: 
Compile failed; see the compiler error output for details.

Total time: 17 minutes 21 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-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+95) - Build # 15141 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15141/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseParallelGC 
-XX:-CompactStrings

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=6076, name=groupCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
at 
java.util.concurrent.Sch

[jira] [Commented] (SOLR-8378) Add upconfig and downconfig commands to the bin/solr script and managed-only schema to configsets

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8378:
-

bq. Solr-8131 defaults to schemaless mode. While related, these are two 
different beasts from a user's perspective. I've run into lots of situations 
where the user wants docs to fail indexing first time, every time when it 
contains undefined fields, fields of an unintended type, etc.. One of the 
points of this ticket is to accommodate that desire while being able to define 
fields via the new admin UI. You'll notice that there aren't even any dynamic 
fields defined in the schema for instance.

SOLR-8131 doesn't default to schemaless mode. It defaults to managed schema 
mode , meaning the Schema APIs will be available to everyone to modify 
fields/fieldTypes etc. The type guessing is only part of the data_driven 
example like before.

> Add upconfig and downconfig commands to the bin/solr script and managed-only 
> schema to configsets
> -
>
> Key: SOLR-8378
> URL: https://issues.apache.org/jira/browse/SOLR-8378
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4, Trunk
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-8378.patch, SOLR-8378.patch, SOLR-8378.patch, 
> SOLR-8378.patch
>
>
> It would be convenient to be able to upload and download arbitrary configsets 
> to Zookeeper.
> This _might_ be the last thing we need before not requiring users be aware of 
> zkcli, which is awkward.



--
This message was sent by Atlassian 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-8368) A SolrCore needs to replay it's tlog before the leader election process.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8368:
---

bq. 1

Probably the best thing that could be done is multithreaded replay. As far as 
anything being a lot better on a shared filesystem, that doesn't help me at all 
for general issues like this.

bq. 2

The current leader election system is a lot more involved than simply looking 
at what replica has the greatest version for it’s last update.

Perhaps when the min replication param is fully first class and full featured 
we can considering getting fairly wild in how we deal with this, but in the 
current state of things, we are careful to minimize data loss as much as 
possible

By the way, this would really going to complicate / upset my shared index / 
tlog on a shared filesystem solution

> A SolrCore needs to replay it's tlog before the leader election process.
> 
>
> Key: SOLR-8368
> URL: https://issues.apache.org/jira/browse/SOLR-8368
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>
> If we do it after like now, the correct leader may not be able to become 
> leader.



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

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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 683 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([F20EDBD78973A58B:1B5460EF17EA3523]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:749)
at 
org.apache.solr.core.TestArbitraryIndexDir.testLoadNewIndexDir(TestArbitraryIndexDir.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=*[count(//doc)=1]
xml response was: 

00


request was:q=id:2&qt=standard&start=0&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:742)
.

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[Varun Rajput (JIRA)]

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

Varun Rajput commented on SOLR-6736:


Hey [~erickerickson], as discussed previously, the problem of uploading through 
browser is already addressed by having the user enable it. Uploading a 
configset or config file through the browser is much easier and convenient for 
the user while adding more actions to the ConfigSetsAPI.

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
> Attachments: SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, 
> SOLR-6736-newapi.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, newzkconf.zip, test_private.pem, test_pub.der, 
> zkconfighandler.zip, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14844/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 7092 lines...]
[javac] Compiling 6 source files to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/join/classes/test
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:794: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:738: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:472: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2252: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/module-build.xml:58: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/module-build.xml:55: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:818: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:832: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1968: 
Compile failed; see the compiler error output for details.

Total time: 17 minutes 52 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] [Updated] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[Varun Rajput (JIRA)]

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

Varun Rajput updated SOLR-6736:
---
Attachment: SOLR-6736-newapi.patch

[~anshumg] and [~gchanan], I have updated the patch with all the minor changes 
you both suggested. Please provide feedback on the upload as well as config 
property check questions I had asked so I can update the patch for those as 
well. Thanks!

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
> Attachments: SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, 
> SOLR-6736-newapi.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, newzkconf.zip, test_private.pem, test_pub.der, 
> zkconfighandler.zip, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian 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-6736) A collections-like request handler to manage solr configurations on zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6736:
--

SOLR-8378 avoids the problem of uploading arbitrary XML in a browser, it uses a 
client jar instead. Perhaps that JIRA can provide the necessary functionality?

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
> Attachments: SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> newzkconf.zip, test_private.pem, test_pub.der, zkconfighandler.zip, 
> zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian 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-6736) A collections-like request handler to manage solr configurations on zookeeper

[Varun Rajput (JIRA)]

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

Varun Rajput commented on SOLR-6736:


Hey [~gchanan], did you get a chance to look into this?

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
> Attachments: SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> newzkconf.zip, test_private.pem, test_pub.der, zkconfighandler.zip, 
> zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian 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-MAVEN] Lucene-Solr-Maven-5.x #1126: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/1126/

No tests ran.

Build Log:
[...truncated 3207 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:810: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:291: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:563:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:558:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/build.xml:461: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:2252:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/module-build.xml:55:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:818:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:832:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/lucene/common-build.xml:1968:
 Compile failed; see the compiler error output for details.

Total time: 1 minute 10 seconds
Build step 'Invoke Ant' marked build as failure
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-Tests-5.x-Java7 - Build # 3821 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 7157 lines...]
[javac] Compiling 6 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build/join/classes/test
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:794: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:738: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/build.xml:59: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/build.xml:472:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:2252:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/module-build.xml:58:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/module-build.xml:55:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:818:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:832:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/lucene/common-build.xml:1968:
 Compile failed; see the compiler error output for details.

Total time: 22 minutes 14 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
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-SmokeRelease-trunk - Build # 356 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/356/

No tests ran.

Build Log:
[...truncated 52706 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (14.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.3 MB in 0.04 sec (807.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 65.4 MB in 0.08 sec (786.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 75.9 MB in 0.10 sec (766.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5953 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5953 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 211 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (170.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.0.0-src.tgz...
   [smoker] 37.2 MB in 0.06 sec (654.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.tgz...
   [smoker] 132.1 MB in 0.17 sec (758.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.zip...
   [smoker] 140.4 MB in 0.18 sec (765.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]  

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build # 15140 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15140/
Java: 32bit/jdk-9-ea+95 -server -XX:+UseSerialGC -XX:-CompactStrings

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=10374, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
at 
java.util.concurrent.Sched

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

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8266:
-

bq. I was aware of the patch naming convention. I broke it in an effort to call 
out that this patch contains a commented out test, and (probably? maybe?) 
shouldn't be committed as-is. If that break from convention isn't worthwhile 
though, I'll stop doing that sort of thing. Still learning the ropes here a bit.

I've seen folks put a {{//nocommit}} tag to intentionally fail the validation 
check in cases like these.

> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions will be used to serialize Streaming 
> API Objects. 



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

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

[jira] [Created] (SOLR-8385) Narrow StreamFactory.withFunctionName clazz parameter to prevent misconfiguration.

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-8385:
-

 Summary: Narrow StreamFactory.withFunctionName clazz parameter to 
prevent misconfiguration.
 Key: SOLR-8385
 URL: https://issues.apache.org/jira/browse/SOLR-8385
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: Trunk
Reporter: Jason Gerlowski
Priority: Trivial
 Fix For: Trunk


Currently, {{StreamFactory}} has several overloaded {{withFunctionName}} 
methods.  One of these, takes two parameters: a {{String}} functionName, and a 
{{Class}} implementation type.

This second parameter is a little too generic, because it's really only ever 
valid for a small, small subset of classes (i.e. {{Class

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

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-8266:
---

No problem; hopefully you're still as thankful after giving it a review :-p

I did write it against trunk, though I can put it on top of another branch if 
you'd prefer.

I was aware of the patch naming convention.  I broke it in an effort to call 
out that this patch contains a commented out test, and (probably? maybe?) 
shouldn't be committed as-is.  If that break from convention isn't worthwhile 
though, I'll stop doing that sort of thing.  Still learning the ropes here a 
bit.

As for the questions/change-suggestions in my earlier comment, I'll throw 
together JIRAs for those and toss up a starter patch on them.

> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions will be used to serialize Streaming 
> API Objects. 



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

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

[jira] [Commented] (LUCENE-6913) Standard/Classic/UAX tokenizers could be more ram efficient

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-6913:


bq. I think ideally we want to fix jflex to use byte[] when there are <= 256 
character classes?

+1

> Standard/Classic/UAX tokenizers could be more ram efficient
> ---
>
> Key: LUCENE-6913
> URL: https://issues.apache.org/jira/browse/LUCENE-6913
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-6913.not.a.patch
>
>
> These tokenizers map codepoints to character classes with the following 
> datastructure (loaded in clinit):
> {noformat}
>   private static char [] zzUnpackCMap(String packed) {
> char [] map = new char[0x11];
> {noformat}
> This requires 2MB RAM for each tokenizer class (in trunk 6MB if all 3 classes 
> are loaded, in branch_5x 10MB since there are 2 additional backwards compat 
> classes).
> On the other hand, none of our tokenizers actually use a huge number of 
> character classes, so {{char}} is overkill: e.g. this map can safely be a 
> byte [] and we can save half the memory. Perhaps it could make these 
> tokenizers faster too.



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 7044 lines...]
[javac] Compiling 6 source files to 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build/join/classes/test
[javac] 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:794: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:738: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/build.xml:59: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/build.xml:472: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:2252: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/module-build.xml:58: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/module-build.xml:55: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:818: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:832: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-5.x-MacOSX/lucene/common-build.xml:1968: 
Compile failed; see the compiler error output for details.

Total time: 20 minutes 23 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-5868) JoinUtil support for NUMERIC docValues fields

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-5868:


Compilation is failing on branch_5x: 
https://builds.apache.org/job/Lucene-Artifacts-5.x/1037/ (java8 constructs on a 
java7 build I imagine): 

{noformat}
   [javac] Compiling 6 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build/join/classes/test
   [javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
   [javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
   [javac]  ^
   [javac]   symbol:   method parseUnsignedInt(String,int)
   [javac]   location: class Integer
   [javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
   [javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
   [javac]^
   [javac]   symbol:   method parseUnsignedInt(String,int)
   [javac]   location: class Integer
   [javac] Note: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
   [javac] Note: Recompile with -Xlint:deprecation for details.
   [javac] 2 errors
{noformat}

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-Artifacts-5.x - Build # 1037 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-5.x/1037/

No tests ran.

Build Log:
[...truncated 2873 lines...]
[javac] Compiling 6 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build/join/classes/test
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:954:
 error: cannot find symbol
[javac] assert nextInt == 
Integer.parseUnsignedInt(uniqueRandomValue,16);
[javac]  ^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java:1206:
 error: cannot find symbol
[javac] final int linkInt = Integer.parseUnsignedInt(linkValue,16);
[javac]^
[javac]   symbol:   method parseUnsignedInt(String,int)
[javac]   location: class Integer
[javac] Note: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoin.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/build.xml:461: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:2252:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/module-build.xml:55:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:818:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:832:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Artifacts-5.x/lucene/common-build.xml:1968:
 Compile failed; see the compiler error output for details.

Total time: 1 minute 2 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
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-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2923 - Failure!

[Policeman Jenkins Server]

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

19 tests failed.
FAILED:  org.apache.solr.cloud.CollectionStateFormat2Test.test

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:50892/cl_ou/e, http://127.0.0.1:50900/cl_ou/e, 
http://127.0.0.1:50884/cl_ou/e, http://127.0.0.1:50872/cl_ou/e, 
http://127.0.0.1:50908/cl_ou/e]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:50892/cl_ou/e, 
http://127.0.0.1:50900/cl_ou/e, http://127.0.0.1:50884/cl_ou/e, 
http://127.0.0.1:50872/cl_ou/e, http://127.0.0.1:50908/cl_ou/e]
at 
__randomizedtesting.SeedInfo.seed([CAA768A767D7EB05:42F3577DC92B86FD]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1100)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1574)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1528)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1788)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.testZkNodeLocation(CollectionStateFormat2Test.java:61)
at 
org.apache.solr.cloud.CollectionStateFormat2Test.test(CollectionStateFormat2Test.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.ru

[jira] [Resolved] (SOLR-4742) Autocommit configuration is not working

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-4742.
--
Resolution: Not A Problem

I ran across this recently, I can't imagine anyone's going to pursue it so I'm 
closing.

> Autocommit configuration is not working
> ---
>
> Key: SOLR-4742
> URL: https://issues.apache.org/jira/browse/SOLR-4742
> Project: Solr
>  Issue Type: Bug
>  Components: replication (scripts), update
>Affects Versions: 3.6.1
> Environment: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
> Weblogic 11g
>Reporter: Gustavo Zopelari Nasu
>
> We've configured solrconfig.xml to autocommit after 500 docs added or 30 
> seconds as following the configuration bellow:
> 
>   500
>   3
> 
> The problem that has been occured is after some time the commit is executed 
> after a long time reaching 40 minutes.
> That same problem has been happened with the slaves. The new documents 
> appears after a long time on the slaves.
> We executed the optimize but the problem happened again.



--
This message was sent by Atlassian 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: [VOTE] Release Lucene/Solr 5.4.0-RC1

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

+1 for release. (tested with Java 7)

SUCCESS! [0:56:31.943245]


On Mon, Dec 7, 2015 at 8:05 PM Steve Rowe  wrote:

> +1
>
> Docs, javadocs, and changes look good.
>
> Smoke tester was happy with Java7 and Java8:
>
> SUCCESS! [1:53:58.550314]
>
> Steve
>
> > On Dec 7, 2015, at 5:31 AM, Upayavira  wrote:
> >
> > Yes, Shalin, you are right. My fix was still required, but I clearly
> > manually entered the SVN commit command wrong. Seeing as it does not
> > impact upon the contents of the files, I have executed an SVN mv
> > command, rerun the smoke test with the below, which worked:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev1718046
> >
> > Please, folks, use the above to run the smoke test for this release.
> >
> > Upayavira
> >
> > On Mon, Dec 7, 2015, at 04:00 AM, Shalin Shekhar Mangar wrote:
> >> Hi Upayavira,
> >>
> >> The svn revision in the URL is wrong. It should be 1718046 but it is
> >> 178046 which makes the smoke tester fail with the following message:
> >>
> >> RuntimeError: JAR file
> >>
> "/tmp/smoke_lucene_5.4.0_178046_1/unpack/lucene-5.4.0/analysis/common/lucene-analyzers-common-5.4.0.jar"
> >> is missing "Implementation-Version: 5.4.0 178046 " inside its
> >> META-INF/MANIFEST.MF (wrong svn revision?)
> >>
> >> I think you may need to generate a new RC. But perhaps an svn move to
> >> a path with the right revision number may also suffice?
> >>
> >> On Mon, Dec 7, 2015 at 9:12 AM, Shalin Shekhar Mangar
> >>  wrote:
> >>> Thanks Upayavira. I guess Apache has started redirecting http traffic
> >>> to https recently on dist.apache.org which must have broken this
> >>> script. I am able to run smoke tester after applying your patch.
> >>>
> >>> On Mon, Dec 7, 2015 at 2:08 AM, Upayavira  wrote:
>  The getHREFs() method is taking in an HTTPS URL, but failing to
> preserve
>  the protocol, resulting in an HTTP call that the server naturally
>  bounces to HTTPS. Unfortunately, the next loop round also forgets the
>  HTTPS, and hence we're stuck in an endless loop. Below is a patch that
>  fixes this issue. I'd rather someone with more knowledge of this
> script
>  confirm my suspicion and apply the patch for us all to use, as I
> cannot
>  see how this ever worked.
> 
>  I personally ran the smoke test on my local copy, so did not hit this
>  HTTP/HTTPS code. I'm running the HTTP version now, and will check on
> it
>  in the morning.
> 
>  Index: dev-tools/scripts/smokeTestRelease.py
>  ===
>  --- dev-tools/scripts/smokeTestRelease.py   (revision 1718046)
>  +++ dev-tools/scripts/smokeTestRelease.py   (working copy)
>  @@ -84,7 +84,12 @@
>    # Deref any redirects
>    while True:
>  url = urllib.parse.urlparse(urlString)
>  -h = http.client.HTTPConnection(url.netloc)
>  +if url.scheme == "http":
>  +  h = http.client.HTTPConnection(url.netloc)
>  +elif url.scheme == "https":
>  +  h = http.client.HTTPSConnection(url.netloc)
>  +else:
>  +  raise RuntimeError("Unknown protocol: %s" % url.scheme)
>  h.request('GET', url.path)
>  r = h.getresponse()
>  newLoc = r.getheader('location')
> 
>  Upayavira
> 
>  On Sun, Dec 6, 2015, at 06:26 PM, Noble Paul wrote:
> > Same here.
> >
> > On Sun, Dec 6, 2015 at 2:36 PM, Shalin Shekhar Mangar
> >  wrote:
> >> Is anyone able to run the smoke tester on this RC? It just hangs
> for a
> >> long time on "loading release URL" for me.
> >>
> >> python3 -u dev-tools/scripts/smokeTestRelease.py --tmp-dir
> >> ../smoke-5.4 --revision 178046 --version 5.4.0 --test-java8
> >> ~/programs/jdk8
> >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
> >> Java 1.7 JAVA_HOME=/home/shalin/programs/jdk7
> >> Java 1.8 JAVA_HOME=/home/shalin/programs/jdk8
> >> NOTE: output encoding is UTF-8
> >>
> >> Load release URL
> >> "
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
> "...
> >>
> >> I did a strace and found that the server is returning a HTTP 301
> moved
> >> permanently response to the http request.
> >>
> >> On Sat, Dec 5, 2015 at 4:28 PM, Upayavira  wrote:
> >>> Please vote for the RC1 release candidate for Lucene/Solr 5.4.0
> >>>
> >>> The artifacts can be downloaded from:
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
> >>>
> >>> You can run the smoke tester directly with this command:
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
> >>>
> >>> I will let this vote run until midnight (GMT) on Wednesday 9
> December.

Re: [VOTE] Release Lucene/Solr 5.4.0-RC1

[Steve Rowe]

+1

Docs, javadocs, and changes look good.

Smoke tester was happy with Java7 and Java8:

SUCCESS! [1:53:58.550314]

Steve

> On Dec 7, 2015, at 5:31 AM, Upayavira  wrote:
> 
> Yes, Shalin, you are right. My fix was still required, but I clearly
> manually entered the SVN commit command wrong. Seeing as it does not
> impact upon the contents of the files, I have executed an SVN mv
> command, rerun the smoke test with the below, which worked:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev1718046
> 
> Please, folks, use the above to run the smoke test for this release.
> 
> Upayavira
> 
> On Mon, Dec 7, 2015, at 04:00 AM, Shalin Shekhar Mangar wrote:
>> Hi Upayavira,
>> 
>> The svn revision in the URL is wrong. It should be 1718046 but it is
>> 178046 which makes the smoke tester fail with the following message:
>> 
>> RuntimeError: JAR file
>> "/tmp/smoke_lucene_5.4.0_178046_1/unpack/lucene-5.4.0/analysis/common/lucene-analyzers-common-5.4.0.jar"
>> is missing "Implementation-Version: 5.4.0 178046 " inside its
>> META-INF/MANIFEST.MF (wrong svn revision?)
>> 
>> I think you may need to generate a new RC. But perhaps an svn move to
>> a path with the right revision number may also suffice?
>> 
>> On Mon, Dec 7, 2015 at 9:12 AM, Shalin Shekhar Mangar
>>  wrote:
>>> Thanks Upayavira. I guess Apache has started redirecting http traffic
>>> to https recently on dist.apache.org which must have broken this
>>> script. I am able to run smoke tester after applying your patch.
>>> 
>>> On Mon, Dec 7, 2015 at 2:08 AM, Upayavira  wrote:
 The getHREFs() method is taking in an HTTPS URL, but failing to preserve
 the protocol, resulting in an HTTP call that the server naturally
 bounces to HTTPS. Unfortunately, the next loop round also forgets the
 HTTPS, and hence we're stuck in an endless loop. Below is a patch that
 fixes this issue. I'd rather someone with more knowledge of this script
 confirm my suspicion and apply the patch for us all to use, as I cannot
 see how this ever worked.
 
 I personally ran the smoke test on my local copy, so did not hit this
 HTTP/HTTPS code. I'm running the HTTP version now, and will check on it
 in the morning.
 
 Index: dev-tools/scripts/smokeTestRelease.py
 ===
 --- dev-tools/scripts/smokeTestRelease.py   (revision 1718046)
 +++ dev-tools/scripts/smokeTestRelease.py   (working copy)
 @@ -84,7 +84,12 @@
   # Deref any redirects
   while True:
 url = urllib.parse.urlparse(urlString)
 -h = http.client.HTTPConnection(url.netloc)
 +if url.scheme == "http":
 +  h = http.client.HTTPConnection(url.netloc)
 +elif url.scheme == "https":
 +  h = http.client.HTTPSConnection(url.netloc)
 +else:
 +  raise RuntimeError("Unknown protocol: %s" % url.scheme)
 h.request('GET', url.path)
 r = h.getresponse()
 newLoc = r.getheader('location')
 
 Upayavira
 
 On Sun, Dec 6, 2015, at 06:26 PM, Noble Paul wrote:
> Same here.
> 
> On Sun, Dec 6, 2015 at 2:36 PM, Shalin Shekhar Mangar
>  wrote:
>> Is anyone able to run the smoke tester on this RC? It just hangs for a
>> long time on "loading release URL" for me.
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py --tmp-dir
>> ../smoke-5.4 --revision 178046 --version 5.4.0 --test-java8
>> ~/programs/jdk8
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
>> Java 1.7 JAVA_HOME=/home/shalin/programs/jdk7
>> Java 1.8 JAVA_HOME=/home/shalin/programs/jdk8
>> NOTE: output encoding is UTF-8
>> 
>> Load release URL
>> "https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/";...
>> 
>> I did a strace and found that the server is returning a HTTP 301 moved
>> permanently response to the http request.
>> 
>> On Sat, Dec 5, 2015 at 4:28 PM, Upayavira  wrote:
>>> Please vote for the RC1 release candidate for Lucene/Solr 5.4.0
>>> 
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
>>> 
>>> You can run the smoke tester directly with this command:
>>> python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
>>> 
>>> I will let this vote run until midnight (GMT) on Wednesday 9 December.
>>> 
>>> Please cast your votes! (and let me know, politely :-) if I missed
>>> anything)
>>> 
>>> Upayavira
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.ap

[jira] [Commented] (SOLR-3089) Make ResponseBuilder.isDistrib public

[Kelvin Tan (JIRA)]

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

Kelvin Tan commented on SOLR-3089:
--

I, too, am writing a SearchComponent that needs access to isDistrib. 

Is there any obvious reason not to commit this?


> Make ResponseBuilder.isDistrib public
> -
>
> Key: SOLR-3089
> URL: https://issues.apache.org/jira/browse/SOLR-3089
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 4.0-ALPHA
>Reporter: Rok Rejc
> Fix For: 4.9, Trunk
>
> Attachments: Solr-3089.patch
>
>
> Hi,
> i have posted this issue on a mailing list but i didn't get any response.
> I am trying to write distributed search component (a class that extends 
> SearchComponent). I have checked FacetComponent and TermsComponent. If I want 
> that search component works in a distributed environment I have to set 
> ResponseBuilder's isDistrib to true, like this (this is also done in 
> TermsComponent for example):
>   public void prepare(ResponseBuilder rb) throws IOException {
>   SolrParams params = rb.req.getParams();
>   String shards = params.get(ShardParams.SHARDS);
>   if (shards != null) {
>   List lst = StrUtils.splitSmart(shards, ",", 
> true);
>   rb.shards = lst.toArray(new String[lst.size()]);
>   rb.isDistrib = true;
>   }
>   }
> If I have my component outside the package org.apache.solr.handler.component 
> this doesn't work. Is it possible to make isDistrib public (or is this the 
> wrong procedure/behaviour/design)?
> Many thanks,
> Rok



--
This message was sent by Atlassian 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-6917) Move NumericField out of core to backwards-codecs

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6917:
---
Attachment: LUCENE-6917.patch

Another patch, I think it's ready.

I fixed nocommits, added some limits on numBytes (16) and numDims (8), and 
fixed ant precommit, which was annoyingly not easy ... I could not get @link 
out to backward-codecs to render correctly into javadocs ... so I had to 
cutover to @code for links outside of core.

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch, LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+95) - Build # 15139 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15139/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
-XX:-CompactStrings

75 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrClient.testTwoServers

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:45489/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:45489/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([3657A1F35A9660A0:96BD0F7E81DD4E80]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:107)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:72)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:86)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.addDocs(TestLBHttpSolrClient.java:115)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.setUp(TestLBHttpSolrClient.java:101)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:905)
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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.j

[jira] [Resolved] (LUCENE-5096) WhitespaceTokenizer supports Java whitespace, should also support Unicode whitespace

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-5096.

Resolution: Duplicate

> WhitespaceTokenizer supports Java whitespace, should also support Unicode 
> whitespace
> 
>
> Key: LUCENE-5096
> URL: https://issues.apache.org/jira/browse/LUCENE-5096
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Affects Versions: 4.3.1
> Environment: all
>Reporter: Jörg Prante
>Priority: Minor
>
> The whitespace tokenizer supports only Java whitespace as defined in 
> http://docs.oracle.com/javase/6/docs/api/java/lang/Character.html#isWhitespace(char)
> A useful improvement would be to support also Unicode whitespace as defined 
> in the Unicode property list 
> http://www.unicode.org/Public/UCD/latest/ucd/PropList.txt



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
ERROR: SolrIndexSearcher opens=27 closes=26

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=27 closes=26
at __randomizedtesting.SeedInfo.seed([F1B0EF4985C4E60C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:453)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:225)
at sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

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

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


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=3187, name=searcherExecutor-1461-thread-1, stat

[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk-9-ea+95) - Build # 14842 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14842/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseG1GC -XX:-CompactStrings

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=2117, name=ou=system.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at jdk.internal.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:218)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2103)
at 
java.util.concurrent.ScheduledThre

[jira] [Comment Edited] (SOLR-8373) KerberosPlugin: Using multiple nodes on same machine leads clients to fetch TGT for every request

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8373 at 12/7/15 10:46 PM:
--

Updated patch.

# All authentication plugins are CoreContainer aware. This was needed for 
letting the plugin know the port number on which Solr was started.
# Introduces a new startup parameter, {{solr.kerberos.cookie.portaware=true}}. 
When using SolrCloud, and this parameter is true, the cookies use both the host 
and the port to identify the domain. This should be enabled only on hosts where 
more than one solr node needs to be setup. This can go in the 
{{bin/solr.in.sh}}.



was (Author: ichattopadhyaya):
Updated patch.

# All authentication plugins are CoreContainer aware. This was needed for 
letting the plugin know the port number on which Solr was started.
# Introduces a new startup parameter, {{solr.kerberos.cookie.portaware=true}}. 
When using SolrCloud, and this parameter is true, the cookies use both the host 
and the port to identify the domain. This should be enabled only on hosts where 
more than one solr node needs to be setup.


> KerberosPlugin: Using multiple nodes on same machine leads clients to fetch 
> TGT for every request
> -
>
> Key: SOLR-8373
> URL: https://issues.apache.org/jira/browse/SOLR-8373
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Critical
> Attachments: SOLR-8373.patch, SOLR-8373.patch, SOLR-8373.patch
>
>
> Kerberized solr nodes accept negotiate/spnego/kerberos requests and processes 
> them. It also passes back to the client a cookie called "hadoop.auth" (which 
> is currently unused, but will eventually be used for delegation tokens). 
> If two or more nodes are on the same machine, they all send out the cookie 
> which have the same domain (hostname) and same path, but different cookie 
> values.
> Upon receipt at the client, if a cookie is rejected (which in this case will 
> be), the client compulsorily gets a ​​*new*​​ TGT from the KDC instead of 
> reading the same ticket from the ticketcache. This is causing the heavy 
> traffic at the KDC, plus intermittent "Request is a replay" (which indicates 
> race condition at KDC while handing out the TGT for the same principal).



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

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

[JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build # 341 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/341/
Java: 32bit/jdk-9-ea+95 -client -XX:+UseConcMarkSweepGC -XX:-CompactStrings

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testEmbeddedDocsLegacy

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([6A78779A7DB89BB2:67DC0663DB6CDCB7]:0)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at 
org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:159)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:417)
at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:481)
at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:186)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
at org.apache.solr.util.TestHarness.query(TestHarness.java:311)
at 
org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:87)
at 
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testEmbeddedDocsLegacy(TestTikaEntityProcessor.java:168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingO

[jira] [Commented] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[ASF subversion and git services (JIRA)]

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

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

Commit 1718486 from [~nknize] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718486 ]

LUCENE-6908: Fix TestGeoUtils.testGeoRelations to handle irregular rectangles. 
Refactors relational methods to new GeoRelationUtils class.

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch, 
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



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

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

[jira] [Updated] (SOLR-8373) KerberosPlugin: Using multiple nodes on same machine leads clients to fetch TGT for every request

[Ishan Chattopadhyaya (JIRA)]

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

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

Updated patch.

# All authentication plugins are CoreContainer aware. This was needed for 
letting the plugin know the port number on which Solr was started.
# Introduces a new startup parameter, {{solr.kerberos.cookie.portaware=true}}. 
When using SolrCloud, and this parameter is true, the cookies use both the host 
and the port to identify the domain. This should be enabled only on hosts where 
more than one solr node needs to be setup.


> KerberosPlugin: Using multiple nodes on same machine leads clients to fetch 
> TGT for every request
> -
>
> Key: SOLR-8373
> URL: https://issues.apache.org/jira/browse/SOLR-8373
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Critical
> Attachments: SOLR-8373.patch, SOLR-8373.patch, SOLR-8373.patch
>
>
> Kerberized solr nodes accept negotiate/spnego/kerberos requests and processes 
> them. It also passes back to the client a cookie called "hadoop.auth" (which 
> is currently unused, but will eventually be used for delegation tokens). 
> If two or more nodes are on the same machine, they all send out the cookie 
> which have the same domain (hostname) and same path, but different cookie 
> values.
> Upon receipt at the client, if a cookie is rejected (which in this case will 
> be), the client compulsorily gets a ​​*new*​​ TGT from the KDC instead of 
> reading the same ticket from the ticketcache. This is causing the heavy 
> traffic at the KDC, plus intermittent "Request is a replay" (which indicates 
> race condition at KDC while handing out the TGT for the same principal).



--
This message was sent by Atlassian 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-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5868:
--

it passed 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/875/console


> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[ASF subversion and git services (JIRA)]

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

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

Commit 1718481 from [~nknize] in branch 'dev/trunk'
[ https://svn.apache.org/r1718481 ]

LUCENE-6908: Fix TestGeoUtils.testGeoRelations to handle irregular rectangles. 
Refactors relational methods to new GeoRelationUtils class.

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch, 
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



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

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

[jira] [Resolved] (LUCENE-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-6732.
---
Resolution: Fixed

Fixed. Thanks Mikhail!

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732-verbose.patch, 
> LUCENE-6732.patch, LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[ASF subversion and git services (JIRA)]

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

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

Commit 1718480 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718480 ]

Merged revision(s) 1718479 from lucene/dev/trunk:
LUCENE-6732: Improve logging, add verbose logging of filenames

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732-verbose.patch, 
> LUCENE-6732.patch, LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[ASF subversion and git services (JIRA)]

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

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

Commit 1718479 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1718479 ]

LUCENE-6732: Improve logging, add verbose logging of filenames

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732-verbose.patch, 
> LUCENE-6732.patch, LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-8378) Add upconfig and downconfig commands to the bin/solr script and managed-only schema to configsets

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-8378:
-
Attachment: SOLR-8378.patch

Updated patch with Windows support.

WARNING: this hasn't been tested yet as I don't have a handy Windows 
environment. I'll spin up an EC2 instance sometime if someone doesn't beat me 
to it.

> Add upconfig and downconfig commands to the bin/solr script and managed-only 
> schema to configsets
> -
>
> Key: SOLR-8378
> URL: https://issues.apache.org/jira/browse/SOLR-8378
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4, Trunk
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-8378.patch, SOLR-8378.patch, SOLR-8378.patch, 
> SOLR-8378.patch
>
>
> It would be convenient to be able to upload and download arbitrary configsets 
> to Zookeeper.
> This _might_ be the last thing we need before not requiring users be aware of 
> zkcli, which is awkward.



--
This message was sent by Atlassian 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-5868) JoinUtil support for NUMERIC docValues fields

[ASF subversion and git services (JIRA)]

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

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

Commit 1718473 from m...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718473 ]

LUCENE-5868: query-time join for numerics

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-4280) spellcheck.maxResultsForSuggest based on filter query results

[James Dyer (JIRA)]

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

James Dyer updated SOLR-4280:
-
Attachment: SOLR-4280.patch

Here is an updated patch for Trunk.  I've included unit tests and changed 
javadoc to reflect the added functionality.  I've also modified how this gets 
triggered.  Rather than introduce a new request parameter, the user passes in 
"spellcheck.maxResultsForSuggest" as a fractional percent, between 0 and 1.  So 
if the user wants no more than 5% of the most-selective filter's results to be 
the maximum results to trigger suggestions, they would specify 
"spellcheck.maxResultsForSuggest=.05".  If, for instance, the most-selective 
filter returns (by itself) 100 documents, then the effective maximum number of 
hits we will return without triggering spelling suggestions is 5.

[~markus17] does this all sound right to you?  Is this still a feature you want 
and would be interested in seeing committed?

> spellcheck.maxResultsForSuggest based on filter query results
> -
>
> Key: SOLR-4280
> URL: https://issues.apache.org/jira/browse/SOLR-4280
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Reporter: Markus Jelsma
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-4280-trunk-1.patch, SOLR-4280-trunk.patch, 
> SOLR-4280-trunk.patch, SOLR-4280.patch
>
>
> spellcheck.maxResultsForSuggest takes a fixed number but ideally should be 
> able to take a ratio and calculate that against the maximum number of results 
> the filter queries return.
> At least in our case this would certainly add a lot of value. >99% of our 
> end-users search within one or more filters of which one is always unique. 
> The number of documents for each of those unique filters varies significantly 
> ranging from 300 to 3.000.000 documents in which they search. The 
> maxResultsForSuggest is set to a reasonable low value so it kind of works 
> fine but sometimes leads to undesired suggestions for a large subcorpus that 
> has more misspellings.
> Spun off from SOLR-4278.



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6732:
--
Attachment: LUCENE-6732-verbose.patch

Simple patch.

The output won't change, but if you get an error like this try: {{ant -verbose 
validate}}

I will commit this later. The behaviour is now identical to the {{}} 
task, hwich also prints all files when verbose.

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732-verbose.patch, 
> LUCENE-6732.patch, LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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: [VOTE] Release Lucene/Solr 5.4.0-RC1

[Upayavira]

I've committed the smoke test patch to trunk, 5x and 5_4 branches.

Upayavira

On Mon, Dec 7, 2015, at 06:27 PM, Michael McCandless wrote:
> +1 to release, smoke tester was happy for me (after applying the patch):
> 
> SUCCESS! [0:30:52.332883]
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> On Mon, Dec 7, 2015 at 11:08 AM, Michael McCandless
>  wrote:
> > +1 for your patch to smokeTestRelease.py, Upayavira; please commit it!
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> > On Sun, Dec 6, 2015 at 3:38 PM, Upayavira  wrote:
> >> The getHREFs() method is taking in an HTTPS URL, but failing to preserve
> >> the protocol, resulting in an HTTP call that the server naturally
> >> bounces to HTTPS. Unfortunately, the next loop round also forgets the
> >> HTTPS, and hence we're stuck in an endless loop. Below is a patch that
> >> fixes this issue. I'd rather someone with more knowledge of this script
> >> confirm my suspicion and apply the patch for us all to use, as I cannot
> >> see how this ever worked.
> >>
> >> I personally ran the smoke test on my local copy, so did not hit this
> >> HTTP/HTTPS code. I'm running the HTTP version now, and will check on it
> >> in the morning.
> >>
> >> Index: dev-tools/scripts/smokeTestRelease.py
> >> ===
> >> --- dev-tools/scripts/smokeTestRelease.py   (revision 1718046)
> >> +++ dev-tools/scripts/smokeTestRelease.py   (working copy)
> >> @@ -84,7 +84,12 @@
> >># Deref any redirects
> >>while True:
> >>  url = urllib.parse.urlparse(urlString)
> >> -h = http.client.HTTPConnection(url.netloc)
> >> +if url.scheme == "http":
> >> +  h = http.client.HTTPConnection(url.netloc)
> >> +elif url.scheme == "https":
> >> +  h = http.client.HTTPSConnection(url.netloc)
> >> +else:
> >> +  raise RuntimeError("Unknown protocol: %s" % url.scheme)
> >>  h.request('GET', url.path)
> >>  r = h.getresponse()
> >>  newLoc = r.getheader('location')
> >>
> >> Upayavira
> >>
> >> On Sun, Dec 6, 2015, at 06:26 PM, Noble Paul wrote:
> >>> Same here.
> >>>
> >>> On Sun, Dec 6, 2015 at 2:36 PM, Shalin Shekhar Mangar
> >>>  wrote:
> >>> > Is anyone able to run the smoke tester on this RC? It just hangs for a
> >>> > long time on "loading release URL" for me.
> >>> >
> >>> > python3 -u dev-tools/scripts/smokeTestRelease.py --tmp-dir
> >>> > ../smoke-5.4 --revision 178046 --version 5.4.0 --test-java8
> >>> > ~/programs/jdk8
> >>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
> >>> > Java 1.7 JAVA_HOME=/home/shalin/programs/jdk7
> >>> > Java 1.8 JAVA_HOME=/home/shalin/programs/jdk8
> >>> > NOTE: output encoding is UTF-8
> >>> >
> >>> > Load release URL
> >>> > "https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/";...
> >>> >
> >>> > I did a strace and found that the server is returning a HTTP 301 moved
> >>> > permanently response to the http request.
> >>> >
> >>> > On Sat, Dec 5, 2015 at 4:28 PM, Upayavira  wrote:
> >>> >> Please vote for the RC1 release candidate for Lucene/Solr 5.4.0
> >>> >>
> >>> >> The artifacts can be downloaded from:
> >>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
> >>> >>
> >>> >> You can run the smoke tester directly with this command:
> >>> >> python3 -u dev-tools/scripts/smokeTestRelease.py
> >>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
> >>> >>
> >>> >> I will let this vote run until midnight (GMT) on Wednesday 9 December.
> >>> >>
> >>> >> Please cast your votes! (and let me know, politely :-) if I missed
> >>> >> anything)
> >>> >>
> >>> >> Upayavira
> >>> >>
> >>> >> -
> >>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Regards,
> >>> > Shalin Shekhar Mangar.
> >>> >
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> -
> >>> Noble Paul
> >>>
> >>> -
> >>> 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-

[jira] [Commented] (LUCENE-6908) TestGeoUtils.testGeoRelations is buggy with irregular rectangles

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-6908:


Thanks [~mikemccand]! I plan to add the benchmark to luceneutil unless you 
think there's a better place for it? Going to commit shortly.

> TestGeoUtils.testGeoRelations is buggy with irregular rectangles
> 
>
> Key: LUCENE-6908
> URL: https://issues.apache.org/jira/browse/LUCENE-6908
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Nicholas Knize
> Attachments: LUCENE-6908.patch, LUCENE-6908.patch, LUCENE-6908.patch, 
> LUCENE-6908.patch
>
>
> The {{.testGeoRelations}} method doesn't exactly test the behavior of 
> GeoPoint*Query as its using the BKD split technique (instead of quad cell 
> division) to divide the space on each pass. For "large" distance queries this 
> can create a lot of irregular rectangles producing large radial distortion 
> error when using the cartesian approximation methods provided by 
> {{GeoUtils}}. This issue improves the accuracy of GeoUtils cartesian 
> approximation methods on irregular rectangles without having to cut over to 
> an expensive oblate geometry approach.



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

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

[jira] [Commented] (LUCENE-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6732:
---

If you want to fix underlying issue open bug in Java bugtracker and request 
that File streams include file name in exception message.

The Groovy script is fine, so please leve it as is. Maybe add debug logging for 
investigation as said before.

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732.patch, 
> LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6732:
---

bq. log the filename
+1

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732.patch, 
> LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6732:
---

This is a standard Java Exception. There is no problem with it. Ant or Java 
would report similar. You cannot really improve this. The operating system does 
not give more information. This is basic ant semantics of using FileScanner and 
opening files.

The only thing you can do is to log the filename with debug prio, so you can 
try with ant -verbose. Should I do this?

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732.patch, 
> LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-8266) Remove Java Serialization from the Streaming API

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8266:
--

[~gerlowskija], thanks for patch!

I'll will review it in the next day or two. You didn't mention but I'm assuming 
this is a trunk patch?

Also typically you would update the same patch file name (SOLR-8266.patch) and 
jira will display them all. I would then pick your latest patch to apply. Don't 
worry about it in this case, I'll just take your latest patch file.



> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions will be used to serialize Streaming 
> API Objects. 



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

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

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

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8266:
--

#1:  You've got the big picture right.

#2: Probably a good idea.

#3: The rather unwieldy StreamingTest will eventually be split into smaller 
test cases, one for each stream. Same with the StreamingExpressions tests. We 
should probably add a ticket for this. 

> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions will be used to serialize Streaming 
> API Objects. 



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

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

[jira] [Updated] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-5868:
-
Attachment: LUCENE-5868-5x.patch

fixed some precommit issues in [^LUCENE-5868-5x.patch]

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-6732) Improve validate-source-patterns in build.xml (e.g., detect invalid license headers!!)

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-6732:
--

Got an observation. Something weird happen with one of my working copy files, 
the validation script failed with quite laconic:
{code}
java.io.IOException: Input/output error
{code}
There is no a problem path, in exception. It's not a problem of the script, but 
just a lack of usability. Do you think it's worth to improve exception 
reporting in groovy script? I'm not familiar, but I can try. 
for the reference the stack trace:
{code}
Caused by: java.io.IOException: Input/output error
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.read1(BufferedReader.java:210)
at java.io.BufferedReader.read(BufferedReader.java:286)
at java.io.Reader.read(Reader.java:140)
at 
org.codehaus.groovy.runtime.IOGroovyMethods.getText(IOGroovyMethods.java:884)
at 
org.codehaus.groovy.runtime.ResourceGroovyMethods.getText(ResourceGroovyMethods.java:588)
at org.codehaus.groovy.runtime.dgm$964.invoke(Unknown Source)
at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at 
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at 
embedded_script_in__Users_mkhl_Documents_lucene_solr_https_5x_build_dot_xml$_run_closure3.doCall(embedded_script_in__Users_mkhl_Documents_lucene_solr_https_5x_build_dot_xml:60)
{code} 

> Improve validate-source-patterns in build.xml (e.g., detect invalid license 
> headers!!)
> --
>
> Key: LUCENE-6732
> URL: https://issues.apache.org/jira/browse/LUCENE-6732
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6732-v2.patch, LUCENE-6732.patch, 
> LUCENE-6732.patch
>
>
> Today I enabled warnings analysis on Policeman Jenkins. This scans the build 
> log for warnings by javac and reports them in statistics, together with 
> source file dumps.
> When doing that I found out that someone added again a lot of "invalid" 
> license headers using {{/\*\*}} instead a simple comment. This causes 
> javadocs warnings under some circumstances, because {{/\*\*}} is start of 
> javadocs and not a license comment.
> I then tried to fix the validate-source-patterns to detect this, but due to a 
> bug in ANT, the {{}} filter is applied per line (although it 
> has multiline matching capabilities!!!).
> So I rewrote our checker to run with groovy. This also has some good parts:
> - it tells you wwhat was broken, otherwise you just know there is an error, 
> but not whats wrong (tab, nocommit,...)
> - its much faster (multiple {{}} read file over and over, 
> this one reads file one time into a string and then applies all regular 
> expressions).



--
This message was sent by Atlassian 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-8383) SolrCore.java container initialCapacity tweaks

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8383:
-

bq. +HashMap m= new HashMap<>(14);
HashMap default load factor is 0.75, so this will still get resized after the 
10th item. We should either use the two argument constructor with loadFactor = 
1.0 or a larger initial capacity to compensate (19).

bq. +Map result = new LinkedHashMap<>(map.entrySet().size());
Why not {{map.size()}}? Also, same comments about load factor apply.

> SolrCore.java container initialCapacity tweaks
> --
>
> Key: SOLR-8383
> URL: https://issues.apache.org/jira/browse/SOLR-8383
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8383.patch
>
>
> patch against trunk to follow



--
This message was sent by Atlassian 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-8266) Remove Java Serialization from the Streaming API

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-8266 at 12/7/15 8:21 PM:


Thanks for the early look/help guys.  I've updated the patch to align with your 
suggestions.  The tests all pass now, with the caveat that I had to comment out 
the testParallelEOF call in testStreams().  Everything else seems to work fine.

While I'm confident in the code I wrote, I do have some questions about how 
this code is working:

1.) I just wanted to double-check my understanding of the {{StreamFactory}} 
configuration discrepancies causing the stack trace I mentioned above.

{{StreamFactory}} is used to convert between {{TupleStreams}} and 
{{StreamExpressionParameters}} and are used in both SolrJ ( {{ParallelStream}} 
for example) and SOLR ({{StreamHandler}}).  These factories need to be in sync. 
 If not, SolrJ can end up sending serialized values to Solr that it doesn't 
know what to do with (as in the conflicting "count" types from a few comments 
ago).

Just trying to make sure I understand the big picture, so I can make edits with 
more confidence next time.

2.) I noticed that {{StreamFactory.withFunctionName()}} takes any {{Class}} as 
it's second argument.  Is there any value in narrowing the type of that 
parameter, so that it's harder to misconfigure {{StreamFactory}}?  (i.e. 
{{withFunctionName(String name, Class clazz)}}).

3.) StreamingTest has a single test that triggers 20ish independent sub-tests 
(e.g. testParallelEOF, testStatsStream).  Updating these tests to use the 
{{StreamFactory}} was a bit more painful that it probably could've been.  With 
the sub-tests all bundled together, the process for fixing them looked like: 
(a) run them all, (b) wait for a failure, (c) scroll back through the output to 
see which clause failed, (d) fix and repeat.  Had the sub-tests been separate 
JUnit tests, identifying the failing pieces and fixing them would've been 
easier.  Is there a historical reason theses tests have all been grouped 
together (performance/overhead for example)?  If not, do you think there would 
be any pushback on splitting these test clauses apart (as a part of a separate 
JIRA).



was (Author: gerlowskija):
Thanks for the early look/help guys.  I've updated the patch to align with your 
suggestions.  The tests all pass now, with the caveat that I had to comment out 
the testParallelEOF call in testStreams().  Everything else seems to work fine.

While I'm confident in the code I wrote, I do have some questions about how 
this code is working:

1.) I just wanted to double-check my understanding of the {{StreamFactory}} 
configuration discrepancies causing the stack trace I mentioned above.

{{StreamFactory}} is used to convert between {{TupleStream}}s and 
{{StreamExpressionParameters}} and are used in both SolrJ ({{ParallelStream}} 
for example) and SOLR ({{StreamHandler}}).  These factories need to be in sync. 
 If not, SolrJ can end up sending serialized values to Solr that it doesn't 
know what to do with (as in the conflicting "count" types from a few comments 
ago).

Just trying to make sure I understand the big picture, so I can make edits with 
more confidence next time.

2.) I noticed that {{StreamFactory.withFunctionName()}} takes any {{Class}} as 
it's second argument.  Is there any value in narrowing the type of that 
parameter, so that it's harder to misconfigure {{StreamFactory}}?  (i.e. 
{{withFunctionName(String name, Class clazz)}}).

3.) StreamingTest has a single test that triggers 20ish independent sub-tests 
(e.g. testParallelEOF, testStatsStream).  Updating these tests to use the 
{{StreamFactory}} was a bit more painful that it probably could've been.  With 
the sub-tests all bundled together, the process for fixing them looked like: 
(a) run them all, (b) wait for a failure, (c) scroll back through the output to 
see which clause failed, (d) fix and repeat.  Had the sub-tests been separate 
JUnit tests, identifying the failing pieces and fixing them would've been 
easier.  Is there a historical reason theses tests have all been grouped 
together (performance/overhead for example)?  If not, do you think there would 
be any pushback on splitting these test clauses apart (as a part of a separate 
JIRA).


> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions wi

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

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-8266:
--
Attachment: SOLR-8266-comment-out-testParallelEOF.patch

Thanks for the early look/help guys.  I've updated the patch to align with your 
suggestions.  The tests all pass now, with the caveat that I had to comment out 
the testParallelEOF call in testStreams().  Everything else seems to work fine.

While I'm confident in the code I wrote, I do have some questions about how 
this code is working:

1.) I just wanted to double-check my understanding of the {{StreamFactory}} 
configuration discrepancies causing the stack trace I mentioned above.

{{StreamFactory}} is used to convert between {{TupleStream}}s and 
{{StreamExpressionParameters}} and are used in both SolrJ ({{ParallelStream}} 
for example) and SOLR ({{StreamHandler}}).  These factories need to be in sync. 
 If not, SolrJ can end up sending serialized values to Solr that it doesn't 
know what to do with (as in the conflicting "count" types from a few comments 
ago).

Just trying to make sure I understand the big picture, so I can make edits with 
more confidence next time.

2.) I noticed that {{StreamFactory.withFunctionName()}} takes any {{Class}} as 
it's second argument.  Is there any value in narrowing the type of that 
parameter, so that it's harder to misconfigure {{StreamFactory}}?  (i.e. 
{{withFunctionName(String name, Class clazz)}}).

3.) StreamingTest has a single test that triggers 20ish independent sub-tests 
(e.g. testParallelEOF, testStatsStream).  Updating these tests to use the 
{{StreamFactory}} was a bit more painful that it probably could've been.  With 
the sub-tests all bundled together, the process for fixing them looked like: 
(a) run them all, (b) wait for a failure, (c) scroll back through the output to 
see which clause failed, (d) fix and repeat.  Had the sub-tests been separate 
JUnit tests, identifying the failing pieces and fixing them would've been 
easier.  Is there a historical reason theses tests have all been grouped 
together (performance/overhead for example)?  If not, do you think there would 
be any pushback on splitting these test clauses apart (as a part of a separate 
JIRA).


> Remove Java Serialization from the Streaming API
> 
>
> Key: SOLR-8266
> URL: https://issues.apache.org/jira/browse/SOLR-8266
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
> Attachments: SOLR-8266-comment-out-testParallelEOF.patch, 
> SOLR-8266.patch
>
>
> This is being done mainly for security reasons but it's also architecturally 
> the right thing to do.
> Going forward only Streaming Expressions will be used to serialize Streaming 
> API Objects. 



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

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

[jira] [Updated] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-5868:
-
Attachment: LUCENE-5868-5x.patch

moved to java7, got [^LUCENE-5868-5x.patch] 

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-5x.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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: VOTE: RC0 Release apache-solr-ref-guide-5.4.pdf

[Cassandra Targett]

Sorry, bad link in my earlier mail:

https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-5.4-RC0/

On Mon, Dec 7, 2015 at 1:23 PM, Cassandra Targett 
wrote:

> Please VOTE to release the Apache Solr Ref Guide for Solr 5.4:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-X.Y-RCZ
>
> $ cat apache-solr-ref-guide-5.4-RC0/apache-solr-ref-guide-5.4.pdf.sha1
>
> 56413817546a1f7acf2493f24d96bab8071659ef  apache-solr-ref-guide-5.4.pdf
>
>
> +1 from me.
>
> Cassandra
>

Re: [JENKINS] Lucene-Solr-5.x-Solaris (64bit/jdk1.8.0) - Build # 238 - Failure!

[Uwe Schindler]

Hi,

I think this happens when the VBOX virtual machine daemon adjusts time at wrong 
moment or some other VM running on same hardware causes some hang, maybe caused 
by saturated IO. How long is the time limit, the nanosecond unit makes it hard 
to figure out from error message.

Uwe

Am 7. Dezember 2015 20:02:26 MEZ, schrieb Policeman Jenkins Server 
:
>Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/238/
>Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -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:
>597367202266360 (System.nanoTime(): 597371702796891),
>TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@3a15c305
>
>Stack Trace:
>org.apache.lucene.index.ExitableDirectoryReader$ExitingReaderException:
>The request took too long to iterate over terms. Timeout: timeoutAt:
>597367202266360 (System.nanoTime(): 597371702796891),
>TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@3a15c305
>   at
>__randomizedtesting.SeedInfo.seed([C503106CB6F6D521:7D66BD2DDD2C5CD8]:0)
>   at
>org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.checkAndThrow(ExitableDirectoryReader.java:167)
>   at
>org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.(ExitableDirectoryReader.java:157)
>   at
>org.apache.lucene.index.ExitableDirectoryReader$ExitableTerms.iterator(ExitableDirectoryReader.java:141)
>   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:108)
>   at
>org.apache.lucene.search.MultiTermQuery.getTermsEnum(MultiTermQuery.java:318)
>   at
>org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite(MultiTermQueryConstantScoreWrapper.java:146)
>   at
>org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.bulkScorer(MultiTermQueryConstantScoreWrapper.java:199)
>   at
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:818)
>   at
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
>   at
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:744)
>   at
>org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:460)
>   at
>org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:489)
>   at
>org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader(TestExitableDirectoryReader.java:127)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   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:50)
>   at
>org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at
>org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at
>org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at
>org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at
>com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at
>com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>   at
>com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>   at
>com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>   at
>com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
>   at
>c

VOTE: RC0 Release apache-solr-ref-guide-5.4.pdf

[Cassandra Targett]

Please VOTE to release the Apache Solr Ref Guide for Solr 5.4:

https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-X.Y-RCZ

$ cat apache-solr-ref-guide-5.4-RC0/apache-solr-ref-guide-5.4.pdf.sha1

56413817546a1f7acf2493f24d96bab8071659ef  apache-solr-ref-guide-5.4.pdf


+1 from me.

Cassandra

[jira] [Commented] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-5868:
--

oh.my... there are no λ-s in 5.x. the patch is gonna missing its' most of beauty

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-3191) field exclusion from fl

[Demian Katz (JIRA)]

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

Demian Katz commented on SOLR-3191:
---

I just took another look at this and discovered that the patch no longer 
applies cleanly against the latest code. Looks like it was broken by r1714994. 
Any chance somebody could generate an updated patch? I don't think there are 
any major conflicts here -- just enough to break the patch.

> field exclusion from fl
> ---
>
> Key: SOLR-3191
> URL: https://issues.apache.org/jira/browse/SOLR-3191
> Project: Solr
>  Issue Type: Improvement
>Reporter: Luca Cavanna
>Priority: Minor
> Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, 
> SOLR-3191.patch
>
>
> I think it would be useful to add a way to exclude field from the Solr 
> response. If I have for example 100 stored fields and I want to return all of 
> them but one, it would be handy to list just the field I want to exclude 
> instead of the 99 fields for inclusion through fl.



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/238/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -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: 
597367202266360 (System.nanoTime(): 597371702796891), 
TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@3a15c305

Stack Trace:
org.apache.lucene.index.ExitableDirectoryReader$ExitingReaderException: The 
request took too long to iterate over terms. Timeout: timeoutAt: 
597367202266360 (System.nanoTime(): 597371702796891), 
TermsEnum=org.apache.lucene.codecs.blockterms.BlockTermsReader$FieldReader$SegmentTermsEnum@3a15c305
at 
__randomizedtesting.SeedInfo.seed([C503106CB6F6D521:7D66BD2DDD2C5CD8]:0)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.checkAndThrow(ExitableDirectoryReader.java:167)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTermsEnum.(ExitableDirectoryReader.java:157)
at 
org.apache.lucene.index.ExitableDirectoryReader$ExitableTerms.iterator(ExitableDirectoryReader.java:141)
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:108)
at 
org.apache.lucene.search.MultiTermQuery.getTermsEnum(MultiTermQuery.java:318)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.rewrite(MultiTermQueryConstantScoreWrapper.java:146)
at 
org.apache.lucene.search.MultiTermQueryConstantScoreWrapper$1.bulkScorer(MultiTermQueryConstantScoreWrapper.java:199)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:818)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:535)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:744)
at 
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:460)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:489)
at 
org.apache.lucene.index.TestExitableDirectoryReader.testExitableFilterIndexReader(TestExitableDirectoryReader.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRu

[jira] [Commented] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[ASF subversion and git services (JIRA)]

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

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

Commit 1718443 from m...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1718443 ]

LUCENE-5868: query-time join for numerics

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



--
This message was sent by Atlassian 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-8373) KerberosPlugin: Using multiple nodes on same machine leads clients to fetch TGT for every request

[Ishan Chattopadhyaya (JIRA)]

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

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

Here's a patch I'm working on. 

As of this patch, to invoke this, Solr nodes (that are on a shared hosting, so 
to speak) need to start Solr using the port number as part of the cookie domain:

{{bin/solr -c -p 8983 -Dsolr.kerberos.cookie.domain=hostname:8983}}
(This, obviously, cannot go into the solr.in.sh, and hence needs to be removed 
from there).

Looking to see if there's something better that can be done to pass the port 
number to the kerberos authentication plugin.

> KerberosPlugin: Using multiple nodes on same machine leads clients to fetch 
> TGT for every request
> -
>
> Key: SOLR-8373
> URL: https://issues.apache.org/jira/browse/SOLR-8373
> Project: Solr
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Noble Paul
>Priority: Critical
> Attachments: SOLR-8373.patch, SOLR-8373.patch
>
>
> Kerberized solr nodes accept negotiate/spnego/kerberos requests and processes 
> them. It also passes back to the client a cookie called "hadoop.auth" (which 
> is currently unused, but will eventually be used for delegation tokens). 
> If two or more nodes are on the same machine, they all send out the cookie 
> which have the same domain (hostname) and same path, but different cookie 
> values.
> Upon receipt at the client, if a cookie is rejected (which in this case will 
> be), the client compulsorily gets a ​​*new*​​ TGT from the KDC instead of 
> reading the same ticket from the ticketcache. This is causing the heavy 
> traffic at the KDC, plus intermittent "Request is a replay" (which indicates 
> race condition at KDC while handing out the TGT for the same principal).



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

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

RE: [JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build # 338 - Failure!

[Uwe Schindler]

Hi,

I disabled the tests in Apache Solr (extraction, morphlines-cell, 
dataimporthandler-extras) when ran under Java 9.
I did this for branch_5x and trunk, but not for the 5.4 release branch. So you 
may see tests failing for the release branch, unless backporting the change. 
Unfortunately the Jenkins infrstrautcure does not allow easily to disable JDK 9 
randomization just for the 5.4 build.

Comments?
Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Monday, December 07, 2015 3:42 PM
> To: dev@lucene.apache.org
> Subject: RE: [JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build #
> 338 - Failure!
> 
> Issue: https://issues.apache.org/jira/browse/PDFBOX-3155
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Monday, December 07, 2015 2:16 PM
> > To: dev@lucene.apache.org
> > Subject: RE: [JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build
> #
> > 338 - Failure!
> >
> > This is a problem in PDFBOX:
> >
> >
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.pdfbox/pd
> > fbox/1.8.10/org/apache/pdfbox/util/PDFTextStripper.java/#121
> >
> > This code uses the system property in a wrong way. Like Lucene's code it
> > should use java.specification.version (and/or cleanup the string befor
> parsing
> > as number).
> >
> > I'll open issue in PDFBox. For now we can only exclude this test in Java 9.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> > > Sent: Monday, December 07, 2015 2:06 PM
> > > To: dev@lucene.apache.org
> > > Subject: [JENKINS-EA] Lucene-Solr-5.4-Linux (32bit/jdk-9-ea+95) - Build #
> > 338
> > > - Failure!
> > > Importance: Low
> > >
> > > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.4-Linux/338/
> > > Java: 32bit/jdk-9-ea+95 -server -XX:+UseConcMarkSweepGC -XX:-
> > > CompactStrings
> > >
> > > 3 tests failed.
> > > FAILED:
> > >
> >
> org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testEmbeddedD
> > > ocsLegacy
> > >
> > > Error Message:
> > >
> > >
> > > Stack Trace:
> > > java.lang.ExceptionInInitializerError
> > >   at
> > >
> >
> __randomizedtesting.SeedInfo.seed([DB63511572AAE364:D6C720ECD47EA4
> > > 61]:0)
> > >   at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
> > >   at
> > >
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
> > >   at
> > >
> org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
> > >   at
> > >
> >
> org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntity
> > > Processor.java:159)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(Entity
> > > ProcessorWrapper.java:244)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.j
> > > ava:476)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.j
> > > ava:415)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:
> > > 330)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233
> > > )
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporte
> > > r.java:417)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.jav
> > > a:481)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody
> > > (DataImportHandler.java:186)
> > >   at
> > >
> >
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandl
> > > erBase.java:156)
> > >   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2073)
> > >   at org.apache.solr.util.TestHarness.query(TestHarness.java:311)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.run
> > > FullImport(AbstractDataImportHandlerTestCase.java:87)
> > >   at
> > >
> >
> org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testEmbeddedD
> > > ocsLegacy(TestTikaEntityProcessor.java:168)
> > >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >   at
> > >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> > > ava:62)
> > >   at
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > > sorImpl.java:43)
> > >   at java.lang.reflect.Method.invoke(Method.java:520)
> > >   at
> > >
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner.i

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 15 
seconds
at 
__randomizedtesting.SeedInfo.seed([BA52467E5B4F93E:83F11BBD4B4894C6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:175)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:837)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393)
at 
org.apache.solr.cloud.AsyncMigrateRouteKeyTest.test(AsyncMigrateRouteKeyTest.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:965)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:940)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
o

[jira] [Comment Edited] (LUCENE-6917) Move NumericField out of core to backwards-codecs

[David Smiley (JIRA)]

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

David Smiley edited comment on LUCENE-6917 at 12/7/15 6:40 PM:
---

bq. Because this is the simplest cutover I could do for now. For BBoxStrategy, 
it would be a major change (you must reindex) to switch from postings to 
DimensionalValues

Since this is for 6.0, a major release, so this is acceptable.

bq.  I think we should switch over consumers of LegacyNumeric* in follow-on 
issues?

Okay, if that's how you want to do it.  But I figured the effort (albeit not 
"large") in using LegacyNumeric could have instead been directed on using 
DimensionalValues, and in the end there will be less effort to move fully over. 
 For example adding dependency on backwards-codecs only to then take it away in 
another issue.  Your call.  Maybe I'm misjudging what's involved in switching 
to DimensionalValues but I hope it's easy.


was (Author: dsmiley):
bq. Because this is the simplest cutover I could do for now. For
BBoxStrategy, it would be a major change (you must reindex) to
switch from postings to DimensionalValues

Since this is for 6.0, a major release, so this is acceptable.

bq.  I think we should
switch over consumers of LegacyNumeric* in follow-on
issues?

Okay, if that's how you want to do it.  But I figured the effort (albeit not 
"large") in using LegacyNumeric could have instead been directed on using 
DimensionalValues, and in the end there will be less effort to move fully over. 
 For example adding dependency on backwards-codecs only to then take it away in 
another issue.  Your call.  Maybe I'm misjudging what's involved in switching 
to DimensionalValues but I hope it's easy.

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



--
This message was sent by Atlassian 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-6917) Move NumericField out of core to backwards-codecs

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6917:
--

bq. Because this is the simplest cutover I could do for now. For
BBoxStrategy, it would be a major change (you must reindex) to
switch from postings to DimensionalValues

Since this is for 6.0, a major release, so this is acceptable.

bq.  I think we should
switch over consumers of LegacyNumeric* in follow-on
issues?

Okay, if that's how you want to do it.  But I figured the effort (albeit not 
"large") in using LegacyNumeric could have instead been directed on using 
DimensionalValues, and in the end there will be less effort to move fully over. 
 For example adding dependency on backwards-codecs only to then take it away in 
another issue.  Your call.  Maybe I'm misjudging what's involved in switching 
to DimensionalValues but I hope it's easy.

> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



--
This message was sent by Atlassian 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: [VOTE] Release Lucene/Solr 5.4.0-RC1

[Michael McCandless]

+1 to release, smoke tester was happy for me (after applying the patch):

SUCCESS! [0:30:52.332883]

Mike McCandless

http://blog.mikemccandless.com

On Mon, Dec 7, 2015 at 11:08 AM, Michael McCandless
 wrote:
> +1 for your patch to smokeTestRelease.py, Upayavira; please commit it!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Sun, Dec 6, 2015 at 3:38 PM, Upayavira  wrote:
>> The getHREFs() method is taking in an HTTPS URL, but failing to preserve
>> the protocol, resulting in an HTTP call that the server naturally
>> bounces to HTTPS. Unfortunately, the next loop round also forgets the
>> HTTPS, and hence we're stuck in an endless loop. Below is a patch that
>> fixes this issue. I'd rather someone with more knowledge of this script
>> confirm my suspicion and apply the patch for us all to use, as I cannot
>> see how this ever worked.
>>
>> I personally ran the smoke test on my local copy, so did not hit this
>> HTTP/HTTPS code. I'm running the HTTP version now, and will check on it
>> in the morning.
>>
>> Index: dev-tools/scripts/smokeTestRelease.py
>> ===
>> --- dev-tools/scripts/smokeTestRelease.py   (revision 1718046)
>> +++ dev-tools/scripts/smokeTestRelease.py   (working copy)
>> @@ -84,7 +84,12 @@
>># Deref any redirects
>>while True:
>>  url = urllib.parse.urlparse(urlString)
>> -h = http.client.HTTPConnection(url.netloc)
>> +if url.scheme == "http":
>> +  h = http.client.HTTPConnection(url.netloc)
>> +elif url.scheme == "https":
>> +  h = http.client.HTTPSConnection(url.netloc)
>> +else:
>> +  raise RuntimeError("Unknown protocol: %s" % url.scheme)
>>  h.request('GET', url.path)
>>  r = h.getresponse()
>>  newLoc = r.getheader('location')
>>
>> Upayavira
>>
>> On Sun, Dec 6, 2015, at 06:26 PM, Noble Paul wrote:
>>> Same here.
>>>
>>> On Sun, Dec 6, 2015 at 2:36 PM, Shalin Shekhar Mangar
>>>  wrote:
>>> > Is anyone able to run the smoke tester on this RC? It just hangs for a
>>> > long time on "loading release URL" for me.
>>> >
>>> > python3 -u dev-tools/scripts/smokeTestRelease.py --tmp-dir
>>> > ../smoke-5.4 --revision 178046 --version 5.4.0 --test-java8
>>> > ~/programs/jdk8
>>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/
>>> > Java 1.7 JAVA_HOME=/home/shalin/programs/jdk7
>>> > Java 1.8 JAVA_HOME=/home/shalin/programs/jdk8
>>> > NOTE: output encoding is UTF-8
>>> >
>>> > Load release URL
>>> > "https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046/";...
>>> >
>>> > I did a strace and found that the server is returning a HTTP 301 moved
>>> > permanently response to the http request.
>>> >
>>> > On Sat, Dec 5, 2015 at 4:28 PM, Upayavira  wrote:
>>> >> Please vote for the RC1 release candidate for Lucene/Solr 5.4.0
>>> >>
>>> >> The artifacts can be downloaded from:
>>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
>>> >>
>>> >> You can run the smoke tester directly with this command:
>>> >> python3 -u dev-tools/scripts/smokeTestRelease.py
>>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.4.0-RC1-rev178046
>>> >>
>>> >> I will let this vote run until midnight (GMT) on Wednesday 9 December.
>>> >>
>>> >> Please cast your votes! (and let me know, politely :-) if I missed
>>> >> anything)
>>> >>
>>> >> Upayavira
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Shalin Shekhar Mangar.
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> -
>>> Noble Paul
>>>
>>> -
>>> 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] [Updated] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-5868:
-
Attachment: LUCENE-5868.patch

I'm going to commit [^LUCENE-5868.patch] in trunk and 5.x then in couple of 
hours.
* applied all suggested changes
* amended CHANGES.txt 
* checked {{precommit}} and javadocs  

> JoinUtil support for NUMERIC docValues fields 
> --
>
> Key: LUCENE-5868
> URL: https://issues.apache.org/jira/browse/LUCENE-5868
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Fix For: 5.5
>
> Attachments: LUCENE-5868-lambdarefactoring.patch, 
> LUCENE-5868-lambdarefactoring.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, LUCENE-5868.patch, 
> qtj.diff
>
>
> while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at 
> least. 
> I plan to provide test/patch. It might be important, because Solr's join can 
> do that. Please vote if you care! 



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+95) - Build # 15137 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15137/
Java: 64bit/jdk-9-ea+95 -XX:-UseCompressedOops -XX:+UseParallelGC 
-XX:-CompactStrings

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testIndexingWithTikaEntityProcessor

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([8F1AB1205578EC88:D2C6B0B57585623A]:0)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
at 
org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
at 
org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:159)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:417)
at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:481)
at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:186)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2070)
at org.apache.solr.util.TestHarness.query(TestHarness.java:311)
at 
org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:87)
at 
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.testIndexingWithTikaEntityProcessor(TestTikaEntityProcessor.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java: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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverr

[jira] [Commented] (SOLR-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8349:


I'm sure folks have been busy getting stuff into 5.4, but with the RC nearly 
produced, perhaps someone can review this now? It's intended for 6.x, but I'd 
like feedback/review so that I have something to chew on (unless of course it's 
already perfect :) ). I would definitely like someone who's comfortable with 
{{CoreContainer}} and class loading in Solr to take a peek. I put the 
definition for {{ContainerResourceSharing}} in Lucene package space. It needed 
to be there so that the hunspell analyzer for SOLR-3443 could leverage it 
without depending on Solr classes (or any other Lucene class that might load a 
large file that doesn't change from core to core). This patch adds no 
implementation in the Lucene world, only for {{SolrResourceLoader}}. Folks who 
are using Lucene in a container other than Solr can implement for their 
container or not as they desire.

The intended pattern for usage within Solr (i.e. {{SearchComponent}} 
implementations) is to either navigate to {{CoreContainer}} from a core if 
{{CoreAware}} or cast the ResourceLoader if only {{ResourceLoaderAware}}. 
Either path leads to the same place as SolrResourceLoader merely delegates to 
it's CoreContainer anyway. 

At the Lucene level, code would want to test {{instanceof 
ContainerResourceSharing}} and do the right thing based on the result, 
retaining existing behavior to support use of Lucene outside of containers on 
in containers without support.  Let me know if there are better ideas here...

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
> Attachments: SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



--
This message was sent by Atlassian 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-6917) Move NumericField out of core to backwards-codecs

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6917:


bq. Can you please link to the benchmarks you did?

The results are a bit scattered ... I need to re-run and I think get a
blog post out describing all of this, at some point ... but in the
meantime, here are the benchmmarks:

LUCENE-6901 has the most recent index-time benchmarks, and LUCENE-6891
has the most recent search-time benchmarks and LUCENE-6881 has the
NumericField baseline.

The sources for these benchmarks are all in luceneutil.

bq. And I'm curious why some uses, say BBoxStrategy to pick one example, still 
use the Legacy version;

Because this is the simplest cutover I could do for now.  For
{{BBoxStrategy}}, it would be a major change (you must reindex) to
switch from postings to {{DimensionalValues}} ... I think we should
switch over consumers of {{LegacyNumeric*}} in follow-on
issues?


> Move NumericField out of core to backwards-codecs
> -
>
> Key: LUCENE-6917
> URL: https://issues.apache.org/jira/browse/LUCENE-6917
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 6.0
>
> Attachments: LUCENE-6917.patch
>
>
> DimensionalValues seems to be better across the board (indexing time, 
> indexing size, search-speed, search-time heap required) than NumericField, at 
> least in my testing so far.
> I think for 6.0 we should move {{IntField}}, {{LongField}}, {{FloatField}}, 
> {{DoubleField}} and {{NumericRangeQuery}} to {{backward-codecs}}, and rename 
> with {{Legacy}} prefix?



--
This message was sent by Atlassian 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] (LUCENE-6907) make TestParser extendable

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-6907.
-
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> make TestParser extendable
> --
>
> Key: LUCENE-6907
> URL: https://issues.apache.org/jira/browse/LUCENE-6907
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: LUCENE-6907.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} class.



--
This message was sent by Atlassian 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-6919) Change the Scorer API to expose an iterator instead of extending DocIdSetIterator

[Adrien Grand (JIRA)]

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

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

Good point about Scorer.docId(). I think it's also better to not require 
Collectors to go though the iterator since they are not supposed to move the 
iterator. Once this change is in, maybe in the future we can expose a smaller 
interface in Collector.setScorer (that only exposes a doc ID, a freq and a 
score, as suggested in LUCENE-6228).

Here is a patch with the proposed changes. It makes some things slightly less 
complicated due to the additional level of indirection between a Weight and a 
DocIdSetIterator (eg. for delete-by-query) but it also makes some Scorer 
implementations simpler since they can now just return the iterator instead of 
reimplementing the whole DISI API and forwarding it to an existing 
DocIdSetIterator (for instance this is what conjunctions did).

For consistency, Scorer.asTwoPhaseIterator has been renamed to 
Scorer.twoPhaseIterator. So now Scorer has Scorer.iterator() which is a 
required method and returns a DocIdSetIterator and Scorer.twoPhaseIterator 
which is an optional method and returns a TwoPhaseIterator.

The luceneutil report is consistent with what I got with the hacky patch:
{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
OrNotHighLow 1119.21  (3.9%) 1078.59  (5.3%)   
-3.6% ( -12% -5%)
  AndHighLow  796.76  (4.9%)  774.43  (5.6%)   
-2.8% ( -12% -8%)
 MedSloppyPhrase   58.28  (4.0%)   57.67  (4.9%)   
-1.0% (  -9% -8%)
 LowSpanNear  122.71  (2.0%)  121.65  (2.8%)   
-0.9% (  -5% -4%)
HighSpanNear3.25  (2.3%)3.22  (2.0%)   
-0.8% (  -4% -3%)
   LowPhrase  113.56  (1.5%)  112.73  (2.1%)   
-0.7% (  -4% -2%)
 MedSpanNear  109.63  (2.4%)  109.15  (1.7%)   
-0.4% (  -4% -3%)
HighSloppyPhrase6.23  (5.0%)6.22  (5.4%)   
-0.2% ( -10% -   10%)
OrHighNotLow  102.42  (3.8%)  102.32  (3.5%)   
-0.1% (  -7% -7%)
 LowSloppyPhrase   22.01  (2.3%)   22.01  (2.8%)
0.0% (  -4% -5%)
   MedPhrase   15.92  (1.6%)   15.94  (1.8%)
0.1% (  -3% -3%)
  HighPhrase   34.63  (3.1%)   34.75  (3.2%)
0.3% (  -5% -6%)
OrNotHighMed  141.69  (3.3%)  142.75  (3.3%)
0.7% (  -5% -7%)
   OrNotHighHigh   50.74  (2.1%)   51.15  (2.7%)
0.8% (  -3% -5%)
 Respell   63.24  (3.2%)   64.05  (3.1%)
1.3% (  -4% -7%)
   OrHighNotHigh   42.37  (2.8%)   42.92  (3.0%)
1.3% (  -4% -7%)
OrHighNotMed   80.74  (2.9%)   82.18  (2.9%)
1.8% (  -3% -7%)
 Prefix3  151.13  (4.7%)  155.37  (6.7%)
2.8% (  -8% -   14%)
 AndHighHigh   36.96  (2.3%)   38.37  (2.3%)
3.8% (   0% -8%)
  Fuzzy1   25.95  (5.9%)   27.00  (5.7%)
4.0% (  -7% -   16%)
   OrHighMed   50.05  (5.0%)   52.10  (5.7%)
4.1% (  -6% -   15%)
  OrHighHigh   33.64  (5.2%)   35.16  (4.7%)
4.5% (  -5% -   15%)
  IntNRQ   10.93  (6.9%)   11.46  (6.2%)
4.8% (  -7% -   19%)
 MedTerm  179.51  (3.8%)  188.22  (3.9%)
4.9% (  -2% -   13%)
   OrHighLow   79.55  (2.9%)   83.56  (2.8%)
5.0% (   0% -   11%)
 LowTerm  682.13  (8.0%)  716.84  (6.4%)
5.1% (  -8% -   21%)
  AndHighMed  114.21  (2.4%)  120.06  (2.4%)
5.1% (   0% -   10%)
Wildcard   29.31  (6.4%)   31.07  (5.8%)
6.0% (  -5% -   19%)
HighTerm  118.05  (3.5%)  125.83  (4.4%)
6.6% (  -1% -   14%)
  Fuzzy2   61.23 (20.9%)   67.19 (21.3%)
9.7% ( -26% -   65%)
{noformat}

> Change the Scorer API to expose an iterator instead of extending 
> DocIdSetIterator
> -
>
> Key: LUCENE-6919
> URL: https://issues.apache.org/jira/browse/LUCENE-6919
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6919.patch, LUCENE-6919.patch
>
>
> I was working on trying to address the performanc

[jira] [Commented] (SOLR-7977) SOLR_HOST in solr.in.sh doesn't apply to Jetty's host property

[Xavier (JIRA)]

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

Xavier commented on SOLR-7977:
--

[~elyograg], I'd agree that two different option variables are a good idea. For 
instance, in my (small) deployment, I have a single solr server, thus I don't 
really care how SolrCloud addresses the server; but I care which IP is used to 
listen for requests. Right now, following [~shalinmangar]'s recommendation, I'm 
directly passing the {{jetty.host}} parameter using {{$SOLR_OPTS}}. However, 
that's a temporary workaround, especially since the fact that the solr black 
box uses jetty is an implementation detail.

Adding a {{$SOLR_LISTEN}} or {{$SOLR_BIND_IP}} variable to the _solr.in.sh_ 
file, which then gets translated to the appropriate parameter, would, in my 
opinion, be the best way of solving the problem, and if the internal 
implementation changes (solr moves off an embedded jetty), the configuration 
files will need little to no editing.

> SOLR_HOST in solr.in.sh doesn't apply to Jetty's host property
> --
>
> Key: SOLR-7977
> URL: https://issues.apache.org/jira/browse/SOLR-7977
> Project: Solr
>  Issue Type: Bug
>  Components: security, SolrCloud
>Reporter: Shalin Shekhar Mangar
>  Labels: impact-medium
> Fix For: 5.4, Trunk
>
>
> [~sdavids] pointed out that the SOLR_HOST config option in solr.in.sh doesn't 
> set Jetty's host property (solr.jetty.host) so it still binds to all net 
> interfaces. Perhaps it should apply to jetty as well because the user 
> explicitly wants us to bind to specific IP?



--
This message was sent by Atlassian 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-6907) make TestParser extendable

[ASF subversion and git services (JIRA)]

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

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

Commit 1718434 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718434 ]

LUCENE-6907: make TestParser extendable, rename 
lucene/queryparser/src/test/org/apache/lucene/queryparser/xml/NumericRangeQueryQuery.xml
 to NumericRangeQuery.xml (merge in revision 1718427 from trunk)

> make TestParser extendable
> --
>
> Key: LUCENE-6907
> URL: https://issues.apache.org/jira/browse/LUCENE-6907
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-6907.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} class.



--
This message was sent by Atlassian 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-8382) Allow configuration of the bind IP(host) in solr 5

[Xavier (JIRA)]

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

Xavier commented on SOLR-8382:
--

Thanks, will do.

> Allow configuration of the bind IP(host) in solr 5
> --
>
> Key: SOLR-8382
> URL: https://issues.apache.org/jira/browse/SOLR-8382
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04
>Reporter: Xavier
>
> With the new standalone configuration, I haven't been able to configure solr 
> to bind to a specific IP. Is there an option to do so?
> So far I've had to configure the firewall to block access to to port instead 
> of simply making solr bind to only the interface I want it to.
> Adding a _clear_ option to manage the bind host (like we have for the bind 
> port) would be very 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] [Commented] (SOLR-8382) Allow configuration of the bind IP(host) in solr 5

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8382:
-

You are right. I initially though that we should use the same SOLR_HOST for 
both jetty and solrcloud but there is some pushback on that. There is an issue 
open for that SOLR-7977 so please add your opinion on that issue.

https://issues.apache.org/jira/browse/SOLR-7977

> Allow configuration of the bind IP(host) in solr 5
> --
>
> Key: SOLR-8382
> URL: https://issues.apache.org/jira/browse/SOLR-8382
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04
>Reporter: Xavier
>
> With the new standalone configuration, I haven't been able to configure solr 
> to bind to a specific IP. Is there an option to do so?
> So far I've had to configure the firewall to block access to to port instead 
> of simply making solr bind to only the interface I want it to.
> Adding a _clear_ option to manage the bind host (like we have for the bind 
> port) would be very 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] [Commented] (SOLR-8368) A SolrCore needs to replay it's tlog before the leader election process.

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-8368:
--

1.  On the taking a long time concern, there is a lot we could do to speed up 
the tlog replaying, right?  Particularly if on a shared/distributed filesystem.

2.  We can't figure out who should be the leader by looking at the end of the 
tlog(s) (again, on a shared/distributed filesystem), but not actually replaying 
them before waiting for the election?

> A SolrCore needs to replay it's tlog before the leader election process.
> 
>
> Key: SOLR-8368
> URL: https://issues.apache.org/jira/browse/SOLR-8368
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>
> If we do it after like now, the correct leader may not be able to become 
> leader.



--
This message was sent by Atlassian 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-8382) Allow configuration of the bind IP(host) in solr 5

[Xavier (JIRA)]

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

Xavier commented on SOLR-8382:
--

I had tried the {{SOLR_HOST}} option, but as you discovered, it only changes 
the ip used for solrcloud calls; it leaves the bind ip unchanged.

As for directly setting {{jetty.host}}, while it may work for now, the fact 
that solr internally uses jetty is an implementation detail (as specified by 
the docs), and should not be relied on. At the very least, the _bin/solr_ 
script should translate some sort of option, maybe {{SOLR_BIND_IP}} or 
something, into the required jetty parameter.

> Allow configuration of the bind IP(host) in solr 5
> --
>
> Key: SOLR-8382
> URL: https://issues.apache.org/jira/browse/SOLR-8382
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04
>Reporter: Xavier
>
> With the new standalone configuration, I haven't been able to configure solr 
> to bind to a specific IP. Is there an option to do so?
> So far I've had to configure the firewall to block access to to port instead 
> of simply making solr bind to only the interface I want it to.
> Adding a _clear_ option to manage the bind host (like we have for the bind 
> port) would be very 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] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Tim Allison (JIRA)]

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

Tim Allison resolved LUCENE-5205.
-
   Resolution: Later
Lucene Fields:   (was: New,Patch Available)

Ticket is getting too long.  Development has moved to github, and I'll actively 
maintain it and respond to bug reports there:  
https://github.com/tballison/lucene-addons.  

If a committer has an interest in incorporating this into Lucene proper, I'll 
be more than happy to collaborate on a new ticket.

Thank you, [~rcmuir] for all of your work on this!  Thank you, 
[~paul.elsc...@xs4all.nl] for your many contributions, as well!

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
This message was sent by Atlassian 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-8382) Allow configuration of the bind IP(host) in solr 5

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8382:
-

I blogged about this a while back: 
http://shal.in/post/127561227271/how-to-make-apache-solr-listen-on-a-specific-ip

> Allow configuration of the bind IP(host) in solr 5
> --
>
> Key: SOLR-8382
> URL: https://issues.apache.org/jira/browse/SOLR-8382
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04
>Reporter: Xavier
>
> With the new standalone configuration, I haven't been able to configure solr 
> to bind to a specific IP. Is there an option to do so?
> So far I've had to configure the firewall to block access to to port instead 
> of simply making solr bind to only the interface I want it to.
> Adding a _clear_ option to manage the bind host (like we have for the bind 
> port) would be very 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] [Commented] (LUCENE-5205) SpanQueryParser with recursion, analysis and syntax very similar to classic QueryParser

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5205:
-

Fixed in [lexer2 
branch|https://github.com/tballison/lucene-addons/tree/lexer2], which is the 
most recent 5.0-5.2 branch and in 
[lucene5.3on-0.1|https://github.com/tballison/lucene-addons/tree/lucene5.3on-0.1].

The current fix effectively ignores double quotes around a single term that is 
analyzed to a single term.  The user needs to use single quotes or use \ to 
escape multiterm operators that should not be parsed (e.g. {{'term*'}}...find 
the five letter term that ends with an asterisk...not a prefix query for words 
starting with {{term}}).

> SpanQueryParser with recursion, analysis and syntax very similar to classic 
> QueryParser
> ---
>
> Key: LUCENE-5205
> URL: https://issues.apache.org/jira/browse/LUCENE-5205
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/queryparser
>Reporter: Tim Allison
>  Labels: patch
> Attachments: LUCENE-5205-cleanup-tests.patch, 
> LUCENE-5205-date-pkg-prvt.patch, LUCENE-5205.patch.gz, LUCENE-5205.patch.gz, 
> LUCENE-5205_dateTestReInitPkgPrvt.patch, 
> LUCENE-5205_improve_stop_word_handling.patch, 
> LUCENE-5205_smallTestMods.patch, LUCENE_5205.patch, 
> SpanQueryParser_v1.patch.gz, patch.txt
>
>
> This parser extends QueryParserBase and includes functionality from:
> * Classic QueryParser: most of its syntax
> * SurroundQueryParser: recursive parsing for "near" and "not" clauses.
> * ComplexPhraseQueryParser: can handle "near" queries that include multiterms 
> (wildcard, fuzzy, regex, prefix),
> * AnalyzingQueryParser: has an option to analyze multiterms.
> At a high level, there's a first pass BooleanQuery/field parser and then a 
> span query parser handles all terminal nodes and phrases.
> Same as classic syntax:
> * term: test 
> * fuzzy: roam~0.8, roam~2
> * wildcard: te?t, test*, t*st
> * regex: /\[mb\]oat/
> * phrase: "jakarta apache"
> * phrase with slop: "jakarta apache"~3
> * default "or" clause: jakarta apache
> * grouping "or" clause: (jakarta apache)
> * boolean and +/-: (lucene OR apache) NOT jakarta; +lucene +apache -jakarta
> * multiple fields: title:lucene author:hatcher
>  
> Main additions in SpanQueryParser syntax vs. classic syntax:
> * Can require "in order" for phrases with slop with the \~> operator: 
> "jakarta apache"\~>3
> * Can specify "not near": "fever bieber"!\~3,10 ::
> find "fever" but not if "bieber" appears within 3 words before or 10 
> words after it.
> * Fully recursive phrasal queries with \[ and \]; as in: \[\[jakarta 
> apache\]~3 lucene\]\~>4 :: 
> find "jakarta" within 3 words of "apache", and that hit has to be within 
> four words before "lucene"
> * Can also use \[\] for single level phrasal queries instead of " as in: 
> \[jakarta apache\]
> * Can use "or grouping" clauses in phrasal queries: "apache (lucene solr)"\~3 
> :: find "apache" and then either "lucene" or "solr" within three words.
> * Can use multiterms in phrasal queries: "jakarta\~1 ap*che"\~2
> * Did I mention full recursion: \[\[jakarta\~1 ap*che\]\~2 (solr~ 
> /l\[ou\]\+\[cs\]\[en\]\+/)]\~10 :: Find something like "jakarta" within two 
> words of "ap*che" and that hit has to be within ten words of something like 
> "solr" or that "lucene" regex.
> * Can require at least x number of hits at boolean level: "apache AND (lucene 
> solr tika)~2
> * Can use negative only query: -jakarta :: Find all docs that don't contain 
> "jakarta"
> * Can use an edit distance > 2 for fuzzy query via SlowFuzzyQuery (beware of 
> potential performance issues!).
> Trivial additions:
> * Can specify prefix length in fuzzy queries: jakarta~1,2 (edit distance =1, 
> prefix =2)
> * Can specifiy Optimal String Alignment (OSA) vs Levenshtein for distance 
> <=2: (jakarta~1 (OSA) vs jakarta~>1(Levenshtein)
> This parser can be very useful for concordance tasks (see also LUCENE-5317 
> and LUCENE-5318) and for analytical search.  
> Until LUCENE-2878 is closed, this might have a use for fans of SpanQuery.
> Most of the documentation is in the javadoc for SpanQueryParser.
> Any and all feedback is welcome.  Thank you.
> Until this is added to the Lucene project, I've added a standalone 
> lucene-addons repo (with jars compiled for the latest stable build of Lucene) 
>  on [github|https://github.com/tballison/lucene-addons].



--
This message was sent by Atlassian 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-6907) make TestParser extendable

[ASF subversion and git services (JIRA)]

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

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

Commit 1718427 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1718427 ]

LUCENE-6907: make TestParser extendable, rename 
lucene/queryparser/src/test/org/apache/lucene/queryparser/xml/NumericRangeQueryQuery.xml
 to NumericRangeQuery.xml

> make TestParser extendable
> --
>
> Key: LUCENE-6907
> URL: https://issues.apache.org/jira/browse/LUCENE-6907
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-6907.patch
>
>
> Tests for the xml query parser in SOLR-839 for example could then be 
> extending the {{TestParser}} class.



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

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

[jira] [Created] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option

[Jeremy Anderson (JIRA)]

Jeremy Anderson created SOLR-8384:
-

 Summary: Windows Start Script when Changing SOLR_SERVER_DIR via -d 
option
 Key: SOLR-8384
 URL: https://issues.apache.org/jira/browse/SOLR-8384
 Project: Solr
  Issue Type: Bug
  Components: scripts and tools
Affects Versions: 5.3.1
 Environment: Windows
Reporter: Jeremy Anderson
Priority: Trivial


bin\solr.cmd Requires change of environment variables used in the " REM now 
wait to see Solr come online ..." command.  Currently this call uses 
DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a 
different server directory using the -d command option.

Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries 
are able to be found when checking that SOLR started.

There may be other uses in the script where this issue is present when starting 
SOLR from a different directory other than 'server'.



--
This message was sent by Atlassian 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-8383) SolrCore.java container initialCapacity tweaks

[Christine Poerschke (JIRA)]

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

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

> SolrCore.java container initialCapacity tweaks
> --
>
> Key: SOLR-8383
> URL: https://issues.apache.org/jira/browse/SOLR-8383
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8383.patch
>
>
> patch against trunk to follow



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

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

[jira] [Created] (SOLR-8383) SolrCore.java container initialCapacity tweaks

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-8383:
-

 Summary: SolrCore.java container initialCapacity tweaks
 Key: SOLR-8383
 URL: https://issues.apache.org/jira/browse/SOLR-8383
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor


patch against trunk to follow



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

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