[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 7 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25707 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (35.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.1.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1280.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.tgz...
   [smoker] 69.0 MB in 0.06 sec (1248.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.zip...
   [smoker] 79.3 MB in 0.06 sec (1244.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (290.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.1.0-src.tgz...
   [smoker] 50.2 MB in 0.04 sec (1175.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.tgz...
   [smoker] 141.7 MB in 0.12 sec (1178.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.zip...
   [smoker] 142.6 MB in 0.12 sec (1181.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]  
   [smoker] Started Solr server on port 8983 

[jira] [Closed] (SOLR-8457) DocumentObjectBinder should be able to work with highlight

[David Smiley (JIRA)]

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

David Smiley closed SOLR-8457.
--
Resolution: Duplicate

> DocumentObjectBinder should be able to work with highlight
> --
>
> Key: SOLR-8457
> URL: https://issues.apache.org/jira/browse/SOLR-8457
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.4
>Reporter: Alessandro Benedetti
>Priority: Trivial
>
> It is a common use case, when you have configured the highlighter in your 
> request handler to quickly get a pojo object containing the highlighted 
> content, instead of accessing the highlighting snippet map.
> it could be useful to have an option in the document binder to take a look 
> first to the highlighted snippets and then fallback to the normal field ( 
> usually the fallback is already in the highlighter component anyway) .
> In this way would be much simpler for a SolrJ user to get directly a java 
> pojo bean, with the fields already with the highlighted value.
> Without accessing both the pojo and the highlighting map, and make 
> intersection.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_131) - Build # 32 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/32/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([CD6940D631DE5E7C:74E896091D345AF6]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:14==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more




Build Log:
[...truncated 12116 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]  

[jira] [Commented] (SOLR-9560) Solr should check max open files and other ulimits and refuse to start if they are set too low

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9560:
-

Thanks Rohit. I think a better way to implement something like this would be to 
call a Java executable class which can do comparisons and print out warnings. 
It has two advantages:
# We don't need to do the implementation twice (once for bin/solr, again for 
bin/solr.cmd)
# There are certain things we can do in a standard way in Java such as finding 
free disk space
# Later that class can be used by a running Solr instance to expose violations 
via API -- perhaps the Metrics API is apt here.

Also I think you can get most of these interesting values via JMX but if not, 
it is easy to pass the values from the script to the java class.

> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low
> --
>
> Key: SOLR-9560
> URL: https://issues.apache.org/jira/browse/SOLR-9560
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>  Labels: newdev
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-9560.patch
>
>
> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low. Specifically:
> # max open files should be at least 32768
> # max memory size and virtual memory should both be unlimited



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-1494) Bind highlighting info using SolrJ's DocumentObjectBinder

[David Smiley (JIRA)]

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

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

Closing.  IMO this isn't a good use of the DocumentObjectBinder which I think 
should be deliberately limited to field value retrieval.  

Nevertheless it's plausible to imagine some a highlighting 
"DocumentTransformer" feature that would allow the existing DOB to support 
fl=highlight_fieldA:highlight(fieldA) which would be useful for various use 
cases and sometimes more convenient for folks.

> Bind highlighting info using SolrJ's DocumentObjectBinder
> -
>
> Key: SOLR-1494
> URL: https://issues.apache.org/jira/browse/SOLR-1494
> Project: Solr
>  Issue Type: New Feature
>  Components: clients - java
>Reporter: Avlesh Singh
>Priority: Minor
> Fix For: 6.0, 4.9
>
>
> The DocumentObjectBinder class should "bind" highlighting info in 
> QueryResponse, if specified by a end user. This can be achieved using an 
> annotated interface {{@Highlight}} as underneath -
> {code:java}
> class MyBean{
>   @Field
>   @Highlight
>   String name;
>   @Field ("solr_category_field_name")
>   List categories;
>   @Highlight ("solr_category_field_name")
>   List highlightedCategories
>   @Field
>   float score;
>   ...
> }
> {code}
> With this bean definition, if someone tries to fetch the response as 
> {{QueryResponse#getBeans(MyBean.class)}}, the beans will have highlighting 
> data populated into its corresponding fields.
> Original mail thread here - 
> http://www.lucidimagination.com/search/document/897f5a26e35bd27e/highlighting_bean_properties_using_documentobjectbinder_new_feature



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-6889) Highlight using multiple threads

[David Smiley (JIRA)]

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

David Smiley updated SOLR-6889:
---
Summary: Highlight using multiple threads  (was: debug, highlight with 
parallel streams)

I've done this before and it can make a big difference for some use-cases.  
Then I worked on the UnifiedHighlighter and I never got around to adding 
support for that since it was plenty fast as-is for the use-case I was focusing 
on.  I'd be interested to hear if threading the UH is worth doing from anyone 
who tries adding it. The UH allows you to do things like put offsets in 
postings to speed up highlighting a ton, and so adding threading became super 
low priority.

> Highlight using multiple threads
> 
>
> Key: SOLR-6889
> URL: https://issues.apache.org/jira/browse/SOLR-6889
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Shinichiro Abe
> Attachments: SOLR-6889.patch
>
>
> I think we could gain search performance a little bit using 
> Stream.parallel().forEach()~ which has processors awareness via f/j framework 
> under the hood.
> Especially it would affect docList's for-loop processes, e.g. debugging, 
> highlighting.
> It seems to me that this improvement is effective for many CPUs environment.
> My test condition:
> 1. Core i5(2core 4thead), standalone Solr.
> 2. q=日本=true=true, other parameters are 
> [here|https://github.com/anond2/simplesearch/blob/master/conf/solrconfig.xml#L836].
> 3. 7171 hits / 12000 docs(taken from ja.wikipedia dump)
> 4. compared to trunk, parallel streams are faster a little.
> My query execution results(QTime):
> {noformat}
> == rows=10 ==
> trunk  patch 
> 1st 236146
> 2nd 179100
> 3rd 79 72
> 4th 75 53
> 5th 91 80
> == rows=50 ==
> trunk  patch 
> 1st 485325
> 2nd 225243
> 3rd 199151
> 4th 168127
> 5th 149118
> == rows=100 ==
> trunk  patch 
> 1st 948607
> 2nd 472390
> 3rd 237201
> 4th 256200
> 5th 224178
> == rows=500 ==
> trunk  patch 
> 1st 3248   2826
> 2nd 1545   1067
> 3rd 1563   801
> 4th 1551   816
> 5th 1452   777
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8729) Querying using a standard query parser on a copied field and highlighting hangs indefinitely

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-8729:


Seems doubtful this is a Solr bug since people do this all the time. Can you 
show the stack trace?  Solr even has this in it's UI. Also share the full query 
(set of params; even full URL perhaps) that hangs.

> Querying using a standard query parser on a copied field and highlighting 
> hangs indefinitely 
> -
>
> Key: SOLR-8729
> URL: https://issues.apache.org/jira/browse/SOLR-8729
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.4.1
> Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR 
> clouds servers
>Reporter: Jean-Renaud Margelidon
>
> On SOLR cloud, I've created a new collection using the 
> sample_techproducts_configs config (2 shards, 2 replicas)
> On that collection, I've crated a single document containing an ID (value 1) 
> and a content field (containing some text).
> When I make a query, using the dismax parser (qf=text) and activating the 
> highlighting, defining the field list to content (hl.fl=content), the result 
> is good.
> Doing the same query with the standard query parser hangs indefinitely 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-6889) Highlight using multiple threads

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-6889:


Oh, and by sharding your data more you get some amount of threading 
automatically.  So this also lowers the usefulness of adding threading.

> Highlight using multiple threads
> 
>
> Key: SOLR-6889
> URL: https://issues.apache.org/jira/browse/SOLR-6889
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Shinichiro Abe
> Attachments: SOLR-6889.patch
>
>
> I think we could gain search performance a little bit using 
> Stream.parallel().forEach()~ which has processors awareness via f/j framework 
> under the hood.
> Especially it would affect docList's for-loop processes, e.g. debugging, 
> highlighting.
> It seems to me that this improvement is effective for many CPUs environment.
> My test condition:
> 1. Core i5(2core 4thead), standalone Solr.
> 2. q=日本=true=true, other parameters are 
> [here|https://github.com/anond2/simplesearch/blob/master/conf/solrconfig.xml#L836].
> 3. 7171 hits / 12000 docs(taken from ja.wikipedia dump)
> 4. compared to trunk, parallel streams are faster a little.
> My query execution results(QTime):
> {noformat}
> == rows=10 ==
> trunk  patch 
> 1st 236146
> 2nd 179100
> 3rd 79 72
> 4th 75 53
> 5th 91 80
> == rows=50 ==
> trunk  patch 
> 1st 485325
> 2nd 225243
> 3rd 199151
> 4th 168127
> 5th 149118
> == rows=100 ==
> trunk  patch 
> 1st 948607
> 2nd 472390
> 3rd 237201
> 4th 256200
> 5th 224178
> == rows=500 ==
> trunk  patch 
> 1st 3248   2826
> 2nd 1545   1067
> 3rd 1563   801
> 4th 1551   816
> 5th 1452   777
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_131) - Build # 6737 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6737/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseParallelGC

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

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

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard1_replica_n2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard1_replica_n2\data

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard1_replica_n2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard1_replica_n2

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2\data

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2\collection1_shard2_replica_n2

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node2

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node1\collection1_shard1_replica_n1\data\tlog\tlog.001:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_E2BF3D04A32F2305-001\tempDir-001\node1\collection1_shard1_replica_n1\data\tlog\tlog.001:
 The process cannot access the file because it is being used by another 
process. 

[jira] [Updated] (SOLR-10109) SoftAutoCommitTest is too fragile.

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10109:

Attachment: SOLR-10109.testSoftAndHardCommitMaxTimeRapidAdds.patch

bq. I'll experiment with this idea.

As written, I had the valid assertions mixed up in that comment -- but I think 
i've got them correct in this version of the patch.

(still hammering on it with randomized sleep delays, but so far so good)

[~markrmil...@gmail.com] - what do you think?



> SoftAutoCommitTest is too fragile.
> --
>
> Key: SOLR-10109
> URL: https://issues.apache.org/jira/browse/SOLR-10109
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SoftAutoCommitTest.2017-02-25.2938.log.txt, 
> SoftAutoCommitTest.2017-05-02.3983.log.txt, 
> SOLR-10109.testSoftAndHardCommitMaxTimeRapidAdds.patch, 
> SOLR-10109.testSoftAndHardCommitMaxTimeRapidAdds.patch
>
>
> In my beast test runs it has failed 7% of the time, then 3% of the time, then 
> when I started using hardware with 8 cores instead of 16, 40% of the time 
> (unless something else also shifted). That gives it a test rating of 'screwy'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 8 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/8/

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([34B6BEF3334F408B:56DB40B2FCC120B5]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12767 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11043:
-
Attachment: SOLR-11043.patch

Here is a patch with some more tests. The random test fails for some seeds with 
point fields. I suspect it may be a bug with point fields. Will look into that

> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11043.patch, SOLR-11043.patch
>
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "dv"),
> 18:String.format(countAssertion, field)
> 19:);
> 20:  }
> {code}
> From {{schema.xml}}:
> {code:xml}
>docValues="${solr.tests.numeric.dv}" precisionStep="0" omitNorms="true" 
> positionIncrementGap="0"/>
>docValues="true" multiValued="false"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11041) MoveReplicaCmd do not specify ulog dir in case of HDFS

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-11041:

Attachment: SOLR-11041.patch

A patch for this ticket, will commit soon.

> MoveReplicaCmd do not specify ulog dir in case of HDFS
> --
>
> Key: SOLR-11041
> URL: https://issues.apache.org/jira/browse/SOLR-11041
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
> Attachments: SOLR-11041.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10109) SoftAutoCommitTest is too fragile.

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10109:

Attachment: SOLR-10109.testSoftAndHardCommitMaxTimeRapidAdds.patch


bq. ... I'll start working on a patch (and include some nocommit random sleeps 
to help test for the possibility of this lag) ...

I'm attaching what I wrote up, but even as I was working on it I started having 
doubts which were verified the first time i ran it with the random sleeps in 
place: The {{minExpectedFoo}} calculations are fundementally assuming that the 
"lag" is even between the updates.  If we imagine a machine where the first 4 
docs are added w/o any lag, but then the CPU stalls the main test thread for ~4 
* the autoCommit value before adding the final document, the math i suggested 
will assumethere must be a min of 3 commits, but in reality it makes sense that 
only 2 commits would have happened.

I think the "correct" assertions we should be able to make are...

* there _must_ be a minimum of 1 each hard/soft commit
** the (non-null) timestamps of these commits reported by the monitor must be 
less then the "after add" time (recorded by the test thread) of the first doc + 
the autoCommit value + some fudge
* there _may_ be additional commits of each type...
** the upper limit on the # of additional commits allowed can be determined by 
dividing the total add duration (recorded by the test thread) by the autoCommit 
values for each type
** if we poll a monitor for that type of commit and find a _non-null_ timestamp:
*** the timestamp must be less then the _last_ timestamp (from the same 
monitor) + the autoCommit value + some fudge
** if we poll a monitor for that type of commit and find a _null_ timestamp:
*** there better not be any more commits of that type later if we keep polling

This is sort of along the lines of what the existing (in master) loop logic for 
{{i <= expectedSoft}} does -- in terms of treating {{i == 1}} as required -- 
except that:
* it only asserts that all commit timestamps are within the expected range of 
the last doc added -- not the previous commit
* the existing {{i <= expectedHard}} loop doesn't have similar logic / 
accounting.


I'll experiment with this idea.


