[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

[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] [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] [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=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

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

[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] [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=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

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

[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 

[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=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] [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] [Commented] (SOLR-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7774: revise BasicDistributedZkTest.test logic w.r.t. 'commitWithin did 
not work on some nodes'

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7774.patch
>
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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] [Commented] (SOLR-8263) Tlog replication could interfere with the replay of buffered updates

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8263:
-

Good to know, thanks Renaud!

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



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

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

[jira] [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=15045055#comment-15045055
 ] 

Joel Bernstein commented on SOLR-8266:
--

Just checked and the StreamHandler is using the CountMetric. It may be that 
this test is incompatible with the current StreamHandler setup.

Probably best to just comment it out for now. If you run into other test errors 
dealing with *count* comment them out as well.

I'll take a look a those tests when I review the patch.



> 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.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] [Resolved] (LUCENE-6924) Upgrade randomizedtesting to 2.3.2

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-6924.
-
Resolution: Fixed

> Upgrade randomizedtesting to 2.3.2
> --
>
> Key: LUCENE-6924
> URL: https://issues.apache.org/jira/browse/LUCENE-6924
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: Trunk, 5.5
>
>




--
This message was sent by Atlassian 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-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-7774:
---

Thanks for the review Shalin. Change now committed to both trunk and branch_5x.

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7774.patch
>
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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

[JENKINS] Lucene-Solr-NightlyTests-5.4 - Build # 11 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.4/11/

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([978B2AF96872E167:4901448453D08394]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:175)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:136)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:131)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:831)
at 
org.apache.solr.cloud.LeaderInitiatedRecoveryOnShardRestartTest.testRestartWithAllInLIR(LeaderInitiatedRecoveryOnShardRestartTest.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
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 

[jira] [Commented] (SOLR-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7774: revise BasicDistributedZkTest.test logic w.r.t. 'commitWithin did 
not work on some nodes' (merge in revision 1718364 from trunk)

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7774.patch
>
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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

Re: test suite counter skipping numbers?

[Dawid Weiss]

Done, Hoss.
https://issues.apache.org/jira/browse/LUCENE-6924

D.

On Mon, Nov 16, 2015 at 9:13 AM, Dawid Weiss  wrote:
> Yeah... it'd be perfect to make it somehow configurable so that tweaks
> like this can be done without changing the code. I'll see what I can
> do.
>
> https://github.com/randomizedtesting/randomizedtesting/issues/220
>
> By the way -- if any of you guys is using argument factory methods
> I've added a nicer way to provide their names without the need to wrap
> the argument in a custom class, etc.
>
> https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.3.0
>
> Dawid
>
> On Sun, Nov 15, 2015 at 10:21 PM, Chris Hostetter
>  wrote:
>>
>> : > Tests summary: 100 suites (2 ignored), xx tests, xx ignored (xx 
>> assumptions).
>> :
>> : Will do it in the next version. Thanks for letting me know.
>>
>> Dawid: that reminds me, if you are tweaking the logging, it would also be
>> helpful if the "Completed [X/Y] ..." line after each test also indicated
>> if there had been any failures so far, so you can see at a glance in your
>> terminal if any thing has failed up to this point (w/o needing to scroll
>> back, or wait for the ant command to complete.
>>
>> for example...
>>
 [junit4] Completed [1/545] on J1 in 17.77s, 3 tests, 1 skipped
>>
>> ..just started, everything is all good..
>>
 [junit4] Completed [25/545 (1!)] on J3 in 7.35s, 5 tests, 5 skipped
>>
>> ..a suite just had failure, every "Completed" line after that will include
>> "(1!)" until another quite has a failure...
>>
 [junit4] Completed [26/545 (1!)] on J0 in 1.34s, 42 tests, 1 skipped
 [junit4] Completed [27/545 (1!)] on J1 in 3.45s, 31 tests, 4 skipped
>>
>> ... if you glance at your terminal now, you know to scroll up because
>> something failed earlier...
>>
>> If another test fails later the output changes a bit...
>>
 [junit4] Completed [145/545 (2!)] on J1 in 13.73s, 42 tests, 1 skipped
>>
>> ...etc...
>>
>>
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>

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

[jira] [Updated] (LUCENE-6924) Upgrade randomizedtesting to 2.3.2

[Dawid Weiss (JIRA)]

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

Dawid Weiss updated LUCENE-6924:

Description: 
https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.3.2

> Upgrade randomizedtesting to 2.3.2
> --
>
> Key: LUCENE-6924
> URL: https://issues.apache.org/jira/browse/LUCENE-6924
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: Trunk, 5.5
>
>
> https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.3.2



--
This message was sent by Atlassian 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: Early-access build b95 of JDK 9 is available for download

[Uwe Schindler]

Hi Rory,

 

The Apache Lucene test suite passes perfectly with project Verona. Apache Solr 
also passes its main module, but because of a dependent library, Solr’s 
DataExtractionHandler tests don’t pass. In fact some 3rd party JAR (Apache 
PDFBOX) parses “java.version” in some incompatible way…. (as described in the 
JEP:  “Note that all code which has historically detected . in any of these 
system properties as part of version identification will need to be examined 
and potentially modified. For example, 
System.getProperty("java.version").indexof('.') will return -1 for major 
releases.”

 

See the following 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

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:19 AM
To: u...@thetaphi.de; dawid.we...@cs.put.poznan.pl
Cc: rory.odonn...@oracle.com; Dalibor Topic ; 
Balchandra Vaidya ; Abdul Kolarkunnu 
; dev@lucene.apache.org
Subject: Early-access build b95 of JDK 9 is available for download

 


Hi Uwe & Dawid, 

Early-access builds of JDK 9 with Project Verona [0] in b95 are available for 
download here  . 

The goal of this Project is to implement the new JDK version string as 
described in JEP-223   [1].
The new version-string scheme is designed to easily distinguish major, minor, 
and security-update releases.
For more information please see Iris Clark's email [2] , also see Dalibor 
Topic's blog on this topic [3].

Please send usage questions, feedback and experience reports to the verona-dev 
  mailing list. 

Note: If you haven’t already subscribed to that mailing list then please do so 
first, otherwise 
your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223 
[2] http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html
[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version



-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

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

[Uwe Schindler]

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.invoke(Randomize
> > dRunner.java:1764)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> > mizedRunner.java:871)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
> > mizedRunner.java:907)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
> > omizedRunner.java:921)
> > at
> >
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.
> > evaluate(SystemPropertiesRestoreRule.java:57)
> > at
> >
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> > SetupTeardownChained.java:50)
> > at
> >
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> > fterRule.java:46)
> > at
> >
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> > readAndTestName.java:49)
> > at
> >
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> > IgnoreAfterMaxFailures.java:65)
> > at
> >
> 

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

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-8266 at 12/7/15 2:50 PM:


While that mapping is setup in the test you've got to remember that in a 
parallel situation the expression is passed off to a different process which 
doesn't use the factory created in the test. Instead it uses a factory created 
in StreamHandler. That one has some defaults set and also reads solrconfig.xml 
to get any new mappings. Check that factory to make sure count is mapped there. 
I've tried to keep the default up to date with all default stream classes but 
may have missed some. 

This setup is there so that people can add their own implementation of both 
streams and expressions (and really anything else that is in the Expressible 
hierarchy). 


was (Author: dpgove):
While that mapping is setup in the test you've got to remember that in a 
parallel situation the expression is passed off to a different process ehoch 
doesn't use the factory created in the test. Instead it uses a factory created 
in StreamHandler. That one has some defaults set and also reads solrconfig.xml 
to get any new mappings. Check that factory to make sure count is mapped there. 
I've tried to keep the default up to date with all default stream classes but 
may have missed some. 

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

Re: Early-access build b95 of JDK 9 is available for download

