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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8419 lines...]
[javac] Compiling 786 source files to 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\classes\java
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\java\org\apache\solr\response\transform\RawValueTransformerFactory.java:140:
 error: cannot find symbol
[javac] str = ((IndexableField)val).stringValue();
[javac]^
[javac]   symbol:   method stringValue()
[javac]   location: interface IndexableField
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:526: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:474: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:61: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:39: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:229: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:512:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:464:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:377:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:506:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1927:
 Compile failed; see the compiler error output for details.

Total time: 17 minutes 9 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.8.0_40 
-XX:+UseCompressedOops -XX:+UseG1GC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.util.TestLongBitSet.testHugeCapacity

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([8BC48D2625075146:F184C7DDCCF77742]:0)
at org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:320)
at org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:52)
at 
org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:327)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)




Build Log:
[...truncated 1809 lines...]
   [junit4] Suite: org.apache.lucene.util.TestLongBitSet
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestLongBitSet 
-Dtests.method=testHugeCapacity -Dtests.seed=8BC48D2625075146 -Dtests.slow=true 
-Dtests.locale=es -Dtests.timezone=Europe/Vienna -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.74s J0 | TestLongBitSet.testHugeCapacity <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: Java heap space
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([8BC48D2625075146:F184C7DDCCF77742]:0)
   [junit4]>at 
org.apache.lucene.util.ArrayUtil.grow(ArrayUtil.java:320)
   [junit4]>at 
org.apache.lucene.util.LongBitSet.ensureCapacity(LongBitSet.java:52)
   [junit4]>at 
org.apache.lucene.util.TestLongBitSet.testHugeCapacity(TestLongBitSet.java:327)
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene50): {}, 
docValues:{}, sim=RandomSimilarityProvider(queryNorm=false,coord=yes): {}, 
locale=es, timezone=Europe/Vienna
   [junit4]   2> NOTE: Mac OS X 10.8.5 x86_64/Oracle Corporation 1.7.0_76 
(64-bit)/cpus=3,threads=1,free=252327504,total=277872640
   [junit4]   2> NOTE: All tests run in this JVM: [TestRollback, 
TestDisjunctionMaxQuery, TestRecyclingByteBlockAllocator, TestRegexpRandom2, 
TestIndexWr

[jira] [Commented] (SOLR-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[ASF subversion and git services (JIRA)]

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

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

Commit 1673655 from [~ryantxu] in branch 'dev/trunk'
[ https://svn.apache.org/r1673655 ]

Merged revision(s) 1673654 from lucene/dev/branches/branch_5x:
SOLR-7376: adding missing files


> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



--
This message was sent by Atlassian 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-Linux (64bit/jdk1.8.0_60-ea-b06) - Build # 12308 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12308/
Java: 64bit/jdk1.8.0_60-ea-b06 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 8424 lines...]
[javac] Compiling 784 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:474: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:61: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:39: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:229: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:512: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:464: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:377: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:506: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1927: 
Compile failed; see the compiler error output for details.

Total time: 17 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.8.0_60-ea-b06 
-XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
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] [Commented] (SOLR-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[ASF subversion and git services (JIRA)]

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

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

Commit 1673654 from [~ryantxu] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1673654 ]

SOLR-7376: adding missing fields

> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



--
This message was sent by Atlassian 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-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7376:
-

This commit is causing compilation errors. See 
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12139/

> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



--
This message was sent by Atlassian 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-MacOSX (64bit/jdk1.8.0) - Build # 2178 - Still Failing!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8411 lines...]
[javac] Compiling 784 source files to 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/classes/java
[javac] 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:526: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:474: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:61: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/extra-targets.xml:39: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:229: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/common-build.xml:512: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/common-build.xml:464: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/common-build.xml:377: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:506: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:1927: 
Compile failed; see the compiler error output for details.

Total time: 26 minutes 16 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.8.0 
-XX:-UseCompressedOops -XX:+UseG1GC
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] [Updated] (SOLR-3419) XSS vulnerability in the json.wrf parameter

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-3419:

Attachment: SOLR-3419-escape.patch

seems like this can not hurt

> XSS vulnerability in the json.wrf parameter
> ---
>
> Key: SOLR-3419
> URL: https://issues.apache.org/jira/browse/SOLR-3419
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers
>Affects Versions: 3.5
>Reporter: Prafulla Kiran
>Priority: Minor
> Attachments: SOLR-3419-escape.patch
>
>
> There's no filtering of the wrapper function name passed to the solr search 
> service
> If the name of the wrapper function passed to the solr query service is the 
> following string - 
> %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E
> solr passes the string back as-is which results in an XSS attack in browsers 
> like IE-7 which perform mime-sniffing. In any case, the callback function in 
> a jsonp response should always be sanitized - 
> http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call



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

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

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12139 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12139/
Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 8760 lines...]
[javac] Compiling 785 source files to 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/classes/java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

[...truncated 1 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:484: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:61: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:39: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build.xml:229: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/common-build.xml:511: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/common-build.xml:463: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/common-build.xml:376: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:523: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1946: 
Compile failed; see the compiler error output for details.

Total time: 21 minutes 35 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.9.0-ea-b54 
-XX:-UseCompressedOops -XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8899 lines...]
[javac] Compiling 785 source files to 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\classes\java
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.7
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\java\org\apache\solr\response\transform\TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\java\org\apache\solr\response\transform\TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\java\org\apache\solr\response\TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\java\org\apache\solr\response\TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

[...truncated 1 lines...]
BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:536: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:484: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\build.xml:61: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\extra-targets.xml:39: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build.xml:229: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\common-build.xml:511:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\common-build.xml:463:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\common-build.xml:376:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\common-build.xml:523:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\lucene\common-build.xml:1946:
 Compile failed; see the compiler error output for details.

Total time: 18 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_40 -client 
-XX:+UseSerialGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12307/
Java: 32bit/jdk1.8.0_60-ea-b06 -client -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 8577 lines...]
[javac] Compiling 784 source files to 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/transform/TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:474: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:61: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:39: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build.xml:229: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:512: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:464: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:377: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:506: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:1927: 
Compile failed; see the compiler error output for details.

Total time: 19 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 32bit/jdk1.8.0_60-ea-b06 -client 
-XX:+UseParallelGC
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 8449 lines...]
[javac] Compiling 784 source files to 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\classes\java
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\java\org\apache\solr\response\transform\TransformerFactory.java:51:
 error: cannot find symbol
[javac] defaultFactories.put( "json", new 
RawValueTransformerFactory("json") );
[javac]   ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\java\org\apache\solr\response\transform\TransformerFactory.java:52:
 error: cannot find symbol
[javac] defaultFactories.put( "xml", new 
RawValueTransformerFactory("xml") );
[javac]  ^
[javac]   symbol:   class RawValueTransformerFactory
[javac]   location: class TransformerFactory
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\java\org\apache\solr\response\TextResponseWriter.java:206:
 error: cannot find symbol
[javac] } else if (val instanceof WriteableValue) {
[javac]   ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\java\org\apache\solr\response\TextResponseWriter.java:207:
 error: cannot find symbol
[javac]   ((WriteableValue)val).write(name, this);
[javac] ^
[javac]   symbol:   class WriteableValue
[javac]   location: class TextResponseWriter
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 4 errors

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:526: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:474: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:61: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:39: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:229: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:512:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:464:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\common-build.xml:377:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:506:
 The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1927:
 Compile failed; see the compiler error output for details.

Total time: 16 minutes 29 seconds
Build step 'Invoke Ant' marked build as failure
[description-setter] Description set: Java: 64bit/jdk1.8.0_40 
-XX:-UseCompressedOops -XX:+UseG1GC
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] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: LUCENE-6196-additions.patch

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, 
> ShapeImpl.java, geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



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

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

[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: (was: LUCENE-6196-additions.patch)

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, 
> ShapeImpl.java, geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-4685) JSON response write modification to support RAW JSON

[Ryan McKinley (JIRA)]

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

Ryan McKinley resolved SOLR-4685.
-
Resolution: Duplicate

The behavior is now supported by SOLR-7376

> JSON response write modification to support RAW JSON
> 
>
> Key: SOLR-4685
> URL: https://issues.apache.org/jira/browse/SOLR-4685
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Priority: Minor
> Attachments: SOLR-4685.1.patch, SOLR-4685.SOLR_4_5.patch
>
>
> If the field ends with "_json" allow the field to return raw JSON.
> For example the field,
> office_json -- string
> I already put into the field raw JSON already escaped. I want it to come with 
> no double quotes and not escaped.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=6349, 
name=NioSocketAcceptor-1, state=RUNNABLE, group=TGRP-SaslZkACLProviderTest] 
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at 
sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at 
sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79) at 
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98) at 
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102) at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.select(NioSocketAcceptor.java:234)
 at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:417)
 at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64) 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=6344, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:503) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)3) Thread[id=6347, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=6346, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=6348, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=6345, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor

[jira] [Commented] (SOLR-7390) Throw an exception when requesting an unknown document transformer

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-7390:
-

we don't throw an exception for unknown field in the fl list 
(&fl=id,asgasgasgdasga works fine) so we should likely have a similar behavior.

thoughts?


> Throw an exception when requesting an unknown document transformer
> --
>
> Key: SOLR-7390
> URL: https://issues.apache.org/jira/browse/SOLR-7390
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7390-exception-for-unknown-transformer.patch
>
>
> Currently, a request for an unknown doc transformer silently does nothing.  
> We could have this make a noisy exception.
> is there any reason we would want a silent behavior with:
> &fl=id,name,[asdgasdgasgdasg]



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

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

[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: (was: LUCENE-6196-additions.patch)

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, 
> ShapeImpl.java, geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



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

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

[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: LUCENE-6196-additions.patch

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, 
> ShapeImpl.java, geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



--
This message was sent by Atlassian 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-7390) Throw an exception when requesting an unknown document transformer

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-7390:

Attachment: SOLR-7390-exception-for-unknown-transformer.patch

simple patch

> Throw an exception when requesting an unknown document transformer
> --
>
> Key: SOLR-7390
> URL: https://issues.apache.org/jira/browse/SOLR-7390
> Project: Solr
>  Issue Type: Bug
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7390-exception-for-unknown-transformer.patch
>
>
> Currently, a request for an unknown doc transformer silently does nothing.  
> We could have this make a noisy exception.
> is there any reason we would want a silent behavior with:
> &fl=id,name,[asdgasdgasgdasg]



--
This message was sent by Atlassian 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-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[ASF subversion and git services (JIRA)]

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

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

Commit 1673649 from [~ryantxu] in branch 'dev/trunk'
[ https://svn.apache.org/r1673649 ]

Merged revision(s) 1673647 from lucene/dev/branches/branch_5x:
SOLR-7376: Return raw XML or JSON


> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



--
This message was sent by Atlassian 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-7388) warning log about deprecated class things

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7388:


In 5.0, the classes are still there, but they are deprecated.  You can use them 
if you must, but the warning is displayed, because anything that is deprecated 
will be removed in the next major release.

In trunk, which is version 6.0.0-SNAPSHOT, these classes have been entirely 
removed, as I just described.  The trunk configs are

I think we can remove /get, /update, and /admin/ from all the configs, plus the 
ThaiWordFilterFactory from all the schemas, but in at least some of the 
examples, /replication has comments showing how to set up master/slave 
replication.  We should make sure that a defined replication handler will 
override the built in one.  I remember seeing something about a defined /update 
handler with an update processor chain not overriding the built-in handler.

> warning log about deprecated class things
> -
>
> Key: SOLR-7388
> URL: https://issues.apache.org/jira/browse/SOLR-7388
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.0
>Reporter: Stephen Chen
>Priority: Minor
>  Labels: LOG, warnings
>
> I deployed SOLR5.0.0 to tomcat, and there are some logs shown every time 
> after deployment, it might affect lots of users although it functions well, 
> please kindly help to have a look and advice, many thanks!
> there is a similar issue I searched on-line, for reference
> http://grokbase.com/t/lucene/dev/14626fjmk0/jira-created-solr-6128-solrresourceloader-error-messages
> WARN  - 2015-04-14 20:23:58.136; org.apache.solr.core.SolrResourceLoader; 
> Solr loaded a deprecated plugin/analysis class [solr.ThaiWordFilterFactory]. 
> Please consult documentation how to replace it accordingly.
> WARN  - 2015-04-14 20:23:59.374; org.apache.solr.core.SolrResourceLoader; 
> Solr loaded a deprecated plugin/analysis class [solr.admin.AdminHandlers]. 
> Please consult documentation how to replace it accordingly.
> WARN  - 2015-04-14 20:23:59.849; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:23:59.853; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:23:59.854; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:01.511; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:01.693; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:02.319; org.apache.solr.schema.IndexSchema; no 
> uniqueKey specified in schema.
> WARN  - 2015-04-14 20:24:02.429; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:02.453; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore



--
This message was sent by Atlassian 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-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[ASF subversion and git services (JIRA)]

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

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

Commit 1673647 from [~ryantxu] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1673647 ]

SOLR-7376: Return raw XML or JSON

> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



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

[Policeman Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:59716/collection1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:59716/collection1]
at 
__randomizedtesting.SeedInfo.seed([EEECBB6A44BA25D1:66B884B0EA464829]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1074)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:846)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:789)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:943)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:958)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1425)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:102)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:86)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRu

Re: Fwd: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 253 - Failure

[Chris Hostetter]

: This fail seems like I might have missed something doing the 5.1
: release ... any thoughts?

I think it's a post release step? once the release is final, someone needs 
to manually generate test indexes (using the released version of the code) 
and then commit those on trunk & backport to the stable branch.

i'm not to familiar with teh process, but i've seen the comments in 
TestBackwardsCompatibility...

  // To generate backcompat indexes with the current default codec, run 
the following ant command:
  //  ant test -Dtestcase=TestBackwardsCompatibility 
-Dtests.bwcdir=/path/to/store/indexes
  //   -Dtests.codec=default -Dtests.useSecurityManager=false
  // Also add testmethod with one of the index creation methods below, for 
example:
  //-Dtestmethod=testCreateCFS
  //
  // Zip up the generated indexes:
  //
  //cd /path/to/store/indexes/index.cfs   ; zip 
index.-cfs.zip *
  //cd /path/to/store/indexes/index.nocfs ; zip 
index.-nocfs.zip *
  //
  // Then move those 2 zip files to your trunk checkout and add them
  // to the oldNames array.



: 
: 
: 
: -- Forwarded message --
: From: Apache Jenkins Server 
: Date: Tue, Apr 14, 2015 at 8:08 PM
: Subject: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 253 - Failure
: To: dev@lucene.apache.org
: 
: 
: Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/253/
: 
: No tests ran.
: 
: Build Log:
: [...truncated 52564 lines...]
: prepare-release-no-sign:
: [mkdir] Created dir:
: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
:  [copy] Copying 446 files to
: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
:  [copy] Copying 245 files to
: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
:[smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
:[smoker] NOTE: output encoding is US-ASCII
:[smoker]
:[smoker] Load release URL
: 
"file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
:[smoker]
:[smoker] Test Lucene...
:[smoker]   test basics...
:[smoker]   get KEYS
:[smoker] 0.1 MB in 0.01 sec (21.8 MB/sec)
:[smoker]   check changes HTML...
:[smoker]   download lucene-5.2.0-src.tgz...
:[smoker] 28.2 MB in 0.03 sec (879.3 MB/sec)
:[smoker] verify md5/sha1 digests
:[smoker]   download lucene-5.2.0.tgz...
:[smoker] 64.9 MB in 0.07 sec (909.1 MB/sec)
:[smoker] verify md5/sha1 digests
:[smoker]   download lucene-5.2.0.zip...
:[smoker] 74.6 MB in 0.14 sec (515.8 MB/sec)
:[smoker] verify md5/sha1 digests
:[smoker]   unpack lucene-5.2.0.tgz...
:[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
:[smoker] test demo with 1.7...
:[smoker]   got 5751 hits for query "lucene"
:[smoker] checkindex with 1.7...
:[smoker] check Lucene's javadoc JAR
:[smoker]   unpack lucene-5.2.0.zip...
:[smoker] verify JAR metadata/identity/no javax.* or java.* classes...
:[smoker] test demo with 1.7...
:[smoker]   got 5751 hits for query "lucene"
:[smoker] checkindex with 1.7...
:[smoker] check Lucene's javadoc JAR
:[smoker]   unpack lucene-5.2.0-src.tgz...
:[smoker] make sure no JARs/WARs in src dist...
:[smoker] run "ant validate"
:[smoker] run tests w/ Java 7 and
: testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1
: -Dtests.slow=false'...
:[smoker] test demo with 1.7...
:[smoker]   got 212 hits for query "lucene"
:[smoker] checkindex with 1.7...
:[smoker] generate javadocs w/ Java 7...
:[smoker]
:[smoker] Crawl/parse...
:[smoker]
:[smoker] Verify...
:[smoker]   confirm all releases have coverage in TestBackwardsCompatibility
:[smoker] find all past Lucene releases...
:[smoker] run TestBackwardsCompatibility..
:[smoker] Releases that don't seem to be tested:
:[smoker]   5.1.0
:[smoker] Traceback (most recent call last):
:[smoker]   File
: 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
: line 1535, in 
:[smoker] main()
:[smoker]   File
: 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
: line 1480, in main
:[smoker] smokeTest(c.java, c.url, c.revision, c.version,
: c.tmp_dir, c.is_signed, ' '.join(c.test_args))
:[smoker]   File
: 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
: line 1518, in smokeTest
:[smoker] unpackAndVerify(java, 'lucene', tmpDir,
: 'lucene-%s-src.tgz' % version, svnRevision, version, testArgs,
: baseURL)

Fwd: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 253 - Failure

[Timothy Potter]

This fail seems like I might have missed something doing the 5.1
release ... any thoughts?



-- Forwarded message --
From: Apache Jenkins Server 
Date: Tue, Apr 14, 2015 at 8:08 PM
Subject: [JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 253 - Failure
To: dev@lucene.apache.org


Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/253/

No tests ran.

Build Log:
[...truncated 52564 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker]
   [smoker] Load release URL
"file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
   [smoker]
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (21.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.2.0-src.tgz...
   [smoker] 28.2 MB in 0.03 sec (879.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.2.0.tgz...
   [smoker] 64.9 MB in 0.07 sec (909.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.2.0.zip...
   [smoker] 74.6 MB in 0.14 sec (515.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5751 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5751 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.2.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and
testArgs='-Dtests.jettyConnector=Socket -Dtests.multiplier=1
-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker]
   [smoker] Crawl/parse...
   [smoker]
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.1.0
   [smoker] Traceback (most recent call last):
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 1535, in 
   [smoker] main()
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 1480, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version,
c.tmp_dir, c.is_signed, ' '.join(c.test_args))
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 1518, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir,
'lucene-%s-src.tgz' % version, svnRevision, version, testArgs,
baseURL)
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 628, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath,
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 809, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
line 1473, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by
TestBackwardsCompatibility?

BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:421:
exec returned: 1

Total time: 44 minutes 55 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure




-

[jira] [Updated] (LUCENE-6424) DirectoryStream doesnt wrap with FilterPath

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6424:

Attachment: LUCENE-6424.patch

Updated patch with hard checks on unboxing. While this technically deviates 
from some of the APIs, I don't care, this is our tests, and we need to be able 
to debug them (not return false or no results silently).

I also removed SecureDirectoryStream in these wrappers (its optional anyway, 
and quite complicated: we don't need any more of that), and fixed the hacky 
filesystem in TestIOUtils to be well-behaved. I fixed failures in the new tests 
if it got extrasfs as well.

> DirectoryStream doesnt wrap with FilterPath
> -
>
> Key: LUCENE-6424
> URL: https://issues.apache.org/jira/browse/LUCENE-6424
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6424.patch, LUCENE-6424.patch, LUCENE-6424.patch
>
>
> This can cause various mayhem e.g. globs with Files.newDirectoryStream may 
> not work correctly.



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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/253/

No tests ran.

Build Log:
[...truncated 52564 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker] 
   [smoker] Load release URL 
"file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (21.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.2.0-src.tgz...
   [smoker] 28.2 MB in 0.03 sec (879.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.2.0.tgz...
   [smoker] 64.9 MB in 0.07 sec (909.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.2.0.zip...
   [smoker] 74.6 MB in 0.14 sec (515.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5751 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5751 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.2.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket 
-Dtests.multiplier=1 -Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 212 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.1.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1535, in 
   [smoker] main()
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1480, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1518, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 628, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 809, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1473, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:421:
 exec returned: 1

Total time: 44 minutes 55 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (SOLR-7335) Multivalue field that is boosted on indexing time has wrong norm.

[Shingo Sasaki (JIRA)]

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

Shingo Sasaki updated SOLR-7335:

Affects Version/s: Trunk

> Multivalue field that is boosted on indexing time has wrong norm.
> -
>
> Key: SOLR-7335
> URL: https://issues.apache.org/jira/browse/SOLR-7335
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10, 5.0, Trunk
>Reporter: Shingo Sasaki
>Priority: Critical
> Attachments: SOLR-7335.patch
>
>
> Multivalue field has wrong norm when the field value is tokenized, the field 
> or document is boosted, and the field is not source of copyField.
> {noformat}
> $ java -jar start.jar &
> $ echo '{
> "add": {
>   "doc": {
> "id":"no-boosted",
> "features": ["a","b","c"],
> "dyn_not_copied_txt": ["a","b","c"]
>   }
> },
> "add": {
>   "boost": 10,
>   "doc": {
> "id":"boosted",
> "features": ["a","b","c"],
> "dyn_not_copied_txt": ["a","b","c"]
>   }
> }}' > test.json
> $ curl 'http://localhost:8983/solr/update/json?commit=true' -H 
> 'Content-type:application/json' --data-binary @test.json
> {"responseHeader":{"status":0,"QTime":41}}
> $ curl 'http://localhost:8983/solr/select' -d 
> 'omitHeader=true&wt=json&indent=on&q=*:*&fl=id,norm(features),norm(dyn_not_copied_txt)'
> {
>   "response":{"numFound":2,"start":0,"docs":[
>   {
> "id":"no-boosted",
> "norm(features)":0.5,
> "norm(dyn_not_copied_txt)":0.5},
>   {
> "id":"boosted",
> "norm(features)":5.0,
> "norm(dyn_not_copied_txt)":512.0}]
>   }}
> {noformat}
> In the above example, "features" is source of copyField. On the other hand, 
> "dyn_not_copied_txt" is not so. 
> "features" and "dyn_not_copied_txt" have the same type attribute 
> (type="text_general"), the same values ( ["a","b","c"] ) and the same boost. 
> So, both fields must have the same norm in the document.
> But, in boosted document only,  the field that is not copied have too larger 
> norm.



--
This message was sent by Atlassian 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-Linux (32bit/jdk1.8.0_40) - Build # 12305 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
commitWithin did not work on node: http://127.0.0.1:36184/collection1 
expected:<68> but was:<67>

Stack Trace:
java.lang.AssertionError: commitWithin did not work on node: 
http://127.0.0.1:36184/collection1 expected:<68> but was:<67>
at 
__randomizedtesting.SeedInfo.seed([51E2D0459BC04CA4:D9B6EF9F353C215C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:344)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.Sta

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

[Apache Jenkins Server]

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

2 tests failed.
REGRESSION:  org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test

Error Message:
Didn't see all replicas for shard shard1 in collection1 come up within 3 
ms! ClusterState: {   "collection1":{ "autoCreated":"true", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"base_url":"http://127.0.0.1:14997/g/hl";, 
"node_name":"127.0.0.1:14997_g%2Fhl", "core":"collection1", 
"state":"active", "leader":"true"},   "core_node2":{
 "base_url":"http://127.0.0.1:15006/g/hl";, 
"node_name":"127.0.0.1:15006_g%2Fhl", "core":"collection1", 
"state":"recovering", "autoAddReplicas":"false", 
"router":{"name":"compositeId"}, "replicationFactor":"1", 
"maxShardsPerNode":"1"},   "control_collection":{ "autoCreated":"true", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{"core_node1":{ 
"base_url":"http://127.0.0.1:14986/g/hl";, 
"node_name":"127.0.0.1:14986_g%2Fhl", "core":"collection1", 
"state":"active", "leader":"true", 
"autoAddReplicas":"false", "router":{"name":"compositeId"}, 
"replicationFactor":"1", "maxShardsPerNode":"1"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in 
collection1 come up within 3 ms! ClusterState: {
  "collection1":{
"autoCreated":"true",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"base_url":"http://127.0.0.1:14997/g/hl";,
"node_name":"127.0.0.1:14997_g%2Fhl",
"core":"collection1",
"state":"active",
"leader":"true"},
  "core_node2":{
"base_url":"http://127.0.0.1:15006/g/hl";,
"node_name":"127.0.0.1:15006_g%2Fhl",
"core":"collection1",
"state":"recovering",
"autoAddReplicas":"false",
"router":{"name":"compositeId"},
"replicationFactor":"1",
"maxShardsPerNode":"1"},
  "control_collection":{
"autoCreated":"true",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"base_url":"http://127.0.0.1:14986/g/hl";,
"node_name":"127.0.0.1:14986_g%2Fhl",
"core":"collection1",
"state":"active",
"leader":"true",
"autoAddReplicas":"false",
"router":{"name":"compositeId"},
"replicationFactor":"1",
"maxShardsPerNode":"1"}}
at 
__randomizedtesting.SeedInfo.seed([1C867DB1D762E438:94D2426B799E89C0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1920)
at 
org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
  

[jira] [Resolved] (LUCENE-6421) Add two-phase support to MultiPhraseQuery

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-6421.
-
Resolution: Fixed

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6421: defer reading of positions in MultiPhraseQuery until they are 
needed

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 1673595 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1673595 ]

LUCENE-6421: defer reading of positions in MultiPhraseQuery until they are 
needed

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



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

[Policeman Jenkins Server]

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

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

Error Message:
Test abandoned because suite timeout was reached.

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


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

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

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




Build Log:
[...truncated 10601 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest
 84D7FA0C754C4285-001\init-core-data-001
   [junit4]   2> 433164 T2462 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /ri_qhq/
   [junit4]   2> 433170 T2462 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   2> 433175 T2463 oasc.ZkTestServer$2$1.setClientPort client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 433175 T2463 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 433293 T2462 oasc.ZkTestServer.run start zk server on 
port:57580
   [junit4]   2> 433293 T2462 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 433295 T2462 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 433300 T2470 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@ac5c974 name:ZooKeeperConnection 
Watcher:127.0.0.1:57580 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 433302 T2462 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 433303 T2462 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 433303 T2462 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 433308 T2462 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 433312 T2462 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 433317 T2473 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@41025524 
name:ZooKeeperConnection Watcher:127.0.0.1:57580/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 433318 T2462 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 433318 T2462 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 433318 T2462 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 433322 T2462 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 433327 T2462 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 43 T2462 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 46 T2462 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 47 T2462 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 433344 T2462 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 433345 T2462 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 433352 T2462 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 433352 T2462 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 433357 T2462 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 433358 T2462 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 433360 T2462 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 433361 T2462 oascc.SolrZkClient.ma

[jira] [Commented] (LUCENE-6424) DirectoryStream doesnt wrap with FilterPath

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6424:
-

+1

When committing can you make the 'fileSystem' instance variable of 
Filter(Secure)DirectoryStream final?

> DirectoryStream doesnt wrap with FilterPath
> -
>
> Key: LUCENE-6424
> URL: https://issues.apache.org/jira/browse/LUCENE-6424
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6424.patch, LUCENE-6424.patch
>
>
> This can cause various mayhem e.g. globs with Files.newDirectoryStream may 
> not work correctly.



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6421:
-

The bug was silly. MultiPhraseWeight would 'return null' if one term didn't 
exist in the segment, but that code is dead (we just ignore it and check if the 
list of postings is empty at the end).

I also added some unit tests for the postings enum (which didnt have bugs, but 
still good to have direct tests).

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



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

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

[jira] [Updated] (LUCENE-6424) DirectoryStream doesnt wrap with FilterPath

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6424:
---
Attachment: LUCENE-6424.patch

New patch which fixes the glob test to actually check something, and a wraps 
the filter passed to newDirectoryStream so globs actually work.

> DirectoryStream doesnt wrap with FilterPath
> -
>
> Key: LUCENE-6424
> URL: https://issues.apache.org/jira/browse/LUCENE-6424
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6424.patch, LUCENE-6424.patch
>
>
> This can cause various mayhem e.g. globs with Files.newDirectoryStream may 
> not work correctly.



--
This message was sent by Atlassian 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-SmokeRelease-5.1 - Build # 57 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.1/57/

No tests ran.

Build Log:
[...truncated 52265 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/lucene/build/smokeTestRelease/dist
 [copy] Copying 446 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] NOTE: output encoding is US-ASCII
   [smoker] 
   [smoker] Load release URL 
"file:/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (22.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.1.0-src.tgz...
   [smoker] 28.1 MB in 0.08 sec (357.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.1.0.tgz...
   [smoker] 64.6 MB in 0.08 sec (808.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.1.0.zip...
   [smoker] 74.3 MB in 0.09 sec (863.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5711 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 5711 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.jettyConnector=Socket 
-Dtests.multiplier=1 -Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 210 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 1535, in 
   [smoker] main()
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 1480, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 1518, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 628, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 809, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/dev-tools/scripts/smokeTestRelease.py",
 line 1473, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?
   [smoker] Releases that don't seem to be tested:
   [smoker]   5.1.0

BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.1/build.xml:414:
 exec returned: 1

Total time: 44 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (LUCENE-6424) DirectoryStream doesnt wrap with FilterPath

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6424:
---
Attachment: LUCENE-6424.patch

Here is a patch which fixes FilterDirectoryStream to take the filesystem it 
should filter against and a couple tests for newDirectoryStream with and 
without a glob.

> DirectoryStream doesnt wrap with FilterPath
> -
>
> Key: LUCENE-6424
> URL: https://issues.apache.org/jira/browse/LUCENE-6424
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ryan Ernst
> Attachments: LUCENE-6424.patch
>
>
> This can cause various mayhem e.g. globs with Files.newDirectoryStream may 
> not work correctly.



--
This message was sent by Atlassian 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-7388) warning log about deprecated class things

[Stephen Chen (JIRA)]

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

Stephen Chen commented on SOLR-7388:


Hi Shawan,
you are right, I am using example-DIH samples which is include in the 5.0.0 
release, and what do you mean "then do no appear in trunk (Release 5.x.x ?)" ? 
how can I get the latest examples(core conf) ? is it released ?

thanks for your prompt response !!

> warning log about deprecated class things
> -
>
> Key: SOLR-7388
> URL: https://issues.apache.org/jira/browse/SOLR-7388
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.0
>Reporter: Stephen Chen
>Priority: Minor
>  Labels: LOG, warnings
>
> I deployed SOLR5.0.0 to tomcat, and there are some logs shown every time 
> after deployment, it might affect lots of users although it functions well, 
> please kindly help to have a look and advice, many thanks!
> there is a similar issue I searched on-line, for reference
> http://grokbase.com/t/lucene/dev/14626fjmk0/jira-created-solr-6128-solrresourceloader-error-messages
> WARN  - 2015-04-14 20:23:58.136; org.apache.solr.core.SolrResourceLoader; 
> Solr loaded a deprecated plugin/analysis class [solr.ThaiWordFilterFactory]. 
> Please consult documentation how to replace it accordingly.
> WARN  - 2015-04-14 20:23:59.374; org.apache.solr.core.SolrResourceLoader; 
> Solr loaded a deprecated plugin/analysis class [solr.admin.AdminHandlers]. 
> Please consult documentation how to replace it accordingly.
> WARN  - 2015-04-14 20:23:59.849; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:23:59.853; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:23:59.854; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:01.511; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:01.693; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:02.319; org.apache.solr.schema.IndexSchema; no 
> uniqueKey specified in schema.
> WARN  - 2015-04-14 20:24:02.429; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore
> WARN  - 2015-04-14 20:24:02.453; org.apache.solr.handler.admin.AdminHandlers; 
>   class="solr.admin.AdminHandlers" /> is deprecated . It is not required 
> anymore



--
This message was sent by Atlassian 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-6625) HttpClient callback in HttpSolrServer

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-6625:
--

[~ichattopadhyaya] thanks for posting the patch.  As far as I can tell, this 
replaces our own interface/abstract class for callbacks with an 
HttpRequestInterceptor.  That seems reasonable, but there are a few issues 
discussed on this JIRA that don't seem addressed.  A somewhat comprehensive 
list:

1.  How is configuration handled?  Is it the responsibility of the 
authentication layer to specify the HttpRequestInterceptor to use for all 
requests?
2.  There is some question about passing in SolrRequests (client) vs 
SolrQueryRequests (server).  Presumably the authentication layer needs to 
operate on the client side (often the authentication requirements will be the 
same), but what are you supposed to do with the SolrQueryRequest?  You've sort 
of hidden it by putting it in the context, but that seems fragile; we should 
have our own Context that makes clear what is available, but if you pull in 
SolrQueryRequest, then clients need access to server data structures, which 
isn't ideal.  Perhaps the right thing to do is split up client vs server 
interceptors?
3.  Can the request interceptor do everything our own callback can do?  There 
are sample tests in the patch which add cookies, modify the URL, etc. It would 
be good to see those tests with the new implementation
4.  How do you check that we actually pass the correct information to the 
interceptor?  [~steff1193] described this above; what if someone adds another 
httpclient.execute call tomorrow and doesn't pass the SolrRequest object?  
We'll never know, so relying on the HttpRequestInterceptor didn't really help 
us (it automatically dispatches but doesn't check that it has all the info it 
needs to dispatch).  It just limits us to an interface we don't control.  We 
need some way of enforcing the property that every call to httpclient has the 
information we need.

> HttpClient callback in HttpSolrServer
> -
>
> Key: SOLR-6625
> URL: https://issues.apache.org/jira/browse/SOLR-6625
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>Priority: Minor
> Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, 
> SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, 
> SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, 
> SOLR-6625_r1654079.patch
>
>
> Some of our setups use Solr in a SPNego/kerberos setup (we've done this by 
> adding our own filters to the web.xml).  We have an issue in that SPNego 
> requires a negotiation step, but some HttpSolrServer requests are not 
> repeatable, notably the PUT/POST requests.  So, what happens is, 
> HttpSolrServer sends the requests, the server responds with a negotiation 
> request, and the request fails because the request is not repeatable.  We've 
> modified our code to send a repeatable request beforehand in these cases.
> It would be nicer if HttpSolrServer provided a pre/post callback when it was 
> making an httpclient request.  This would allow administrators to make 
> changes to the request for authentication purposes, and would allow users to 
> make per-request changes to the httpclient calls (i.e. modify httpclient 
> requestconfig to modify the timeout on a per-request basis).



--
This message was sent by Atlassian 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-Linux (64bit/jdk1.9.0-ea-b54) - Build # 12304 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12304/
Java: 64bit/jdk1.9.0-ea-b54 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Didn't see all replicas for shard shard1 in collection1 come up within 3 
ms! ClusterState: {   "collection1":{ "replicationFactor":"1", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:43723/ios/qe";,   
  "node_name":"127.0.0.1:43723_ios%2Fqe", "state":"active", 
"leader":"true"},   "core_node2":{ 
"core":"collection1", "base_url":"http://127.0.0.1:57574/ios/qe";,   
  "node_name":"127.0.0.1:57574_ios%2Fqe", 
"state":"recovering", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "control_collection":{ "replicationFactor":"1",
 "shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{"core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:54313/ios/qe";,   
  "node_name":"127.0.0.1:54313_ios%2Fqe", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in 
collection1 come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:43723/ios/qe";,
"node_name":"127.0.0.1:43723_ios%2Fqe",
"state":"active",
"leader":"true"},
  "core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:57574/ios/qe";,
"node_name":"127.0.0.1:57574_ios%2Fqe",
"state":"recovering",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:54313/ios/qe";,
"node_name":"127.0.0.1:54313_ios%2Fqe",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"}}
at 
__randomizedtesting.SeedInfo.seed([470993FA8A376E42:CF5DAC2024CB03BA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1920)
at 
org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:103)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.

[jira] [Reopened] (LUCENE-6421) Add two-phase support to MultiPhraseQuery

[Robert Muir (JIRA)]

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

Robert Muir reopened LUCENE-6421:
-

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 1673577 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1673577 ]

LUCENE-6421: revert

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6421: revert

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 42133 - Failure!

[Robert Muir]

I caused this from LUCENE-6421. I'm gonna revert the changes and add more
tests.

On Tue, Apr 14, 2015 at 6:50 PM,  wrote:

>   *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/42133/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDK7u65,network,heap[1024m],-server
> +UseSerialGC -UseCompressedOops,sec manager on Date of build:Wed, 15 Apr
> 2015 00:47:33 +0200 Build duration:2 min 28 sec
>  *CHANGES*   Revision  by *rmuir: * *(LUCENE-6421: defer reading of
> positions in MultiPhraseQuery until they are needed)*edit
> /lucene/dev/branches/branch_5xedit
> /lucene/dev/branches/branch_5x/luceneedit
> /lucene/dev/branches/branch_5x/lucene/CHANGES.txtedit
> /lucene/dev/branches/branch_5x/lucene/coreedit
> /lucene/dev/branches/branch_5x/lucene/core/src/java/org/apache/lucene/search/MultiPhraseQuery.java
>   edit
> /lucene/dev/branches/branch_5x/lucene/core/src/java/org/apache/lucene/search/PhraseQuery.java
>  *BUILD ARTIFACTS*
> checkout/lucene/build/core/test/temp/junit4-J0-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J1-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J2-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J3-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J4-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J5-20150415_004746_708.events
> 
> checkout/lucene/build/core/test/temp/junit4-J6-20150415_004746_709.events
> 
> checkout/lucene/build/core/test/temp/junit4-J7-20150415_004746_709.events
> 
>  *FAILED JUNIT TESTS* Name: org.apache.lucene.search Failed: 1 test(s),
> Passed: 794 test(s), Skipped: 2 test(s), Total: 797 test(s)
> *Failed:
> org.apache.lucene.search.TestSimpleSearchEquivalence.testExactPhraseVersusMultiPhrase
> *
>  *CONSOLE OUTPUT* [...truncated 1873 lines...] [junit4] Tests with
> failures: [junit4] -
> org.apache.lucene.search.TestSimpleSearchEquivalence.testExactPhraseVersusMultiPhrase
>  [junit4]
>  [junit4]  [junit4] JVM J0: 0.92 .. 123.82 = 122.89s [junit4] JVM J1:
> 0.67 .. 123.63 = 122.96s [junit4] JVM J2: 0.91 .. 125.08 = 124.17s [junit4]
> JVM J3: 0.68 .. 132.36 = 131.68s [junit4] JVM J4: 0.91 .. 123.33 = 122.42s 
> [junit4]
> JVM J5: 0.68 .. 124.71 = 124.03s [junit4] JVM J6: 0.91 .. 125.02 = 124.11s 
> [junit4]
> JVM J7: 0.91 .. 132.34 = 131.44s [junit4] Execution time total: 2 minutes
> 12 seconds [junit4] Tests summary: 429 suites, 3551 tests, 1 failure, 65
> ignored (55 assumptions) BUILD FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1434:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:991:
> There were test failures: 429 suites, 3551 tests, 1 failure, 65 ignored (55
> assumptions) Total time: 2 minutes 20 seconds Build step 'Invoke Ant'
> marked build as failure Archiving artifacts Recording test results 
> [description-setter]
> Description set: JDK7u65,network,heap[1024m],-server +UseSerialGC
> -UseCompressedOops,sec manager on Email was triggered for: Failure - 1st 
> Trigger
> Failure - Any was overridden by another trigger and will not send an email. 
> Trigger
> Failure - Still was overridden by another trigger and will not send an
> email. Sending email for trigger: Failure - 1st
>

[jira] [Commented] (SOLR-7264) DocValues should support BoolField

[Kevin Osborn (JIRA)]

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

Kevin Osborn commented on SOLR-7264:


It has been a while since I submitted this patch. Can someone take a look at 
this so that it can hopefully be committed. Thanks.

> DocValues should support BoolField
> --
>
> Key: SOLR-7264
> URL: https://issues.apache.org/jira/browse/SOLR-7264
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Kevin Osborn
> Attachments: SOLR-7264.patch
>
>
> DocValues supports numerics and strings, but it currently does not support 
> booleans. Please add this support.
> Here is the error message you get if you try to use DocValues with a 
> BoolField.
> ERROR - 2015-03-18 00:49:54.041; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: SolrCore 'test' is not available 
> due to init failure: Could not load conf for core test: F
> ield type 
> boolean{class=org.apache.solr.schema.BoolField,analyzer=org.apache.solr.schema.FieldType$DefaultAnalyzer,args={sortMissingLast=true,
>  class=solr.BoolField}} does not support doc values. Schema fi
> le is /Users/kosborn/solr/server/solr/test/conf/schema.xml



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

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

[jira] [Updated] (SOLR-7264) DocValues should support BoolField

[Kevin Osborn (JIRA)]

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

Kevin Osborn updated SOLR-7264:
---
Fix Version/s: 5.0

> DocValues should support BoolField
> --
>
> Key: SOLR-7264
> URL: https://issues.apache.org/jira/browse/SOLR-7264
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Kevin Osborn
> Attachments: SOLR-7264.patch
>
>
> DocValues supports numerics and strings, but it currently does not support 
> booleans. Please add this support.
> Here is the error message you get if you try to use DocValues with a 
> BoolField.
> ERROR - 2015-03-18 00:49:54.041; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: SolrCore 'test' is not available 
> due to init failure: Could not load conf for core test: F
> ield type 
> boolean{class=org.apache.solr.schema.BoolField,analyzer=org.apache.solr.schema.FieldType$DefaultAnalyzer,args={sortMissingLast=true,
>  class=solr.BoolField}} does not support doc values. Schema fi
> le is /Users/kosborn/solr/server/solr/test/conf/schema.xml



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

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

[jira] [Updated] (SOLR-7264) DocValues should support BoolField

[Kevin Osborn (JIRA)]

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

Kevin Osborn updated SOLR-7264:
---
Fix Version/s: (was: 5.0)

> DocValues should support BoolField
> --
>
> Key: SOLR-7264
> URL: https://issues.apache.org/jira/browse/SOLR-7264
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Kevin Osborn
> Attachments: SOLR-7264.patch
>
>
> DocValues supports numerics and strings, but it currently does not support 
> booleans. Please add this support.
> Here is the error message you get if you try to use DocValues with a 
> BoolField.
> ERROR - 2015-03-18 00:49:54.041; org.apache.solr.common.SolrException; 
> null:org.apache.solr.common.SolrException: SolrCore 'test' is not available 
> due to init failure: Could not load conf for core test: F
> ield type 
> boolean{class=org.apache.solr.schema.BoolField,analyzer=org.apache.solr.schema.FieldType$DefaultAnalyzer,args={sortMissingLast=true,
>  class=solr.BoolField}} does not support doc values. Schema fi
> le is /Users/kosborn/solr/server/solr/test/conf/schema.xml



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

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

[jira] [Resolved] (LUCENE-6421) Add two-phase support to MultiPhraseQuery

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-6421.
-
   Resolution: Fixed
Fix Version/s: 5.2
   Trunk

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6421: defer reading of positions in MultiPhraseQuery until they are 
needed

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[ASF subversion and git services (JIRA)]

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

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

Commit 1673572 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1673572 ]

LUCENE-6421: defer reading of positions in MultiPhraseQuery until they are 
needed

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



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

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

[JENKINS] Lucene-Solr-5.1-Linux (32bit/jdk1.8.0_40) - Build # 267 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.1-Linux/267/
Java: 32bit/jdk1.8.0_40 -server -XX:+UseG1GC

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

Error Message:
Didn't see all replicas for shard shard1 in collection1 come up within 3 
ms! ClusterState: {   "collection1":{ "replicationFactor":"1", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:60817";,  
   "node_name":"127.0.0.1:60817_", "state":"active", 
"leader":"true"},   "core_node2":{ "core":"collection1",
 "base_url":"http://127.0.0.1:52711";, 
"node_name":"127.0.0.1:52711_", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "autoCreated":"true"},   "control_collection":{  
   "replicationFactor":"1", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "core":"collection1", 
"base_url":"http://127.0.0.1:43389";, 
"node_name":"127.0.0.1:43389_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in 
collection1 come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:60817";,
"node_name":"127.0.0.1:60817_",
"state":"active",
"leader":"true"},
  "core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:52711";,
"node_name":"127.0.0.1:52711_",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:43389";,
"node_name":"127.0.0.1:43389_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"}}
at 
__randomizedtesting.SeedInfo.seed([3668041102CC543E:BE3C3BCBAC3039C6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1925)
at 
org.apache.solr.cloud.RecoveryAfterSoftCommitTest.test(RecoveryAfterSoftCommitTest.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
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.randomizedtestin

[jira] [Created] (SOLR-7391) Use a time based expiration cache for one off hdfs FileSystem instances.

[Mark Miller (JIRA)]

Mark Miller created SOLR-7391:
-

 Summary: Use a time based expiration cache for one off hdfs 
FileSystem instances.
 Key: SOLR-7391
 URL: https://issues.apache.org/jira/browse/SOLR-7391
 Project: Solr
  Issue Type: Improvement
  Components: s, hdfs
Reporter: Mark Miller
Assignee: Mark Miller


Most FileSystem clients are tied to a SolrCore and long lived, but in some 
cases where we don't have SolrCore context we create a short lived hdfs client 
object.

Because these instances can be created via user generated actions, we don't 
want to be able to create too many of them - they have overhead that does not 
make them great candidates for being spun up for a single call.



--
This message was sent by Atlassian 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-6424) DirectoryStream doesnt wrap with FilterPath

[Ryan Ernst (JIRA)]

Ryan Ernst created LUCENE-6424:
--

 Summary: DirectoryStream doesnt wrap with FilterPath
 Key: LUCENE-6424
 URL: https://issues.apache.org/jira/browse/LUCENE-6424
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ryan Ernst


This can cause various mayhem e.g. globs with Files.newDirectoryStream may not 
work correctly.



--
This message was sent by Atlassian 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-7390) Throw an exception when requesting an unknown document transformer

[Ryan McKinley (JIRA)]

Ryan McKinley created SOLR-7390:
---

 Summary: Throw an exception when requesting an unknown document 
transformer
 Key: SOLR-7390
 URL: https://issues.apache.org/jira/browse/SOLR-7390
 Project: Solr
  Issue Type: Bug
Reporter: Ryan McKinley
Assignee: Ryan McKinley


Currently, a request for an unknown doc transformer silently does nothing.  We 
could have this make a noisy exception.

is there any reason we would want a silent behavior with:
&fl=id,name,[asdgasdgasgdasg]




--
This message was sent by Atlassian 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-7376) Allow DocTransformers to write directly to the response (support raw json/xml fields)

[Ryan McKinley (JIRA)]

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

Ryan McKinley updated SOLR-7376:

Attachment: SOLR-7376-raw-json-xml-in-response.patch

Here is a patch with tests -- this adds two default document transformers:
{code}
+defaultFactories.put( "json", new RawValueTransformerFactory("json") );
+defaultFactories.put( "xml", new RawValueTransformerFactory("xml") );
{code}

The values are only unescaped when using the appropriate response writer.

So if you have:
 &fl=id,name,json_s:[json],xml_s:[xml]&wt=json
the xml_s value would be escaped, but json_s would be a raw value.



> Allow DocTransformers to write directly to the response (support raw json/xml 
> fields)
> -
>
> Key: SOLR-7376
> URL: https://issues.apache.org/jira/browse/SOLR-7376
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-7376-raw-json-xml-in-response.patch
>
>
> In order to return raw json when wt=json (and raw xml when wt=xml), it would 
> be great if we could output directly to the response.
> I propose we can put a new `WriteableValue` in the response using 
> DocumentTransformer -- when a TextResponseWriter finds this type, it will let 
> the `WriteableValue` figure out what to do.



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

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

[jira] [Updated] (LUCENE-6422) Add StreamingQuadPrefixTree

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6422:
---
Attachment: LUCENE-6422.patch

Developed and tested against branch_5x. I need to run more rigorous (and 
systematic) benchmarking but preliminary tests show a 90% reduction in index 
size on exotic cases (high precision).

One particular shape (the political boundary of Wales): using QuadPrefixTree 
(w/ RecursivePrefixStrategy) consumed 1G of memory at TreeLevel 26 with 
distance_error_pct: 0.  The new PackedQuadPrefixTree brought this down to just 
over 80mb with the same precision.

There are many improvements remaining (including using variable byte array 
instead of 8 bytes for even the lowest levels). But this provides initial 
progress that should open the door for better precision on extreme shapes.

> Add StreamingQuadPrefixTree
> ---
>
> Key: LUCENE-6422
> URL: https://issues.apache.org/jira/browse/LUCENE-6422
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Affects Versions: 5.x
>Reporter: Nicholas Knize
> Attachments: LUCENE-6422.patch
>
>
> To conform to Lucene's inverted index, SpatialStrategies use strings to 
> represent QuadCells and GeoHash cells. Yielding 1 byte per QuadCell and 5 
> bits per GeoHash cell, respectively.  To create the terms representing a 
> Shape, the BytesRefIteratorTokenStream first builds all of the terms into an 
> ArrayList of Cells in memory, then passes the ArrayList.Iterator back to 
> invert() which creates a second lexicographically sorted array of Terms. This 
> doubles the memory consumption when indexing a shape.
> This task introduces a PackedQuadPrefixTree that uses a StreamingStrategy to 
> accomplish the following:
> 1.  Create a packed 8byte representation for a QuadCell
> 2.  Build the Packed cells 'on demand' when incrementToken is called
> Improvements over this approach include the generation of the packed cells 
> using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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-7349) Cleanup or fix cloud-dev scripts

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7349:
---

I don't know anything about them going out as "release artifacts". I just said 
I'm happy where they are in the src tree.

> Cleanup or fix cloud-dev scripts
> 
>
> Key: SOLR-7349
> URL: https://issues.apache.org/jira/browse/SOLR-7349
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Ramkumar Aiyengar
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7349.patch
>
>
> With Jetty 9, cloud-dev scripts no longer work in trunk, we need to either 
> clean up or fix them.



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

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

[jira] [Updated] (LUCENE-6422) Add StreamingQuadPrefixTree

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6422:
---
Affects Version/s: 5.x

> Add StreamingQuadPrefixTree
> ---
>
> Key: LUCENE-6422
> URL: https://issues.apache.org/jira/browse/LUCENE-6422
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Affects Versions: 5.x
>Reporter: Nicholas Knize
>
> To conform to Lucene's inverted index, SpatialStrategies use strings to 
> represent QuadCells and GeoHash cells. Yielding 1 byte per QuadCell and 5 
> bits per GeoHash cell, respectively.  To create the terms representing a 
> Shape, the BytesRefIteratorTokenStream first builds all of the terms into an 
> ArrayList of Cells in memory, then passes the ArrayList.Iterator back to 
> invert() which creates a second lexicographically sorted array of Terms. This 
> doubles the memory consumption when indexing a shape.
> This task introduces a PackedQuadPrefixTree that uses a StreamingStrategy to 
> accomplish the following:
> 1.  Create a packed 8byte representation for a QuadCell
> 2.  Build the Packed cells 'on demand' when incrementToken is called
> Improvements over this approach include the generation of the packed cells 
> using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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-7344) Use two thread pools, one for internal requests and one for external, to avoid distributed deadlock and decrease the number of threads that need to be created.

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-7344:


[~andyetitmoves] Thanks for the feedback. Yes this makes perfect sense. 

I think I have enough information/context to get started with the actual 
implementation. I suggested to keep this configuration under /live_nodes ZNODE 
since I don't see any other appropriate ZNODE. If you have any other ideas, 
please let me know. But I think we can get started with this and make changes 
if necessary. I will reply once I have a patch ready.


> Use two thread pools, one for internal requests and one for external, to 
> avoid distributed deadlock and decrease the number of threads that need to be 
> created.
> ---
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>




--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta edited comment on SOLR-7275 at 4/14/15 8:44 PM:
-

I'm just trying to keep custom plugin config for security separate from other 
configuration. About merging authc and authz configs, that was on my mind and I 
plan to do it when I'm integrating the changes here with SOLR-7274.

Let's consider an example of a user wanting to use some proprietary non-json 
format data in a custom security plugin, to store access rules. There wouldn't 
be a way to do that. I am all for exploring more options if there are any as 
long as they don't stop users from doing their own thing.

I can have a straight mechanism to just read the {{authorization}} part of 
{{/security.json}} and pass that map to the plugin during init instead of the 
plugin reading from a file directly, but then instead of the security plugin 
deciding if it wants to keep a watch on the file, Solr would always keep a 
watch (when authz is enabled). In cases where access rules don't reside in zk 
and are in a 3rd party system, we don't want to keep a watch. Allowing the 
plugin to make that choice might be a better way to move.

I'm about to separate out the implementation of default/OTB plugin from this 
JIRA and I guess things would be clearer for everyone to understand after that 
happens.


was (Author: anshumg):
I'm just trying to keep custom plugin config for security separate from other 
configuration. About merging authc and authz configs, that was on my mind and I 
plan to do it when I'm integrating the changes here with SOLR-7274.

Let's consider an example of a user wanting to use some proprietary non-json 
format data in a custom security plugin, to store access rules. There wouldn't 
be a way to do that. I am all for exploring more options if there are any as 
long as they don't stop users from doing their own thing.

I can have a straight mechanism to just read the {authorization} part of 
{/security.json} and pass that map to the plugin during init instead of the 
plugin reading from a file directly, but then instead of the security plugin 
deciding if it wants to keep a watch on the file, Solr would always keep a 
watch (when authz is enabled). In cases where access rules don't reside in zk 
and are in a 3rd party system, we don't want to keep a watch. Allowing toe 
plugin to make that choice might be a better way to move.

I'm about to separate out the implementation of default/OTB plugin from this 
JIRA and I guess things would be clearer for everyone to understand after that 
happens.

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



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

---

[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7275:


I'm just trying to keep custom plugin config for security separate from other 
configuration. About merging authc and authz configs, that was on my mind and I 
plan to do it when I'm integrating the changes here with SOLR-7274.

Let's consider an example of a user wanting to use some proprietary non-json 
format data in a custom security plugin, to store access rules. There wouldn't 
be a way to do that. I am all for exploring more options if there are any as 
long as they don't stop users from doing their own thing.

I can have a straight mechanism to just read the {authorization} part of 
{/security.json} and pass that map to the plugin during init instead of the 
plugin reading from a file directly, but then instead of the security plugin 
deciding if it wants to keep a watch on the file, Solr would always keep a 
watch (when authz is enabled). In cases where access rules don't reside in zk 
and are in a 3rd party system, we don't want to keep a watch. Allowing toe 
plugin to make that choice might be a better way to move.

I'm about to separate out the implementation of default/OTB plugin from this 
JIRA and I guess things would be clearer for everyone to understand after that 
happens.

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



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

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

[jira] [Updated] (LUCENE-6422) Add StreamingQuadPrefixTree

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-6422:
---
Issue Type: Improvement  (was: Bug)

> Add StreamingQuadPrefixTree
> ---
>
> Key: LUCENE-6422
> URL: https://issues.apache.org/jira/browse/LUCENE-6422
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: Nicholas Knize
>
> To conform to Lucene's inverted index, SpatialStrategies use strings to 
> represent QuadCells and GeoHash cells. Yielding 1 byte per QuadCell and 5 
> bits per GeoHash cell, respectively.  To create the terms representing a 
> Shape, the BytesRefIteratorTokenStream first builds all of the terms into an 
> ArrayList of Cells in memory, then passes the ArrayList.Iterator back to 
> invert() which creates a second lexicographically sorted array of Terms. This 
> doubles the memory consumption when indexing a shape.
> This task introduces a PackedQuadPrefixTree that uses a StreamingStrategy to 
> accomplish the following:
> 1.  Create a packed 8byte representation for a QuadCell
> 2.  Build the Packed cells 'on demand' when incrementToken is called
> Improvements over this approach include the generation of the packed cells 
> using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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-7344) Use two thread pools, one for internal requests and one for external, to avoid distributed deadlock and decrease the number of threads that need to be created.

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-7344:
-

No separate threadpools: For very small solr clouds, it might just be overkill 
or just sit there without being used at all (what if I had only one replica?)

Per request type: I might want to dedicate separate amount of resources to say, 
indexing and searching, so that one doesn't starve out the other. In indexing 
spikes, you can currently visibly see search performance be affected on 
leaders..

On the ZK layout, I guess this would work.. Just that I am in two minds about 
if all this configuration should be in live nodes.. But happy to be convinced.. 

The alternative would be for the endpoint could just have a port and a name. 
May be it could guarantee a "default" endpoint being always present. So live 
nodes just "publishes" information about its resources, and how its "consumed" 
is decoupled. SolrJ could just hard code the default name and allow people to 
configure the end point name to start things off -- or this could be part of 
separate per-coll config which SolrJ reads (isn't there a clusterprops.json? I 
forget..) and that could store configuration for logically what each operation 
should use. Similarly indexing config for Solr could allow for an endpoint to 
be configured.

> Use two thread pools, one for internal requests and one for external, to 
> avoid distributed deadlock and decrease the number of threads that need to be 
> created.
> ---
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>




--
This message was sent by Atlassian 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: [ANNOUNCE] Apache Solr 5.1.0 released

[Joseph Obernberger]

Great news!
Any tips on how to do an upgrade from 5.0.0 to 5.1.0?
Thank you!

-Joe

On 4/14/2015 2:39 PM, Timothy Potter wrote:

I apologize - Yonik prepared these nice release notes for 5.1 and I
neglected to include them:

Solr 5.1 Release Highlights:

  * The new Facet Module, including the JSON Facet API.
This module is currently marked as experimental to allow for
further API feedback and improvements.

  * A new JSON request API.
This feature is currently marked as experimental to allow for
further API feedback and improvements.

  * The ability to upload and download Solr configurations via SolrJ
(CloudSolrClient).

  * First-class support for Real-Time Get in SolrJ.

  * Spatial 2D heat-map faceting.

  * EnumField now has docValues support.

  * API to dynamically add Jars to Solr's classpath for plugins.

  * Ability to enable/disable individual stats in the StatsComponent.

  * lucene/solr query syntax to give any query clause a constant score.

  * Schema API enhancements to remove or replace fields, dynamic
fields, field types and copy fields.

  * When posting XML or JSON to Solr with curl, there is no need to
specify the content type.

  * A list of update processors to be used for an update can be
specified dynamically for any given request.

  * StatsComponent now supports Percentiles.

  * facet.contains option to limit which constraints are returned.

  * Streaming Aggregation for SolrCloud.

  * The admin UI now visualizes Lucene segment information.

  * Parameter substitution / macro expansion across entire request


On Tue, Apr 14, 2015 at 11:42 AM, Timothy Potter  wrote:

14 April 2015 - The Lucene PMC is pleased to announce the release of
Apache Solr 5.1.0.

Solr 5.1.0 is available for immediate download at:
http://www.apache.org/dyn/closer.cgi/lucene/solr/5.1.0

Solr 5.1.0 includes 39 new features, 40 bug fixes, and 36 optimizations
/ other changes from over 60 unique contributors.

For detailed information about what is included in 5.1.0 release,
please see: http://lucene.apache.org/solr/5_1_0/changes/Changes.html

Enjoy!



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

[jira] [Created] (LUCENE-6423) New LimitTokenOffsetFilter

[David Smiley (JIRA)]

David Smiley created LUCENE-6423:


 Summary: New LimitTokenOffsetFilter
 Key: LUCENE-6423
 URL: https://issues.apache.org/jira/browse/LUCENE-6423
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: David Smiley
Assignee: David Smiley


It would be nice to have a token filter that limited based on the offset.  I 
suggest the start offset.  It should be named LimitTokenOffsetFilter to have a 
name similar to the other LimitToken*Filter choices, including a 
"consumeAllTokens" option.  I plan to use this filter in LUCENE-6392 (to limit 
tokens from analyzed text for applicable methods in TokenSources) and in 
LUCENE-6375.



--
This message was sent by Atlassian 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-6422) Add StreamingQuadPrefixTree

[Nicholas Knize (JIRA)]

Nicholas Knize created LUCENE-6422:
--

 Summary: Add StreamingQuadPrefixTree
 Key: LUCENE-6422
 URL: https://issues.apache.org/jira/browse/LUCENE-6422
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Reporter: Nicholas Knize


To conform to Lucene's inverted index, SpatialStrategies use strings to 
represent QuadCells and GeoHash cells. Yielding 1 byte per QuadCell and 5 bits 
per GeoHash cell, respectively.  To create the terms representing a Shape, the 
BytesRefIteratorTokenStream first builds all of the terms into an ArrayList of 
Cells in memory, then passes the ArrayList.Iterator back to invert() which 
creates a second lexicographically sorted array of Terms. This doubles the 
memory consumption when indexing a shape.

This task introduces a PackedQuadPrefixTree that uses a StreamingStrategy to 
accomplish the following:

1.  Create a packed 8byte representation for a QuadCell
2.  Build the Packed cells 'on demand' when incrementToken is called

Improvements over this approach include the generation of the packed cells 
using an AutoPrefixAutomaton



--
This message was sent by Atlassian 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-6373) Complete two phase doc id iteration support for Spans

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6373:
--

Great, it was indeed almost there.
Before benchmarking there is another (small) optimization possible: 
topPositionSpans can be put at the object level and maintained together with 
byPositionQueue, and then it can also be tested for null in start/endPosition.


> Complete two phase doc id iteration support for Spans
> -
>
> Key: LUCENE-6373
> URL: https://issues.apache.org/jira/browse/LUCENE-6373
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
> Attachments: LUCENE-6373-SpanOr.patch, LUCENE-6373.patch, 
> LUCENE-6737-SpanOr-oneTestFails.patch
>
>
> Spin off from LUCENE-6308, see comments there from about 23 March 2015.



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

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

[jira] [Updated] (SOLR-1837) Reconstruct a Document (stored fields, indexed fields, payloads)

[John Wooden (JIRA)]

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

John Wooden updated SOLR-1837:
--
Attachment: SOLR-1837.patch

Added a simple UX for the document reconstructor. When a core is selected 
within the management console, a new "DocInspector" link appears. Provide a 
Document ID and the handler will be triggered.

Applies to Solr 4.10.4

> Reconstruct a Document (stored fields, indexed fields, payloads)
> 
>
> Key: SOLR-1837
> URL: https://issues.apache.org/jira/browse/SOLR-1837
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis, web gui
>Affects Versions: 1.5
> Environment: All
>Reporter: Trey Grainger
>Priority: Minor
>  Labels: admin, indexed, luke, payload, reconstruct, stored
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-1837.patch, SOLR-1837.patch, 
> SOLR-1837_WithHandler.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> One Solr feature I've been sorely in need of is the ability to inspect an 
> index for any particular document.  While the analysis page is good when you 
> have specific content and a specific field/type your want to test the 
> analysis process for, once a document is indexed it is not currently possible 
> to easily see what is actually sitting in the index.
> One can use the Lucene Index Browser (Luke), but this has several limitations 
> (gui only, doesn't understand solr schema, doesn't display many non-text 
> fields in human readable format, doesn't show payloads, some bugs lead to 
> missing terms, exposes features dangerous to use in a production Solr 
> environment, slow or difficult to check from a remote location, etc.).  The 
> document reconstruction feature of Luke provides the base for what can become 
> a much more powerful tool when coupled with Solr's understanding of a schema, 
> however.



--
This message was sent by Atlassian 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-6382) Don't allow position = Integer.MAX_VALUE going forward

[ASF subversion and git services (JIRA)]

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

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

Commit 1673508 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1673508 ]

LUCENE-6382: enforce max allowed indexed position

> Don't allow position = Integer.MAX_VALUE going forward
> --
>
> Key: LUCENE-6382
> URL: https://issues.apache.org/jira/browse/LUCENE-6382
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6382.patch, LUCENE-6382.patch, LUCENE-6382.patch
>
>
> Spinoff from LUCENE-6308, where Integer.MAX_VALUE position is now used as a 
> sentinel during position iteration to indicate that there are no more 
> positions.
> Where IW now detects int overflow of position, it should now also detect == 
> Integer.MAX_VALUE.
> And CI should note corruption if a segment's version is >= 5.2 and has 
> Integer.MAX_VALUE position.



--
This message was sent by Atlassian 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: [ANNOUNCE] Apache Solr 5.1.0 released

[Timothy Potter]

I apologize - Yonik prepared these nice release notes for 5.1 and I
neglected to include them:

Solr 5.1 Release Highlights:

 * The new Facet Module, including the JSON Facet API.
   This module is currently marked as experimental to allow for
further API feedback and improvements.

 * A new JSON request API.
   This feature is currently marked as experimental to allow for
further API feedback and improvements.

 * The ability to upload and download Solr configurations via SolrJ
(CloudSolrClient).

 * First-class support for Real-Time Get in SolrJ.

 * Spatial 2D heat-map faceting.

 * EnumField now has docValues support.

 * API to dynamically add Jars to Solr's classpath for plugins.

 * Ability to enable/disable individual stats in the StatsComponent.

 * lucene/solr query syntax to give any query clause a constant score.

 * Schema API enhancements to remove or replace fields, dynamic
fields, field types and copy fields.

 * When posting XML or JSON to Solr with curl, there is no need to
specify the content type.

 * A list of update processors to be used for an update can be
specified dynamically for any given request.

 * StatsComponent now supports Percentiles.

 * facet.contains option to limit which constraints are returned.

 * Streaming Aggregation for SolrCloud.

 * The admin UI now visualizes Lucene segment information.

 * Parameter substitution / macro expansion across entire request


On Tue, Apr 14, 2015 at 11:42 AM, Timothy Potter  wrote:
> 14 April 2015 - The Lucene PMC is pleased to announce the release of
> Apache Solr 5.1.0.
>
> Solr 5.1.0 is available for immediate download at:
> http://www.apache.org/dyn/closer.cgi/lucene/solr/5.1.0
>
> Solr 5.1.0 includes 39 new features, 40 bug fixes, and 36 optimizations
> / other changes from over 60 unique contributors.
>
> For detailed information about what is included in 5.1.0 release,
> please see: http://lucene.apache.org/solr/5_1_0/changes/Changes.html
>
> Enjoy!

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

[jira] [Commented] (LUCENE-6382) Don't allow position = Integer.MAX_VALUE going forward

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6382:


Good idea [~rcmuir] I'll move it there.

> Don't allow position = Integer.MAX_VALUE going forward
> --
>
> Key: LUCENE-6382
> URL: https://issues.apache.org/jira/browse/LUCENE-6382
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6382.patch, LUCENE-6382.patch, LUCENE-6382.patch
>
>
> Spinoff from LUCENE-6308, where Integer.MAX_VALUE position is now used as a 
> sentinel during position iteration to indicate that there are no more 
> positions.
> Where IW now detects int overflow of position, it should now also detect == 
> Integer.MAX_VALUE.
> And CI should note corruption if a segment's version is >= 5.2 and has 
> Integer.MAX_VALUE position.



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

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

Re: Solr Ref Guide for 5.1

[Yonik Seeley]

Additionally, one can use /query instead of /select in your examples
and people will get an indented JSON response by default instead of
XML.

-Yonik

On Thu, Apr 9, 2015 at 5:18 PM, Yonik Seeley  wrote:
> I don't know how often "curl" is used for any examples in the docs,
> but if so, they can be simplified by omitting the content type spec
> (for JSON or XML).  That's due to this:
>
> SOLR-7217: HTTP POST body is auto-detected when the client is curl and
> the content type is form data (curl's default), allowing users to use
> curl to send JSON or XML without having to specify the content type.
> (yonik)
>
> -Yonik

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

[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators

[Rebecca Tang (JIRA)]

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

Rebecca Tang commented on SOLR-2649:


Just saw the announcement that solr 5.1.0 is released.  Looks like this bug 
didn't make it in.  Is it likely for it to be included in the next release?

> MM ignored in edismax queries with operators
> 
>
> Key: SOLR-2649
> URL: https://issues.apache.org/jira/browse/SOLR-2649
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Reporter: Magnus Bergmark
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-2649-with-Qop.patch, SOLR-2649-with-Qop.patch, 
> SOLR-2649.diff, SOLR-2649.patch
>
>
> Hypothetical scenario:
>   1. User searches for "stocks oil gold" with MM set to "50%"
>   2. User adds "-stockings" to the query: "stocks oil gold -stockings"
>   3. User gets no hits since MM was ignored and all terms where AND-ed 
> together
> The behavior seems to be intentional, although the reason why is never 
> explained:
>   // For correct lucene queries, turn off mm processing if there
>   // were explicit operators (except for AND).
>   boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; 
> (lines 232-234 taken from 
> tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java)
> This makes edismax unsuitable as an replacement to dismax; mm is one of the 
> primary features of dismax.



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-7275 at 4/14/15 5:56 PM:
-

+1 to a single /security.json file.
I propose the following format for /security.json, to fold in both SOLR-7274 
and SOLR-7275 (this issue) zk configs. This would need support for nested 
objects in ZkStateReader. The "configs" could be passed in into the plugins' 
init() and hence it will no longer be necessary to pass in a 
ZkClient/ZkController into the plugin's init().
 
{noformat}
{
  "authentication": {
"pluginClass": "org.blahblah",
"pluginName": "kerberos",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  },
  "authorization": {
"pluginClass": "...",
"pluginName": "ranger",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  }
}
{noformat}


was (Author: ichattopadhyaya):
+1 to a single /security.json file.
I propose the following, to fold in both SOLR-7274 and SOLR-7275 (this issue) 
zk configs. This would need support for nested objects in ZkStateReader. The 
"configs" could be passed in into the plugins' init() and hence it will no 
longer be necessary to pass in a ZkClient/ZkController into the plugin's init().
 
{noformat}
{
  "authentication": {
"pluginClass": "org.blahblah",
"pluginName": "kerberos",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  },
  "authorization": {
"pluginClass": "...",
"pluginName": "ranger",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  }
}
{noformat}

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



--
This message was sent by Atlassian 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-7344) Use two thread pools, one for internal requests and one for external, to avoid distributed deadlock and decrease the number of threads that need to be created.

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-7344:


[~andyetitmoves] I like your suggestion and it is not very difficult to 
incorporate in my earlier proposal. The main change would be as follows,

- Instead of defining 'externalPort' property, we can define an 'endpoint' 
element which would allow specifying details such as
  --> port number
  --> request type (either a URL suffix of the REST API or a wildcard e.g. '*' 
for all requests)
  --> Anything else (?)
- We would publish the information about all configured pools as part of the 
ZNODE representing the given Solr server (under /live_nodes ZNODE)
- We would change solrj to use the correct endpoint based on the request_type 
(may be a URL suffix?). If no endpoint is available, we can fallback on 
base_url value (i.e. the current behavior) to maintain backward compatibility.

Just out of curiosity, can you please explain why someone would *not* want to 
define separate thread pools for internal and external requests? Also do you 
think if there would be use-cases which would require separate endpoints per 
request type?   

> Use two thread pools, one for internal requests and one for external, to 
> avoid distributed deadlock and decrease the number of threads that need to be 
> created.
> ---
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>




--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-7275 at 4/14/15 5:55 PM:
-

+1 to a single /security.json file.
I propose the following, to fold in both SOLR-7274 and SOLR-7275 (this issue) 
zk configs. This would need support for nested objects in ZkStateReader. The 
"configs" could be passed in into the plugins' init() and hence it will no 
longer be necessary to pass in a ZkClient/ZkController into the plugin's init().
 
{noformat}
{
  "authentication": {
"pluginClass": "org.blahblah",
"pluginName": "kerberos",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  },
  "authorization": {
"pluginClass": "...",
"pluginName": "ranger",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  }
}
{noformat}


was (Author: ichattopadhyaya):
+1 to a single /security.json file.
I propose the following, to fold in both SOLR-7274 and SOLR-7275 (this issue) 
zk configs. This would need support for nested objects in ZkStateReader. The 
"configs" could be passed in into the plugins' init() and hence it will no 
longer be necessary to pass in a ZkClient/ZkController into the plugin's init().
 
{quote}
{
  "authentication": {
"pluginClass": "org.blahblah",
"pluginName": "kerberos",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  },
  "authorization": {
"pluginClass": "...",
"pluginName": "ranger",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  }
}
{quote}

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-7275:


+1 to a single /security.json file.
I propose the following, to fold in both SOLR-7274 and SOLR-7275 (this issue) 
zk configs. This would need support for nested objects in ZkStateReader. The 
"configs" could be passed in into the plugins' init() and hence it will no 
longer be necessary to pass in a ZkClient/ZkController into the plugin's init().
 
{quote}
{
  "authentication": {
"pluginClass": "org.blahblah",
"pluginName": "kerberos",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  },
  "authorization": {
"pluginClass": "...",
"pluginName": "ranger",
"configs": {
  "prop1": "val1",
  "prop2": "val2"
}
  }
}
{quote}

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



--
This message was sent by Atlassian 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-6382) Don't allow position = Integer.MAX_VALUE going forward

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6382:
-

+1

Maybe the static index test+index should sit in backwards/ so that it can go 
away in a future version when those indexes cannot be read?

> Don't allow position = Integer.MAX_VALUE going forward
> --
>
> Key: LUCENE-6382
> URL: https://issues.apache.org/jira/browse/LUCENE-6382
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6382.patch, LUCENE-6382.patch, LUCENE-6382.patch
>
>
> Spinoff from LUCENE-6308, where Integer.MAX_VALUE position is now used as a 
> sentinel during position iteration to indicate that there are no more 
> positions.
> Where IW now detects int overflow of position, it should now also detect == 
> Integer.MAX_VALUE.
> And CI should note corruption if a segment's version is >= 5.2 and has 
> Integer.MAX_VALUE position.



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

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

[ANNOUNCE] Apache Solr 5.1.0 released

[Timothy Potter]

14 April 2015 - The Lucene PMC is pleased to announce the release of
Apache Solr 5.1.0.

Solr 5.1.0 is available for immediate download at:
http://www.apache.org/dyn/closer.cgi/lucene/solr/5.1.0

Solr 5.1.0 includes 39 new features, 40 bug fixes, and 36 optimizations
/ other changes from over 60 unique contributors.

For detailed information about what is included in 5.1.0 release,
please see: http://lucene.apache.org/solr/5_1_0/changes/Changes.html

Enjoy!

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

[ANNOUNCE] Apache Lucene 5.1.0 released

[Timothy Potter]

14 April 2015 - The Lucene PMC is pleased to announce the release of
Apache Lucene 5.1.0

The release is available for immediate download at:
http://www.apache.org/dyn/closer.cgi/lucene/java/5.1.0

Lucene 5.1.0 includes 9 new features, 10 bug fixes, and 24 optimizations / other
changes from 18 unique contributors.

For detailed information about what is included in 5.1.0 release,
please see: http://lucene.apache.org/core/5_1_0/changes/Changes.html

Enjoy!

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

[jira] [Commented] (LUCENE-6419) Add AssertingQuery / two-phase iteration to AssertingScorer

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6419:
-

+1


> Add AssertingQuery / two-phase iteration to AssertingScorer
> ---
>
> Key: LUCENE-6419
> URL: https://issues.apache.org/jira/browse/LUCENE-6419
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Attachments: LUCENE-6419.patch
>
>
> I am working on a similar issue with Spans (LUCENE-6411).
> AssertingScorer is currently only used as a top-level wrapper, and it doesnt 
> support asserting for asTwoPhaseIterator (wouldn't help at the moment, the 
> way it is currently used).
> Today some good testing of this is done, but only when 
> RandomApproximationQuery is explicitly used.
> I think we should add AssertingQuery that can wrap a query with asserts and 
> we can then have checks everywhere in a complicated tree?



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

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

[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: (was: LUCENE-6196-additions.patch)

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, 
> ShapeImpl.java, geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



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

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

[jira] [Updated] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6196:

Attachment: LUCENE-6196-additions.patch

New version of additions with problem fixed

> Include geo3d package, along with Lucene integration to make it useful
> --
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/spatial
>Reporter: Karl Wright
>Assignee: David Smiley
> Attachments: LUCENE-6196-additions.patch, 
> LUCENE-6196-additions.patch, LUCENE-6196_Geo3d.patch, ShapeImpl.java, 
> geo3d-tests.zip, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene.  This can be 
> used in conjunction with Lucene search, both for generating geohashes (via 
> spatial4j) for complex geographic shapes, as well as limiting results 
> resulting from those queries to those results within the exact shape in 
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits 
> computation necessary to determine membership (once a shape has been 
> initialized, of course) to only multiplications and additions, which makes it 
> feasible to construct a performant BoostSource-based filter for geographic 
> shapes.  The math is somewhat more involved when generating geohashes, but is 
> still more than fast enough to do a good job.



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

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

[jira] [Updated] (LUCENE-6419) Add AssertingQuery / two-phase iteration to AssertingScorer

[Adrien Grand (JIRA)]

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

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

Here is a patch. It removes some unused code from AssertingScorer and adds 
assertions to two-phase iteration:
 - matches() must be called at most once
 - the approximation and the scorer must advance synchronously
 - score() and freq() cannot be called if matches() has not be called too

> Add AssertingQuery / two-phase iteration to AssertingScorer
> ---
>
> Key: LUCENE-6419
> URL: https://issues.apache.org/jira/browse/LUCENE-6419
> Project: Lucene - Core
>  Issue Type: Test
>Reporter: Robert Muir
> Attachments: LUCENE-6419.patch
>
>
> I am working on a similar issue with Spans (LUCENE-6411).
> AssertingScorer is currently only used as a top-level wrapper, and it doesnt 
> support asserting for asTwoPhaseIterator (wouldn't help at the moment, the 
> way it is currently used).
> Today some good testing of this is done, but only when 
> RandomApproximationQuery is explicitly used.
> I think we should add AssertingQuery that can wrap a query with asserts and 
> we can then have checks everywhere in a complicated tree?



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7275:
--

bq. whereas /simplesecurity.json could also be called anything else tomorrow 
and is used by a specific implementation. Doesn't make any sense to merge the 2 
and Solr be bothered about a specific plugin data.

I fail to see why it is not possible, If Solr already supports configuration of 
almost a dozen plugins with standardized formats , what is so special about an 
authorization plugin? This is akin to having {{solrconfig_myplugin.xml}} for 
every custom plugin I write

bq.Is there a reason not to? The client would need information about zk and 
also might need to read information about it, I don't see a reason why we 
should create a new zkclient there.

There should be no need for the client to read stuff from ZK. Take the analogy 
of our current set of plugins. Do they ever try to read solrconfig.xml/ or 
configoverlay.json?  


> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



--
This message was sent by Atlassian 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-7381) Improve Debuggability of SolrCloud using MDC

[ASF subversion and git services (JIRA)]

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

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

Commit 1673471 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1673471 ]

SOLR-7381: MDC keys are now exposed in thread names automatically so that a 
thread dump can give hints on what the thread was doing

> Improve Debuggability of SolrCloud using MDC
> 
>
> Key: SOLR-7381
> URL: https://issues.apache.org/jira/browse/SOLR-7381
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.2
>
> Attachments: SOLR-7381-forbid-threadpoolexecutor.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381-thread-names.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381.patch, SOLR-7381.patch
>
>
> SOLR-6673 added MDC based logging in a few places but we have a lot of ground 
> to cover.
> # Threads created via thread pool executors do not inherit MDC values and 
> those are some of the most interesting places to log MDC context.
> # We must expose node names (in tests) so that we can debug faster
> # We can expose more information via thread names so that a thread dump has 
> enough context to help debug problems in production
> This is critical to help debug SolrCloud failures.



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

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

[jira] [Commented] (SOLR-7381) Improve Debuggability of SolrCloud using MDC

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-7381: MDC keys are now exposed in thread names automatically so that a 
thread dump can give hints on what the thread was doing

> Improve Debuggability of SolrCloud using MDC
> 
>
> Key: SOLR-7381
> URL: https://issues.apache.org/jira/browse/SOLR-7381
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.2
>
> Attachments: SOLR-7381-forbid-threadpoolexecutor.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381-thread-names.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381.patch, SOLR-7381.patch
>
>
> SOLR-6673 added MDC based logging in a few places but we have a lot of ground 
> to cover.
> # Threads created via thread pool executors do not inherit MDC values and 
> those are some of the most interesting places to log MDC context.
> # We must expose node names (in tests) so that we can debug faster
> # We can expose more information via thread names so that a thread dump has 
> enough context to help debug problems in production
> This is critical to help debug SolrCloud failures.



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

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

[jira] [Updated] (SOLR-7381) Improve Debuggability of SolrCloud using MDC

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7381:

Attachment: SOLR-7381-thread-names.patch

# Renamed some MDC keys to be consistent with each other
# Added a null check in CoreAdminHandler for action (which can be null if a 
custom action is invoked)

All tests pass. I'll commit this shortly.

> Improve Debuggability of SolrCloud using MDC
> 
>
> Key: SOLR-7381
> URL: https://issues.apache.org/jira/browse/SOLR-7381
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: 5.2
>
> Attachments: SOLR-7381-forbid-threadpoolexecutor.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381-thread-names.patch, 
> SOLR-7381-thread-names.patch, SOLR-7381.patch, SOLR-7381.patch
>
>
> SOLR-6673 added MDC based logging in a few places but we have a lot of ground 
> to cover.
> # Threads created via thread pool executors do not inherit MDC values and 
> those are some of the most interesting places to log MDC context.
> # We must expose node names (in tests) so that we can debug faster
> # We can expose more information via thread names so that a thread dump has 
> enough context to help debug problems in production
> This is critical to help debug SolrCloud failures.



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

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

[jira] [Updated] (LUCENE-6382) Don't allow position = Integer.MAX_VALUE going forward

[Michael McCandless (JIRA)]

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

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

Another iteration, fixing the nocommits.  I think it's ready.

I added a test with a static (zip file) index containing a too-large position, 
and confirmed that both CheckIndex and IndexWriter (on merge) detect it.

> Don't allow position = Integer.MAX_VALUE going forward
> --
>
> Key: LUCENE-6382
> URL: https://issues.apache.org/jira/browse/LUCENE-6382
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6382.patch, LUCENE-6382.patch, LUCENE-6382.patch
>
>
> Spinoff from LUCENE-6308, where Integer.MAX_VALUE position is now used as a 
> sentinel during position iteration to indicate that there are no more 
> positions.
> Where IW now detects int overflow of position, it should now also detect == 
> Integer.MAX_VALUE.
> And CI should note corruption if a segment's version is >= 5.2 and has 
> Integer.MAX_VALUE position.



--
This message was sent by Atlassian 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-6421) Add two-phase support to MultiPhraseQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6421:
--

+1 this looks much cleaner already

> Add two-phase support to MultiPhraseQuery
> -
>
> Key: LUCENE-6421
> URL: https://issues.apache.org/jira/browse/LUCENE-6421
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-6421.patch, LUCENE-6421_luceneutil.patch
>
>
> Two-phase support currently works for both sloppy and exact Scorers but it 
> does not work if you have multiple terms at the same position 
> (MultiPhraseQuery).
> This is because UnionPostingsEnum.nextDoc() aggressively reads and merges all 
> the positions. Even making this initialization lazy might just be enough?



--
This message was sent by Atlassian 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-7349) Cleanup or fix cloud-dev scripts

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7349:


I feel like you are re-iterating my point about why we should change things, 
while arguing that nothing needs changed -- if they are not intended for 
release, then why are they included in the release artifacts for end users?

> Cleanup or fix cloud-dev scripts
> 
>
> Key: SOLR-7349
> URL: https://issues.apache.org/jira/browse/SOLR-7349
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Reporter: Ramkumar Aiyengar
>Assignee: Ramkumar Aiyengar
>Priority: Minor
> Fix For: 5.2
>
> Attachments: SOLR-7349.patch
>
>
> With Jetty 9, cloud-dev scripts no longer work in trunk, we need to either 
> clean up or fix them.



--
This message was sent by Atlassian 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-7389) Expose znode version in clusterstatus API

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-7389:
---

 Summary: Expose znode version in clusterstatus API
 Key: SOLR-7389
 URL: https://issues.apache.org/jira/browse/SOLR-7389
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: Trunk, 5.2


We should expose the znode version of the cluster state for each collection 
that is returned by the clusterstatus API.

Apart from giving an idea about when the clusterstatus was executed, this 
information can be used by non-java clients to use the same _stateVer_ 
mechanism that SolrJ currently uses for routing requests without watching all 
cluster states.



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7275:


Thanks for looking at this Shalin.

bq. please create a different linked issue for a default/basic implementation.
Sure, that makes sense. I'll split it and create a new sub-issue.

bq. We need to define the contract between this new plugin type and Solr better.
I did try to answer most of those questions in the write up above but I'm happy 
to explain that again.

* This framework is a cluster level configuration (and hence the need to 
specify and set up the implementation before starting a node). 
* It gets created in the init for SDF. 
* The configuration goes into /security.json (implementation to use) and plugin 
details go into plugin-specific file/mechanism e.g. you could write your own 
plugin that has hard-coded list for IPs or usernames or combination etc.
* You can only have 1 such plugin used by a cluster at any given point (there's 
no check for that and the node would end up using the implementation defined in 
/security.json when it comes up.
* As this happens at CoreContainer level, I didn't add anything to change the 
implementation type for plugin but I'm working on configuration changes. The 
change would need to be handled by the plugin writer e.g. in case of the OTB 
plugin, which depends on access rules stored in zk, it needs to watch that file 
for changes and update the blacklist accordingly. For cases involving 3rd party 
security mechanisms e.g. Apache Ranger/Sentry, the config changes would be 
handled by those plugins. When a request comes in after the access rules are 
updated, the plugin should be able to use the new rules from Ranger, without 
any need to update anything in Solr.
* I'm moving this to be initialized and kept in the corecontainer, and also 
adding a shutdown hook for the plugins. The hook would get invoked during the 
corecontainer shutdown.

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



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

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

[jira] [Updated] (LUCENE-6373) Complete two phase doc id iteration support for Spans

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6373:

Attachment: LUCENE-6373.patch

Paul's patch just with the above changes to fix the test failure.

I will look at benchmarking, API changes, and beasting tests to move this 
forward. Thanks Paul!

> Complete two phase doc id iteration support for Spans
> -
>
> Key: LUCENE-6373
> URL: https://issues.apache.org/jira/browse/LUCENE-6373
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
> Attachments: LUCENE-6373-SpanOr.patch, LUCENE-6373.patch, 
> LUCENE-6737-SpanOr-oneTestFails.patch
>
>
> Spin off from LUCENE-6308, see comments there from about 23 March 2015.



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

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

[jira] [Commented] (LUCENE-6373) Complete two phase doc id iteration support for Spans

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6373:
-

OK i found the bug. sneaky one. in DISIWrapper this is my fix:
{code}
  public int lastApproxMatchDoc = -2; // last doc of approximation that did 
match
  public int lastApproxNonMatchDoc = -2; // last doc of approximation that did 
not match
{code}

Previously only one of these was initialized, the other was initialized to 
zero. So this could cause problems for docid 0.

> Complete two phase doc id iteration support for Spans
> -
>
> Key: LUCENE-6373
> URL: https://issues.apache.org/jira/browse/LUCENE-6373
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
> Attachments: LUCENE-6373-SpanOr.patch, 
> LUCENE-6737-SpanOr-oneTestFails.patch
>
>
> Spin off from LUCENE-6308, see comments there from about 23 March 2015.



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

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

[jira] [Commented] (SOLR-7275) Pluggable authorization module in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-7275:


That was my thought at this point. I'd want to propagate ACL/principal 
information when we get to say, Document level security but as I'm not handling 
that right now, let's just move ahead and build that in when we get to it.

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



--
This message was sent by Atlassian 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-7275) Pluggable authorization module in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta edited comment on SOLR-7275 at 4/14/15 3:50 PM:
-

Thanks for looking at it Noble. 

bq. Do the initialization and other things of Authorization plugin in 
CoreContainer
Sure, I'll move it.

bq. why multiple json files? /security.json and /simplesecurity.json ?
They are used for 2 different reasons, the /security.json is the one used 
for/by Solr's framework whereas /simplesecurity.json could also be called 
anything else tomorrow and is used by a specific implementation. Doesn't make 
any sense to merge the 2 and Solr be bothered about a specific plugin data.

bq. Why should a component use SolrZkClient directly to read configuration?
Is there a reason not to? The client would need information about zk and also 
might need to read information about it, I don't see a reason why we should 
create a new zkclient there.


was (Author: anshumg):
bq. Do the initialization and other things of Authorization plugin in 
CoreContainer
Sure, I'll move it.

bq. why multiple json files? /security.json and /simplesecurity.json ?
They are used for 2 different reasons, the /security.json is the one used 
for/by Solr's framework whereas /simplesecurity.json could also be called 
anything else tomorrow and is used by a specific implementation. Doesn't make 
any sense to merge the 2 and Solr be bothered about a specific plugin data.

bq. Why should a component use SolrZkClient directly to read configuration?
Is there a reason not to? The client would need information about zk and also 
might need to read information about it, I don't see a reason why we should 
create a new zkclient there.

> Pluggable authorization module in Solr
> --
>
> Key: SOLR-7275
> URL: https://issues.apache.org/jira/browse/SOLR-7275
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Attachments: SOLR-7275.patch
>
>
> Solr needs an interface that makes it easy for different authorization 
> systems to be plugged into it. Here's what I plan on doing:
> Define an interface {{SolrAuthorizationPlugin}} with one single method 
> {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
> return an {{SolrAuthorizationResponse}} object. The object as of now would 
> only contain a single boolean value but in the future could contain more 
> information e.g. ACL for document filtering etc.
> The reason why we need a context object is so that the plugin doesn't need to 
> understand Solr's capabilities e.g. how to extract the name of the collection 
> or other information from the incoming request as there are multiple ways to 
> specify the target collection for a request. Similarly request type can be 
> specified by {{qt}} or {{/handler_name}}.
> Flow:
> Request -> SolrDispatchFilter -> isAuthorized(context) -> Process/Return.
> {code}
> public interface SolrAuthorizationPlugin {
>   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
> }
> {code}
> {code}
> public  class SolrRequestContext {
>   UserInfo; // Will contain user context from the authentication layer.
>   HTTPRequest request;
>   Enum OperationType; // Correlated with user roles.
>   String[] CollectionsAccessed;
>   String[] FieldsAccessed;
>   String Resource;
> }
> {code}
> {code}
> public class SolrAuthorizationResponse {
>   boolean authorized;
>   public boolean isAuthorized();
> }
> {code}
> User Roles: 
> * Admin
> * Collection Level:
>   * Query
>   * Update
>   * Admin
> Using this framework, an implementation could be written for specific 
> security systems e.g. Apache Ranger or Sentry. It would keep all the security 
> system specific code out of Solr.



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

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