> SoftAutoCommitTest is too fragile.
> --
>
> Key: SOLR-10109
> URL: https://issues.apache.org/jira/browse/SOLR-10109
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SoftAutoCommitTest.2017-02-25.2938.log.txt, 
> SoftAutoCommitTest.2017-05-02.3983.log.txt, 
> SOLR-10109.testSoftAndHardCommitMaxTimeRapidAdds.patch
>
>
> In my beast test runs it has failed 7% of the time, then 3% of the time, then 
> when I started using hardware with 8 cores instead of 16, 40% of the time 
> (unless something else also shifted). That gives it a test rating of 'screwy'.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11048) Randomize PointFields in schema-add-schema-fields-update-processor.xml in core/src/test-files/solr/collection1

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11048:

Summary: Randomize PointFields in 
schema-add-schema-fields-update-processor.xml in 
core/src/test-files/solr/collection1  (was: Randomize PointFields in all server 
tests unless explicit reason not to)

> Randomize PointFields in schema-add-schema-fields-update-processor.xml in 
> core/src/test-files/solr/collection1
> --
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11048) Randomize PointFields in all server tests unless explicit reason not to

[Anshum Gupta (JIRA)]

Anshum Gupta created SOLR-11048:
---

 Summary: Randomize PointFields in all server tests unless explicit 
reason not to
 Key: SOLR-11048
 URL: https://issues.apache.org/jira/browse/SOLR-11048
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 7.0






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10796:
---

A reproducing branch_7_0 failure, from 
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-7.0/22/] - I'm investigating:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPointFields 
-Dtests.method=testLongPointFieldRangeFacet -Dtests.seed=A3AB56679F64D76 
-Dtests.slow=true -Dtests.locale=id-ID -Dtests.timezone=Europe/Paris 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.09s J6  | TestPointFields.testLongPointFieldRangeFacet <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A3AB56679F64D76:EB5AA9B848F84E66]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testLongPointFieldRangeFacet(TestPointFields.java:1217)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='number_p_l_dv']/lst[@name='counts']/int[@name='-894046239074522863'][.='4']
   [junit4]>xml response was: 
   [junit4]> 
   [junit4]> 0001586386398396807928158638639839680792815726674072808980481838816421469093292083881642146909329201572667407282995200234591901051644197934591901051644197915726674072829952013-6612528902354323499-661252890235432349915726674072829952024-4613459503085754991-461345950308575499115726674072840437765-4144127791340196059-414412779134019605915726674072840437776-1192431832086875895-119243183208687589515726674072840437787-6179315529630012256-617931552963001225615726674072840437798-7082186541584826723-708218654158482672315726674072850923529181564487047671614318156448704767161431572667407285092353513013094070151255151930-70821865415848267238388164214690932927
   [junit4]> 
   [junit4]>request 
was:facet.range=number_p_l_dv=*:*=3094070151255151930=true=xml=-7082186541584826723=8388164214690932920
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
{noformat}

> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 29 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/29/

1 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([69535053CADF9011:75522DDEBF7AEE82]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:497)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12759 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestTlogReplica
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/build/solr-core/test/J0/temp/solr.cloud.TestTlogReplica_69535053CADF9011-001/init-core-data-001
   [junit4]   2> 

[jira] [Created] (LUCENE-7904) Refactoring of SegmentInfos

[JIRA]

João Paulo Lemes Machado created LUCENE-7904:


 Summary: Refactoring of SegmentInfos
 Key: LUCENE-7904
 URL: https://issues.apache.org/jira/browse/LUCENE-7904
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: João Paulo Lemes Machado


Hello everyone.
I was analyzing the modularization of some classes, and I identified that the 
class SegmentInfos has an opportunity for cohesion improvement. 
The class IndexWriter was in the same situation and the problem was solved as 
follows: The IndexWriterConfig class was created, and several get() and set() 
methods that were used only to configure the class parameters were moved from 
IndexWriter to IndexWriterConfig. 
The new class was then accessed through an instance variable in IndexWriter. 
This strategy has cleaned and improved IndexWriter cohesion.
With this in mind, I would recommend creating a new class: SegmentInfosConfig , 
and moving the following methods:
getLastCommitGeneration
getLastCommitSegmentsFileName
getSegmentsFileName
getNextPendingGeneration
getId
getVersion
getGeneration
getLastGeneration
setInfoStream
getInfoStream
setNextWriteGeneration
setUserData
setVersion
getCommitLuceneVersion
getMinSegmentLuceneVersion
from the SegmentInfos.
Those parameters accessed by an instance variable in the SegmentInfos.
Moreover, the orthogonality is the design would be enhanced.

What do you think about that?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11048) Randomize PointFields in all server tests unless explicit reason not to

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11048:

Reporter: Anshum Gupta  (was: Hoss Man)

> Randomize PointFields in all server tests unless explicit reason not to
> ---
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_131) - Build # 2 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/2/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([9801A6A77F77C8A0:2F5DB45E1ED549C]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:270)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more




Build Log:
[...truncated 11416 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]   2> Creating dataDir: 

[jira] [Assigned] (SOLR-11048) Randomize PointFields in all server tests unless explicit reason not to

[Anshum Gupta (JIRA)]

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

Anshum Gupta reassigned SOLR-11048:
---

Assignee: Anshum Gupta  (was: Hoss Man)

> Randomize PointFields in all server tests unless explicit reason not to
> ---
>
> Key: SOLR-11048
> URL: https://issues.apache.org/jira/browse/SOLR-11048
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Anshum Gupta
> Fix For: 7.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.0-Windows (64bit/jdk-9-ea+173) - Build # 2 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/2/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1E5A232E9FEDE19D:B91E9B8AF256F224]:0)
at 
org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:201)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:87)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.SolrExceptionTest

Error Message:
The test or suite printed 9250 bytes to 

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10760:
-

there appears to be some consensus on the dev list that SOLR-10807 should be 
considered a blocker for this issue, so linking it as such.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11043:
--
Fix Version/s: 7.0

> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11043.patch
>
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "dv"),
> 18:String.format(countAssertion, field)
> 19:);
> 20:  }
> {code}
> From {{schema.xml}}:
> {code:xml}
>docValues="${solr.tests.numeric.dv}" precisionStep="0" omitNorms="true" 
> positionIncrementGap="0"/>
>docValues="true" multiValued="false"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11043:
--
Priority: Blocker  (was: Major)

> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11043.patch
>
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "dv"),
> 18:String.format(countAssertion, field)
> 19:);
> 20:  }
> {code}
> From {{schema.xml}}:
> {code:xml}
>docValues="${solr.tests.numeric.dv}" precisionStep="0" omitNorms="true" 
> positionIncrementGap="0"/>
>docValues="true" multiValued="false"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 7.0 Release Update

[Chris Hostetter]

: So, my overall point is that if A) we agree that we want to deprecate
: Trie* numeric fields, and B) we want to hold up the 7.0 release until
: that's done, it's more than just updating the example schemas if we
: want to ensure a quality app for users. We still need to fix the tests
: and also fix bugs that are going to be really painful for users. And
: to get all that done soon, we definitely need some more volunteers.

I've beefed up the description of SOLR-10807 with tips on how people can 
help out...

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



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

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

[jira] [Updated] (SOLR-10807) Randomize PointFields in all tests unless explicit reason not to

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10807:

Description: 
We need to seriously beef up our testing of PointFields to figure out what Solr 
features don't currently work with PointFields.

The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start 
-- but only a handful of schema files leverage it.



Allthough a jira/SOLR-10807 branch was originally created with this goal, it 
was ultimately just used for initial experimentation, and has been abandoned.  
The "meat" of the work needed to improve _how_ we randomize in Point fields was 
done in SOLR-10864, and other sub-tasks of this issue have been / are being 
used to track rolling out this randomization to more and more test schema files 
and validating the affected tests.