[Rory O'Donnell]

Hi Uwe,

Thanks for the feedback.

Rgds,Rory

On 07/12/2015 14:44, Uwe Schindler wrote:


Hi Rory,

The Apache Lucene test suite passes perfectly with project Verona. 
Apache Solr also passes its main module, but because of a dependent 
library, Solr’s DataExtractionHandler tests don’t pass. In fact some 
3^rd party JAR (Apache PDFBOX) parses “java.version” in some 
incompatible way…. (as described in the JEP:  “Note that all code 
which has historically detected . in any of these system properties as 
part of version identification will need to be examined and 
potentially modified. For example, 
System.getProperty("java.version").indexof('.') will return -1 for 
major releases.”


See the following 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

*From:*Rory O'Donnell [mailto:rory.odonn...@oracle.com]
*Sent:* Monday, December 07, 2015 10:19 AM
*To:* u...@thetaphi.de; dawid.we...@cs.put.poznan.pl
*Cc:* rory.odonn...@oracle.com; Dalibor Topic 
; Balchandra Vaidya 
; Abdul Kolarkunnu 
; dev@lucene.apache.org

*Subject:* Early-access build b95 of JDK 9 is available for download


Hi Uwe & Dawid,

Early-access builds of JDK 9 with Project Verona [0] in b95 are 
available for download here .


The goal of this Project is to implement the new JDK version string as 
described in JEP-223  [1].
The new version-string scheme is designed to easily distinguish major, 
minor, and security-update releases.
For more information please see Iris Clark's email [2] , also see 
Dalibor Topic's blog on this topic [3].


Please send usage questions, feedback and experience reports to the 
verona-dev  
mailing list.


Note: If you haven’t already subscribed to that mailing list then 
please do so first, otherwise

your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223
[2] 
http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html

[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Updated] (LUCENE-6925) add (test-framework) [Random]ForceMergePolicy classes

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-6925:

Attachment: LUCENE-6925.patch

proposed patch against trunk

> add (test-framework) [Random]ForceMergePolicy classes
> -
>
> Key: LUCENE-6925
> URL: https://issues.apache.org/jira/browse/LUCENE-6925
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: LUCENE-6925.patch
>
>
> lucene changes:
>  * {{ForceMergePolicy}} for disallowing background segment merges but 
> permitting optimize/forceMerge segment merges
>  * {{TestForceMergePolicy}}
> solr changes:
>  * {{RandomForceMergePolicy}} extending {{RandomMergePolicy}}
>  * {{TestRandomForceMergePolicy}}
> motivation:
>  * test cases e.g. for SOLR-5730 may wish to distinguish before-merge and 
> after-merge query results or behaviour



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

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

[jira] [Created] (LUCENE-6925) add (test-framework) [Random]ForceMergePolicy classes

[Christine Poerschke (JIRA)]

Christine Poerschke created LUCENE-6925:
---

 Summary: add (test-framework) [Random]ForceMergePolicy classes
 Key: LUCENE-6925
 URL: https://issues.apache.org/jira/browse/LUCENE-6925
 Project: Lucene - Core
  Issue Type: Test
Reporter: Christine Poerschke
Assignee: Christine Poerschke
 Attachments: LUCENE-6925.patch

lucene changes:
 * {{ForceMergePolicy}} for disallowing background segment merges but 
permitting optimize/forceMerge segment merges
 * {{TestForceMergePolicy}}

solr changes:
 * {{RandomForceMergePolicy}} extending {{RandomMergePolicy}}
 * {{TestRandomForceMergePolicy}}

motivation:
 * test cases e.g. for SOLR-5730 may wish to distinguish before-merge and 
after-merge query results or behaviour




--
This message was sent by Atlassian 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-6922) Improve svn to git workaround script

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6922:
-

Is the announcement of the EOL to the git-svn mirror available publicly?

How will this affect users that rely on the github mirror to access the 
Lucene/Solr repository?



> Improve svn to git workaround script
> 
>
> Key: LUCENE-6922
> URL: https://issues.apache.org/jira/browse/LUCENE-6922
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: svnBranchToGit.py
>
>
> As the git-svn mirror for Lucene/Solr will be turned off near the end of 
> 2015, try and improve the workaround script to become more usable.



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

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

[jira] [Resolved] (SOLR-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-7774.
---
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-7774.patch
>
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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] [Commented] (SOLR-8378) Add upconfig and downconfig commands to the bin/solr script and managed-only schema to configsets

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-8378:
--

I don't think this should be committed w/o also including these new commands in 
{{bin\solr.cmd}} for our Windows users. I like Varun's idea of just having 
managed schema enabled in the existing configs, making managed_schema_configs 
== basic_configs ... but sounds like he's already handled that issue in another 
ticket.

I know the Windows stuff is a major pain, but this addition shouldn't be much 
more than copy-paste in a few key areas, but then there's the testing. I 
usually spin up an instance in EC2 to do my Windows testing, so I can help test.



> 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
>
>
> 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-6922) Improve svn to git workaround script

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6922:
-

Oops, I guess I'm behind with the mailing list, just found the discussion and 
will include the link here for anyone else that misses it: 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201512.mbox/%3ccal8pwkbfvt83zbczm0y-x-mdeth6hyc_xyejrev9fzzk5yx...@mail.gmail.com%3e



> Improve svn to git workaround script
> 
>
> Key: LUCENE-6922
> URL: https://issues.apache.org/jira/browse/LUCENE-6922
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: svnBranchToGit.py
>
>
> As the git-svn mirror for Lucene/Solr will be turned off near the end of 
> 2015, try and improve the workaround script to become more usable.



--
This message was sent by Atlassian 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-7885) Add support for loading HTTP resources

[Aaron LaBella (JIRA)]

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

Aaron LaBella commented on SOLR-7885:
-

Sure.  Our DIH configuration files are stored, protected and maintained on a 
*separate* HTTP server with an admin/editing interface.  This allows us to give 
users an actual front-end editor, make changes to the DIH, and have those 
changes reloaded in SOLR automatically -- *without* having to explicitly reload 
SOLR in any form (either at runtime or with a server restart).

I guess I didn't try reload-config because a.) I'm not really seeing any great 
documentation on this feature and b.) I'm confused if it actually *persists* an 
uploaded and/or reloaded configuration back to the local file system.  If not, 
then this is a problem because it means that if the SOLR server restarts it'll 
re-load the old configurations.

I suppose you could argue this as a "back door" to SOLR, but, it's also 
something that is disabled by default and users would have to consciously 
enable using -Dsolr.allow.http.resourceloading, assuming they are willing to 
accept the risk.

> Add support for loading HTTP resources
> --
>
> Key: SOLR-7885
> URL: https://issues.apache.org/jira/browse/SOLR-7885
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler, SolrJ
>Affects Versions: 5.3
>Reporter: Aaron LaBella
> Attachments: SOLR-7885-1.patch, SOLR-7885-2.patch
>
>
> I have a need to be able to load data import handler configuration files from 
> an HTTP server instead of the local file system.  So, I modified 
> {code}org.apache.solr.core.SolrResourceLoader{code} and some of the 
> respective dataimport files in {code}org.apache.solr.handler.dataimport{code} 
> to be able to support doing this.  
> {code}solrconfig.xml{code} now has the option to define a parameter: 
> *configRemote*, and if defined (and it's an HTTP(s) URL), it'll attempt to 
> load the resource.  If successfully, it'll also persist the resource to the 
> local file system so that it is available on a solr server restart per chance 
> that the remote resource is currently unavailable.
> Lastly, to be consistent with the pattern that already exists in 
> SolrResourceLoader, this feature is *disabled* by default, and requires the 
> setting of an additional JVM property: 
> {code}-Dsolr.allow.http.resourceloading=true{code}.
> Please review and let me know if there is anything else that needs to be done 
> in order for this patch to make the next release.  As far as I can tell, it's 
> fully tested and ready to go.
> Thanks.



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

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

[jira] [Commented] (SOLR-8360) ExternalFileField.getValueSource uses req.datadir but this.schema

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-8360:
-

The data directory should always be the same, so I think your second patch is 
the way to go.

> ExternalFileField.getValueSource uses req.datadir but this.schema
> -
>
> Key: SOLR-8360
> URL: https://issues.apache.org/jira/browse/SOLR-8360
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8360-option1.patch, SOLR-8360-option2.patch
>
>
> {{ExternalFileField.getValueSource(SchemaField field, QParser parser)}} has 
> available:
> * datadir
> ** parser.getReq().getCore().getDataDir()
> ** this.schema.getResourceLoader().getDataDir()
> * schema
> ** parser.getReq().getSchema()
> ** this.schema
> {{ExternalFileField.getValueSource}} uses 
> {{parser.getReq().getCore().getDataDir()}} explicitly but implicitly 
> {{this.schema}} - should it use {{parser.getReq().getSchema()}} instead 
> (Option 1 patch)? Or if in practice actually req.datadir and this.datadir are 
> always the same could we stop using the parser argument (Option 2 patch (1 
> line))?



--
This message was sent by Atlassian 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=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] [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=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] (SOLR-8360) ExternalFileField.getValueSource uses req.datadir but this.schema

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8360:
---