This effort is now highly parallelizable  -- so here are some rough 
guidelines/suggestions for folks interested in contributing to this effort:
* create a subtask identifying the name (or glob) of the test-files schema file 
you plan to tackle before starting (so multiple people don't duplicate work on 
the same tests
* run the following one liner (assumming bash/perl) to change all Trie field 
types in the schema(s) to use the new randomized system vars...{code}
find -name \*your-schema-glob-or-name\* -type f | xargs perl -i -ple 
's/class="solr.TrieIntField"/class="solr.TrieIntegerField"/g; 
s/class="solr.Trie(.*)Field"/class="\${solr.tests.$1FieldType}"/g; unless 
(/docValues/) { s/(class="\${solr.tests..*FieldType}")/$1 
docValues="\${solr.tests.numeric.dv}"/g; }'
{code}
* identify the affected tests
** grep for the schema file names in all test classes to start building the list
** recursively check each test class in the list for subclasses
* hammer on all affected tests with many diff seeds
** NOTE: you can force the points vs trie choice by specifying 
{{-Dsolr.tests.use.numeric.points=true}} vs 
{{-Dsolr.tests.use.numeric.points=false}}
*** folks with beefy machines may find it handy to use 2 git working dirs to 
hammer on diff seeds with a diff hardcoded values of that sysprop
* If you encounter any test failures...
** figure out the root  cause
** file a new "Bug" jira, link it as related to SOLR-10807 & SOLR-8396
*** NOTE: first double check there isn't already a bug on point linked to from 
one of those places
** use {{@SuppressPointFields}} (citing the new jira) if necessary for any 
functionality that absolutely will not work with point fields
** use something like this in tests where functionality requires docValues in 
order to work properly with points (although in practice, the comment should 
always cite the relevant jira)
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/handler/component/DistributedFacetPivotLargeTest.java;h=eb6f54d5db42ba6f24d88d9bbda78bfab198a94e;hp=0c5e128ba8a5cf1a8b488b17ddf9ce2030e0f22d;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037
** use something like this if a small subset of a test is known to not work 
with points...
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/search/function/TestFunctionQuery.java;h=4cee94b86bb41dcc451f72c81c21f6ed911b9e95;hp=f19e4b08530c9650515c64ef7d589f21db939ccf;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037
** use something like this if the test has a need/reason to care/assert what 
the underying FieldType is of a numeric field...
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/schema/IndexSchemaTest.java;h=4719f0408fbc39e8b806197c2eb0b26bf533b0c7;hp=7790859fcde43fb9ecedaed8a146aef3cac1ae10;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037
* when committing changes, the commit msg should cite both the original 
sub-task jira#, as well as any bug jira#s that needed special 
annotation/handling/assumptions - so that in the future people working on 
fixing those bugs have easy to find GIT SHAs identifying when/where tests are 
currently hacked to avoid the bugs.

  was:
We need to seriously beef up our testing of PointFields to figure out what Solr 
features don't currently work with PointFields.

The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start 
-- but only a handful of schema files leverage it.



Allthough a jira/SOLR-10807 branch was originally created with this goal, it 
was ultimately just used for initial experimentation, and has been abandoned.  
The "meat" of the work needed to improve _how_ we randomize in Point fields was 
done in SOLR-10864, and other sub-tasks of this issue have been / are being 
used to track rolling out this randomization to more and more test schema files 
and validating the affected tests.

This effort is now highly parallelizable  -- so here are some rough 

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 2 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/2/

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testDoublePointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([FDC2A906B090758:20C6E4C69FA41BFC]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2200)
at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[jira] [Updated] (SOLR-10807) Randomize PointFields in all tests unless explicit reason not to

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10807:

Description: 
We need to seriously beef up our testing of PointFields to figure out what Solr 
features don't currently work with PointFields.

The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start 
-- but only a handful of schema files leverage it.



Allthough a jira/SOLR-10807 branch was originally created with this goal, it 
was ultimately just used for initial experimentation, and has been abandoned.  
The "meat" of the work needed to improve _how_ we randomize in Point fields was 
done in SOLR-10864, and other sub-tasks of this issue have been / are being 
used to track rolling out this randomization to more and more test schema files 
and validating the affected tests.

This effort is now highly parallelizable  -- so here are some rough 
guidelines/suggestions for folks interested in contributing to this effort:
* create a subtask identifying the name (or glob) of the test-files schema file 
you plan to tackle before starting (so multiple people don't duplicate work on 
the same tests
* run the following one liner (assumming bash/perl) to change all Trie field 
types in the schema(s) to use the new randomized system vars...{code}
find -name \*your-schema-glob-or-name\* -type f | xargs perl -i -ple 
's/class="solr.TrieIntField"/class="solr.TrieIntegerField"/g; 
s/class="solr.Trie(.*)Field"/class="\${solr.tests.$1FieldType}"/g; unless 
(/docValues/) { s/(class="\${solr.tests..*FieldType}")/$1 
docValues="\${solr.tests.numeric.dv}"/g; }'
{code}
* identify the affected tests
** grep for the schema file names in all test classes to start building the list
** recursively check each test class in the list for subclasses
* hammer on all affected tests with many diff seeds
** NOTE: you can force the points vs trie choice by specifying 
{{-Dsolr.tests.use.numeric.points=true}} vs 
{{-Dsolr.tests.use.numeric.points=false}}
*** folks with beefy machines may find it handy to use 2 git working dirs to 
hammer on diff seeds with a diff hardcoded values of that sysprop
* If you encounter any test failures...
** figure out the root  cause
** file a new "Bug" jira, link it as related to SOLR-10807 & SOLR-8396
** use {{@SuppressPointFields}} (citing the new jira) if necessary for any 
functionality that absolutely will not work with point fields
** use something like this in tests where functionality requires docValues in 
order to work properly with points (although in practice, the comment should 
always cite the relevant jira)
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/handler/component/DistributedFacetPivotLargeTest.java;h=eb6f54d5db42ba6f24d88d9bbda78bfab198a94e;hp=0c5e128ba8a5cf1a8b488b17ddf9ce2030e0f22d;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037
** use something like this if a small subset of a test is known to not work 
with points...
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/search/function/TestFunctionQuery.java;h=4cee94b86bb41dcc451f72c81c21f6ed911b9e95;hp=f19e4b08530c9650515c64ef7d589f21db939ccf;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037
** use something like this if the test has a need/reason to care/assert what 
the underying FieldType is of a numeric field...
*** 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=blobdiff;f=solr/core/src/test/org/apache/solr/schema/IndexSchemaTest.java;h=4719f0408fbc39e8b806197c2eb0b26bf533b0c7;hp=7790859fcde43fb9ecedaed8a146aef3cac1ae10;hb=38f29b2;hpb=a948e1714609ef662184c71eedb219caf44fc037

  was:
We need to seriously beef up our testing of PointFields to figure out what Solr 
features don't currently work with PointFields.

The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start 
-- but only a handful of schema files leverage it.




>  Randomize PointFields in all tests unless explicit reason not to
> -
>
> Key: SOLR-10807
> URL: https://issues.apache.org/jira/browse/SOLR-10807
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: 
> core.test.log.fde06f34b7f9d0916a134b3efaa8780892ff8e39.txt, core.test.log.txt
>
>
> We need to seriously beef up our testing of PointFields to figure out what 
> Solr features don't currently work with PointFields.
> The existing Trie/Point randomization logic in SolrTestCaseJ4 is a good start 
> -- but only a handful of schema files leverage it.
> 
> Allthough a jira/SOLR-10807 branch was originally created with 

[jira] [Commented] (SOLR-9560) Solr should check max open files and other ulimits and refuse to start if they are set too low

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-9560:


{code} Current Settings[OK]: Open... {code}

I don't think we should log that when settings are acceptable. Also, for sake 
of consistency with other parts of the script, lets print "WARNING" instead of 
"WARN".

> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low
> --
>
> Key: SOLR-9560
> URL: https://issues.apache.org/jira/browse/SOLR-9560
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>  Labels: newdev
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-9560.patch
>
>
> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low. Specifically:
> # max open files should be at least 32768
> # max memory size and virtual memory should both be unlimited



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-9560) Solr should check max open files and other ulimits and refuse to start if they are set too low

[Rohit (JIRA)]

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

Rohit updated SOLR-9560:

Attachment: SOLR-9560.patch

Adding patch with following features:

OS: Linux
Basic checks for
1. max open file (-n)
2. Max memory size and virtual memory size

It logs a warning in case the parameters are less than the recommended values:

_{color:#707070}WARN: Current Settings[User=Username]: Open File(-n)=10240, max 
memory size(-m)=unlimited, virtual memory(-v)=unlimited
WARN: Please ensure max open file(-n) is more than 32768 and [max memory(-m), 
virtual memory(-v) are set to unlimited], refer ULIMIT man page or, Solr Ref 
Guide
{color}_

Please review and let me know for any suggestions.

> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low
> --
>
> Key: SOLR-9560
> URL: https://issues.apache.org/jira/browse/SOLR-9560
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shalin Shekhar Mangar
>  Labels: newdev
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-9560.patch
>
>
> Solr should check max open files and other ulimits and refuse to start if 
> they are set too low. Specifically:
> # max open files should be at least 32768
> # max memory size and virtual memory should both be unlimited



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10944:
--

Hi Joel,

Can you please review the patch, suggest any changes and commit to have it in 
next 7.x release.  This will be a simple fix but is very much required in 
simple to complex expressions involving Get expressions.

Thanks,
Susheel

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 7.0 Release Update

[Yonik Seeley]

On Tue, Jul 11, 2017 at 2:35 PM, Anshum Gupta  wrote:
> Thanks for wording it in a much better manner Cassandra.
>
> The 2 points from my discussion with Hoss/Steve yesterday, are just about
> that. Changing the examples is just a part of what’s needed to *confidently*
> deprecate the Trie/Legacy Numeric fields.
>
> I intend to start helping out with the test, but as you mentioned, the more
> of us contribute to it, the sooner we’d be in a spot to make the decision
> about (not) deprecating the fields in 7.0.

I'll be back home next week and can help out as well.

-Yonik

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 7 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/7/

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testLongPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([587BAE40E97ABC28:EF863895C22F484D]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2200)
at 
org.apache.solr.schema.TestPointFields.testLongPointStats(TestPointFields.java:1251)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide

[JIRA]

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

Jan Høydahl commented on SOLR-10595:


Note the rest of my sentence that you quoted from: "...which do not redirect to 
a particular version but stays on that URL"

If we redirect confluence to this redirect that in turn redirects to 6_6 then 
the PageRank of a page will not be permanently transferred to a stable URL in 
the new guide but to a moving target..

> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_131) - Build # 58 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/58/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testFloatPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([DF39E3F6EB4A4A1D:65339BD1535B88FF]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2200)
at 
org.apache.solr.schema.TestPointFields.testFloatPointStats(TestPointFields.java:989)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

Re: Build Error on Fedora 25

[Andi Vajda]

On Tue, 11 Jul 2017, Joshua Campbell wrote:


Yeah you have to do this on debian/ubuntu as well


I just now added a conditional 'm' suffix with using python 3 on linux

Andi..



On Mon, Jul 10, 2017 at 2:43 PM, Michael Alcorn  wrote:


Hi all,

When trying to follow the PyLucene installation instructions on Fedora 25,
I was getting the following error:

/opt/gcc-4.9.3/bin/g++ -pthread -shared
-L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
-Wl,-rpath=/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-I/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3/include/
build/temp.linux-x86_64-3.5/jcc3/sources/jcc.o
build/temp.linux-x86_64-3.5/jcc3/sources/JCCEnv.o
-L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib -lpython3.5m -o
build/lib.linux-x86_64-3.5/libjcc3.so
-L/usr/lib/jvm/java-1.8.0/jre/lib/amd64 -ljava
-L/usr/lib/jvm/java-1.8.0/jre/lib/amd64/server -ljvm
-Wl,-rpath=/usr/lib/jvm/java-1.8.0/jre/lib/amd64:/usr/lib/
jvm/java-1.8.0/jre/lib/amd64/server
-Wl,-S -lpython3.5
/usr/bin/ld: cannot find -lpython3.5

It looks like the compile command is assuming an incorrect name for the
Python 3 development library. The development libraries I have include:

libpython3.5m.so.1.0
libpython3.5m.so (linked to the above)
libpython3.so

Providing the expected name through a link, e.g.:

ln -s /path/to/.pyenv/versions/3.5.2/lib/libpython3.5m.so.1.0
/path/to/.pyenv/versions/3.5.2/lib/libpython3.5.so

fixed the issue. Everything works great after that. Thanks for the project!

-Michael





--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

Re: 7.0 Release Update

[Anshum Gupta]

Thanks for wording it in a much better manner Cassandra.

The 2 points from my discussion with Hoss/Steve yesterday, are just about that. 
Changing the examples is just a part of what’s needed to *confidently* 
deprecate the Trie/Legacy Numeric fields.

I intend to start helping out with the test, but as you mentioned, the more of 
us contribute to it, the sooner we’d be in a spot to make the decision about 
(not) deprecating the fields in 7.0.


-Anshum



> On Jul 11, 2017, at 11:22 AM, Cassandra Targett  wrote:
> 
> It's more than just SOLR-10760, actually. SOLR-10760 is just about
> updating the example schemas. No problem, easy to do, we could commit
> it today. But I think focusing on that issue obscures the larger
> situation.
> 
> If we care about having a quality application, though, we need to
> address the other points Hoss shared with Anshum yesterday. This
> relies on the test randomization in SOLR-10807 to be sure. The
> strategy there is to create sub-tasks for each test schema file you
> will randomize and fix/file jiras/suppress tests depending on what
> breaks. That effort can be done in parallel, and doesn't rely on Hoss
> or Steve because of some magic knowledge only they possess. However,
> it will go faster if more people help.
> 
> When that's done, assuming we're confident we found everything that
> may be broken, can we live with the broken features in a 7.0 release?
> I think we should understand there will be another decision point once
> we're confident we have updated all the tests and found as many bugs
> as we can.
> 
> So, my overall point is that if A) we agree that we want to deprecate
> Trie* numeric fields, and B) we want to hold up the 7.0 release until
> that's done, it's more than just updating the example schemas if we
> want to ensure a quality app for users. We still need to fix the tests
> and also fix bugs that are going to be really painful for users. And
> to get all that done soon, we definitely need some more volunteers.
> 
> On Tue, Jul 11, 2017 at 10:28 AM, Anshum Gupta  wrote:
>> Here’s an update for 7.0 release.
>> 
>> We are (rightfully) waiting for SOLR-10760 to be completed so that we could
>> deprecate all Trie/LegacyNumeric based fields in 7.0. I discussed this with
>> Hoss, and Steve Rowe, and here are the 2 things that Hoss highlighted that
>> were not directly related for 7.0, but for being able to comfortable
>> deprecate those fields:
>> 
>> "a) points fields have been around for many 6.x releases, but a lot of
>> features silently fail (or fail in weird ways) if you use points ... so i
>> wnat to get those bugs found and documented
>> b) i want the test randomization in place so that as people create new
>> functionality w/ explicit/implicit assumptions about *either* points or
>> tries the tests will fail on them (someitmes)”
>> 
>> While we wait for this, we should now only get bug fixes and critical
>> deprecations into branch_7_0.
>> 
>> P.S: Like always, if someone thinks otherwise, let everyone else know.
>> 
>> -Anshum
>> 
>> 
>> 
>> On Jul 10, 2017, at 8:50 AM, Cassandra Targett 
>> wrote:
>> 
>> Thanks Steve.
>> 
>> On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta 
>> wrote:
>> 
>> Thanks Steve, and Cassandra.
>> 
>> On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe  wrote:
>> 
>> 
>> 
>> On Jul 10, 2017, at 11:04 AM, Cassandra Targett 
>> wrote:
>> 
>> We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
>> maybe you could help with that?
>> 
>> 
>> I created 7.x & 7.0 ref guide jobs by cloning the master job.
>> 
>> On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
>> 
>> 
>> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet
>> create
>> 7.0 jobs. I just want the 7.x builds succeed.
>> 
>> 
>> I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x
>> jobs are behaving normally.  I did not create the 7.0 jobs on Policeman
>> Jenkins.
>> 
>> I disabled all 6.x builds. I’d like to nuke them at some and just leave
>> the
>> 6.6 builds disabled as a fallback for a new point release. This goes in
>> line
>> with Erick’s question about JIRA labels! I’d not go for a 6.7 release,
>> we
>> should just focus on 7.0.
>> 
>> 
>> I also disabled the 6.x ref guide job.
>> 
>> --
>> Steve
>> www.lucidworks.com
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: 

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: try again to fix failing stats tests: fix hard-coded assertions to 
depend on doc count where it's affected by the random multiplier.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11024) ParallelStream should set the StreamContext when constructing SolrStreams

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11024:


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

SOLR-11024: ParallelStream should set the StreamContext when constructing 
SolrStreams added to CHANGES.txt

(cherry picked from commit ce949aa)


> ParallelStream should set the StreamContext when constructing SolrStreams
> -
>
> Key: SOLR-11024
> URL: https://issues.apache.org/jira/browse/SOLR-11024
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: SOLR-11024.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Building a class with JCC from setup.py

[Andi Vajda]

On Tue, 11 Jul 2017, Joshua Campbell wrote:


Would it be possible to abstract about parts of the compile routine
from python.py so that I could have a setup.py that does like:

from setuptools import setup
from jcc import jcc_extension

my_extension = jcc_extension(
   name='py_lex_java'
   clases=['ca.ualberta.cs.ScannerWrapper'],
   includes=['target/lex-java-1.0-SNAPSHOT-jar-with-dependencies.jar'],
   )


Neat idea !
Patches welcome !

Andi..



setup(
   name='py_lex_java',
   version="1.8.1",
   description='Call the Java Compiler\'s lexer from Python.',
   long_description=open('README.txt').read(),
   author='Joshua Campbell',
   author_email='py_lex_j...@orezpraw.com',
   url='https://github.com/naturalness/py-lex-java',
   license='GPLv3+',
   packages=['py_lex_java'],
   zip_safe=False,
   ext_modules=[my_extension.ext_module],
   'package_dir': {'py_lex_java': my_extension.package_dir},
   'package_data': {'py_lex_java': my_extension.package_data},
)

On Tue, Jul 11, 2017 at 12:00 PM, Joshua Campbell  wrote:

I thought of it but I have other, swig-based modules that are also
built by my setup.py...

So I gave up on that but then how do I specify the things that aren't
package name or version to setup(), such as description,
long_description, author, author_email, url, license?

On Tue, Jul 11, 2017 at 10:00 AM, Andi Vajda  wrote:



On Jul 11, 2017, at 08:30, Joshua Campbell  wrote:

Does anyone know how to do this? I don't want to install the java
stuff as its own thing like python -m jcc --install... I just want to
include it as a submodule of a package I already have.


I think you add python files on the jcc command line (there should be 
exhaustive help in its __main__.py file). You might then be able to build your 
package and your java stuff as one jcc thing.

Andi..



--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca






--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca




--
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

[jira] [Created] (SOLR-11047) Add ebeMultiply Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11047:
-

 Summary: Add ebeMultiply Stream Evaluator
 Key: SOLR-11047
 URL: https://issues.apache.org/jira/browse/SOLR-11047
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The ebeMultiply Stream Evaluator will perform and element-by-element 
multiplication of two arrays.