Hi [~romseygeek] - saw your name in the history of this class/method and 
wondered if you would have any thoughts on this JIRA here? As I see it, if 
req.datadir and this.datadir are always the same (and req.schema and 
this.schema are always the same) then the 'Option 2' patch would simplify the 
code. On the other hand, if req.schema and this.schema can sometimes be 
different then the 'Option 1' patch might be fixing an edge case bug? Or 
'Option 3' could be to only add a clarifying comment that and why this.schema 
rather than req.schema is used combined with req.datadir.

> ExternalFileField.getValueSource uses req.datadir but this.schema
> -
>
> Key: SOLR-8360
> URL: https://issues.apache.org/jira/browse/SOLR-8360
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
> Attachments: SOLR-8360-option1.patch, SOLR-8360-option2.patch
>
>
> {{ExternalFileField.getValueSource(SchemaField field, QParser parser)}} has 
> available:
> * datadir
> ** parser.getReq().getCore().getDataDir()
> ** this.schema.getResourceLoader().getDataDir()
> * schema
> ** parser.getReq().getSchema()
> ** this.schema
> {{ExternalFileField.getValueSource}} uses 
> {{parser.getReq().getCore().getDataDir()}} explicitly but implicitly 
> {{this.schema}} - should it use {{parser.getReq().getSchema()}} instead 
> (Option 1 patch)? Or if in practice actually req.datadir and this.datadir are 
> always the same could we stop using the parser argument (Option 2 patch (1 
> line))?



--
This message was sent by Atlassian 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 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] [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

[jira] [Resolved] (SOLR-7304) Spellcheck.collate Sometimes Invalidates Range Queries

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-7304.
--
   Resolution: Fixed
 Assignee: James Dyer
Fix Version/s: 5.5

Thanks Hakim for reporting this.

> Spellcheck.collate Sometimes Invalidates Range Queries
> --
>
> Key: SOLR-7304
> URL: https://issues.apache.org/jira/browse/SOLR-7304
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
> Environment: Jetty
> Debian
>Reporter: Hakim
>Assignee: James Dyer
>Priority: Minor
>  Labels: range, spellchecker
> Fix For: 5.5, 4.9
>
> Attachments: SOLR-7304.patch, SOLR-7304.patch
>
>
> I have an error with SpellCheckComponent since I have added this 
> SearchComponent to /select RequestHandler (see solrconfig.xml).
>   
> 
>  
>explicit
>10
>titre
> 
>on
>default
>true
>3
>3
>5
>true
>true
>10
>1
>false
>false
>  
> The error seems to be related to range queries, with the [.. to ..] written 
> in lowercase. The query performed by the SpellCheck component using 'to' in 
> lower case throws the RANGE_GOOP error.
> 101615 [qtp2145626092-38] WARN  org.apache.solr.spelling.SpellCheckCollator  
> - Exception trying to re-query to check if a spell check possibility would 
> return any hits.
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
> Cannot parse 'offredemande:offre AND categorieparente:"audi" AND 
> prix:[216 to 2250008} AND anneemodele:[2003 to 2008} AND etat:"nauf"': 
> Encountered "  "2250008 "" at line 1, column 68.
> Was expecting one of:
> "]" ...
> "}" ...
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:205)
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:230)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:197)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1962)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
> at 
> org.eclipse.jetty.server.handler.IPAccessHandler.handle(IPAccessHandler.java:220)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
> at org.eclipse.jetty.server.Server.handle(Server.java:461)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.solr.search.SyntaxError: Cannot parse 
> 

[jira] [Commented] (SOLR-7304) Spellcheck.collate Sometimes Invalidates Range Queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1718416 from jd...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718416 ]

SOLR-7304: SpellingQueryConverter to ignore "TO" as a possible range query 
operator

> Spellcheck.collate Sometimes Invalidates Range Queries
> --
>
> Key: SOLR-7304
> URL: https://issues.apache.org/jira/browse/SOLR-7304
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
> Environment: Jetty
> Debian
>Reporter: Hakim
>Priority: Minor
>  Labels: range, spellchecker
> Fix For: 4.9, 5.5
>
> Attachments: SOLR-7304.patch, SOLR-7304.patch
>
>
> I have an error with SpellCheckComponent since I have added this 
> SearchComponent to /select RequestHandler (see solrconfig.xml).
>   
> 
>  
>explicit
>10
>titre
> 
>on
>default
>true
>3
>3
>5
>true
>true
>10
>1
>false
>false
>  
> The error seems to be related to range queries, with the [.. to ..] written 
> in lowercase. The query performed by the SpellCheck component using 'to' in 
> lower case throws the RANGE_GOOP error.
> 101615 [qtp2145626092-38] WARN  org.apache.solr.spelling.SpellCheckCollator  
> - Exception trying to re-query to check if a spell check possibility would 
> return any hits.
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
> Cannot parse 'offredemande:offre AND categorieparente:"audi" AND 
> prix:[216 to 2250008} AND anneemodele:[2003 to 2008} AND etat:"nauf"': 
> Encountered "  "2250008 "" at line 1, column 68.
> Was expecting one of:
> "]" ...
> "}" ...
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:205)
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:230)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:197)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1962)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
> at 
> org.eclipse.jetty.server.handler.IPAccessHandler.handle(IPAccessHandler.java:220)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
> at org.eclipse.jetty.server.Server.handle(Server.java:461)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
> at 
> 

[JENKINS-EA] Lucene-Solr-5.4-Linux (64bit/jdk-9-ea+95) - Build # 339 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([FA5598E447B5CB2C:3C3A30FFF12B]: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.testSkip(TestTikaEntityProcessor.java:118)
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 

[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=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] (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=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] [Created] (SOLR-8382) Allow configuration of the bind IP(host) in solr 5

[Xavier (JIRA)]

Xavier created SOLR-8382:


 Summary: 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-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=15045239#comment-15045239
 ] 

Ishan Chattopadhyaya commented on SOLR-8373:


It seems if ticket caching (credentials cache) isn't set up properly, ignoring 
cookies always (as in this patch) will have the client fetch the TGT from the 
KDC again. 

Since, fetching the ticket from the KDC (or even the ticket cache) and sending 
again and again isn't ideal, I am now looking to have a modified cookie spec 
implemented within the realms of HttpClient (which SolrJ depends on), which 
will restrict the cookies by host *and port*, since the standard cookie RFCs 
and the browsers are okay to share cookies for the same host across different 
applications running on different ports. This will allow multiple solr nodes on 
the same host to work properly without the clients going to the KDC (or even 
ticket cache) for the tickets.

I shall post a patch for this approach in a while.

> 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
>
>
> 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] [Closed] (SOLR-2555) Always incorrectly spelled with onlyMorePopular enabled

[James Dyer (JIRA)]

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

James Dyer closed SOLR-2555.

Resolution: Cannot Reproduce

Please re-open this with a failing unit test if this indeed is still a problem.

> Always incorrectly spelled with onlyMorePopular enabled
> ---
>
> Key: SOLR-2555
> URL: https://issues.apache.org/jira/browse/SOLR-2555
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.1
>Reporter: Markus Jelsma
> Attachments: SOLR-2555.patch
>
>
> The spellcheck component will always mark the term(s) as incorrectly spelled 
> when onlyMorePopular=true, regardless of the term being actually spelled 
> correctly.
> The onlyMorePopular setting can produce collations while the term(s) are 
> correctly spelled. This is fine behaviour. The problem is that is also marks 
> the term(s) as incorrectly spelled when they're actually in the spellcheck 
> index.
> See also this thread:
> http://lucene.472066.n3.nabble.com/correctlySpelled-and-onlyMorePopular-in-3-1-td2975773.html#a2984201