{code}
a = ebeMultiply(b, c)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: try again to fix failing stats tests: fix hard-coded assertions to 
depend on doc count where it's affected by the random multiplier.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: try again to fix failing stats tests: fix hard-coded assertions to 
depend on doc count where it's affected by the random multiplier.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10908) CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq clauses

[Rohit (JIRA)]

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

Rohit updated SOLR-10908:
-
Attachment: SOLR-10908.patch

Added check in function CloudSolrStream.toExpression to correct the behaviour 
for fq parameter.
Post fix:

ExpressionString: search(collection1,q="*:*",fl="id,a_s,a_i,a_f",sort="a_f asc, 
a_i 
asc",*{color:#205081}fq="a_s:one",fq="a_s:two"{color}*,zkHost="testhost:1234")

> CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq 
> clauses
> 
>
> Key: SOLR-10908
> URL: https://issues.apache.org/jira/browse/SOLR-10908
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 7.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10229.patch, SOLR-10908.patch
>
>
> toExpression in at least CloudSolrStream concatenates parameters in a 
> comma-separated list. This is fine for things like sorting but incorrect for 
> fq clauses. If my input is something like
> fq=condition1
> fq=condition2
> it winds up being something like
> fq=condition1,condition2
> I've seen it in this class for this parameter, other classes and other 
> parameters might have the same problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10908) CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq clauses

[Rohit (JIRA)]

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

Rohit edited comment on SOLR-10908 at 7/11/17 6:46 PM:
---

Added check in function CloudSolrStream.toExpression to correct the behaviour 
for fq parameter.
Post fix:

ExpressionString: search(collection1,q="*:*",fl="id,a_s,a_i,a_f",sort="a_f asc, 
a_i 
asc",*{color:#205081}fq="a_s:one",fq="a_s:two"{color}*,zkHost="testhost:1234")

Requesting you to please review the patch and provide any suggestions that you 
see fit.


was (Author: rohitcse):
Added check in function CloudSolrStream.toExpression to correct the behaviour 
for fq parameter.
Post fix:

ExpressionString: search(collection1,q="*:*",fl="id,a_s,a_i,a_f",sort="a_f asc, 
a_i 
asc",*{color:#205081}fq="a_s:one",fq="a_s:two"{color}*,zkHost="testhost:1234")

> CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq 
> clauses
> 
>
> Key: SOLR-10908
> URL: https://issues.apache.org/jira/browse/SOLR-10908
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 7.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10229.patch, SOLR-10908.patch
>
>
> toExpression in at least CloudSolrStream concatenates parameters in a 
> comma-separated list. This is fine for things like sorting but incorrect for 
> fq clauses. If my input is something like
> fq=condition1
> fq=condition2
> it winds up being something like
> fq=condition1,condition2
> I've seen it in this class for this parameter, other classes and other 
> parameters might have the same problem.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6736 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6736/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Live Nodes: 
[127.0.0.1:59225_solr, 127.0.0.1:59222_solr] Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:59225/solr;,   
"node_name":"127.0.0.1:59225_solr",   "state":"active",   
"type":"NRT",   "leader":"true"}, "core_node2":{   
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"http://127.0.0.1:59222/solr;,   
"node_name":"127.0.0.1:59222_solr",   "state":"down",   
"type":"NRT",   "router":{"name":"compositeId"},   "maxShardsPerNode":"1",  
 "autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Live Nodes: [127.0.0.1:59225_solr, 127.0.0.1:59222_solr]
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"http://127.0.0.1:59225/solr;,
  "node_name":"127.0.0.1:59225_solr",
  "state":"active",
  "type":"NRT",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"http://127.0.0.1:59222/solr;,
  "node_name":"127.0.0.1:59222_solr",
  "state":"down",
  "type":"NRT",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([2DCE54811718FEFB:7D9BCC824E3948E6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)

Re: 7.0 Release Update

[Cassandra Targett]

It's more than just SOLR-10760, actually. SOLR-10760 is just about
updating the example schemas. No problem, easy to do, we could commit
it today. But I think focusing on that issue obscures the larger
situation.

If we care about having a quality application, though, we need to
address the other points Hoss shared with Anshum yesterday. This
relies on the test randomization in SOLR-10807 to be sure. The
strategy there is to create sub-tasks for each test schema file you
will randomize and fix/file jiras/suppress tests depending on what
breaks. That effort can be done in parallel, and doesn't rely on Hoss
or Steve because of some magic knowledge only they possess. However,
it will go faster if more people help.

When that's done, assuming we're confident we found everything that
may be broken, can we live with the broken features in a 7.0 release?
I think we should understand there will be another decision point once
we're confident we have updated all the tests and found as many bugs
as we can.

So, my overall point is that if A) we agree that we want to deprecate
Trie* numeric fields, and B) we want to hold up the 7.0 release until
that's done, it's more than just updating the example schemas if we
want to ensure a quality app for users. We still need to fix the tests
and also fix bugs that are going to be really painful for users. And
to get all that done soon, we definitely need some more volunteers.

On Tue, Jul 11, 2017 at 10:28 AM, Anshum Gupta  wrote:
> Here’s an update for 7.0 release.
>
> We are (rightfully) waiting for SOLR-10760 to be completed so that we could
> deprecate all Trie/LegacyNumeric based fields in 7.0. I discussed this with
> Hoss, and Steve Rowe, and here are the 2 things that Hoss highlighted that
> were not directly related for 7.0, but for being able to comfortable
> deprecate those fields:
>
> "a) points fields have been around for many 6.x releases, but a lot of
> features silently fail (or fail in weird ways) if you use points ... so i
> wnat to get those bugs found and documented
> b) i want the test randomization in place so that as people create new
> functionality w/ explicit/implicit assumptions about *either* points or
> tries the tests will fail on them (someitmes)”
>
> While we wait for this, we should now only get bug fixes and critical
> deprecations into branch_7_0.
>
> P.S: Like always, if someone thinks otherwise, let everyone else know.
>
> -Anshum
>
>
>
> On Jul 10, 2017, at 8:50 AM, Cassandra Targett 
> wrote:
>
> Thanks Steve.
>
> On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta 
> wrote:
>
> Thanks Steve, and Cassandra.
>
> On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe  wrote:
>
>
>
> On Jul 10, 2017, at 11:04 AM, Cassandra Targett 
> wrote:
>
> We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
> maybe you could help with that?
>
>
> I created 7.x & 7.0 ref guide jobs by cloning the master job.
>
> On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
>
>
> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet
> create
> 7.0 jobs. I just want the 7.x builds succeed.
>
>
> I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x
> jobs are behaving normally.  I did not create the 7.0 jobs on Policeman
> Jenkins.
>
> I disabled all 6.x builds. I’d like to nuke them at some and just leave
> the
> 6.6 builds disabled as a fallback for a new point release. This goes in
> line
> with Erick’s question about JIRA labels! I’d not go for a 6.7 release,
> we
> should just focus on 7.0.
>
>
> I also disabled the 6.x ref guide job.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

Re: Building a class with JCC from setup.py

[Joshua Campbell]

I thought of it but I have other, swig-based modules that are also
built by my setup.py...

So I gave up on that but then how do I specify the things that aren't
package name or version to setup(), such as description,
long_description, author, author_email, url, license?

On Tue, Jul 11, 2017 at 10:00 AM, Andi Vajda  wrote:
>
>> On Jul 11, 2017, at 08:30, Joshua Campbell  wrote:
>>
>> Does anyone know how to do this? I don't want to install the java
>> stuff as its own thing like python -m jcc --install... I just want to
>> include it as a submodule of a package I already have.
>
> I think you add python files on the jcc command line (there should be 
> exhaustive help in its __main__.py file). You might then be able to build 
> your package and your java stuff as one jcc thing.
>
> Andi..
>
>>
>> --
>> Joshua Charles Campbell
>> Ph.D. Student and Research Assistant
>> Department of Computing Science
>> University of Alberta
>> josh...@ualberta.ca
>



-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

Re: [JENKINS] Lucene-Solr-SmokeRelease-master - Build # 810 - Still Failing

[Steve Rowe]

> 
> On Jul 11, 2017, at 1:26 PM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/810/
> 
> [...]
> 
>   [smoker][junit4] Tests with failures [seed: 9D2F48CFFBC4F45C]:
>   [smoker][junit4]   - 
> org.apache.solr.schema.TestPointFields.testIntPointStats
>   [smoker][junit4]   - 
> org.apache.solr.schema.TestPointFields.testLongPointStats
>   [smoker][junit4]   - 
> org.apache.solr.schema.TestPointFields.testFloatPointStats
>   [smoker][junit4]   - 
> org.apache.solr.schema.TestPointFields.testDoublePointStats

Hmm, this is the first Jenkins failure on the TestPointFields stats tests for a 
commit after I thought I fixed the problem.  I’m looking into it.

--
Steve
www.lucidworks.com


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

[jira] [Commented] (SOLR-10263) Different SpellcheckComponents should have their own suggestMode

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-10263:
---

Agreed, "maxCollationTries" is expensive, especially if it takes in the tens of 
tries to find the user one or more good collations.  The worst scenario, when 
we spend a lot of time trying possibilities and then still come up empty handed 
can be frustrating.  On the other hand, spell-check should hopefully only come 
into play for a small % of queries.  In those cases, we hope the user is 
willing to wait a bit longer to both correct spelling and to give results.  
This is where it can pay dividends to have a simpler query that returns quickly 
in any case:  in the spellcheck scenario it may have to run multiple times so a 
faster query could result in a much faster spell check.

I am not convinced a typical solr user would know in advance -- globally -- 
whether or not a user is more likely to misspell words that happen to have the 
misspelling in the index when it is a word-break misspelling or otherwise.  I 
sincerely doubt even you can tell for sure if a user is more likely to hit on a 
word already in the index when they accidently combine words versus when they 
accidently break words.  My thinking is that real data is too varied for us to 
be able to set something like this in th configuration and then expect it to be 
optimal for everyone's query.

I would recommend you look into creating a synonym list for common misspelling 
for the words in your corpus.  This would be a faster and more sure way to 
handle the cases you know exist like "sun glasses > sunglasses".  The 
spellchecker would exist as a a fallback for those cases that are less common 
or you do not know about.

> Different SpellcheckComponents should have their own suggestMode
> 
>
> Key: SOLR-10263
> URL: https://issues.apache.org/jira/browse/SOLR-10263
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Reporter: Abhishek Kumar Singh
>Priority: Minor
> Attachments: SOLR-10263.v2.patch
>
>
> As of now, common spellcheck options are applied to all the 
> SpellCheckComponents.
> This can create problem in the following case:-
>  It may be the case that we want *DirectSolrSpellChecker* to ALWAYS_SUGGEST 
> spellcheck suggestions. 
> But we may want *WordBreakSpellChecker* to suggest only if the token is not 
> in the index  (for relevance or performance reasons)  
> (SUGGEST_WHEN_NOT_IN_INDEX) . 
> *UPDATE :* Recently, we also figured out that, for 
> {{WordBreakSolrSpellChecker}} also, both - The {{WordBreak}} and {{WordJoin}} 
> should also have different suggestModes.
> We faced this problem in our case, wherein, Most of the WordJoin cases are 
> those where the words individually are valid tokens, but what the users are 
> looking for is actually a  combination (wordjoin) of the two tokens. 
> For example:-
> *gold mine sunglasses* : Here, both *gold* and *mine* are valid tokens. But 
> the actual product being looked for is *goldmine sunglasses* , where 
> *goldmine* is a brand.
> In such cases, we should recommend {{didYouMean:goldmine sunglasses}} . But 
> this wont be possible because we had set   {{SUGGEST_WHEN_NOT_IN_INDEX}}  for 
> {{WordBreakSolrSpellChecker}} (of which, WordJoin is a part)  . 
> For this, we should have separate suggestModes for both `wordJoin` as well as 
> `wordBreak`. 
> Related changes have been done at Latest PR. : 
> https://github.com/apache/lucene-solr/pull/218. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 810 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/810/

No tests ran.

Build Log:
[...truncated 25695 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (29.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 28.9 MB in 0.03 sec (834.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 68.9 MB in 0.08 sec (849.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.2 MB in 0.09 sec (867.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (196.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 49.7 MB in 0.06 sec (774.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 141.6 MB in 0.18 sec (786.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 142.6 MB in 0.23 sec (613.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=4932). Happy searching!
   [smoker] 

[JENKINS] Lucene-Solr-Tests-master - Build # 1965 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1965/

5 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([C5F03F71A196402B:D9F142FCD4333EB8]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:497)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.schema.TestPointFields.testFloatPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([C5F03F71A196402B:7FFA4756198782C9]:0)
at 

[jira] [Commented] (SOLR-9835) Create another replication mode for SolrCloud

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-9835:


Thanks [~tomasflobbe]!

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Fix For: 7.0
>
> Attachments: OnlyLeaderIndexesTest-fail-1.zip, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> On CAP point of view, this ticket will trying to promise to end users a 
> distributed systems :
> - Partition tolerance
> - Weak Consistency for normal query : clusters can serve stale data. This 
> happen when leader finish a commit and slave is fetching for latest segment. 
> This period can at most {{pollInterval + time to fetch latest segment}}.
> - Consistency for RTG : if we *do not use DQBs*, replicas will consistence 
> with master just like original SolrCloud mode
> - Weak Availability : just like original SolrCloud mode. If a leader down, 
> client must wait until new leader being elected.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 29 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/29/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([F1CBF5781942B010:93A60B39D6CCD02E]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12733 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Updated] (LUCENE-7903) Highlighting boolean queries shouldn't always highlight some clauses

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7903:
-
Priority: Minor  (was: Major)
 Summary: Highlighting boolean queries shouldn't always highlight some 
clauses  (was: Highlighting does not work as expected)

I've retitled this issue and moved it to Lucene.  It's debatable if this is a 
bug vs improvement but I classified as minor well.  This is a long-standing 
known issue that affects the original Highlighter as well as the 
UnifiedHighlighter.  It probably affects the FVH too but I'm not sure.  I think 
there may be a previous issue on this matter but I'm having difficulty finding 
it so maybe not.

This is a hard problem that requires re-engineering a large and complicated 
part of the UnifiedHighlighter (PhraseHelper) -- and one already on my mind but 
I have no time for right now.  For inspiration, we can look at the highlighter 
in Luwak which decomposes the query tree into separate SpanScorers.  It doesn't 
suffer from this problem and from some related problems to the current approach 
that are already filed in other issues.

> Highlighting boolean queries shouldn't always highlight some clauses
> 
>
> Key: LUCENE-7903
> URL: https://issues.apache.org/jira/browse/LUCENE-7903
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: Damian Pawski
>Priority: Minor
>
> I am having difficulties with getting correct "highlighting" section from 
> Solr.
> My query returns correct results, only highlighting does not work as I would 
> expected.
> My query:
> http://solrServer/solr/solrCore/select?q=(((field1:((word1)AND(word2)))%20OR%20(field2:((word1)AND(word2)))%20OR%20(field3:((word1)AND(word2)))%20OR%20(field4:((word1)AND(word2)=field5:()=true=field1:(word1)=field1,field2,field3,field4
> If I run this query the highlighting section is correct - there is no 
> document with phrase "word1" - therefore field1 is not listed in the 
> highlighting element - correct.
> If I update my query to:
> http://solrServer/solr/solrCore/select?q=(((field1:((word1)AND(word2)))%20OR%20(field2:((word1)AND(word2)))%20OR%20(field3:((word1)AND(word2)))%20OR%20(field4:((word1)AND(word2)=field5:()=true=field1:(word1
>  OR word2)=field1,field2,field3,field4
> then I am not getting expected results, word2 has been found in field1 but 
> word1 is missing, but Solr returned field1 in highlighting element with 
> highlighted "word2" only.
> I have explicitly added an extra query using hl.q and I have used AND 
> operator (word1 AND word2), why Solr returns field1 in case when only word2 
> has been found?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (32bit/jdk1.8.0_131) - Build # 1 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/1/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testFloatPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([CD87D1440BAAC619:778DA963B3BB04FB]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testFloatPointStats(TestPointFields.java:989)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[jira] [Updated] (SOLR-10109) SoftAutoCommitTest is too fragile.

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10109:

Attachment: SoftAutoCommitTest.2017-02-25.2938.log.txt
SoftAutoCommitTest.2017-05-02.3983.log.txt


[~markrmil...@gmail.com]: Since your commit in feb, the number of jenkins 
failures for SoftAutoCommitTest has dropped noticeably -- well done!

There have only been 2 jenkins failures, since then -- I don't have the full 
logs, but i'm attaching the bodies of the jenkins emails.  In both cases, the 
failure was the same assertion in {{testSoftAndHardCommitMaxTimeRapidAdds}}...

{noformat}
java.lang.AssertionError: 2: hard wasn't fast enough
at 
__randomizedtesting.SeedInfo.seed([FF159C05808D08C6:A300323C6B0F49BE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds(SoftAutoCommitTest.java:382)
{noformat}

If you look at the timing info from the logs, and do some simple math, the 
problem seems clear...

{noformat}
   [junit4]   2> 2824567 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.SolrTestCaseJ4 ###Starting testSoftAndHardCommitMaxTimeRapidAdds
   [junit4]   2> 2832001 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null 
path=null params={}{add=[5000 (1566326219147837440)]} 0 2424
   [junit4]   2> 2832002 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null 
path=null params={}{add=[5001 (1566326221690634240)]} 0 0
   [junit4]   2> 2832003 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null 
path=null params={}{add=[5002 (1566326221690634241)]} 0 0
   [junit4]   2> 2832003 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null 
path=null params={}{add=[5003 (1566326221691682816)]} 0 0
   [junit4]   2> 2832004 INFO  
(TEST-SoftAutoCommitTest.testSoftAndHardCommitMaxTimeRapidAdds-seed#[FF159C05808D08C6])
 [] o.a.s.u.p.LogUpdateProcessorFactory [collection1]  webapp=null 
path=null params={}{add=[5004 (1566326221691682817)]} 0 0
   [junit4]   2> 2832506 INFO  (commitScheduler-7474-thread-1) [] 
o.a.s.u.DirectUpdateHandler2 start 
commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=true,prepareCommit=false}
   [junit4]   2> 2832509 INFO  (commitScheduler-7474-thread-1) [] 
o.a.s.s.SolrIndexSearcher Opening [Searcher@1d85065c[collection1] main]
   [junit4]   2> 2832509 INFO  (commitScheduler-7474-thread-1) [] 
o.a.s.u.DirectUpdateHandler2 end_commit_flush
   [junit4]   2> 2832511 INFO  (searcherExecutor-7470-thread-1) [] 
o.a.s.c.SolrCore [collection1] Registered new searcher 
Searcher@1d85065c[collection1] 
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_1(7.0.0):c1)
 Uninverting(_2(7.0.0):c1) Uninverting(_3(7.0.0):c1) 
Uninverting(_4(7.0.0):c5)))}
   [junit4]   2> 2833207 INFO  (commitScheduler-7473-thread-1) [] 
o.a.s.u.DirectUpdateHandler2 start 
commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
{noformat}

If you compare the timstamp when the first doc *finished* being added (2832001) 
with the timstamp of when the hard commit *started* (2833207) then that's 
almost exactly the 1200ms hardCommitWaitMillis ({{2833207 - 2832001 = 1206}}) 
and it's understandable that only 1 hard commit happened since all of the docs 
were added in under 12 seconds.  But the test requires the {{fast5start}} 
timestamp _before_ adding the first document, and as we can see from the 
{{add=[5000 (1566326219147837440)]} 0 2424}} log line that request was stalled 
for 2.4seconds -- which probably explains why the test thread thinks the 5 adds 
took longer then 12seconds and expects more then 1 hardCommit.  (it's not clear 
since the test does actaully log fast5start or fast5end)


I think the right fix is to do something like this...

{code}
// record pre/post times for start/stop to account for flux in when add
// recorded by commit tracker for first/last doc in the set
final long preStart = System.nanoTime();
assertU(adoc("id",5000));
final long postStart = System.nanoTime();
assertU(adoc("id",5001));
assertU(adoc("id",5002));
assertU(adoc("id",5003));
final long preEnd = System.nanoTime();
assertU(adoc("id",5004));
final long postEnd = System.nanoTime();

[JENKINS] Lucene-Solr-Tests-7.x - Build # 28 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/28/

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testIntPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([B9D4EB6F0F15E32:6018B7BD6E5740EB]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testIntPointStats(TestPointFields.java:278)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

Re: Building a class with JCC from setup.py

[Andi Vajda]

> On Jul 11, 2017, at 08:30, Joshua Campbell  wrote:
> 
> Does anyone know how to do this? I don't want to install the java
> stuff as its own thing like python -m jcc --install... I just want to
> include it as a submodule of a package I already have.

I think you add python files on the jcc command line (there should be 
exhaustive help in its __main__.py file). You might then be able to build your 
package and your java stuff as one jcc thing.

Andi..

> 
> -- 
> Joshua Charles Campbell
> Ph.D. Student and Research Assistant
> Department of Computing Science
> University of Alberta
> josh...@ualberta.ca

[JENKINS] Lucene-Solr-7.0-Windows (64bit/jdk1.8.0_131) - Build # 1 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/1/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([D13148D926203F0:6F7EEACC5DEC63CE]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12826 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-11024) ParallelStream should set the StreamContext when constructing SolrStreams

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-11024.
---
   Resolution: Fixed
Fix Version/s: 6.7

> ParallelStream should set the StreamContext when constructing SolrStreams
> -
>
> Key: SOLR-11024
> URL: https://issues.apache.org/jira/browse/SOLR-11024
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: SOLR-11024.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11024) ParallelStream should set the StreamContext when constructing SolrStreams

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11024:


Commit 6953f87a869a4f6caa304c84e6904702d51ed12b in lucene-solr's branch 
refs/heads/branch_7x from [~erickerickson]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6953f87 ]

SOLR-11024: ParallelStream should set the StreamContext when constructing 
SolrStreams added to CHANGES.txt

(cherry picked from commit ce949aa)


> ParallelStream should set the StreamContext when constructing SolrStreams
> -
>
> Key: SOLR-11024
> URL: https://issues.apache.org/jira/browse/SOLR-11024
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: SOLR-11024.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: 7.0 Release Update

[Anshum Gupta]

Here’s an update for 7.0 release.

We are (rightfully) waiting for SOLR-10760 to be completed so that we could 
deprecate all Trie/LegacyNumeric based fields in 7.0. I discussed this with 
Hoss, and Steve Rowe, and here are the 2 things that Hoss highlighted that were 
not directly related for 7.0, but for being able to comfortable deprecate those 
fields:

"a) points fields have been around for many 6.x releases, but a lot of features 
silently fail (or fail in weird ways) if you use points ... so i wnat to get 
those bugs found and documented
b) i want the test randomization in place so that as people create new 
functionality w/ explicit/implicit assumptions about *either* points or tries 
the tests will fail on them (someitmes)”

While we wait for this, we should now only get bug fixes and critical 
deprecations into branch_7_0.

P.S: Like always, if someone thinks otherwise, let everyone else know.

-Anshum



> On Jul 10, 2017, at 8:50 AM, Cassandra Targett  wrote:
> 
> Thanks Steve.
> 
> On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta  wrote:
>> Thanks Steve, and Cassandra.
>> 
>> On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe  wrote:
>>> 
>>> 
 On Jul 10, 2017, at 11:04 AM, Cassandra Targett 
 wrote:
 
 We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
 maybe you could help with that?
>>> 
>>> I created 7.x & 7.0 ref guide jobs by cloning the master job.
>>> 
 On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
> 
> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet
> create
> 7.0 jobs. I just want the 7.x builds succeed.
>>> 
>>> I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x
>>> jobs are behaving normally.  I did not create the 7.0 jobs on Policeman
>>> Jenkins.
>>> 
> I disabled all 6.x builds. I’d like to nuke them at some and just leave
> the
> 6.6 builds disabled as a fallback for a new point release. This goes in
> line
> with Erick’s question about JIRA labels! I’d not go for a 6.7 release,
> we
> should just focus on 7.0.
>>> 
>>> I also disabled the 6.x ref guide job.
>>> 
>>> --
>>> Steve
>>> www.lucidworks.com
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Commented] (SOLR-11024) ParallelStream should set the StreamContext when constructing SolrStreams

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11024:


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

SOLR-11024: ParallelStream should set the StreamContext when constructing 
SolrStreams

(cherry picked from commit ed4783a)


> ParallelStream should set the StreamContext when constructing SolrStreams
> -
>
> Key: SOLR-11024
> URL: https://issues.apache.org/jira/browse/SOLR-11024
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: SOLR-11024.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11024) ParallelStream should set the StreamContext when constructing SolrStreams

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11024:


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

SOLR-11024: ParallelStream should set the StreamContext when constructing 
SolrStreams added to CHANGES.txt


> ParallelStream should set the StreamContext when constructing SolrStreams
> -
>
> Key: SOLR-11024
> URL: https://issues.apache.org/jira/browse/SOLR-11024
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11024.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Building a class with JCC from setup.py

[Joshua Campbell]

Does anyone know how to do this? I don't want to install the java
stuff as its own thing like python -m jcc --install... I just want to
include it as a submodule of a package I already have.

-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

Re: Build Error on Fedora 25

[Joshua Campbell]

Yeah you have to do this on debian/ubuntu as well

On Mon, Jul 10, 2017 at 2:43 PM, Michael Alcorn  wrote:

> Hi all,
>
> When trying to follow the PyLucene installation instructions on Fedora 25,
> I was getting the following error:
>
> /opt/gcc-4.9.3/bin/g++ -pthread -shared
> -L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
> -Wl,-rpath=/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
> -L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
> -L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
> -L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
> -I/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3/include/
> build/temp.linux-x86_64-3.5/jcc3/sources/jcc.o
> build/temp.linux-x86_64-3.5/jcc3/sources/JCCEnv.o
> -L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib -lpython3.5m -o
> build/lib.linux-x86_64-3.5/libjcc3.so
> -L/usr/lib/jvm/java-1.8.0/jre/lib/amd64 -ljava
> -L/usr/lib/jvm/java-1.8.0/jre/lib/amd64/server -ljvm
> -Wl,-rpath=/usr/lib/jvm/java-1.8.0/jre/lib/amd64:/usr/lib/
> jvm/java-1.8.0/jre/lib/amd64/server
> -Wl,-S -lpython3.5
> /usr/bin/ld: cannot find -lpython3.5
>
> It looks like the compile command is assuming an incorrect name for the
> Python 3 development library. The development libraries I have include:
>
> libpython3.5m.so.1.0
> libpython3.5m.so (linked to the above)
> libpython3.so
>
> Providing the expected name through a link, e.g.:
>
> ln -s /path/to/.pyenv/versions/3.5.2/lib/libpython3.5m.so.1.0
> /path/to/.pyenv/versions/3.5.2/lib/libpython3.5.so
>
> fixed the issue. Everything works great after that. Thanks for the project!
>
> -Michael
>