--
This message was sent by Atlassian 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-2555) Always incorrectly spelled with onlyMorePopular enabled

[James Dyer (JIRA)]

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

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

The attached patch contains what would be a failing unit test.  However, this 
test passes.  It searches for "thus", which is in the index.  The 
"onlyMorePopular" flag causes it to correct it to "this", which has tf=2 vs 
tf=1 for "thus".  The correctlySpelled flag return "true", as expected.

This issue likely was fixed with SOLR-2585.

> Always incorrectly spelled with onlyMorePopular enabled
> ---
>
> Key: SOLR-2555
> URL: https://issues.apache.org/jira/browse/SOLR-2555
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 3.1
>Reporter: Markus Jelsma
> Attachments: SOLR-2555.patch
>
>
> The spellcheck component will always mark the term(s) as incorrectly spelled 
> when onlyMorePopular=true, regardless of the term being actually spelled 
> correctly.
> The onlyMorePopular setting can produce collations while the term(s) are 
> correctly spelled. This is fine behaviour. The problem is that is also marks 
> the term(s) as incorrectly spelled when they're actually in the spellcheck 
> index.
> See also this thread:
> http://lucene.472066.n3.nabble.com/correctlySpelled-and-onlyMorePopular-in-3-1-td2975773.html#a2984201



--
This message was sent by Atlassian 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-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:comment-tabpanel=15045188#comment-15045188
 ] 

Erick Erickson commented on SOLR-8378:
--

[~thelabdude] Rats! I thought about the windows command file on Saturday but 
then forgot it completely. Siiigggh. I'll take you up on the testing bits. 
Thanks for reminding me.

[~varunthacker] 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.

I did struggle a bit with whether or not to leave all the fieldTypes defined 
but in the end decided to leave them in. I became convinced that in managed 
schema mode they're actually more important than in the manually-edited 
examples we've been shipping for so long.

bq:  If there not being another 5.x release a motive here.

I'll defer to the release manager here and he's spoken. It's not going in 5.4.

[~upayavira] OK, not going in 5.4 ;)



> 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
>
>
> 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-6922) Improve svn to git workaround script

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6922:
--

bq. How will this affect users that rely on the github mirror to access the 
Lucene/Solr repository?

I would expect that no more updates will be available after the apache mirror 
is turned off.

I just realized that the script here could be simpler when the git working tree 
and the svn working copy are in the same directory. Does anyone have experience 
with that?

> Improve svn to git workaround script
> 
>
> Key: LUCENE-6922
> URL: https://issues.apache.org/jira/browse/LUCENE-6922
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: -tools
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: svnBranchToGit.py
>
>
> As the git-svn mirror for Lucene/Solr will be turned off near the end of 
> 2015, try and improve the workaround script to become more usable.



--
This message was sent by Atlassian 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-7304) Spellcheck.collate Sometimes Invalidates Range Queries

[ASF subversion and git services (JIRA)]

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

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

Commit 1718415 from jd...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1718415 ]

SOLR-7304: SpellingQueryConverter to ignore "TO" as a possible range query 
operator

> Spellcheck.collate Sometimes Invalidates Range Queries
> --
>
> Key: SOLR-7304
> URL: https://issues.apache.org/jira/browse/SOLR-7304
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
> Environment: Jetty
> Debian
>Reporter: Hakim
>Priority: Minor
>  Labels: range, spellchecker
> Fix For: 4.9
>
> Attachments: SOLR-7304.patch, SOLR-7304.patch
>
>
> I have an error with SpellCheckComponent since I have added this 
> SearchComponent to /select RequestHandler (see solrconfig.xml).
>   
> 
>  
>explicit
>10
>titre
> 
>on
>default
>true
>3
>3
>5
>true
>true
>10
>1
>false
>false
>  
> The error seems to be related to range queries, with the [.. to ..] written 
> in lowercase. The query performed by the SpellCheck component using 'to' in 
> lower case throws the RANGE_GOOP error.
> 101615 [qtp2145626092-38] WARN  org.apache.solr.spelling.SpellCheckCollator  
> - Exception trying to re-query to check if a spell check possibility would 
> return any hits.
> org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
> Cannot parse 'offredemande:offre AND categorieparente:"audi" AND 
> prix:[216 to 2250008} AND anneemodele:[2003 to 2008} AND etat:"nauf"': 
> Encountered "  "2250008 "" at line 1, column 68.
> Was expecting one of:
> "]" ...
> "}" ...
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:205)
> at 
> org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:141)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:230)
> at 
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:197)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1962)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1645)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:564)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:578)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:498)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
> at 
> org.eclipse.jetty.server.handler.IPAccessHandler.handle(IPAccessHandler.java:220)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:98)
> at org.eclipse.jetty.server.Server.handle(Server.java:461)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:284)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
> at 

[jira] [Closed] (SOLR-4278) Spellchecker correctlySpelled flag is improperly false in many cases

[James Dyer (JIRA)]

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

James Dyer closed SOLR-4278.

Resolution: Not A Problem

The 4.0 /spell handler had "maxResultsForSuggest" set to 5, meaning that we 
need 5 hits to set "correctlySpelled" to true.  Had "maxResultsForSuggest" not 
been specified, the expected behavior would have occurred.

The behavior of the "correctlySpelled" flag is given here: 
https://wiki.apache.org/solr/SpellCheckComponent#spellcheck.maxResultsForSuggest
 .


> Spellchecker correctlySpelled flag is improperly false in many cases
> 
>
> Key: SOLR-4278
> URL: https://issues.apache.org/jira/browse/SOLR-4278
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Reporter: Jack Krupansky
>
> I issued a request to the /spell request handler with no misspellings, but 
> the response still have a value of "false" for the "correctlySpelled" flag.
> Using the Solr 4.0 example, I added some mini documents:
> {code}
> curl http://localhost:8983/solr/update?commit=true -H 
> 'Content-type:application/csv' -d '
> id,name
> spel-1,aardvark abacus ball bill cat cello
> spel-2,abate accord band bell cattle check
> spel-3,adorn border clean clock'
> {code}
> Then I issued this request to the /spell handler:
> {code}
> curl "http://localhost:8983/solr/spell/?q=abate=true;
> {code}
> The response indicates that no corrections were needed, but the 
> "correctlySpelled" flag is "false" when it should be "true".
> {code}
> 
>   
> false
>   
> 
> {code}



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

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

[jira] [Updated] (SOLR-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-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] [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] [Created] (SOLR-8381) Cleanup the data_driven configset

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-8381:
---

 Summary: Cleanup the data_driven configset
 Key: SOLR-8381
 URL: https://issues.apache.org/jira/browse/SOLR-8381
 Project: Solr
  Issue Type: Improvement
Reporter: Varun Thacker
Assignee: Varun Thacker
Priority: Minor


I was looking at the data_driven config set and we could do some simple 
cleanups there.

- Remove commented out copyFields as they aren't adding any value here.
- Fix indentation in the managed-schema file
- in the solrconfig.xml file the spellchecker refers to non existent fields. 
Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark that 
as a duplicate of this Jira