-- 
Joshua Charles Campbell
Ph.D. Student and Research Assistant
Department of Computing Science
University of Alberta
josh...@ualberta.ca

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: fix failing stats tests by starting with an empty index.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: fix failing stats tests by starting with an empty index.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Moved] (LUCENE-7903) Highlighting does not work as expected

[David Smiley (JIRA)]

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

David Smiley moved SOLR-10331 to LUCENE-7903:
-

Affects Version/s: (was: 5.4.1)
 Security: (was: Public)
  Component/s: (was: highlighter)
   modules/highlighter
Lucene Fields: New
  Key: LUCENE-7903  (was: SOLR-10331)
  Project: Lucene - Core  (was: Solr)

> Highlighting does not work as expected
> --
>
> Key: LUCENE-7903
> URL: https://issues.apache.org/jira/browse/LUCENE-7903
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: Damian Pawski
>
> I am having difficulties with getting correct "highlighting" section from 
> Solr.
> My query returns correct results, only highlighting does not work as I would 
> expected.
> My query:
> http://solrServer/solr/solrCore/select?q=(((field1:((word1)AND(word2)))%20OR%20(field2:((word1)AND(word2)))%20OR%20(field3:((word1)AND(word2)))%20OR%20(field4:((word1)AND(word2)=field5:()=true=field1:(word1)=field1,field2,field3,field4
> If I run this query the highlighting section is correct - there is no 
> document with phrase "word1" - therefore field1 is not listed in the 
> highlighting element - correct.
> If I update my query to:
> http://solrServer/solr/solrCore/select?q=(((field1:((word1)AND(word2)))%20OR%20(field2:((word1)AND(word2)))%20OR%20(field3:((word1)AND(word2)))%20OR%20(field4:((word1)AND(word2)=field5:()=true=field1:(word1
>  OR word2)=field1,field2,field3,field4
> then I am not getting expected results, word2 has been found in field1 but 
> word1 is missing, but Solr returned field1 in highlighting element with 
> highlighted "word2" only.
> I have explicitly added an extra query using hl.q and I have used AND 
> operator (word1 AND word2), why Solr returns field1 in case when only word2 
> has been found?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: fix failing stats tests by starting with an empty index.


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Shorter URLs to Solr ref-guide?

[Cassandra Targett]

I was out on vacation last week, so just catching up to this discussion.

Upfront I'll say I'm +0 on this effort - short URLs are nice, but in
my mind I balance the effort against its relative priority with other
things the Ref Guide needs and, for me, this would be lower on my
list. I don't wish to stop anyone from improving things, though, if
this is where available skills/energy lie.

That said, a few more specific comments:

>> Register a domain for the guide, e.g. http://solr.guide/ — 12 chars instead 
>> of 30 ($35/yr)

Without "apache.org" in the domain, comments don't work today.
Supposedly it's possible to make it work, but whatever docs INFRA has
already written about it are out of date. Investigating that further
would need to be a step in the process if the permanent URL is
"solr.guide" instead of "apache.org".

>> Long domain and prefix: http://lucene.apache.org/solr/guide/

It's really no longer than the old domain & prefix:
https://cwiki.apache.org/confluence/solr/.

>> Write a script that removes the duplicate names in anchors, and run a 
>> one-time conversion
   e.g. converts #OtherSchemaElements-Similarity to #Similarity

There is a reason why these are there for now and it's because every
section heading throughout the entire guide must be unique. It's not
so bad for the HTML version, because each HTML page is a separate
entity but for the PDF it can cause real problems. The build process
has a step where it checks the built pages/pdf to ensure all section
titles or related anchor tags are unique - if there are any
duplicates, the build fails (it also fails if an anchor doesn't
exist). So you can't just automatically change them without ensuring
that there aren't any other pages with a section titled "Similarity",
or "Examples", or "Parameters", "Input", etc. (the latter 3 being very
common).

To make the conversion simpler and ensure stuff just worked we simply
copied Confluence's anchors, knowing we would remove them later after
some review, which I've been doing with other edits. It's a multi-step
process - find where might be referring to the anchor you want to
remove & fix the reference, remove the Confluence-style anchor, then
run the build to ensure you didn't make a duplicate. And if you did,
figure out how to change one or more section titles or add simpler
anchor tags and fix the reference again. A script would help some of
this, but there will be a long list of things to fix afterwards, and
many of those probably need some human intervention.

This is also pretty much exactly the same as before, by the way, just
Confluence had some built-in logic to obscure it in many cases (and
most probably don't realize how many inter-page links I used to find
broken all the time).

>> That would probably simplify the publishing instructions as well, if we 
>> could use scp/rsync/ftp instead of svn. Cassandra?

I'm not sure what you're asking me to comment on - perhaps it would
simplify publishing instructions? Not really sure. It's not that
onerous today, really, once you do it once. It's nearly exactly the
same as publishing the javadocs for a release, which is update a
single file in the CMS then issue a single SVN command to import the
new pages. And the PDF still requires SVN no matter what you do with
the online version.

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

[jira] [Commented] (SOLR-10321) Unified highlighter returns empty fields when using glob

[Christoph Hack (JIRA)]

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

Christoph Hack commented on SOLR-10321:
---

I think not sending empty entries at all (even if there is a field in the 
document) might be a good option, since transferring and decoding the keys can 
take a considerable amount of time. It's always possible to look at the 
retrieved document to see if the field is available or not. Unfortunately, 
changing the default might break some clients that are currently depending on 
this behavior and I am not sure if it's worth breaking them (and forcing them 
to fix a potential performance problem). The other option would be to introduce 
yet another highlighting option.

> Unified highlighter returns empty fields when using glob
> 
>
> Key: SOLR-10321
> URL: https://issues.apache.org/jira/browse/SOLR-10321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4.2
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 7.0
>
>
> {code}
> q=lama=unified=content_*
> {code}
> returns:
> {code}
>name="http://www.nu.nl/weekend/3771311/dalai-lama-inspireert-westen.html;>
> 
> 
>   Nobelprijs Voorafgaand aan zijn bezoek aan Nederland is de dalai 
> emlama/em in Noorwegen om te vieren dat 25 jaar geleden de 
> Nobelprijs voor de Vrede aan hem werd toegekend. Anders dan in Nederland 
> wordt de dalai emlama/em niet ontvangen in het Noorse 
> parlement. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> {code}
> FastVector and original do not emit: 
> {code}
> 
> 
> 
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-6070) Cannot use multiple highlighting components in a single solrconfig

[David Smiley (JIRA)]

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

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

I'm closing this as Won't-Fix.  I think the UnifiedHighlighter addresses the 
underlying need here, even though you still can't have multiple highlight 
components.

> Cannot use multiple highlighting components in a single solrconfig
> --
>
> Key: SOLR-6070
> URL: https://issues.apache.org/jira/browse/SOLR-6070
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 4.7.2, 4.8
>Reporter: Elaine Cario
>  Labels: highlighting
>
> I'm trying to use both the PostingsHighlighter and the FastVectorHighlighter 
> in the same solrconfig (selection driven by different request handlers), but 
> once I define 2 search components in the config, it always picks the Postings 
> Highlighter (even if I never reference it in any request handler).
> I think the culprit is some specific code in SolrCore.loadSearchComponents(), 
> which overwrites the "highlighting" component with the contents of the 
> "postingshighlight" component - so the components map has 2 entries, but they 
> both point to the same highlighting class (the PostingsHighlighter).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Increasing ASF Jenkins bandwidth

[Steve Rowe]

> On Jul 11, 2017, at 3:41 AM, Uwe Schindler  wrote:
> 
> Thanks Steve!
> 
> How came that we got a second machine? Is it a VM or is it some other 
> (sponsored one)?

It is a VM.  See .

INFRA-14004 was closed as “Won’t Fix” a month ago, and then suddenly yesterday 
the request on that issue was honored.

I don’t understand why (hence my comment about it being bizarre), but we were 
maybe grandfathered out of Greg Stein’s kiboshing of new project-specific VMs 
(see 
).

--
Steve
www.lucidworks.com


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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 6 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/6/

5 tests failed.
FAILED:  org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml

Error Message:
expected:<1000> but was:<999>

Stack Trace:
java.lang.AssertionError: expected:<1000> but was:<999>
at 
__randomizedtesting.SeedInfo.seed([85EA38C878EF5B6:A3BC1A7A0588ECDB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.doThreads(TestSolrJErrorHandling.java:185)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.doIt(TestSolrJErrorHandling.java:200)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml(TestSolrJErrorHandling.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Commented] (SOLR-10321) Unified highlighter returns empty fields when using glob

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10321:
-

If there are a great number of fields to potentially highlight (even though 
each doc will match very few), this could also be a performance issue as 
reported in SOLR-10993 (a duplicate of this issue really).

> Unified highlighter returns empty fields when using glob
> 
>
> Key: SOLR-10321
> URL: https://issues.apache.org/jira/browse/SOLR-10321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.4.2
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 7.0
>
>
> {code}
> q=lama=unified=content_*
> {code}
> returns:
> {code}
>name="http://www.nu.nl/weekend/3771311/dalai-lama-inspireert-westen.html;>
> 
> 
>   Nobelprijs Voorafgaand aan zijn bezoek aan Nederland is de dalai 
> emlama/em in Noorwegen om te vieren dat 25 jaar geleden de 
> Nobelprijs voor de Vrede aan hem werd toegekend. Anders dan in Nederland 
> wordt de dalai emlama/em niet ontvangen in het Noorse 
> parlement. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> {code}
> FastVector and original do not emit: 
> {code}
> 
> 
> 
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10993) lots of empty highlight entries

[Christoph Hack (JIRA)]

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

Christoph Hack edited comment on SOLR-10993 at 7/11/17 2:25 PM:


Thanks for your reply, but I am not asking a question... I have already looked 
at the source and have confirmed that it is a bug, as I have written before.

Here is a simple example to reconstruct the behavior:

1. Create a new core "bin/solr create -c bug"

2. Index some documents:

{code|title=Example Data}
{"id": "D1", "prop01_txt": "foo", "prop03_txt": "foo"}
{"id": "D2", "prop02_txt": "foo", "prop04_txt": "foo"}
{"id": "D3", "prop02_txt": "foo", "prop05_txt": "foo"}
{"id": "D4", "prop03_txt": "foo", "prop06_txt": "foo"}
{"id": "D5", "prop03_txt": "foo", "prop07_txt": "foo"}
{code}


3. Query the database with the unified highlighter:

{code:title=Query}
http://localhost:8983/solr/bug/select?hl.fl=prop*_txt=unified=on=on=foo=json
{code}

{code:title=Response}
{
  "responseHeader":{
"status":0,
"QTime":20,
"params":{
  "q":"foo",
  "hl":"on",
  "indent":"on",
  "hl.fl":"prop*_txt",
  "hl.method":"unified",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"docs":[
  {
"id":"D1",
"prop01_txt":["foo"],
"prop03_txt":["foo"],
"_version_":1572635524573691904},
  {
"id":"D2",
"prop02_txt":["foo"],
"prop04_txt":["foo"],
"_version_":1572635532961251328},
  {
"id":"D3",
"prop02_txt":["foo"],
"prop05_txt":["foo"],
"_version_":1572635545661603840},
  {
"id":"D4",
"prop03_txt":["foo"],
"prop06_txt":["foo"],
"_version_":1572635551479103488},
  {
"id":"D5",
"prop03_txt":["foo"],
"prop07_txt":["foo"],
"_version_":1572635557318623232}]
  },
  "highlighting":{
"D1":{
  "prop01_txt":["foo"],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D2":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":["foo"],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D3":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":[],
  "prop05_txt":["foo"],
  "prop06_txt":[],
  "prop07_txt":[]},
"D4":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":["foo"],
  "prop07_txt":[]},
"D5":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":["foo"]}}}
{code}

As you can see, the highlighting response contains far too many entries. In my 
example, I get about 10k entries per result item which is painfully slow.


was (Author: tux21b):
Thanks for your reply, but I am not asking a question... I have already looked 
at the source and have confirmed that it is a bug, as I have written before.

Here is a simple example to reconstruct the behavior:

1. Create a new core "bin/solr create -c bug"

2. Index some documents:

{code:json|title=Example Data}
{"id": "D1", "prop01_txt": "foo", "prop03_txt": "foo"}
{"id": "D2", "prop02_txt": "foo", "prop04_txt": "foo"}
{"id": "D3", "prop02_txt": "foo", "prop05_txt": "foo"}
{"id": "D4", "prop03_txt": "foo", "prop06_txt": "foo"}
{"id": "D5", "prop03_txt": "foo", "prop07_txt": "foo"}
{code}


3. Query the database with the unified highlighter:

{code|title=Query}
http://localhost:8983/solr/bug/select?hl.fl=prop*_txt=unified=on=on=foo=json
{code}

{code:json|title=Response}
{
  "responseHeader":{
"status":0,
"QTime":20,
"params":{
  "q":"foo",
  "hl":"on",
  "indent":"on",
  "hl.fl":"prop*_txt",
  "hl.method":"unified",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"docs":[
  {
"id":"D1",
"prop01_txt":["foo"],
"prop03_txt":["foo"],
"_version_":1572635524573691904},
  {
"id":"D2",
"prop02_txt":["foo"],
"prop04_txt":["foo"],
"_version_":1572635532961251328},
  {
"id":"D3",
"prop02_txt":["foo"],
"prop05_txt":["foo"],
"_version_":1572635545661603840},
  {
"id":"D4",
"prop03_txt":["foo"],
"prop06_txt":["foo"],
"_version_":1572635551479103488},
  {
"id":"D5",
"prop03_txt":["foo"],
"prop07_txt":["foo"],
"_version_":1572635557318623232}]
  },
  "highlighting":{
"D1":{
  "prop01_txt":["foo"],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D2":{
  

[jira] [Assigned] (SOLR-11046) Add residuals Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11046:
-

Assignee: Joel Bernstein

> Add residuals Stream Evaluator
> --
>
> Key: SOLR-11046
> URL: https://issues.apache.org/jira/browse/SOLR-11046
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> The residuals stream evaluator returns an array of the residuals (difference 
> between predicted and actual values) from applying a simple regression model 
> to a sample set.
> {code}
> a = regress(b, c)
> d = residuals(a, b, c)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10993) lots of empty highlight entries

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10993:
-

I think this is a known issue -- SOLR-10321.  Please discuss there.

> lots of empty highlight entries
> ---
>
> Key: SOLR-10993
> URL: https://issues.apache.org/jira/browse/SOLR-10993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.6
>Reporter: Christoph Hack
>
> I have indexed documents with lots of different text fields representing 
> different properties in Solr (version 6.6). Those text fields are indexed 
> with storeOffsetsWithPositions=true and termVectors=true to speed up 
> highlighting using the UnifiedHighlighter.
> During a search, i would like to highlight those properties and I have set 
> hl.fl to wildcard match all properties. Everything is working fine, except 
> that the responses are huge.
> Every document only has a small set of properties (let's say 10 in total, 
> with 1-2 matching ones), but Solr returns in the highlighting section, a 
> dictionary with every possible property (about 10k) for every item. Nearly 
> all of the entries are empty, but decoding the keys of the map takes a 
> considerable amount of time.
> In fact, the time spent decoding this unnecessary entries is enormous. Solr 
> takes about 174ms for the search + encoding (i expect that the timing could 
> be much better) and decoding the response in Go (using the default JSON 
> package from the standard library) takes 695ms.
> I guess the offending line is somewhere around:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L175
> Why is Solr generating map entries for missing values in the first place?
> The question had been posted on stackoverflow before:
> https://stackoverflow.com/questions/44846220/solr-huge-and-slow-highlighting-response-with-mostly-empty-fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10993) lots of empty highlight entries

[Christoph Hack (JIRA)]

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

Christoph Hack resolved SOLR-10993.
---
Resolution: Duplicate

Ah, many thanks David. I haven't seen that issue before, sorry.

> lots of empty highlight entries
> ---
>
> Key: SOLR-10993
> URL: https://issues.apache.org/jira/browse/SOLR-10993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.6
>Reporter: Christoph Hack
>
> I have indexed documents with lots of different text fields representing 
> different properties in Solr (version 6.6). Those text fields are indexed 
> with storeOffsetsWithPositions=true and termVectors=true to speed up 
> highlighting using the UnifiedHighlighter.
> During a search, i would like to highlight those properties and I have set 
> hl.fl to wildcard match all properties. Everything is working fine, except 
> that the responses are huge.
> Every document only has a small set of properties (let's say 10 in total, 
> with 1-2 matching ones), but Solr returns in the highlighting section, a 
> dictionary with every possible property (about 10k) for every item. Nearly 
> all of the entries are empty, but decoding the keys of the map takes a 
> considerable amount of time.
> In fact, the time spent decoding this unnecessary entries is enormous. Solr 
> takes about 174ms for the search + encoding (i expect that the timing could 
> be much better) and decoding the response in Go (using the default JSON 
> package from the standard library) takes 695ms.
> I guess the offending line is somewhere around:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L175
> Why is Solr generating map entries for missing values in the first place?
> The question had been posted on stackoverflow before:
> https://stackoverflow.com/questions/44846220/solr-huge-and-slow-highlighting-response-with-mostly-empty-fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-10993) lots of empty highlight entries

[Christoph Hack (JIRA)]

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

Christoph Hack reopened SOLR-10993:
---

> lots of empty highlight entries
> ---
>
> Key: SOLR-10993
> URL: https://issues.apache.org/jira/browse/SOLR-10993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.6
>Reporter: Christoph Hack
>
> I have indexed documents with lots of different text fields representing 
> different properties in Solr (version 6.6). Those text fields are indexed 
> with storeOffsetsWithPositions=true and termVectors=true to speed up 
> highlighting using the UnifiedHighlighter.
> During a search, i would like to highlight those properties and I have set 
> hl.fl to wildcard match all properties. Everything is working fine, except 
> that the responses are huge.
> Every document only has a small set of properties (let's say 10 in total, 
> with 1-2 matching ones), but Solr returns in the highlighting section, a 
> dictionary with every possible property (about 10k) for every item. Nearly 
> all of the entries are empty, but decoding the keys of the map takes a 
> considerable amount of time.
> In fact, the time spent decoding this unnecessary entries is enormous. Solr 
> takes about 174ms for the search + encoding (i expect that the timing could 
> be much better) and decoding the response in Go (using the default JSON 
> package from the standard library) takes 695ms.
> I guess the offending line is somewhere around:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L175
> Why is Solr generating map entries for missing values in the first place?
> The question had been posted on stackoverflow before:
> https://stackoverflow.com/questions/44846220/solr-huge-and-slow-highlighting-response-with-mostly-empty-fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10993) lots of empty highlight entries

[Christoph Hack (JIRA)]

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

Christoph Hack edited comment on SOLR-10993 at 7/11/17 2:26 PM:


Thanks for your reply, but I am not asking a question... I have already looked 
at the source and have confirmed that it is a bug, as I have written before.

Here is a simple example to reconstruct the behavior:

1. Create a new core "bin/solr create -c bug"

2. Index some documents:

{code:title=Example Data}
{"id": "D1", "prop01_txt": "foo", "prop03_txt": "foo"}
{"id": "D2", "prop02_txt": "foo", "prop04_txt": "foo"}
{"id": "D3", "prop02_txt": "foo", "prop05_txt": "foo"}
{"id": "D4", "prop03_txt": "foo", "prop06_txt": "foo"}
{"id": "D5", "prop03_txt": "foo", "prop07_txt": "foo"}
{code}


3. Query the database with the unified highlighter:

{code:title=Query}
http://localhost:8983/solr/bug/select?hl.fl=prop*_txt=unified=on=on=foo=json
{code}

{code:title=Response}
{
  "responseHeader":{
"status":0,
"QTime":20,
"params":{
  "q":"foo",
  "hl":"on",
  "indent":"on",
  "hl.fl":"prop*_txt",
  "hl.method":"unified",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"docs":[
  {
"id":"D1",
"prop01_txt":["foo"],
"prop03_txt":["foo"],
"_version_":1572635524573691904},
  {
"id":"D2",
"prop02_txt":["foo"],
"prop04_txt":["foo"],
"_version_":1572635532961251328},
  {
"id":"D3",
"prop02_txt":["foo"],
"prop05_txt":["foo"],
"_version_":1572635545661603840},
  {
"id":"D4",
"prop03_txt":["foo"],
"prop06_txt":["foo"],
"_version_":1572635551479103488},
  {
"id":"D5",
"prop03_txt":["foo"],
"prop07_txt":["foo"],
"_version_":1572635557318623232}]
  },
  "highlighting":{
"D1":{
  "prop01_txt":["foo"],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D2":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":["foo"],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D3":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":[],
  "prop05_txt":["foo"],
  "prop06_txt":[],
  "prop07_txt":[]},
"D4":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":["foo"],
  "prop07_txt":[]},
"D5":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":["foo"]}}}
{code}

As you can see, the highlighting response contains far too many entries. In my 
example, I get about 10k entries per result item which is painfully slow.


was (Author: tux21b):
Thanks for your reply, but I am not asking a question... I have already looked 
at the source and have confirmed that it is a bug, as I have written before.

Here is a simple example to reconstruct the behavior:

1. Create a new core "bin/solr create -c bug"

2. Index some documents:

{code|title=Example Data}
{"id": "D1", "prop01_txt": "foo", "prop03_txt": "foo"}
{"id": "D2", "prop02_txt": "foo", "prop04_txt": "foo"}
{"id": "D3", "prop02_txt": "foo", "prop05_txt": "foo"}
{"id": "D4", "prop03_txt": "foo", "prop06_txt": "foo"}
{"id": "D5", "prop03_txt": "foo", "prop07_txt": "foo"}
{code}


3. Query the database with the unified highlighter:

{code:title=Query}
http://localhost:8983/solr/bug/select?hl.fl=prop*_txt=unified=on=on=foo=json
{code}

{code:title=Response}
{
  "responseHeader":{
"status":0,
"QTime":20,
"params":{
  "q":"foo",
  "hl":"on",
  "indent":"on",
  "hl.fl":"prop*_txt",
  "hl.method":"unified",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"docs":[
  {
"id":"D1",
"prop01_txt":["foo"],
"prop03_txt":["foo"],
"_version_":1572635524573691904},
  {
"id":"D2",
"prop02_txt":["foo"],
"prop04_txt":["foo"],
"_version_":1572635532961251328},
  {
"id":"D3",
"prop02_txt":["foo"],
"prop05_txt":["foo"],
"_version_":1572635545661603840},
  {
"id":"D4",
"prop03_txt":["foo"],
"prop06_txt":["foo"],
"_version_":1572635551479103488},
  {
"id":"D5",
"prop03_txt":["foo"],
"prop07_txt":["foo"],
"_version_":1572635557318623232}]
  },
  "highlighting":{
"D1":{
  "prop01_txt":["foo"],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D2":{
  "prop01_txt":[],
  

[jira] [Assigned] (SOLR-11047) Add ebeMultiply Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11047:
-

Assignee: Joel Bernstein

> Add ebeMultiply Stream Evaluator
> 
>
> Key: SOLR-11047
> URL: https://issues.apache.org/jira/browse/SOLR-11047
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> The ebeMultiply Stream Evaluator will perform and element-by-element 
> multiplication of two arrays.
> {code}
> a = ebeMultiply(b, c)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 27 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/27/

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testDoublePointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([4266684B28950312:6D7CA61DDC381FB6]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[jira] [Commented] (SOLR-10993) lots of empty highlight entries

[Christoph Hack (JIRA)]

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

Christoph Hack commented on SOLR-10993:
---

Thanks for your reply, but I am not asking a question... I have already looked 
at the source and have confirmed that it is a bug, as I have written before.

Here is a simple example to reconstruct the behavior:

1. Create a new core "bin/solr create -c bug"

2. Index some documents:

{code:json|title=Example Data}
{"id": "D1", "prop01_txt": "foo", "prop03_txt": "foo"}
{"id": "D2", "prop02_txt": "foo", "prop04_txt": "foo"}
{"id": "D3", "prop02_txt": "foo", "prop05_txt": "foo"}
{"id": "D4", "prop03_txt": "foo", "prop06_txt": "foo"}
{"id": "D5", "prop03_txt": "foo", "prop07_txt": "foo"}
{code}


3. Query the database with the unified highlighter:

{code|title=Query}
http://localhost:8983/solr/bug/select?hl.fl=prop*_txt=unified=on=on=foo=json
{code}

{code:json|title=Response}
{
  "responseHeader":{
"status":0,
"QTime":20,
"params":{
  "q":"foo",
  "hl":"on",
  "indent":"on",
  "hl.fl":"prop*_txt",
  "hl.method":"unified",
  "wt":"json"}},
  "response":{"numFound":5,"start":0,"docs":[
  {
"id":"D1",
"prop01_txt":["foo"],
"prop03_txt":["foo"],
"_version_":1572635524573691904},
  {
"id":"D2",
"prop02_txt":["foo"],
"prop04_txt":["foo"],
"_version_":1572635532961251328},
  {
"id":"D3",
"prop02_txt":["foo"],
"prop05_txt":["foo"],
"_version_":1572635545661603840},
  {
"id":"D4",
"prop03_txt":["foo"],
"prop06_txt":["foo"],
"_version_":1572635551479103488},
  {
"id":"D5",
"prop03_txt":["foo"],
"prop07_txt":["foo"],
"_version_":1572635557318623232}]
  },
  "highlighting":{
"D1":{
  "prop01_txt":["foo"],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D2":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":["foo"],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":[]},
"D3":{
  "prop01_txt":[],
  "prop03_txt":[],
  "prop02_txt":["foo"],
  "prop04_txt":[],
  "prop05_txt":["foo"],
  "prop06_txt":[],
  "prop07_txt":[]},
"D4":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":["foo"],
  "prop07_txt":[]},
"D5":{
  "prop01_txt":[],
  "prop03_txt":["foo"],
  "prop02_txt":[],
  "prop04_txt":[],
  "prop05_txt":[],
  "prop06_txt":[],
  "prop07_txt":["foo"]}}}
{code}

As you can see, the highlighting response contains far too many entries. In my 
example, I get about 10k entries per result item which is painfully slow.

> lots of empty highlight entries
> ---
>
> Key: SOLR-10993
> URL: https://issues.apache.org/jira/browse/SOLR-10993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.6
>Reporter: Christoph Hack
>
> I have indexed documents with lots of different text fields representing 
> different properties in Solr (version 6.6). Those text fields are indexed 
> with storeOffsetsWithPositions=true and termVectors=true to speed up 
> highlighting using the UnifiedHighlighter.
> During a search, i would like to highlight those properties and I have set 
> hl.fl to wildcard match all properties. Everything is working fine, except 
> that the responses are huge.
> Every document only has a small set of properties (let's say 10 in total, 
> with 1-2 matching ones), but Solr returns in the highlighting section, a 
> dictionary with every possible property (about 10k) for every item. Nearly 
> all of the entries are empty, but decoding the keys of the map takes a 
> considerable amount of time.
> In fact, the time spent decoding this unnecessary entries is enormous. Solr 
> takes about 174ms for the search + encoding (i expect that the timing could 
> be much better) and decoding the response in Go (using the default JSON 
> package from the standard library) takes 695ms.
> I guess the offending line is somewhere around:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L175
> Why is Solr generating map entries for missing values in the first place?
> The question had been posted on stackoverflow before:
> https://stackoverflow.com/questions/44846220/solr-huge-and-slow-highlighting-response-with-mostly-empty-fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SOLR-11046) Add residuals Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11046:
-

 Summary: Add residuals Stream Evaluator
 Key: SOLR-11046
 URL: https://issues.apache.org/jira/browse/SOLR-11046
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The residuals stream evaluator returns an array of the residuals (difference 
between predicted and actual values) from applying a simple regression model to 
a sample set.

{code}
a = regress(b, c)
d = residuals(a, b, c)
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+175) - Build # 20112 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20112/
Java: 32bit/jdk-9-ea+175 -client -XX:+UseG1GC --illegal-access=deny

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestPointFields

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

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


FAILED:  org.apache.solr.schema.TestPointFields.testLongPointFieldRangeFacet

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([F73407AC5434A61]:0)


FAILED:  org.apache.solr.schema.TestPointFields.testDoublePointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([F73407AC5434A61:20698E2C31EE56C5]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
  

[jira] [Comment Edited] (SOLR-10263) Different SpellcheckComponents should have their own suggestMode

[Abhishek Kumar Singh (JIRA)]

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

Abhishek Kumar Singh edited comment on SOLR-10263 at 7/11/17 1:55 PM:
--

The problem with "maxCollationTries" is that - a {{collationTry}}  is an 
expensive step. So, there is only a limit to which we can increase its value - 
given a certain level of response time/efficiency requirement. 

A control on {{wordBreak}}  suggestions can give us more freedom to get the 
relevant suggestions in cases where we know how our queries are going to be. 
For example: *gold mine sunglasses* will even give suggestions like *gold mine 
sun glasses*  or even *gold mine sung lasses* and later waste our precious 
{{maxCollationTries}}. In this case,   SUGGEST_WHEN_NOT_IN_INDEX for 
{{wordBreak}} will avoid above suggestions which we already know are not 
required.  

This is why, We faced cases wherein different {{SpellCheckComponents}}  
required different *suggestModes*. 
Also, I think _wordBreak_ and _wordJoin_  (within {{WordBreakSolrSpellCheck}} ) 
should also have different _suggestMode_ configurations because the use cases 
can really vary.  (for the above usecase itself, we want *gold* and *mine* to 
be combine to *goldmine* , so {{wordJoin}} will again have SUGGEST_ALWAYS. )

This is why in our case, after applying the above patch, we had to configure 
{{DirectSolrSpellChecker}} to {{SUGGEST_ALWAYS}} , while only {{wordBreak}}  
was configured as {{SUGGEST_WHEN_NOT_IN_INDEX}} and so that {{wordJoin}}  still 
had  {{SUGGEST_ALWAYS}} . 


was (Author: asingh2411):
The problem with "maxCollationTries" is that - a {{collationTry}}  is an 
expensive step. So, there is only a limit to which we can increase its value - 
given a certain level of response time/efficiency requirement. 

A control on {{wordBreak}}  suggestions can give us more freedom to get the 
relevant suggestions in cases where we know how our queries are going to be. 
For example: *gold mine sunglasses* will even give suggestions like *gold mine 
sun glasses*  or even *gold mine sung lasses* and later waste our precious 
{{maxCollationTries}}. In this case,   SUGGEST_WHEN_NOT_IN_INDEX for 
{{wordBreak}} will avoid above suggestions which we already know are not 
required.  

This is why, We faced cases wherein different {{SpellCheckComponents}}  
required different *suggestModes*. 
Also, I think _wordBreak_ and _wordJoin_  (within {{WordBreakSolrSpellCheck}} ) 
should also have different _suggestMode_ configurations because the use cases 
can really vary.  (for the above usecase itself, we want *gold* and *mine* to 
be combine to *goldmine* , so {{wordJoin}} will again have SUGGEST_ALWAYS. )

This is why in our case, we had to configure {{DirectSolrSpellChecker}} to 
{{SUGGEST_ALWAYS}} , while only {{wordBreak}}  was configured as 
{{SUGGEST_WHEN_NOT_IN_INDEX}} and so that {{wordJoin}}  still had  
{{SUGGEST_ALWAYS}} . 

> Different SpellcheckComponents should have their own suggestMode
> 
>
> Key: SOLR-10263
> URL: https://issues.apache.org/jira/browse/SOLR-10263
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Reporter: Abhishek Kumar Singh
>Priority: Minor
> Attachments: SOLR-10263.v2.patch
>
>
> As of now, common spellcheck options are applied to all the 
> SpellCheckComponents.
> This can create problem in the following case:-
>  It may be the case that we want *DirectSolrSpellChecker* to ALWAYS_SUGGEST 
> spellcheck suggestions. 
> But we may want *WordBreakSpellChecker* to suggest only if the token is not 
> in the index  (for relevance or performance reasons)  
> (SUGGEST_WHEN_NOT_IN_INDEX) . 
> *UPDATE :* Recently, we also figured out that, for 
> {{WordBreakSolrSpellChecker}} also, both - The {{WordBreak}} and {{WordJoin}} 
> should also have different suggestModes.
> We faced this problem in our case, wherein, Most of the WordJoin cases are 
> those where the words individually are valid tokens, but what the users are 
> looking for is actually a  combination (wordjoin) of the two tokens. 
> For example:-
> *gold mine sunglasses* : Here, both *gold* and *mine* are valid tokens. But 
> the actual product being looked for is *goldmine sunglasses* , where 
> *goldmine* is a brand.
> In such cases, we should recommend {{didYouMean:goldmine sunglasses}} . But 
> this wont be possible because we had set   {{SUGGEST_WHEN_NOT_IN_INDEX}}  for 
> {{WordBreakSolrSpellChecker}} (of which, WordJoin is a part)  . 
> For this, we should have separate suggestModes for both `wordJoin` as well as 
> `wordBreak`. 
> Related changes have been done at Latest PR. : 
> 

[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10595:
--

bq. Which begs the question whether we should establish a version-less URL for 
the ref-guide

This already exists - put in 
https://lucene.apache.org/solr/guide/coreadmin-api.html and it redirects to 
https://lucene.apache.org/solr/guide/6_6/coreadmin-api.html. There is a rule in 
.htaccess to redirect to the proper version, which will change as new versions 
are released:

{code}
RedirectMatch temp /solr/guide/(?!index.html)([a-z].*) /solr/guide/6_6/$1
{code}

I can't remember what issue I did that on, but it was around the time of the 
6.6 release.

> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence 
> to the new HTML version. 
> I'm undecided if this is the best idea, I can see pros and cons to it. On the 
> pro side, I think it helps firmly establish the move away from Confluence and 
> helps users adjust to the new location. But I could see the argument that 
> redirecting is overly invasive or unnecessary and we should just add a big 
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell 
> Confluence to add to the HEAD of each page to auto-redirect. With some 
> probably simple modifications to it, we could get people to the right page in 
> the HTML site: 
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1964 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1964/

4 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testIntPointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([12A4AB989312A5E9:792152930DB4BB30]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testIntPointStats(TestPointFields.java:278)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_131) - Build # 30 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/30/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerRolesTest.testOverseerRole

Error Message:
Timed out waiting for overseer state change

Stack Trace:
java.lang.AssertionError: Timed out waiting for overseer state change
at 
__randomizedtesting.SeedInfo.seed([121D6F1CECFA9990:F3D69288D749AF41]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:62)
at 
org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12550 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerRolesTest
   [junit4]   2> Creating dataDir: 

RE: New Jenkins build node

[Uwe Schindler]

Thanks Pono & Steve,

the Ivy-Bootstrap and the lucene.build.properties deployment job looks fine. I 
see successful builds already.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Steve Rowe [mailto:sar...@gmail.com]
> Sent: Tuesday, July 11, 2017 7:31 AM
> To: Daniel Pono Takamori 
> Cc: dev@lucene.apache.org; us...@infra.apache.org
> Subject: Re: New Jenkins build node
> 
> Thanks Pono!
> 
> We have a job that does the one-time node configuration that the
> Lucene/Solr jobs need.  I ran that job manually on the “lucene2” node and it
> looks like jobs are now running there.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On Jul 10, 2017, at 11:25 PM, Daniel Pono Takamori 
> wrote:
> >
> > Gavin had me make a ticket to provision a new build node [0].  It's
> > deployed the same as lucene1-us-west [1].  Now you've got 2 nodes
> > which are configured the same in puppet with one executor each with
> > the same compute specs.  Please comment on the ticket if you need any
> > other configuration or have any questions.
> >
> > Cheers,
> > -Pono
> >
> > [0] - https://issues.apache.org/jira/browse/INFRA-14004
> > [1] - https://builds.apache.org/computer/lucene2/
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

[JENKINS] Lucene-Solr-SmokeRelease-7.0 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.0/1/

No tests ran.

Build Log:
[...truncated 25761 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (42.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1294.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 69.0 MB in 0.06 sec (1253.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 79.3 MB in 0.06 sec (1255.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (131.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 50.2 MB in 0.05 sec (916.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 141.7 MB in 0.12 sec (1197.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 142.6 MB in 0.13 sec (1131.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]  
   [smoker] Started Solr server on port 8983 

[jira] [Commented] (LUCENE-6471) Highlighter mergeContiguousFragments shouldn't merge 0-score fragments

[Jim Richards (JIRA)]

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

Jim Richards commented on LUCENE-6471:
--

[~dsmiley],

I'm using [hibernate-search-orm|http://hibernate.org/search/], which is using 
5.5.4 of the Lucene libraries and UnifiedHighlighter is from 6.x. I could 
probably do some magic in {{pom.xml}} to exclude 5.5.4 but my basic test had 
too many incompatibilities.

Jim.

> Highlighter mergeContiguousFragments shouldn't merge 0-score fragments
> --
>
> Key: LUCENE-6471
> URL: https://issues.apache.org/jira/browse/LUCENE-6471
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: David Smiley
>Priority: Minor
>
> Highlighter.mergeContiguousFragments merges adjacent fragments it is given.  
> But it is given a list of fragments that do not necessarily have embedded 
> highlights (e.g. have a score of 0), and so it could grow a fragment 
> needlessly.  I never figured out why this old highlighter keeps around such 
> fragments instead of eagerly tossing them when the fragment completes, which 
> is what I think it should do.  That would address this problem and might make 
> things faster.  I'm not sure if any highlighter user wants the non-scoring 
> fragments though.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 26 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/26/

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

Error Message:
Could not load collection from ZK: c8n_1x3

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: c8n_1x3
at 
__randomizedtesting.SeedInfo.seed([ECC5FF8A53142914:6491C050FDE844EC]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1112)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:646)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:213)
at 
org.apache.solr.common.cloud.ClusterState.getSlice(ClusterState.java:143)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActive(AbstractFullDistribZkTestBase.java:1961)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf3(HttpPartitionTest.java:424)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:137)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+175) - Build # 57 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/57/
Java: 32bit/jdk-9-ea+175 -server -XX:+UseConcMarkSweepGC --illegal-access=deny

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

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:46123/collMinRf_1x3

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:46123/collMinRf_1x3
at 
__randomizedtesting.SeedInfo.seed([62E3B53AF1C2F256:EAB78AE05F3E9FAE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:637)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.realTimeGetDocId(HttpPartitionTest.java:615)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:600)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:557)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:248)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:126)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Closed] (SOLR-10993) lots of empty highlight entries

[JIRA]

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

Jan Høydahl closed SOLR-10993.
--
Resolution: Invalid

Please do not use JIRA for asking questions. You should send your question to 
the Solr User mailing list, and if it turns out that there is actually a bug in 
the software, then it is time to open an issue.

Please see http://lucene.apache.org/solr/community.html#mailing-lists-irc

Also, when posting to the list, your problem description could benefit from an 
example response, highlighting the issue you are experiencing, accompanied with 
a better description of what your documents and queries look like. See also 
https://wiki.apache.org/solr/UsingMailingLists

Closing this for now.

> lots of empty highlight entries
> ---
>
> Key: SOLR-10993
> URL: https://issues.apache.org/jira/browse/SOLR-10993
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Affects Versions: 6.6
>Reporter: Christoph Hack
>
> I have indexed documents with lots of different text fields representing 
> different properties in Solr (version 6.6). Those text fields are indexed 
> with storeOffsetsWithPositions=true and termVectors=true to speed up 
> highlighting using the UnifiedHighlighter.
> During a search, i would like to highlight those properties and I have set 
> hl.fl to wildcard match all properties. Everything is working fine, except 
> that the responses are huge.
> Every document only has a small set of properties (let's say 10 in total, 
> with 1-2 matching ones), but Solr returns in the highlighting section, a 
> dictionary with every possible property (about 10k) for every item. Nearly 
> all of the entries are empty, but decoding the keys of the map takes a 
> considerable amount of time.
> In fact, the time spent decoding this unnecessary entries is enormous. Solr 
> takes about 174ms for the search + encoding (i expect that the timing could 
> be much better) and decoding the response in Go (using the default JSON 
> package from the standard library) takes 695ms.
> I guess the offending line is somewhere around:
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java#L175
> Why is Solr generating map entries for missing values in the first place?
> The question had been posted on stackoverflow before:
> https://stackoverflow.com/questions/44846220/solr-huge-and-slow-highlighting-response-with-mostly-empty-fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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