--
This message was sent by Atlassian 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-8131) Make ManagedIndexSchemaFactory as the default in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1718264 from [~varunthacker] in branch 'dev/trunk'
[ https://svn.apache.org/r1718264 ]

SOLR-8131: Add CHANGES entry under solr 5.4 as well mentioning change to 
ManagedIndexSchemaFactory in all example config files

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch, SOLR-8131.patch, SOLR-8131_5x.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



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

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

[jira] [Assigned] (SOLR-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-7774:
-

Assignee: Christine Poerschke

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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] [Closed] (SOLR-8078) Data driven solrconfig spellchecker refers to a non-existent field

[Varun Thacker (JIRA)]

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

Varun Thacker closed SOLR-8078.
---
   Resolution: Fixed
 Assignee: Varun Thacker
Fix Version/s: 5.5
   Trunk

> Data driven solrconfig spellchecker refers to a non-existent field
> --
>
> Key: SOLR-8078
> URL: https://issues.apache.org/jira/browse/SOLR-8078
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Varun Thacker
> Fix For: Trunk, 5.5
>
>
> In the data driven solrconfig.xml file, the "default" spellchecker refers to 
> a field called "text" which doesn't exist in the schema.
> Even the "wordbreak" spellchecker refers to a field called "name" which does 
> not exist. 
> So when you run this query 
> {{http://localhost:8983/solr/gettingstarted/spell?q=*}} Solr will throw an 
> error. 
> I guess the field name should be {{\_text\_}} ?



--
This message was sent by Atlassian 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-8381) Cleanup the data_driven configset

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8381:

Attachment: SOLR-8381.patch

Patch which does all of the three points mentioned on the ticket. I'll commit 
this soon

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



--
This message was sent by Atlassian 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 # 1039 - Still Failing

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.TestAuthenticationFramework.testCollectionCreateSearchDelete

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([6B4A28DD8930C974:C8B086780ED823D1]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:463)
at sun.nio.ch.Net.bind(Net.java:455)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:321)
at 
org.eclipse.jetty.server.AbstractNetworkConnector.doStart(AbstractNetworkConnector.java:80)
at 
org.eclipse.jetty.server.ServerConnector.doStart(ServerConnector.java:236)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.server.Server.doStart(Server.java:366)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:407)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:357)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testCollectionCreateSearchDelete(TestMiniSolrCloudCluster.java:190)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 

Early-access build b95 of JDK 9 is available for download

[Rory O'Donnell]

Hi Uwe & Dawid,

Early-access builds of JDK 9 with Project Verona [0] in b95 are 
available for download here .


The goal of this Project is to implement the new JDK version string as 
described in JEP-223  [1].
The new version-string scheme is designed to easily distinguish major, 
minor, and security-update releases.
For more information please see Iris Clark's email [2] , also see 
Dalibor Topic's blog on this topic [3].


Please send usage questions, feedback and experience reports to the 
verona-dev  
mailing list.


Note: If you haven’t already subscribed to that mailing list then please 
do so first, otherwise

your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223
[2] 
http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html

[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Closed] (SOLR-8131) Make ManagedIndexSchemaFactory as the default in Solr

[Varun Thacker (JIRA)]

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

Varun Thacker closed SOLR-8131.
---
   Resolution: Fixed
 Assignee: Varun Thacker
Fix Version/s: (was: 5.4)
   5.5

Marking this Jira as Resolved. Thanks everyone!

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
>  Labels: difficulty-easy, impact-high
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch, SOLR-8131.patch, SOLR-8131_5x.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



--
This message was sent by Atlassian 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-8131) Make ManagedIndexSchemaFactory as the default in Solr

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-8131:

Attachment: SOLR-8131_5x.patch

Patch against the 5x branch. It changes no default behaviour and only modifies 
the example config files to use ManagedSchema 

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch, SOLR-8131.patch, SOLR-8131_5x.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



--
This message was sent by Atlassian 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-8131) Make ManagedIndexSchemaFactory as the default in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1718265 from [~varunthacker] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718265 ]

SOLR-8131: Make ManagedIndexSchemaFactory the default schemaFactory in all 
example config files

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-easy, impact-high
> Fix For: 5.4, Trunk
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch, SOLR-8131.patch, SOLR-8131_5x.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



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

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8378:
-

Having a schema sample that does not include the schemaless stuff is really 
important. Schemaless is fraught with danger, and whilst it is clever, and 
useful in a limited range of scenarios, we should not have it being the *only* 
managed schema sample config.

That said, this ticket is about upconfig/downconfig. I support the addition of 
these to bin/solr. It is a real pain to locate the zk-cli script and explain 
its need/etc. 

Neither are bugs in 5.4.0 so should not be a part of that release. 5.5.0 could 
be released in 2 weeks time if we wanted to.

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

Re: Early-access build b95 of JDK 9 is available for download

[Rory O'Donnell]

Hi Uwe,

Thanks for the update, it would be great to provide any feedback to the 
verona-dev list.
I have sent email to the Ant mailing list, not sure if there will be any 
response.


Rgds,Rory

On 07/12/2015 09:37, Uwe Schindler wrote:


Hi Rory,

I will check the new Verone version numbers later and deploy it. 
Lucene’s own version parsing of java.specification.version should be 
fine, but the ANT build script may have problems (I am quite sure it 
has, because Ant cannot parse version numbers and you have to do “bad 
tricks”).


Uwe

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de 

eMail: u...@thetaphi.de

*From:*Rory O'Donnell [mailto:rory.odonn...@oracle.com]
*Sent:* Monday, December 07, 2015 10:19 AM
*To:* u...@thetaphi.de; dawid.we...@cs.put.poznan.pl
*Cc:* rory.odonn...@oracle.com; Dalibor Topic 
; Balchandra Vaidya 
; Abdul Kolarkunnu 
; dev@lucene.apache.org

*Subject:* Early-access build b95 of JDK 9 is available for download


Hi Uwe & Dawid,

Early-access builds of JDK 9 with Project Verona [0] in b95 are 
available for download here .


The goal of this Project is to implement the new JDK version string as 
described in JEP-223  [1].
The new version-string scheme is designed to easily distinguish major, 
minor, and security-update releases.
For more information please see Iris Clark's email [2] , also see 
Dalibor Topic's blog on this topic [3].


Please send usage questions, feedback and experience reports to the 
verona-dev  
mailing list.


Note: If you haven’t already subscribed to that mailing list then 
please do so first, otherwise

your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223
[2] 
http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html

[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

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

[Policeman Jenkins Server]

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

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

Error Message:
Shard a1x2_shard1_replica1 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([ACEFE00B90D5FA42:24BBDFD13E2997BA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:122)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:66)
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 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

RE: Early-access build b95 of JDK 9 is available for download

[Uwe Schindler]

Hi Rory,

 

I will check the new Verone version numbers later and deploy it. Lucene’s own 
version parsing of java.specification.version should be fine, but the ANT build 
script may have problems (I am quite sure it has, because Ant cannot parse 
version numbers and you have to do “bad tricks”).

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:19 AM
To: u...@thetaphi.de; dawid.we...@cs.put.poznan.pl
Cc: rory.odonn...@oracle.com; Dalibor Topic ; 
Balchandra Vaidya ; Abdul Kolarkunnu 
; dev@lucene.apache.org
Subject: Early-access build b95 of JDK 9 is available for download

 


Hi Uwe & Dawid, 

Early-access builds of JDK 9 with Project Verona [0] in b95 are available for 
download here  . 

The goal of this Project is to implement the new JDK version string as 
described in JEP-223   [1].
The new version-string scheme is designed to easily distinguish major, minor, 
and security-update releases.
For more information please see Iris Clark's email [2] , also see Dalibor 
Topic's blog on this topic [3].

Please send usage questions, feedback and experience reports to the verona-dev 
  mailing list. 

Note: If you haven’t already subscribed to that mailing list then please do so 
first, otherwise 
your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223 
[2] http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html
[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version



-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

RE: Early-access build b95 of JDK 9 is available for download

[Uwe Schindler]

Hi,

 

This statement was more referring to *our* ant build.xml scripts. Ant itsself 
works fine, but we need to populate some system properties with some stuff 
parsed form “java.specification.version”. I fixed that already.

 

But it would still be good to let the Ant people figure out if everything is OK 
with version numbers.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:46 AM
To: dev@lucene.apache.org; dawid.we...@cs.put.poznan.pl
Cc: rory.odonn...@oracle.com; 'Dalibor Topic' ; 
'Balchandra Vaidya' ; 'Abdul Kolarkunnu' 

Subject: Re: Early-access build b95 of JDK 9 is available for download

 

Hi Uwe,

Thanks for the update, it would be great to provide any feedback to the 
verona-dev list.
I have sent email to the Ant mailing list, not sure if there will be any 
response.

Rgds,Rory

On 07/12/2015 09:37, Uwe Schindler wrote:

Hi Rory,

 

I will check the new Verone version numbers later and deploy it. Lucene’s own 
version parsing of java.specification.version should be fine, but the ANT build 
script may have problems (I am quite sure it has, because Ant cannot parse 
version numbers and you have to do “bad tricks”).

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: u...@thetaphi.de  

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:19 AM
To: u...@thetaphi.de  ; dawid.we...@cs.put.poznan.pl 
 
Cc: rory.odonn...@oracle.com  ; Dalibor Topic  
 ; Balchandra Vaidya 
  ; Abdul 
Kolarkunnu   ; 
dev@lucene.apache.org  
Subject: Early-access build b95 of JDK 9 is available for download

 


Hi Uwe & Dawid, 

Early-access builds of JDK 9 with Project Verona [0] in b95 are available for 
download here  . 

The goal of this Project is to implement the new JDK version string as 
described in JEP-223   [1].
The new version-string scheme is designed to easily distinguish major, minor, 
and security-update releases.
For more information please see Iris Clark's email [2] , also see Dalibor 
Topic's blog on this topic [3].

Please send usage questions, feedback and experience reports to the verona-dev 
  mailing list. 

Note: If you haven’t already subscribed to that mailing list then please do so 
first, otherwise 
your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223 
[2] http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html
[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version




-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 





-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

RE: Early-access build b95 of JDK 9 is available for download

[Uwe Schindler]

Hi,

 

This statement was more referring to *our* ant build.xml scripts. Ant itsself 
works fine, but we need to populate some system properties with some stuff 
parsed form “java.specification.version”. I fixed that already.

 

But it would still be good to let the Ant people figure out if everything is OK 
with version numbers.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:46 AM
To: dev@lucene.apache.org; dawid.we...@cs.put.poznan.pl
Cc: rory.odonn...@oracle.com; 'Dalibor Topic' ; 
'Balchandra Vaidya' ; 'Abdul Kolarkunnu' 

Subject: Re: Early-access build b95 of JDK 9 is available for download

 

Hi Uwe,

Thanks for the update, it would be great to provide any feedback to the 
verona-dev list.
I have sent email to the Ant mailing list, not sure if there will be any 
response.

Rgds,Rory

On 07/12/2015 09:37, Uwe Schindler wrote:

Hi Rory,

 

I will check the new Verone version numbers later and deploy it. Lucene’s own 
version parsing of java.specification.version should be fine, but the ANT build 
script may have problems (I am quite sure it has, because Ant cannot parse 
version numbers and you have to do “bad tricks”).

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

http://www.thetaphi.de

eMail: u...@thetaphi.de  

 

From: Rory O'Donnell [mailto:rory.odonn...@oracle.com] 
Sent: Monday, December 07, 2015 10:19 AM
To: u...@thetaphi.de  ; dawid.we...@cs.put.poznan.pl 
 
Cc: rory.odonn...@oracle.com  ; Dalibor Topic  
 ; Balchandra Vaidya 
  ; Abdul 
Kolarkunnu   ; 
dev@lucene.apache.org  
Subject: Early-access build b95 of JDK 9 is available for download

 


Hi Uwe & Dawid, 

Early-access builds of JDK 9 with Project Verona [0] in b95 are available for 
download here  . 

The goal of this Project is to implement the new JDK version string as 
described in JEP-223   [1].
The new version-string scheme is designed to easily distinguish major, minor, 
and security-update releases.
For more information please see Iris Clark's email [2] , also see Dalibor 
Topic's blog on this topic [3].

Please send usage questions, feedback and experience reports to the verona-dev 
  mailing list. 

Note: If you haven’t already subscribed to that mailing list then please do so 
first, otherwise 
your message will be discarded as spam.

Rgds,Rory

[0] http://openjdk.java.net/projects/verona/
[1] http://openjdk.java.net/jeps/223 
[2] http://mail.openjdk.java.net/pipermail/verona-dev/2015-November/000293.html
[3] https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version




-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 





-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.dataimport.TestTikaEntityProcessor

Error Message:
access denied ("java.io.FilePermission" 
"/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
 "write")

Stack Trace:
java.security.AccessControlException: access denied ("java.io.FilePermission" 
"/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
 "write")
at __randomizedtesting.SeedInfo.seed([2D7A571BBB4F89E2]:0)
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
at java.io.FileOutputStream.(FileOutputStream.java:200)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at 
org.apache.solr.schema.ManagedIndexSchema.persistManagedSchema(ManagedIndexSchema.java:130)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.upgradeToManagedSchema(ManagedIndexSchemaFactory.java:271)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:186)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:46)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
at org.apache.solr.util.TestHarness.(TestHarness.java:97)
at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:572)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:562)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:404)
at 
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.beforeClass(TestTikaEntityProcessor.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$6.evaluate(RandomizedRunner.java:811)
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)




Build Log:
[...truncated 14187 lines...]
   [junit4] Suite: org.apache.solr.handler.dataimport.TestTikaEntityProcessor
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-8381) Cleanup the data_driven configset

[ASF subversion and git services (JIRA)]

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

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

Commit 1718296 from [~varunthacker] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718296 ]

SOLR-8381: Cleanup the data_driven configset (merged trunk r1718294)

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



--
This message was sent by Atlassian 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-7774) BasicDistributedZkTest.test (commitWithin did not work on node) failures

[Christine Poerschke (JIRA)]

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

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

rebased patch of the pull request and resolved merge conflict

> BasicDistributedZkTest.test (commitWithin did not work on node) failures
> 
>
> Key: SOLR-7774
> URL: https://issues.apache.org/jira/browse/SOLR-7774
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-7774.patch
>
>
> Seeing this now and again in our jenkins instance and also on the dev list's 
> jenkins emails e.g. {{\[JENKINS\] Lucene-Solr-trunk-Linux 
> (32bit/jdk1.8.0_60-ea-b21) - Build # 13356 - Failure!}} - gibhub pull request 
> with proposed test changes 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] [Commented] (SOLR-8131) Make ManagedIndexSchemaFactory as the default in Solr

[ASF subversion and git services (JIRA)]

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

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

Commit 1718307 from [~varunthacker] in branch 'dev/trunk'
[ https://svn.apache.org/r1718307 ]

SOLR-8131: fix test solrconfig.xml files for the contrib modules

> Make ManagedIndexSchemaFactory as the default in Solr
> -
>
> Key: SOLR-8131
> URL: https://issues.apache.org/jira/browse/SOLR-8131
> Project: Solr
>  Issue Type: Wish
>  Components: Data-driven Schema, Schema and Analysis
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
>  Labels: difficulty-easy, impact-high
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8131.patch, SOLR-8131.patch, SOLR-8131.patch, 
> SOLR-8131.patch, SOLR-8131.patch, SOLR-8131_5x.patch
>
>
> The techproducts and other examples shipped with Solr all use the 
> ClassicIndexSchemaFactory which disables all Schema APIs which need to modify 
> schema. It'd be nice to be able to support both read/write schema APIs 
> without needing to enable data-driven or schema-less mode.
> I propose to change all 5.x examples to explicitly use 
> ManagedIndexSchemaFactory and to enable ManagedIndexSchemaFactory by default 
> in trunk (6.x).



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

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

[jira] [Closed] (SOLR-8381) Cleanup the data_driven configset

[Varun Thacker (JIRA)]

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

Varun Thacker closed SOLR-8381.
---
   Resolution: Fixed
Fix Version/s: 5.5
   Trunk

Committed to both branch5x and trunk. My mistake that I didn't have the correct 
CHANGES entry for the first time causing the additional commits . 

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: Trunk, 5.5
>
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



--
This message was sent by Atlassian 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-trunk-Solaris (64bit/jdk1.8.0) - Build # 240 - Failure!

[Varun Thacker]

This was caused by SOLR-8131. I'll fix this right now.

On Mon, Dec 7, 2015 at 4:06 PM, Policeman Jenkins Server <
jenk...@thetaphi.de> wrote:

> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/240/
> Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
>
> 1 tests failed.
> FAILED:
> junit.framework.TestSuite.org.apache.solr.handler.dataimport.TestTikaEntityProcessor
>
> Error Message:
> access denied ("java.io.FilePermission"
> "/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
> "write")
>
> Stack Trace:
> java.security.AccessControlException: access denied
> ("java.io.FilePermission"
> "/export/home/jenkins/workspace/Lucene-Solr-trunk-Solaris/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
> "write")
> at __randomizedtesting.SeedInfo.seed([2D7A571BBB4F89E2]:0)
> at
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at
> java.security.AccessController.checkPermission(AccessController.java:884)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.apache.solr.schema.ManagedIndexSchema.persistManagedSchema(ManagedIndexSchema.java:130)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.upgradeToManagedSchema(ManagedIndexSchemaFactory.java:271)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:186)
> at
> org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:46)
> at
> org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
> at org.apache.solr.util.TestHarness.(TestHarness.java:97)
> at
> org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:572)
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:562)
> at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:404)
> at
> org.apache.solr.handler.dataimport.TestTikaEntityProcessor.beforeClass(TestTikaEntityProcessor.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$6.evaluate(RandomizedRunner.java:811)
> 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)
>
>
>
>
> Build Log:
> [...truncated 14187 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.dataimport.TestTikaEntityProcessor

Error Message:
access denied ("java.io.FilePermission" 
"/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
 "write")

Stack Trace:
java.security.AccessControlException: access denied ("java.io.FilePermission" 
"/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/contrib/dataimporthandler-extras/src/test-files/dihextras/solr/collection1/conf/managed-schema"
 "write")
at __randomizedtesting.SeedInfo.seed([7AE1D761A4DDF82F]:0)
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at 
java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:979)
at java.io.FileOutputStream.(FileOutputStream.java:200)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at 
org.apache.solr.schema.ManagedIndexSchema.persistManagedSchema(ManagedIndexSchema.java:130)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.upgradeToManagedSchema(ManagedIndexSchemaFactory.java:271)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:186)
at 
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:46)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:75)
at org.apache.solr.util.TestHarness.(TestHarness.java:97)
at org.apache.solr.SolrTestCaseJ4.createCore(SolrTestCaseJ4.java:572)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:562)
at org.apache.solr.SolrTestCaseJ4.initCore(SolrTestCaseJ4.java:404)
at 
org.apache.solr.handler.dataimport.TestTikaEntityProcessor.beforeClass(TestTikaEntityProcessor.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$6.evaluate(RandomizedRunner.java:811)
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)




Build Log:
[...truncated 14267 lines...]
   [junit4] Suite: org.apache.solr.handler.dataimport.TestTikaEntityProcessor
   [junit4]   2> Creating dataDir: 

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

[Upayavira]

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.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Regards,
> >>> > Shalin Shekhar Mangar.
> 

[jira] [Commented] (SOLR-8381) Cleanup the data_driven configset

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8381:
-

I forgot to add the jira number to the commit made on trunk . Here is the 
commit for reference: 
https://svn.apache.org/viewvc?view=revision=1718294

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



--
This message was sent by Atlassian 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-8381) Cleanup the data_driven configset

[ASF subversion and git services (JIRA)]

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

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

Commit 1718299 from [~varunthacker] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718299 ]

SOLR-8381: add credits in the changes entry

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



--
This message was sent by Atlassian 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-8381) Cleanup the data_driven configset

[ASF subversion and git services (JIRA)]

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

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

Commit 1718298 from [~varunthacker] in branch 'dev/trunk'
[ https://svn.apache.org/r1718298 ]

SOLR-8381: add credits in the changes entry

> Cleanup the data_driven configset
> -
>
> Key: SOLR-8381
> URL: https://issues.apache.org/jira/browse/SOLR-8381
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
> Attachments: SOLR-8381.patch
>
>
> I was looking at the data_driven config set and we could do some simple 
> cleanups there.
> - Remove commented out copyFields as they aren't adding any value here.
> - Fix indentation in the managed-schema file
> - in the solrconfig.xml file the spellchecker refers to non existent fields. 
> Fix/Remove those as well. SOLR-8078 was created just for that so I'll mark 
> that as a duplicate of this Jira



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5452/
Java: 32bit/jdk1.8.0_66 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.lucene.store.TestSimpleFSLockFactory.testStressLocks

Error Message:
IndexWriter hit unexpected exceptions

Stack Trace:
java.lang.AssertionError: IndexWriter hit unexpected exceptions
at 
__randomizedtesting.SeedInfo.seed([42378077230ABFBE:1C06CE8A3FA677D8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.lucene.store.BaseLockFactoryTestCase.testStressLocks(BaseLockFactoryTestCase.java:175)
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(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 665 lines...]
   [junit4] Suite: org.apache.lucene.store.TestSimpleFSLockFactory
   [junit4]   1> Stress Test Index Writer: creation hit unexpected exception: 
java.io.FileNotFoundException: segments_d in 
dir=NIOFSDirectory@C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSLockFactory_42378077230ABFBE-001\tempDir-004
 lockFactory=org.apache.lucene.store.SimpleFSLockFactory@6e8af0
   [junit4]   1> java.io.FileNotFoundException: segments_d in 

[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=15044847#comment-15044847
 ] 

Joel Bernstein commented on SOLR-8266:
--

Jason,

The key part of the error message is: " function 'count' is unknown (not mapped 
to a valid TupleStream)"

The StreamFactory has have each function mapped. 

> 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.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] [Comment Edited] (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=15044847#comment-15044847
 ] 

Joel Bernstein edited comment on SOLR-8266 at 12/7/15 12:35 PM:


Jason,

The key part of the error message is: " function 'count' is unknown (not mapped 
to a valid TupleStream)"

The StreamFactory has to have each function mapped. 


was (Author: joel.bernstein):
Jason,

The key part of the error message is: " function 'count' is unknown (not mapped 
to a valid TupleStream)"

The StreamFactory has have each function mapped. 

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

[Renaud Delbru (JIRA)]

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

Renaud Delbru commented on SOLR-8263:
-

While the patch SOLR-8263-trunk-3 which added the dedup logic for the buffered 
updates seems straightforward, it introduced an issue which could lead to loss 
of documents.
The dedup logic was using the version of the last operation from the tlog files 
transferred from the master as a starting point for the dedup logic. However, 
these tlog files were not in synch with the index commit point, there were 
likely ahead of the index commit point (i.e., there were containing operations 
that occurred after the index commit point). Therefore, the starting point of 
the dedup logic was ahead of the index commit point, and therefore it was 
dropping all operations that occurred between the index commit point and the 
time the tlog files were transferred from the master.
In order to solve this, we had to modify the ReplicationHandler to filter out 
tlog files that were not associated to a given commit point. To find the tlog 
files associated to an index commit point, we fetch the max version of an index 
commit using VersionInfo.getMaxVersionFromIndex and use this version number to 
discard tlog files. Tlog file name encodes the version of their starting 
operation (this was originally used for seeking more efficiently across 
multiple tlog files), and we use this starting version to discard tlog that 
were created after the commit point (i.e., if starting version > max version).
The new patch committed by Erick includes this approach.


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



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic

Error Message:
Connection reset

Stack Trace:
java.net.SocketException: Connection reset
at 
__randomizedtesting.SeedInfo.seed([5A02CA3432470591:F1F8D721ED9B83BF]:0)
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at 
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at 
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:159)
at 
org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51)
at 
org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196)
at 
org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402)
at 
org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicatorTest.java:122)
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 
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 

[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=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] (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=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] [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

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

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-8373:


Assignee: Noble Paul

> 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
>
>
> 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-trunk-Linux (32bit/jdk-9-ea+95) - Build # 15135 - Failure!

[Uwe Schindler]

Strange error, not sure if this is related to Java 9 and the new version 
numbering.

-
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 1:07 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build #
> 15135 - Failure!
> Importance: Low
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15135/
> Java: 32bit/jdk-9-ea+95 -server -XX:+UseParallelGC -XX:-CompactStrings
> 
> 2 tests failed.
> FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic
> 
> Error Message:
> Connection reset
> 
> Stack Trace:
> java.net.SocketException: Connection reset
>   at
> __randomizedtesting.SeedInfo.seed([5A02CA3432470591:F1F8D721ED9B83B
> F]:0)
>   at java.net.SocketInputStream.read(SocketInputStream.java:209)
>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>   at
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBu
> fferImpl.java:139)
>   at
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBuffe
> rImpl.java:155)
>   at
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBuffe
> rImpl.java:284)
>   at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultH
> ttpResponseParser.java:140)
>   at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultH
> ttpResponseParser.java:57)
>   at
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars
> er.java:261)
>   at
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeade
> r(DefaultBHttpClientConnection.java:165)
>   at
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.
> java:167)
>   at
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRe
> questExecutor.java:272)
>   at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecut
> or.java:124)
>   at
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.jav
> a:271)
>   at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184
> )
>   at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>   at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110
> )
>   at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.
> java:184)
>   at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient
> .java:82)
>   at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient
> .java:107)
>   at
> org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBas
> e.java:159)
>   at
> org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplic
> ator.java:51)
>   at
> org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.ja
> va:196)
>   at
> org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.
> java:402)
>   at
> org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicato
> rTest.java:122)
>   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.invoke(Randomize
> dRunner.java:1764)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> mizedRunner.java:871)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
> mizedRunner.java:907)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
> omizedRunner.java:921)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> SetupTeardownChained.java:50)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> fterRule.java:46)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> readAndTestName.java:49)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> IgnoreAfterMaxFailures.java:65)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> .java:48)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> ementAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
> run(ThreadLeakControl.java:367)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
> (ThreadLeakControl.java:809)
>   at
> 

Re: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build # 15135 - Failure!

[Shalin Shekhar Mangar]

This might also be related to the Jetty 9.3 upgrade in
https://issues.apache.org/jira/browse/SOLR-7339

There is a connection reset issue (reproducible) in Solr as well but
this is the first time I am seeing this kind of a failure in Lucene
replicator.

On Mon, Dec 7, 2015 at 6:14 PM, Uwe Schindler  wrote:
> Strange error, not sure if this is related to Java 9 and the new version 
> numbering.
>
> -
> 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 1:07 PM
>> To: dev@lucene.apache.org
>> Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+95) - Build #
>> 15135 - Failure!
>> Importance: Low
>>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15135/
>> Java: 32bit/jdk-9-ea+95 -server -XX:+UseParallelGC -XX:-CompactStrings
>>
>> 2 tests failed.
>> FAILED:  org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic
>>
>> Error Message:
>> Connection reset
>>
>> Stack Trace:
>> java.net.SocketException: Connection reset
>>   at
>> __randomizedtesting.SeedInfo.seed([5A02CA3432470591:F1F8D721ED9B83B
>> F]:0)
>>   at java.net.SocketInputStream.read(SocketInputStream.java:209)
>>   at java.net.SocketInputStream.read(SocketInputStream.java:141)
>>   at
>> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBu
>> fferImpl.java:139)
>>   at
>> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBuffe
>> rImpl.java:155)
>>   at
>> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBuffe
>> rImpl.java:284)
>>   at
>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultH
>> ttpResponseParser.java:140)
>>   at
>> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultH
>> ttpResponseParser.java:57)
>>   at
>> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessagePars
>> er.java:261)
>>   at
>> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeade
>> r(DefaultBHttpClientConnection.java:165)
>>   at
>> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.
>> java:167)
>>   at
>> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRe
>> questExecutor.java:272)
>>   at
>> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecut
>> or.java:124)
>>   at
>> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.jav
>> a:271)
>>   at
>> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184
>> )
>>   at
>> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
>>   at
>> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110
>> )
>>   at
>> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.
>> java:184)
>>   at
>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient
>> .java:82)
>>   at
>> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient
>> .java:107)
>>   at
>> org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBas
>> e.java:159)
>>   at
>> org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplic
>> ator.java:51)
>>   at
>> org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.ja
>> va:196)
>>   at
>> org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.
>> java:402)
>>   at
>> org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicato
>> rTest.java:122)
>>   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.invoke(Randomize
>> dRunner.java:1764)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
>> mizedRunner.java:871)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
>> mizedRunner.java:907)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
>> omizedRunner.java:921)
>>   at
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
>> SetupTeardownChained.java:50)
>>   at
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>> fterRule.java:46)
>>   at
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
>> readAndTestName.java:49)
>>   at
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
>> IgnoreAfterMaxFailures.java:65)
>>   at
>> 

[jira] [Commented] (SOLR-7919) TestRandomRequestDistribution failures

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7919:
-

This happened again today: 
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2866/

> TestRandomRequestDistribution failures
> --
>
> Key: SOLR-7919
> URL: https://issues.apache.org/jira/browse/SOLR-7919
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 5.3, Trunk
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.4, Trunk
>
> Attachments: tests-failures.txt
>
>
> I have seen this failure while smoke testing 5.3 release and also on jenkins 
> once.
> {code}
> java.lang.AssertionError: Shard a1x2_shard1_replica2 received all 10 requests
> at 
> __randomizedtesting.SeedInfo.seed([3471BAE127CAEEFA:7C4DE321D3C1FF6C]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at 
> org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13606/



--
This message was sent by Atlassian 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 # 338 - Failure!

[Policeman Jenkins Server]

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

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([DB63511572AAE364:D6C720ECD47EA461]: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 

[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=15044882#comment-15044882
 ] 

Jason Gerlowski commented on SOLR-8266:
---

Yeah, I'd keyed in to that part of the error message too.  Looking at 
{{StreamingTest}}, it looks like the {{StreamFactory}} does have a "count" 
mapping specified already: {{.withFunctionName("count", 
RecordCountStream.class)}}.

So either that line doesn't do what I thought it did, or something else is up 
here.

But in any case this is a good excuse to dig a little deeper into the streaming 
code.  Will be taking another pass this afternoon.

> 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.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] (LUCENE-6924) Upgrade randomizedtesting to 2.3.2

[Dawid Weiss (JIRA)]

Dawid Weiss created LUCENE-6924:
---

 Summary: Upgrade randomizedtesting to 2.3.2
 Key: LUCENE-6924
 URL: https://issues.apache.org/jira/browse/LUCENE-6924
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: Trunk, 5.5






--
This message was sent by Atlassian 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-6924) Upgrade randomizedtesting to 2.3.2

[ASF subversion and git services (JIRA)]

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

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

Commit 1718345 from [~dawidweiss] in branch 'dev/trunk'
[ https://svn.apache.org/r1718345 ]

LUCENE-6924: Upgrade randomizedtesting to 2.3.2.

> Upgrade randomizedtesting to 2.3.2
> --
>
> Key: LUCENE-6924
> URL: https://issues.apache.org/jira/browse/LUCENE-6924
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: Trunk, 5.5
>
>




--
This message was sent by Atlassian 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]

This is a problem in PDFBOX:

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.pdfbox/pdfbox/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.invoke(Randomize
> dRunner.java:1764)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> mizedRunner.java:871)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
> mizedRunner.java:907)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
> omizedRunner.java:921)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.
> evaluate(SystemPropertiesRestoreRule.java:57)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> SetupTeardownChained.java:50)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> fterRule.java:46)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> readAndTestName.java:49)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> IgnoreAfterMaxFailures.java:65)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> .java:48)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> ementAdapter.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(ThreadL
> eakControl.java:460)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
> domizedRunner.java:880)
>   at
> 

[jira] [Commented] (LUCENE-6924) Upgrade randomizedtesting to 2.3.2

[ASF subversion and git services (JIRA)]

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

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

Commit 1718347 from [~dawidweiss] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1718347 ]

LUCENE-6924: Upgrade randomizedtesting to 2.3.2.

> Upgrade randomizedtesting to 2.3.2
> --
>
> Key: LUCENE-6924
> URL: https://issues.apache.org/jira/browse/LUCENE-6924
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: Trunk, 5.5
>
>




--
This message was sent by Atlassian 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

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8266:
---

While that mapping is setup in the test you've got to remember that in a 
parallel situation the expression is passed off to a different process ehoch 
doesn't use the factory created in the test. Instead it uses a factory created 
in StreamHandler. That one has some defaults set and also reads solrconfig.xml 
to get any new mappings. Check that factory to make sure count is mapped there. 
I've tried to keep the default up to date with all default stream classes but 
may have missed some. 

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