[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647540#comment-14647540
]
Nicholas Knize commented on LUCENE-6699:
bq. Right, but you'd be comparing 2 sines, 2 cosines, and 1 sqrt against only
the cost of unpacking
Encoding/Decoding ECEF into 96 Bits:
{noformat}
Avg computation: 664.6969666857143 ns Trials: 3500 Total time:
23264.393834 ms
Avg computation: 664.829008375 ns Trials: 4000 Total time: 26593.160335 ms
Avg computation: 667.362547134 ns Trials: 4500 Total time:
30031.314621 ms
Avg computation: 668.46880436 ns Trials: 5000 Total time: 33423.440218 ms
Avg computation: 667.8703028909091 ns Trials: 5500 Total time:
36732.866659 ms
Avg computation: 669.375388866 ns Trials: 6000 Total time:
40162.523332 ms
Avg computation: 668.4362739230769 ns Trials: 6500 Total time:
43448.357805 ms
Avg computation: 667.9539851 ns Trials: 7000 Total time: 46756.778957 ms
Avg computation: 667.363829733 ns Trials: 7500 Total time:
50052.28723 ms
Avg computation: 675.024778375 ns Trials: 8000 Total time: 54001.98227 ms
Avg computation: 674.1673578352941 ns Trials: 8500 Total time:
57304.225416 ms
Avg computation: 673.472343978 ns Trials: 9000 Total time:
60612.510958 ms
Avg computation: 673.0372402842105 ns Trials: 9500 Total time:
63938.537827 ms
Avg computation: 672.55224382 ns Trials: 1 Total time: 67255.224382 ms
{noformat}
Compared to packing/unpacking lat/lon into 64 bits using using GeoPointField
morton bit twiddling:
{noformat}
Avg computation: 60.397136 ns Trials: 3500 Total time: 2113.89976 ms
Avg computation: 61.6391708 ns Trials: 4000 Total time: 2465.566832 ms
Avg computation: 62.7440744 ns Trials: 4500 Total time:
2823.48334 ms
Avg computation: 63.5108 ns Trials: 5000 Total time: 3175.54 ms
Avg computation: 64.18207294545455 ns Trials: 5500 Total time:
3530.014012 ms
Avg computation: 64.7368465667 ns Trials: 6000 Total time:
3884.210794 ms
Avg computation: 65.18073341538461 ns Trials: 6500 Total time:
4236.747672 ms
Avg computation: 65.5902512 ns Trials: 7000 Total time: 4591.317584 ms
Avg computation: 65.0290225333 ns Trials: 7500 Total time: 4877.17669
ms
Avg computation: 63.6249806 ns Trials: 8000 Total time: 5089.998448 ms
Avg computation: 62.4193206 ns Trials: 8500 Total time: 5305.642251 ms
Avg computation: 61.34443397776 ns Trials: 9000 Total time:
5520.999058 ms
Avg computation: 61.402236642105265 ns Trials: 9500 Total time:
5833.212481 ms
Avg computation: 61.10019762 ns Trials: 1 Total time: 6110.019762 ms
{noformat}
So using the 3D BitSet approach is 10 times longer, with the obvious culprit
being the for loop for each bit. This can be optimized, though, using a 3-way
bit twiddle and 2 longs if a 64 bit 3D packing yields unacceptable loss of
precision.
Integrate lat/lon BKD and spatial3d
---
Key: LUCENE-6699
URL: https://issues.apache.org/jira/browse/LUCENE-6699
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: Geo3DPacking.java
I'm opening this for discussion, because I'm not yet sure how to do
this integration, because of my ignorance about spatial in general and
spatial3d in particular :)
Our BKD tree impl is very fast at doing lat/lon shape intersection
(bbox, polygon, soon distance: LUCENE-6698) against previously indexed
points.
I think to integrate with spatial3d, we would first need to record
lat/lon/z into doc values. Somewhere I saw discussion about how we
could stuff all 3 into a single long value with acceptable precision
loss? Or, we could use BinaryDocValues? We need all 3 dims available
to do the fast per-hit query time filtering.
But, second: what do we index into the BKD tree? Can we just index
earth surface lat/lon, and then at query time is spatial3d able to
give me an enclosing surface lat/lon bbox for a 3d shape? Or
... must we index all 3 dimensions into the BKD tree (seems like this
could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6625: - Attachment: SOLR-6625.patch fixed the test error HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-6625: - Attachment: SOLR-6625.patch HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647540#comment-14647540
]
Nicholas Knize edited comment on LUCENE-6699 at 7/30/15 12:23 PM:
--
bq. Right, but you'd be comparing 2 sines, 2 cosines, and 1 sqrt against only
the cost of unpacking
Encoding/Decoding ECEF into 96 Bits:
{noformat}
Avg computation: 664.6969666857143 ns Trials: 3500 Total time:
23264.393834 ms
Avg computation: 664.829008375 ns Trials: 4000 Total time: 26593.160335 ms
Avg computation: 667.362547134 ns Trials: 4500 Total time:
30031.314621 ms
Avg computation: 668.46880436 ns Trials: 5000 Total time: 33423.440218 ms
Avg computation: 667.8703028909091 ns Trials: 5500 Total time:
36732.866659 ms
Avg computation: 669.375388866 ns Trials: 6000 Total time:
40162.523332 ms
Avg computation: 668.4362739230769 ns Trials: 6500 Total time:
43448.357805 ms
Avg computation: 667.9539851 ns Trials: 7000 Total time: 46756.778957 ms
Avg computation: 667.363829733 ns Trials: 7500 Total time:
50052.28723 ms
Avg computation: 675.024778375 ns Trials: 8000 Total time: 54001.98227 ms
Avg computation: 674.1673578352941 ns Trials: 8500 Total time:
57304.225416 ms
Avg computation: 673.472343978 ns Trials: 9000 Total time:
60612.510958 ms
Avg computation: 673.0372402842105 ns Trials: 9500 Total time:
63938.537827 ms
Avg computation: 672.55224382 ns Trials: 1 Total time: 67255.224382 ms
{noformat}
Compared to packing/unpacking lat/lon into 64 bits using using GeoPointField
morton bit twiddling:
{noformat}
Avg computation: 60.397136 ns Trials: 3500 Total time: 2113.89976 ms
Avg computation: 61.6391708 ns Trials: 4000 Total time: 2465.566832 ms
Avg computation: 62.7440744 ns Trials: 4500 Total time:
2823.48334 ms
Avg computation: 63.5108 ns Trials: 5000 Total time: 3175.54 ms
Avg computation: 64.18207294545455 ns Trials: 5500 Total time:
3530.014012 ms
Avg computation: 64.7368465667 ns Trials: 6000 Total time:
3884.210794 ms
Avg computation: 65.18073341538461 ns Trials: 6500 Total time:
4236.747672 ms
Avg computation: 65.5902512 ns Trials: 7000 Total time: 4591.317584 ms
Avg computation: 65.0290225333 ns Trials: 7500 Total time: 4877.17669
ms
Avg computation: 63.6249806 ns Trials: 8000 Total time: 5089.998448 ms
Avg computation: 62.4193206 ns Trials: 8500 Total time: 5305.642251 ms
Avg computation: 61.34443397776 ns Trials: 9000 Total time:
5520.999058 ms
Avg computation: 61.402236642105265 ns Trials: 9500 Total time:
5833.212481 ms
Avg computation: 61.10019762 ns Trials: 1 Total time: 6110.019762 ms
{noformat}
So using the 3D BitSet approach is 10 times longer, with the obvious culprit
being the for loop for each bit. This can be optimized, though, using a 3-way
bit twiddle and 2 longs if a 64 bit 3D packing yields unacceptable loss of
precision.
bq. so I'd think a benchmarking should not overemphasize seeks as being costly
Maybe not. But it does depend on the on-disk representation of the tree (and I
typically don't use SSDs as an excuse for not paying attention to good file
layout). I was mentioning this in the context of index size as a function of a
wasteful vs. efficient encoding.
was (Author: nknize):
bq. Right, but you'd be comparing 2 sines, 2 cosines, and 1 sqrt against only
the cost of unpacking
Encoding/Decoding ECEF into 96 Bits:
{noformat}
Avg computation: 664.6969666857143 ns Trials: 3500 Total time:
23264.393834 ms
Avg computation: 664.829008375 ns Trials: 4000 Total time: 26593.160335 ms
Avg computation: 667.362547134 ns Trials: 4500 Total time:
30031.314621 ms
Avg computation: 668.46880436 ns Trials: 5000 Total time: 33423.440218 ms
Avg computation: 667.8703028909091 ns Trials: 5500 Total time:
36732.866659 ms
Avg computation: 669.375388866 ns Trials: 6000 Total time:
40162.523332 ms
Avg computation: 668.4362739230769 ns Trials: 6500 Total time:
43448.357805 ms
Avg computation: 667.9539851 ns Trials: 7000 Total time: 46756.778957 ms
Avg computation: 667.363829733 ns Trials: 7500 Total time:
50052.28723 ms
Avg computation: 675.024778375 ns Trials: 8000 Total time: 54001.98227 ms
Avg computation: 674.1673578352941 ns Trials: 8500 Total time:
57304.225416 ms
Avg computation: 673.472343978 ns Trials: 9000 Total time:
60612.510958 ms
Avg computation: 673.0372402842105 ns Trials: 9500 Total time:
63938.537827 ms
Avg computation: 672.55224382 ns Trials: 1 Total time: 67255.224382 ms
{noformat}
Compared to packing/unpacking lat/lon into 64 bits using using GeoPointField
morton bit twiddling:
{noformat}
Avg computation:
[jira] [Updated] (SOLR-5894) Speed up high-cardinality facets with sparse counters
[ https://issues.apache.org/jira/browse/SOLR-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated SOLR-5894: - Description: Multiple performance enhancements to Solr String faceting. * Sparse counters, switching the constant time overhead of extracting top-X terms with time overhead linear to result set size * Counter re-use for reduced garbage collection and lower per-call overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly improving the performance of distributed faceting * In-segment threaded faceting * Regexp based white- and black-listing of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10. Source, detailed description and directly usable WAR at http://tokee.github.io/lucene-solr/ This project has grown beyond a simple patch and will require a fair amount of co-operation with a committer to get into Solr. Splitting into smaller issues is a possibility. was: Multiple performance enhancements to Solr String faceting. * Sparse counters, switching the constant time overhead of extracting top-X terms with time linear to result set size * Counter re-use for reduced garbage collection and lower per-call overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly reducing the overhead of distributed faceting * In-segment threaded faceting * Regexp based white- and black-listing of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10 and available as source and directly usable WAR at http://tokee.github.io/lucene-solr/ Speed up high-cardinality facets with sparse counters - Key: SOLR-5894 URL: https://issues.apache.org/jira/browse/SOLR-5894 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 4.7.1 Reporter: Toke Eskildsen Priority: Minor Labels: faceted-search, faceting, memory, performance Attachments: SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894.patch, SOLR-5894_test.zip, SOLR-5894_test.zip, SOLR-5894_test.zip, SOLR-5894_test.zip, SOLR-5894_test.zip, author_7M_tags_1852_logged_queries_warmed.png, sparse_200docs_fc_cutoff_20140403-145412.png, sparse_500docs_20140331-151918_multi.png, sparse_500docs_20140331-151918_single.png, sparse_5051docs_20140328-152807.png Multiple performance enhancements to Solr String faceting. * Sparse counters, switching the constant time overhead of extracting top-X terms with time overhead linear to result set size * Counter re-use for reduced garbage collection and lower per-call overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly improving the performance of distributed faceting * In-segment threaded faceting * Regexp based white- and black-listing of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10. Source, detailed description and directly usable WAR at http://tokee.github.io/lucene-solr/ This project has grown beyond a simple patch and will require a fair amount of co-operation with a committer to get into Solr. Splitting into smaller issues is a possibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6647) Add GeoHash String Utilities to core GeoUtils
[ https://issues.apache.org/jira/browse/LUCENE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6647: --- Attachment: LUCENE-6647.patch Updated patch that depends on LUCENE-6704 - changes morton encoding to use full 64 bits, 32 bits per lat/lon. Add GeoHash String Utilities to core GeoUtils - Key: LUCENE-6647 URL: https://issues.apache.org/jira/browse/LUCENE-6647 Project: Lucene - Core Issue Type: New Feature Reporter: Nicholas Knize Attachments: LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch GeoPointField uses morton encoding to efficiently pack lat/lon values into a single long. GeoHashing effectively does the same thing but uses base 32 encoding to represent this long value as a human readable string. Many user applications already use the string representation of the hash. This issue simply adds the base32 string representation of the already computed morton code. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 752 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/752/ 3 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=23498, name=collection0, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=23498, name=collection0, state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest] Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:38139/f_mmi: collection already exists: awholynewstresscollection_collection0_6 at __randomizedtesting.SeedInfo.seed([6EE885A312A59D56]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:887) REGRESSION: org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:53847/vg_zj/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:53847/vg_zj/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([6EE885A312A59D56:E6BCBA79BC59F0AE]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:332) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at
[jira] [Assigned] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-6625: Assignee: Noble Paul (was: Gregory Chanan) HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13662 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13662/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([DBDE1E937ECAD389:D3BE6BBF71C4FB82]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Comment Edited] (SOLR-7833) Add new Solr book 'Apache Solr 3.1 Cookbook' to selection of Solr books and news.
[ https://issues.apache.org/jira/browse/SOLR-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647492#comment-14647492 ] Zico Fernandes edited comment on SOLR-7833 at 7/30/15 11:37 AM: [~gro] Will you be able to create a patch for this? was (Author: zico): [~gro] Can you create a patch for this? Add new Solr book 'Apache Solr 3.1 Cookbook' to selection of Solr books and news. - Key: SOLR-7833 URL: https://issues.apache.org/jira/browse/SOLR-7833 Project: Solr Issue Type: Task Reporter: Zico Fernandes Attachments: Solr Cookbook_Third Edition.jpg Rafał Kuć is proud to finally announce the book Solr Cookbook - Third Edition by Packt Publishing. This edition will specifically appeal to developers who wish to quickly get to grips with the changes and new features of Apache Solr 5. Solr Cookbook - Third Edition has over 100 easy to follow recipes to solve real-time problems related to Apache Solr 4.x and 5.0 effectively. Starting with vital information on setting up Solr, the developer will quickly progress to analyzing their text data through querying and performance improvement. Finally, they will explore real-life situations, where Solr can be used to simplify daily collection handling. With numerous practical chapters centered on important Solr techniques and methods Solr Cookbook - Third Edition will guide intermediate Solr Developers who are willing to learn and implement Pro-level practices, techniques, and solutions. Click here to read more about the Solr Cookbook - Third Edition: https://www.packtpub.com/big-data-and-business-intelligence/solr-cookbook-third-edition -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: numberOfDocuments in SimilarityBase
I think so. When adding this statistic (lucene 4.0), personally I
really wanted to fix it everywhere. But we had the problem of
backwards compatibility, and its bad to use different formulas for
different segments even if it works...
Nowadays we dont have lucene 3 segments around anymore, so I think we
should fix this. Want to open an issue?
On Wed, Jul 29, 2015 at 10:45 AM, Ahmet Arslan
iori...@yahoo.com.invalid wrote:
Hello List,
SimilarityBase uses CollectionStatistics#maxDoc() for numberOfDocuments.
Shouldn't it be field-based CollectionStatistics#docCount()?
--- core/src/java/org/apache/lucene/search/similarities/SimilarityBase.java
(revision 1693268)
+++ core/src/java/org/apache/lucene/search/similarities/SimilarityBase.java
(working copy)
@@ -102,7 +102,7 @@
protected void fillBasicStats(BasicStats stats, CollectionStatistics
collectionStats, TermStatistics termStats) {
// #positions(field) must be = #positions(term)
assert collectionStats.sumTotalTermFreq() == -1 ||
collectionStats.sumTotalTermFreq() = termStats.totalTermFreq();
-long numberOfDocuments = collectionStats.maxDoc();
+long numberOfDocuments = collectionStats.docCount();
Thanks,
Ahmet
-
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-7833) Add new Solr book 'Apache Solr 3.1 Cookbook' to selection of Solr books and news.
[ https://issues.apache.org/jira/browse/SOLR-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647492#comment-14647492 ] Zico Fernandes commented on SOLR-7833: -- [~gro] Can you create a patch for this? Add new Solr book 'Apache Solr 3.1 Cookbook' to selection of Solr books and news. - Key: SOLR-7833 URL: https://issues.apache.org/jira/browse/SOLR-7833 Project: Solr Issue Type: Task Reporter: Zico Fernandes Attachments: Solr Cookbook_Third Edition.jpg Rafał Kuć is proud to finally announce the book Solr Cookbook - Third Edition by Packt Publishing. This edition will specifically appeal to developers who wish to quickly get to grips with the changes and new features of Apache Solr 5. Solr Cookbook - Third Edition has over 100 easy to follow recipes to solve real-time problems related to Apache Solr 4.x and 5.0 effectively. Starting with vital information on setting up Solr, the developer will quickly progress to analyzing their text data through querying and performance improvement. Finally, they will explore real-life situations, where Solr can be used to simplify daily collection handling. With numerous practical chapters centered on important Solr techniques and methods Solr Cookbook - Third Edition will guide intermediate Solr Developers who are willing to learn and implement Pro-level practices, techniques, and solutions. Click here to read more about the Solr Cookbook - Third Edition: https://www.packtpub.com/big-data-and-business-intelligence/solr-cookbook-third-edition -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647128#comment-14647128
]
Nicholas Knize edited comment on LUCENE-6699 at 7/30/15 12:00 PM:
--
bq. The obvious alternative would be to store just lat/lon, exactly like is
done for Nicholas's code
Just to clarify, so there's no confusion, the attached code converts from
lat/lon to ECEF (either full range in meters, or scaled to the unit spheroid)
and stores the result in a 96 bit BitSet. GeoPointField stores encoded lat/lon
(if that's what you were referring to). The attached was intended to be used
for a Geo3d integration w/ GeoPointField.
bq. I expect the conversion for every record would turn out to be more
expensive.
Just to note again, the conversion from lat/lon to ECEF XYZ is a non-iterative
conversion (2 sines, 2 cosines, 1 sqrt). Conversion cost vs. wateful
representation is the interesting question, so I threw together a quick
encoding/decoding benchmark (on my i7 16GB System76) and ran it on 100M points
(converting from lla to ECEF and back). The law of large numbers took over at
around 35M. For interest the results are provided:
{noformat}
Avg computation: 620.431975767 ns Trials: 3000 Total time:
18612.959273 ms
Avg computation: 621.3008362285715 ns Trials: 3500 Total time:
21745.529268 ms
Avg computation: 621.582647925 ns Trials: 4000 Total time: 24863.305917 ms
Avg computation: 621.372458955 ns Trials: 4500 Total time:
27961.760653 ms
Avg computation: 621.16271364 ns Trials: 5000 Total time: 31058.135682 ms
Avg computation: 621.3857686909091 ns Trials: 5500 Total time:
34176.217278 ms
Avg computation: 621.8110524 ns Trials: 6000 Total time: 37308.663144 ms
Avg computation: 621.6768083230769 ns Trials: 6500 Total time:
40408.992541 ms
Avg computation: 621.5324306714285 ns Trials: 7000 Total time:
43507.270147 ms
Avg computation: 621.444053693 ns Trials: 7500 Total time:
46608.304027 ms
Avg computation: 621.7594845875 ns Trials: 8000 Total time: 49740.758767
ms
Avg computation: 621.9327540705882 ns Trials: 8500 Total time:
52864.284096 ms
Avg computation: 621.942943456 ns Trials: 9000 Total time:
55974.864911 ms
Avg computation: 621.8868688947368 ns Trials: 9500 Total time:
59079.252545 ms
Avg computation: 621.98037608 ns Trials: 1 Total time: 62198.037608 ms
{noformat}
Again, those are both conversions to ECEF and back to LLA. So roughly 1 minute
for 100M points. Halve those numbers and you have the cost for converting
either direction.
Next we could benchmark tree access and compare? I suspect traversal cost
should be a function of the on-disk representation and chosen split method
(that's where RTrees tend to become costly). Since BKD splits a sorted space,
and it can exploit file system cache? I suspect there aren't many random seeks?
Seems benchmarking might be relatively straightforward?
was (Author: nknize):
bq. The obvious alternative would be to store just lat/lon, exactly like is
done for Nicholas's code
Just to clarify, so there's no confusion, the attached code converts from
lat/lon to ECEF (either full range in meters, or scaled to the unit spheroid)
and stores the result in a 96 bit BitSet. GeoPointField stores encoded lat/lon
(if that's what you were referring to). The attached was intended to be used
for a Geo3d integration w/ GeoPointField.
bq. I expect the conversion for every record would turn out to be more
expensive.
Just to note again, the conversion from lat/lon to ECEF XYZ is a non-iterative
conversion (2 sines, 2 cosines, 1 sqrt). Conversion cost vs. wateful
representation is the interesting question, so I threw together a quick
encoding/decoding benchmark (on my i7 16GB System76) and ran it on 1B points
(converting from lla to ECEF and back). The law of large numbers took over at
around 350M. For interest the results are provided:
{noformat}
Avg computation: 620.431975767 ns Trials: 3000 Total time:
18612.959273 ms
Avg computation: 621.3008362285715 ns Trials: 3500 Total time:
21745.529268 ms
Avg computation: 621.582647925 ns Trials: 4000 Total time: 24863.305917 ms
Avg computation: 621.372458955 ns Trials: 4500 Total time:
27961.760653 ms
Avg computation: 621.16271364 ns Trials: 5000 Total time: 31058.135682 ms
Avg computation: 621.3857686909091 ns Trials: 5500 Total time:
34176.217278 ms
Avg computation: 621.8110524 ns Trials: 6000 Total time: 37308.663144 ms
Avg computation: 621.6768083230769 ns Trials: 6500 Total time:
40408.992541 ms
Avg computation: 621.5324306714285 ns Trials: 7000 Total time:
43507.270147 ms
Avg computation: 621.444053693 ns Trials: 7500 Total time:
46608.304027 ms
Avg computation:
[jira] [Updated] (SOLR-5894) Speed up high-cardinality facets with sparse counters
[ https://issues.apache.org/jira/browse/SOLR-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated SOLR-5894: - Description: Multiple performance enhancements to Solr String faceting. * Sparse counters, switching the constant time overhead of extracting top-X terms with time linear to result set size * Counter re-use for reduced garbage collection and lower per-call overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly reducing the overhead of distributed faceting * In-segment threaded faceting * Regexp based white- and black-listing of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10 and available as source and directly usable WAR at http://tokee.github.io/lucene-solr/ was: Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags. The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparse-facet-counting-on-a-real-index/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain int-array of size #unique_tags. Switching to a sparse structure, where only the tag counters 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to non-sparse-mode without a switch-penalty, when the sparse-threshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparse-sets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single- and multi-value, with and without doc-values. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=1 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for auto-selecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.packed=true use PackecInts for counters instead of int[]. This saves memory, but performance will differ. Whether performance will be better or worse depends on the corpus. Experiment with it. * facet.sparse.cutoff=0.90 if the estimated number (based on hitcount) of unique tags in the search result exceeds this fraction of the sparse tracker, do not perform sparse tracking. The estimate is based on the assumption that references from documents to tags are distributed randomly. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and re-using a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=truefacet.field=myfieldfacet.mincount=1facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. Speed up high-cardinality facets with sparse counters - Key: SOLR-5894 URL: https://issues.apache.org/jira/browse/SOLR-5894 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 4.7.1 Reporter: Toke Eskildsen Priority: Minor
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647584#comment-14647584 ] Karl Wright commented on LUCENE-6699: - If the decision is made to use (x,y,z) encoding rather than (lat,lon), then FWIW I think the right way forward with spatial3d would be to extend the current Bounds infrastructure to allow the finding of x,y,z bounds for a shape, rather than just lat/lon. I've thought about this for a day and have concluded it would be far and away the fastest solution, since computing the Bounds for any shape would need to be done only once. Once x, y, and z bounds are known for a shape, the BKD code itself can make most of its decisions itself, without much computation at all, for most of the recursive steps. Only when descending *within* the computed bounds would it be necessary to construct a GeoArea XYZArea object to determine the exact relationship between a 3d rectangle and the specified GeoShape. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6531) Make PhraseQuery immutable
[ https://issues.apache.org/jira/browse/LUCENE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647690#comment-14647690 ] Terry Smith commented on LUCENE-6531: - [~jpountz] The PhraseQuery.Builder setter methods are all void, where as the ones for BooleanQuery and BlendedTermQuery return the Builder itself. Can the set/add methods on PhraseQuery.Builder return this to make the various Query builders consistent with each other? Make PhraseQuery immutable -- Key: LUCENE-6531 URL: https://issues.apache.org/jira/browse/LUCENE-6531 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3, 6.0 Attachments: LUCENE-6531.patch, LUCENE-6531.patch Mutable queries are an issue for automatic filter caching since modifying a query after it has been put into the cache will corrupt the cache. We should make all queries immutable (up to the boost) to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6704) GeoPointInBBox/Distance queries can throw OOME
[ https://issues.apache.org/jira/browse/LUCENE-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647749#comment-14647749 ] Nicholas Knize commented on LUCENE-6704: bq. Can you add a dedicated standalone test that today hits OOME and then with this patch doesn't? Sure thing! I'll isolate one of the OOME failures from testRandom() so before/after patch validation can be run. bq. Why is GeoPointDistanceQuery not final anymore? Seems like nothing wants to extend it... That was a change intended for a new issue. I've added a GeoPointDistanceRangeQuery that extends GeoPointDistanceQuery. I'll remove it from this patch and apply it in a new issue. Sorry for that confusion :) GeoPointInBBox/Distance queries can throw OOME -- Key: LUCENE-6704 URL: https://issues.apache.org/jira/browse/LUCENE-6704 Project: Lucene - Core Issue Type: Bug Reporter: Nicholas Knize Attachments: LUCENE-6704.patch After investigating LUCENE-6685 the performance issues and improvements related to GeoPointInBBox/Distance queries could be categorized into two separate issues: 1. OOME caused by an unnecessary number of ranges computed for Point Distance Queries (bug in the GeoPointTermEnum base class where the bounding box was used for intersections instead of the point radius) 2. API improvements providing configurable detail parameters. This issue addresses 1. LUCENE-6685 will further investigate the need for 2 (after working 1 and correcting for unnecessary range detail, it looks like 2 may not be needed) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6631) Lucene Document Classification
[ https://issues.apache.org/jira/browse/LUCENE-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647770#comment-14647770 ] Tommaso Teofili commented on LUCENE-6631: - Alessandro, thanks for your patch, I'll take a look and let you know shortly. Lucene Document Classification -- Key: LUCENE-6631 URL: https://issues.apache.org/jira/browse/LUCENE-6631 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Labels: classification Attachments: LUCENE-6631.patch Currently the Lucene Classification module supports the classification for an input text using the Lucene index as a trained model. This improvement is adding to the module a set of components to provide Document classification ( where the Document is a Lucene document ). All selected fields from the Document will have their part in the classification ( including the use of the proper Analyzer per field). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7739) Lucene Classification Integration - UpdateRequestProcessor
[ https://issues.apache.org/jira/browse/SOLR-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647768#comment-14647768 ] Tommaso Teofili commented on SOLR-7739: --- Alessandro, thanks for your patch, I'll take a look and let you know shortly. Lucene Classification Integration - UpdateRequestProcessor -- Key: SOLR-7739 URL: https://issues.apache.org/jira/browse/SOLR-7739 Project: Solr Issue Type: New Feature Components: update Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, index-time, update.chain, updateProperties Attachments: SOLR-7739.patch It would be nice to have an UpdateRequestProcessor to interact with the Lucene Classification Module and provide an easy way of auto classifying Solr Documents on indexing. Documentation will be provided with the patch A first design will be provided soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6531) Make PhraseQuery immutable
[ https://issues.apache.org/jira/browse/LUCENE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647701#comment-14647701 ] Terry Smith commented on LUCENE-6531: - Awesome, you rock! Make PhraseQuery immutable -- Key: LUCENE-6531 URL: https://issues.apache.org/jira/browse/LUCENE-6531 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3, 6.0 Attachments: LUCENE-6531.patch, LUCENE-6531.patch Mutable queries are an issue for automatic filter caching since modifying a query after it has been put into the cache will corrupt the cache. We should make all queries immutable (up to the boost) to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6707) PhraseQuery.Builder methods should return this to allow chaining
[ https://issues.apache.org/jira/browse/LUCENE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647713#comment-14647713 ] Uwe Schindler commented on LUCENE-6707: --- +1 -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de PhraseQuery.Builder methods should return this to allow chaining Key: LUCENE-6707 URL: https://issues.apache.org/jira/browse/LUCENE-6707 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6707.patch Currently they return void, so you can't chain. Returning this would make it consistent with BooleanQuery.Builder. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6631) Lucene Document Classification
[ https://issues.apache.org/jira/browse/LUCENE-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647757#comment-14647757 ] Alessandro Benedetti commented on LUCENE-6631: -- Any feedback on this guys ? Cheers Lucene Document Classification -- Key: LUCENE-6631 URL: https://issues.apache.org/jira/browse/LUCENE-6631 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Labels: classification Attachments: LUCENE-6631.patch Currently the Lucene Classification module supports the classification for an input text using the Lucene index as a trained model. This improvement is adding to the module a set of components to provide Document classification ( where the Document is a Lucene document ). All selected fields from the Document will have their part in the classification ( including the use of the proper Analyzer per field). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7739) Lucene Classification Integration - UpdateRequestProcessor
[ https://issues.apache.org/jira/browse/SOLR-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647752#comment-14647752 ] Alessandro Benedetti commented on SOLR-7739: Any feedback guys ? Lucene Classification Integration - UpdateRequestProcessor -- Key: SOLR-7739 URL: https://issues.apache.org/jira/browse/SOLR-7739 Project: Solr Issue Type: New Feature Components: update Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, index-time, update.chain, updateProperties Attachments: SOLR-7739.patch It would be nice to have an UpdateRequestProcessor to interact with the Lucene Classification Module and provide an easy way of auto classifying Solr Documents on indexing. Documentation will be provided with the patch A first design will be provided soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6654) KNearestNeighborClassifier not taking in consideration Class ranking
[ https://issues.apache.org/jira/browse/LUCENE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647769#comment-14647769 ] Tommaso Teofili commented on LUCENE-6654: - Alessandro, thanks for your patch, I'll take a look and let you know shortly. KNearestNeighborClassifier not taking in consideration Class ranking Key: LUCENE-6654 URL: https://issues.apache.org/jira/browse/LUCENE-6654 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, knn Attachments: LUCENE-6654.patch Currently the KNN Classifier assign the score for a ClassificationResult, based only on the frequency of the class in the top K results. This is conceptually a simplification. Actually the ranking must take a part. If not this can happen : Top 4 1) Class1 2) Class1 3) Class2 4) Class2 As a result of this Top 4 , both the classes will have the same score. But the expected result is that Class1 has a better score, as the MLT score the documents accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647778#comment-14647778 ] Michael McCandless commented on LUCENE-6699: I can't follow all the spatial-heavy discussion here, but: bq. Since BKD splits a sorted space, and it can exploit file system cache? BKD tree's tree (the internal nodes) is already forced into heap, at least in the current impl. So walking that tree should always be fast, and then there's only seeking once we hit the leaf nodes. But that seeking should be sequential walk through the file... bq. If the decision is made to use (x,y,z) encoding rather than (lat,lon), bq. So, if you turn the BKD descent into something other than (x,y,z), it would imply that you store points for records in something other than (x,y,z) too, no? I think the encoding for each point's value can be different from what the BKD tree uses? I suspect the points shoudl use (x,y,z) encoding when stored in doc-values per document, because when we need to filter hits for the BKD leaf cells overlapping the shape's boundary, we want to take advantage of the fast math in (x,y,z) space that spatial3d gives us? But then, for the inner-nodes (split values) for the BKD tree, we could use either (lat,lon) or (x,y,z), whichever gives us fastest shape relation computations? At each step in the recursion, BKD tree must check a split in one dimension against the query shape. Integrate lat/lon BKD and spatial3d --- Key: LUCENE-6699 URL: https://issues.apache.org/jira/browse/LUCENE-6699 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: Geo3DPacking.java I'm opening this for discussion, because I'm not yet sure how to do this integration, because of my ignorance about spatial in general and spatial3d in particular :) Our BKD tree impl is very fast at doing lat/lon shape intersection (bbox, polygon, soon distance: LUCENE-6698) against previously indexed points. I think to integrate with spatial3d, we would first need to record lat/lon/z into doc values. Somewhere I saw discussion about how we could stuff all 3 into a single long value with acceptable precision loss? Or, we could use BinaryDocValues? We need all 3 dims available to do the fast per-hit query time filtering. But, second: what do we index into the BKD tree? Can we just index earth surface lat/lon, and then at query time is spatial3d able to give me an enclosing surface lat/lon bbox for a 3d shape? Or ... must we index all 3 dimensions into the BKD tree (seems like this could be somewhat wasteful)? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13482 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13482/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.rule.RulesTest Error Message: ERROR: SolrIndexSearcher opens=25 closes=24 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=25 closes=24 at __randomizedtesting.SeedInfo.seed([8924B6740E1CF03E]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.rule.RulesTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.rule.RulesTest: 1) Thread[id=10232, name=searcherExecutor-5601-thread-1, state=WAITING, group=TGRP-RulesTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)2) Thread[id=10204, name=qtp742053195-10204, state=RUNNABLE, group=TGRP-RulesTest] at java.util.WeakHashMap.get(WeakHashMap.java:471) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.calcEtag(HttpCacheHeaderUtil.java:101) at org.apache.solr.servlet.cache.HttpCacheHeaderUtil.doCacheHeaderValidation(HttpCacheHeaderUtil.java:219) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:444) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at
[jira] [Created] (LUCENE-6707) PhraseQuery.Builder methods should return this to allow chaining
Adrien Grand created LUCENE-6707: Summary: PhraseQuery.Builder methods should return this to allow chaining Key: LUCENE-6707 URL: https://issues.apache.org/jira/browse/LUCENE-6707 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Currently they return void, so you can't chain. Returning this would make it consistent with BooleanQuery.Builder. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6707) PhraseQuery.Builder methods should return this to allow chaining
[ https://issues.apache.org/jira/browse/LUCENE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6707: - Priority: Minor (was: Major) PhraseQuery.Builder methods should return this to allow chaining Key: LUCENE-6707 URL: https://issues.apache.org/jira/browse/LUCENE-6707 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Priority: Minor Currently they return void, so you can't chain. Returning this would make it consistent with BooleanQuery.Builder. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6704) GeoPointInBBox/Distance queries can throw OOME
[ https://issues.apache.org/jira/browse/LUCENE-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647739#comment-14647739 ] Michael McCandless commented on LUCENE-6704: I'm a little lost on this issue. It's focusing on fixing the OOME? But the patch seems to do much more (good things!). Can you add a dedicated standalone test that today hits OOME and then with this patch doesn't? To confirm the patch is fixing OOMEs in both GeoPointInBBoxQuery and GeoPointDistanceQuery... Why is GeoPointDistanceQuery not final anymore? Seems like nothing wants to extend it... I like the added javadocs, and BigInteger usage is always fun :) GeoPointInBBox/Distance queries can throw OOME -- Key: LUCENE-6704 URL: https://issues.apache.org/jira/browse/LUCENE-6704 Project: Lucene - Core Issue Type: Bug Reporter: Nicholas Knize Attachments: LUCENE-6704.patch After investigating LUCENE-6685 the performance issues and improvements related to GeoPointInBBox/Distance queries could be categorized into two separate issues: 1. OOME caused by an unnecessary number of ranges computed for Point Distance Queries (bug in the GeoPointTermEnum base class where the bounding box was used for intersections instead of the point radius) 2. API improvements providing configurable detail parameters. This issue addresses 1. LUCENE-6685 will further investigate the need for 2 (after working 1 and correcting for unnecessary range detail, it looks like 2 may not be needed) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3386 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3386/
1 tests failed.
REGRESSION: org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test
Error Message:
Didn't see replicas [core_node1, core_node3] come up within 9 ms!
ClusterState: DocCollection(c8n_1x3_lf)={ router:{name:compositeId},
maxShardsPerNode:1, replicationFactor:3, autoAddReplicas:false,
shards:{shard1:{ range:8000-7fff,
state:active, replicas:{ core_node1:{
state:recovering, node_name:127.0.0.1:51965_mu%2Ftq,
base_url:http://127.0.0.1:51965/mu/tq;,
core:c8n_1x3_lf_shard1_replica3}, core_node2:{
state:down, node_name:127.0.0.1:49657_mu%2Ftq,
base_url:http://127.0.0.1:49657/mu/tq;,
core:c8n_1x3_lf_shard1_replica2}, core_node3:{
state:active, node_name:127.0.0.1:54737_mu%2Ftq,
base_url:http://127.0.0.1:54737/mu/tq;,
core:c8n_1x3_lf_shard1_replica1, leader:true}
Stack Trace:
java.lang.AssertionError: Didn't see replicas [core_node1, core_node3] come up
within 9 ms! ClusterState: DocCollection(c8n_1x3_lf)={
router:{name:compositeId},
maxShardsPerNode:1,
replicationFactor:3,
autoAddReplicas:false,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
core_node1:{
state:recovering,
node_name:127.0.0.1:51965_mu%2Ftq,
base_url:http://127.0.0.1:51965/mu/tq;,
core:c8n_1x3_lf_shard1_replica3},
core_node2:{
state:down,
node_name:127.0.0.1:49657_mu%2Ftq,
base_url:http://127.0.0.1:49657/mu/tq;,
core:c8n_1x3_lf_shard1_replica2},
core_node3:{
state:active,
node_name:127.0.0.1:54737_mu%2Ftq,
base_url:http://127.0.0.1:54737/mu/tq;,
core:c8n_1x3_lf_shard1_replica1,
leader:true}
at
__randomizedtesting.SeedInfo.seed([34533157CDBD13BD:BC070E8D63417E45]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.HttpPartitionTest.waitToSeeReplicasActive(HttpPartitionTest.java:565)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
[jira] [Updated] (LUCENE-6706) Support Payload scoring for SpanOrQuery
[ https://issues.apache.org/jira/browse/LUCENE-6706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-6706: -- Attachment: LUCENE-6706.patch Here's a patch adding a new PayloadScoreQuery that takes a SpanQuery and a PayloadFunction. PayloadTermQuery and PayloadNearQuery are deprecated. Support Payload scoring for SpanOrQuery --- Key: LUCENE-6706 URL: https://issues.apache.org/jira/browse/LUCENE-6706 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 5.2.1 Reporter: Jamie Johnson Assignee: Alan Woodward Priority: Minor Attachments: LUCENE-6706.patch, PayloadSpanOrQuery.java I need a way to have payloads influence the score of SpanOrQuery's. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647678#comment-14647678 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693432 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1693432 ] SOLR-6625: Enable registering interceptors for the calls made using HttpClient and make the request object available at the interceptor context HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6707) PhraseQuery.Builder methods should return this to allow chaining
[ https://issues.apache.org/jira/browse/LUCENE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6707: - Attachment: LUCENE-6707.patch Here is a patch. PhraseQuery.Builder methods should return this to allow chaining Key: LUCENE-6707 URL: https://issues.apache.org/jira/browse/LUCENE-6707 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6707.patch Currently they return void, so you can't chain. Returning this would make it consistent with BooleanQuery.Builder. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647704#comment-14647704 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693434 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1693434 ] SOLR-6625: formatting fixed HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reopened SOLR-7719: --- Alessandro, I'd like to backport the fix to 5.x branch in order to have this included in next 5.x release, thus reopening. Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Fix For: Trunk Attachments: SOLR-7719.patch, SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc
Adrien Grand created LUCENE-6708: Summary: TopFieldCollector sometimes calls Scorer.score() several times on the same doc Key: LUCENE-6708 URL: https://issues.apache.org/jira/browse/LUCENE-6708 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor If the sort spec includes a sort field that needs scores, and if trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute the score several times on the same document, once to check whether the hit is competitive, and once to update maxScore or to set the score on the ScoreDoc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6531) Make PhraseQuery immutable
[ https://issues.apache.org/jira/browse/LUCENE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647699#comment-14647699 ] Adrien Grand commented on LUCENE-6531: -- Thanks Terry for catching this. This issue was discussed for BooleanQuery after PhraseQuery had already been checked in, and I didn't think of changing PhraseQuery.Builder methods to return this afterwards. I'll do it now. Make PhraseQuery immutable -- Key: LUCENE-6531 URL: https://issues.apache.org/jira/browse/LUCENE-6531 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3, 6.0 Attachments: LUCENE-6531.patch, LUCENE-6531.patch Mutable queries are an issue for automatic filter caching since modifying a query after it has been put into the cache will corrupt the cache. We should make all queries immutable (up to the boost) to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6654) KNearestNeighborClassifier not taking in consideration Class ranking
[ https://issues.apache.org/jira/browse/LUCENE-6654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647756#comment-14647756 ] Alessandro Benedetti commented on LUCENE-6654: -- Any feedback on this ? Cheers KNearestNeighborClassifier not taking in consideration Class ranking Key: LUCENE-6654 URL: https://issues.apache.org/jira/browse/LUCENE-6654 Project: Lucene - Core Issue Type: Improvement Components: modules/classification Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: classification, knn Attachments: LUCENE-6654.patch Currently the KNN Classifier assign the score for a ClassificationResult, based only on the frequency of the class in the top K results. This is conceptually a simplification. Actually the ranking must take a part. If not this can happen : Top 4 1) Class1 2) Class1 3) Class2 4) Class2 As a result of this Top 4 , both the classes will have the same score. But the expected result is that Class1 has a better score, as the MLT score the documents accordingly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7719) Suggester Component results parsing
[ https://issues.apache.org/jira/browse/SOLR-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessandro Benedetti closed SOLR-7719. -- Resolution: Fixed Tommaso committed the patch involved! Suggester Component results parsing --- Key: SOLR-7719 URL: https://issues.apache.org/jira/browse/SOLR-7719 Project: Solr Issue Type: Improvement Components: SolrJ Affects Versions: 5.2.1 Reporter: Alessandro Benedetti Assignee: Tommaso Teofili Priority: Minor Labels: queryResponse, suggester, suggestions Fix For: Trunk Attachments: SOLR-7719.patch, SOLR-7719.patch Original Estimate: 24h Remaining Estimate: 24h Currently SolrJ org.apache.solr.client.solrj.response.QueryResponse is not managing suggestions coming from the Suggest Component . It would be nice to have the suggestions properly managed and returned with simply getter methods. Current Json : lst name=suggest lst name=dictionary1 lst name=queryTerm int name=numFound2/int arr name=suggestions lst str name=termsuggestion1/str.. str name=termsuggestion2/str… /lst /arr /lst /lst.. This will be parsed accordingly . Producing an easy to use Java Map. Dictionary2suggestions -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647819#comment-14647819 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693442 from [~noble.paul] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693442 ] SOLR-6625: Enable registering interceptors for the calls made using HttpClient and make the request object available at the interceptor context HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648171#comment-14648171 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693484 from [~anshumg] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693484 ] SOLR-6625: Set HttpClientImpl in SolrTestCaseJ4 for tests(merge from trunk) HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7851) Angular analysis tab tweaks
[ https://issues.apache.org/jira/browse/SOLR-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648177#comment-14648177 ] ASF subversion and git services commented on SOLR-7851: --- Commit 1693486 from [~upayavira] in branch 'dev/trunk' [ https://svn.apache.org/r1693486 ] SOLR-7851 Angular analysis tab tweaks Angular analysis tab tweaks --- Key: SOLR-7851 URL: https://issues.apache.org/jira/browse/SOLR-7851 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7851.patch The angular analysis tab lacks support for verbose and has a few other issues - e.g. the schema browser link does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6621) two unused variables in analysis/stempel/src/java/org/egothor/stemmer/Compile.java
[
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated LUCENE-6621:
Summary: two unused variables in
analysis/stempel/src/java/org/egothor/stemmer/Compile.java (was: Unused
variables)
two unused variables in
analysis/stempel/src/java/org/egothor/stemmer/Compile.java
--
Key: LUCENE-6621
URL: https://issues.apache.org/jira/browse/LUCENE-6621
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
Fix For: 5.3, Trunk
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
for (int i = 1; i args.length; i++) {
// System.out.println([ + args[i] + ]);
Diff diff = new Diff();
int stems = 0;
int words = 0;
...
{code}
In the file {{Compile.java}}, the variables {{stems}} and {{words}} are
unused.
Although {{words}} gets incremented further in the file, it does not get
referenced or used elsewhere.
{{stems}} is neither incremented nor used elsewhere in the project.
Are these variables redundant?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?
[
https://issues.apache.org/jira/browse/LUCENE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648195#comment-14648195
]
Michael McCandless commented on LUCENE-6629:
Maybe another example:
https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/915/console
{noformat}
Suite: org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat
[junit4] 2 jul 30, 2015 2:46:47 PM
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4] 2 WARNING: Suite execution timed out:
org.apache.lucene.codecs.simpletext.TestSimpleTextTermVectorsFormat
[junit4] 21) Thread[id=147,
name=TEST-TestSimpleTextTermVectorsFormat.testRamBytesUsed-seed#[4AF0D6F4E5896BB7],
state=RUNNABLE, group=TGRP-TestSimpleTextTermVectorsFormat]
[junit4] 2 at
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:132)
[junit4] 2 at
org.apache.lucene.codecs.simpletext.SimpleTextUtil.readLine(SimpleTextUtil.java:60)
[junit4] 2 at
org.apache.lucene.codecs.simpletext.SimpleTextTermVectorsReader.readLine(SimpleTextTermVectorsReader.java:234)
[junit4] 2 at
org.apache.lucene.codecs.simpletext.SimpleTextTermVectorsReader.get(SimpleTextTermVectorsReader.java:141)
[junit4] 2 at
org.apache.lucene.codecs.TermVectorsWriter.merge(TermVectorsWriter.java:194)
[junit4] 2 at
org.apache.lucene.index.SegmentMerger.mergeVectors(SegmentMerger.java:187)
[junit4] 2 at
org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:127)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4089)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3664)
[junit4] 2 at
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1929)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4731)
[junit4] 2 at
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:695)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4757)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4748)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1476)
[junit4] 2 at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1254)
[junit4] 2 at
org.apache.lucene.index.BaseIndexFileFormatTestCase.testRamBytesUsed(BaseIndexFileFormatTestCase.java:260)
[junit4] 2 at
org.apache.lucene.index.BaseTermVectorsFormatTestCase.testRamBytesUsed(BaseTermVectorsFormatTestCase.java:74)
[junit4] 2 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit4] 2 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit4] 2 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] 2 at java.lang.reflect.Method.invoke(Method.java:606)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
[junit4] 2 at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
[junit4] 2 at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
[junit4] 2 at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
[junit4] 2 at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
[junit4] 2 at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4] 2 at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4] 2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
[junit4] 2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
[junit4] 2 at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
[junit4] 2 at
[jira] [Commented] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648285#comment-14648285
]
Gopal Patwa commented on SOLR-4787:
---
if this is not committed to solr 5.x, does anyone has this join patch for solr
5.x ?
Join Contrib
Key: SOLR-4787
URL: https://issues.apache.org/jira/browse/SOLR-4787
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 4.2.1
Reporter: Joel Bernstein
Priority: Minor
Fix For: Trunk
Attachments: SOLR-4787-deadlock-fix.patch,
SOLR-4787-pjoin-long-keys.patch, SOLR-4787-with-testcase-fix.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
SOLR-4797-hjoin-multivaluekeys-nestedJoins.patch,
SOLR-4797-hjoin-multivaluekeys-trunk.patch
This contrib provides a place where different join implementations can be
contributed to Solr. This contrib currently includes 3 join implementations.
The initial patch was generated from the Solr 4.3 tag. Because of changes in
the FieldCache API this patch will only build with Solr 4.2 or above.
*HashSetJoinQParserPlugin aka hjoin*
The hjoin provides a join implementation that filters results in one core
based on the results of a search in another core. This is similar in
functionality to the JoinQParserPlugin but the implementation differs in a
couple of important ways.
The first way is that the hjoin is designed to work with int and long join
keys only. So, in order to use hjoin, int or long join keys must be included
in both the to and from core.
The second difference is that the hjoin builds memory structures that are
used to quickly connect the join keys. So, the hjoin will need more memory
then the JoinQParserPlugin to perform the join.
The main advantage of the hjoin is that it can scale to join millions of keys
between cores and provide sub-second response time. The hjoin should work
well with up to two million results from the fromIndex and tens of millions
of results from the main query.
The hjoin supports the following features:
1) Both lucene query and PostFilter implementations. A *cost* 99 will
turn on the PostFilter. The PostFilter will typically outperform the Lucene
query when the main query results have been narrowed down.
2) With the lucene query implementation there is an option to build the
filter with threads. This can greatly improve the performance of the query if
the main query index is very large. The threads parameter turns on
threading. For example *threads=6* will use 6 threads to build the filter.
This will setup a fixed threadpool with six threads to handle all hjoin
requests. Once the threadpool is created the hjoin will always use it to
build the filter. Threading does not come into play with the PostFilter.
3) The *size* local parameter can be used to set the initial size of the
hashset used to perform the join. If this is set above the number of results
from the fromIndex then the you can avoid hashset resizing which improves
performance.
4) Nested filter queries. The local parameter fq can be used to nest a
filter query within the join. The nested fq will filter the results of the
join query. This can point to another join to support nested joins.
5) Full caching support for the lucene query implementation. The filterCache
and queryResultCache should work properly even with deep nesting of joins.
Only the queryResultCache comes into play with the PostFilter implementation
because PostFilters are not cacheable in the filterCache.
The syntax of the hjoin is similar to the JoinQParserPlugin except that the
plugin is referenced by the string hjoin rather then join.
fq=\{!hjoin fromIndex=collection2 from=id_i to=id_i threads=6
fq=$qq\}user:customer1qq=group:5
The example filter query above will search the fromIndex (collection2) for
user:customer1 applying the local fq parameter to filter the results. The
lucene filter query will be built using 6 threads. This query will generate a
list of values from the from field that will be used to filter the main
query. Only records from the main query, where the to field is present in
the from list will be included in the results.
The solrconfig.xml in the main query core must contain the reference to the
hjoin.
queryParser name=hjoin
class=org.apache.solr.joins.HashSetJoinQParserPlugin/
And the join contrib lib jars must be registed in the solrconfig.xml.
lib dir=../../../contrib/joins/lib regex=.*\.jar /
After issuing the ant dist command from inside the solr directory the joins
contrib jar will
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648332#comment-14648332
]
Steve Rowe commented on SOLR-6625:
--
I tried all of the seeds my Jenkins found today and none of them reproduce for
me on OS X after Anshum's r1693498 commit.
Here are the ones for trunk:
{noformat}
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=F852018ABA4ECDFF -Dtests.slow=true -Dtests.locale=nl
-Dtests.timezone=Asia/Gaza -Dtests.asserts=true -Dtests.file.encoding=UTF-8
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=36C935176479F04C -Dtests.slow=true -Dtests.locale=ar_YE
-Dtests.timezone=Australia/Adelaide -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=D555CA223513ED3F -Dtests.slow=true -Dtests.locale=tr
-Dtests.timezone=Antarctica/Syowa -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=C37B717A18417443 -Dtests.slow=true -Dtests.locale=bg_BG
-Dtests.timezone=SystemV/HST10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
{noformat}
For branch_5x/Java8:
{noformat}
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=FC64970124605306 -Dtests.slow=true -Dtests.locale=ar_LY
-Dtests.timezone=Asia/Vientiane -Dtests.asserts=true -Dtests.file.encoding=UTF-8
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=4A4BDF1F10B61D9 -Dtests.slow=true -Dtests.locale=hu_HU
-Dtests.timezone=Pacific/Fiji -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=E4714ED097B4D0A7 -Dtests.slow=true -Dtests.locale=
-Dtests.timezone=Etc/GMT-5 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=E0C2EF677FA5EC03 -Dtests.slow=true -Dtests.locale=it_CH
-Dtests.timezone=America/New_York -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=7F8305E670B947FE -Dtests.slow=true -Dtests.locale=fr_CH
-Dtests.timezone=Europe/Skopje -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=30D63D1BAD373514 -Dtests.slow=true -Dtests.locale=it
-Dtests.timezone=America/Iqaluit -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{noformat}
And for branch_5x/Java7:
{noformat}
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=98C4B653C6DE38C9 -Dtests.slow=true -Dtests.locale=it
-Dtests.timezone=America/Havana -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
ant test -Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=27A47BFC57FF783D -Dtests.slow=true -Dtests.locale=en_SG
-Dtests.timezone=Pacific/Chatham -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
{noformat}
HttpClient callback in HttpSolrServer
-
Key: SOLR-6625
URL: https://issues.apache.org/jira/browse/SOLR-6625
Project: Solr
Issue Type: Improvement
Components: SolrJ
Reporter: Gregory Chanan
Assignee: Noble Paul
Priority: Minor
Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch,
SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch,
SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch,
SOLR-6625_r1654079.patch
Some of our setups use Solr in a SPNego/kerberos setup (we've done this by
adding our own filters to the web.xml). We have an issue in that SPNego
requires a negotiation step, but some HttpSolrServer requests are not
repeatable, notably the PUT/POST requests.
[jira] [Commented] (LUCENE-6621) Unused variables
[
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648173#comment-14648173
]
ASF subversion and git services commented on LUCENE-6621:
-
Commit 1693485 from [~cpoerschke] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693485 ]
LUCENE-6621: Removed two unused variables in
analysis/stempel/src/java/org/egothor/stemmer/Compile.java
Unused variables
Key: LUCENE-6621
URL: https://issues.apache.org/jira/browse/LUCENE-6621
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
for (int i = 1; i args.length; i++) {
// System.out.println([ + args[i] + ]);
Diff diff = new Diff();
int stems = 0;
int words = 0;
...
{code}
In the file {{Compile.java}}, the variables {{stems}} and {{words}} are
unused.
Although {{words}} gets incremented further in the file, it does not get
referenced or used elsewhere.
{{stems}} is neither incremented nor used elsewhere in the project.
Are these variables redundant?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648172#comment-14648172 ] Anshum Gupta commented on SOLR-6625: I've committed the patch as that would be required anyways. It doesn't fix the NPE issue though. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6621) Unused variables
[
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648162#comment-14648162
]
ASF subversion and git services commented on LUCENE-6621:
-
Commit 1693482 from [~cpoerschke] in branch 'dev/trunk'
[ https://svn.apache.org/r1693482 ]
LUCENE-6621: Removed two unused variables in
analysis/stempel/src/java/org/egothor/stemmer/Compile.java
Unused variables
Key: LUCENE-6621
URL: https://issues.apache.org/jira/browse/LUCENE-6621
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
for (int i = 1; i args.length; i++) {
// System.out.println([ + args[i] + ]);
Diff diff = new Diff();
int stems = 0;
int words = 0;
...
{code}
In the file {{Compile.java}}, the variables {{stems}} and {{words}} are
unused.
Although {{words}} gets incremented further in the file, it does not get
referenced or used elsewhere.
{{stems}} is neither incremented nor used elsewhere in the project.
Are these variables redundant?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6621) Unused variables
[
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated LUCENE-6621:
Fix Version/s: Trunk
5.3
Unused variables
Key: LUCENE-6621
URL: https://issues.apache.org/jira/browse/LUCENE-6621
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
Fix For: 5.3, Trunk
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
for (int i = 1; i args.length; i++) {
// System.out.println([ + args[i] + ]);
Diff diff = new Diff();
int stems = 0;
int words = 0;
...
{code}
In the file {{Compile.java}}, the variables {{stems}} and {{words}} are
unused.
Although {{words}} gets incremented further in the file, it does not get
referenced or used elsewhere.
{{stems}} is neither incremented nor used elsewhere in the project.
Are these variables redundant?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.7.0_80) - Build # 4956 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4956/ Java: 32bit/jdk1.7.0_80 -client -XX:+UseSerialGC 2 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll Error Message: There are still nodes recoverying - waited for 30 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 30 seconds at __randomizedtesting.SeedInfo.seed([CCF5D99500A74DC2:80ABF7EC7B371207]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:834) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1391) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll(StreamExpressionTest.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Resolved] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields
[ https://issues.apache.org/jira/browse/LUCENE-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev resolved LUCENE-5868. -- Resolution: Won't Fix Assignee: Mikhail Khludnev It seems nobody cares. Closing so far. JoinUtil support for NUMERIC docValues fields -- Key: LUCENE-5868 URL: https://issues.apache.org/jira/browse/LUCENE-5868 Project: Lucene - Core Issue Type: New Feature Reporter: Mikhail Khludnev Assignee: Mikhail Khludnev Priority: Minor while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at least. I plan to provide test/patch. It might be important, because Solr's join can do that. Please vote if you care! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648168#comment-14648168 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693483 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1693483 ] SOLR-6625: Set HttpClientImpl in SolrTestCaseJ4 for tests HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13485 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13485/ Java: 32bit/jdk1.9.0-ea-b60 -client -XX:+UseConcMarkSweepGC -Djava.locale.providers=JRE,SPI 2 tests failed. FAILED: org.apache.solr.client.solrj.impl.TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp Error Message: java.lang.NullPointerException Stack Trace: org.apache.solr.client.solrj.SolrServerException: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([7D4C1691741CE71D:66A095312600C2D8]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:414) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.client.solrj.impl.TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp(TestCloudSolrClientConnections.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at
[jira] [Commented] (SOLR-7729) ConcurrentUpdateSolrClient ignoring the collection parameter in some methods
[
https://issues.apache.org/jira/browse/SOLR-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648187#comment-14648187
]
Jorge Luis Betancourt Gonzalez commented on SOLR-7729:
--
I'm going to give it a try to your patch, I was also working on a fix for this,
but I'm out on holidays :) nevertheless I'm going to give it a try.
ConcurrentUpdateSolrClient ignoring the collection parameter in some methods
Key: SOLR-7729
URL: https://issues.apache.org/jira/browse/SOLR-7729
Project: Solr
Issue Type: Bug
Components: SolrJ
Affects Versions: 5.1
Reporter: Jorge Luis Betancourt Gonzalez
Labels: client, solrj
Attachments: SOLR-7729-ConcurrentUpdateSolrClient-collection.patch
Some of the methods in {{ConcurrentUpdateSolrClient}} accept an aditional
{{collection}} parameter, some of this methods are: {{add(String collection,
SolrInputDocument doc)}} and {{request(SolrRequest, String collection)}}.
This collection parameter is being ignored in this cases but works for others
like {{commit(String collection)}}.
[~elyograg] noted that:
{quote}
Looking into how an update request actually gets added to the background
queue in ConcurrentUpdateSolrClient, it appears that the collection
information is ignored before the request is added to the queue.
{quote}
From the source, when a commit is issued or the
{{UpdateParams.WAIT_SEARCHER}} is set in the request params the collection
parameter is used, otherwise the request {{UpdateRequest req}} is queued
without any regarding of the collection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: cwiki.a.org edit right for mkhludnev
Hi Mikhail, I’ve added you here: https://cwiki.apache.org/confluence/spaces/spacepermissions.action?key=solr - you should now have edit rights. Steve On Jul 30, 2015, at 3:42 PM, Mikhail Khludnev mkhlud...@griddynamics.com wrote: Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7852) Angular main tab does not collapse cores menu
[ https://issues.apache.org/jira/browse/SOLR-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-7852: Attachment: SOLR-7852.patch trivial fix Angular main tab does not collapse cores menu - Key: SOLR-7852 URL: https://issues.apache.org/jira/browse/SOLR-7852 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7852.patch A previous fix resolved the issue where main menu tabs (java properties, logging, core admin/etc) where not hiding the per-core menu when clicked. The fix was not applied to the topmost link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6702) [suggest] Make Context Query and Field extensible
[
https://issues.apache.org/jira/browse/LUCENE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Areek Zillur resolved LUCENE-6702.
--
Resolution: Fixed
[suggest] Make Context Query and Field extensible
-
Key: LUCENE-6702
URL: https://issues.apache.org/jira/browse/LUCENE-6702
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: Trunk
Reporter: Areek Zillur
Assignee: Areek Zillur
Fix For: 5.3, Trunk
Attachments: LUCENE-6702.patch, LUCENE-6702.patch
ContextSuggestField indexes context information along with
suggestions, which can be used to filter and/or boost suggestions using
ContextQuery.
It would be useful to make ContextSuggestField extensible such that
subclasses
can inject context values at index-time, without having to specify the
contexts in its ctor.
ContextQuery can be made extensible by allowing sub-classes to override
how context automaton is created from provided query contexts.
Currently, ContextQuery uses a context value of * to consider all context
values,
It makes sense to have a dedicated {{addAllContexts()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648280#comment-14648280 ] Anshum Gupta commented on SOLR-6625: That looks like it should have been interfering and would solve the problem. I'll commit this. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7851) Angular analysis tab tweaks
[ https://issues.apache.org/jira/browse/SOLR-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648199#comment-14648199 ] ASF subversion and git services commented on SOLR-7851: --- Commit 1693489 from [~upayavira] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693489 ] SOLR-7851 Angular analysis tab tweaks Angular analysis tab tweaks --- Key: SOLR-7851 URL: https://issues.apache.org/jira/browse/SOLR-7851 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7851.patch The angular analysis tab lacks support for verbose and has a few other issues - e.g. the schema browser link does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5084 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5084/ Java: 64bit/jdk1.8.0_51 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll Error Message: There are still nodes recoverying - waited for 30 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 30 seconds at __randomizedtesting.SeedInfo.seed([537BF64616D14F4B:1F25D83F6D41108E]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:834) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1391) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testAll(StreamExpressionTest.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Created] (SOLR-7852) Angular main tab does not collapse cores menu
Upayavira created SOLR-7852: --- Summary: Angular main tab does not collapse cores menu Key: SOLR-7852 URL: https://issues.apache.org/jira/browse/SOLR-7852 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 A previous fix resolved the issue where main menu tabs (java properties, logging, core admin/etc) where not hiding the per-core menu when clicked. The fix was not applied to the topmost link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6702) [suggest] Make Context Query and Field extensible
[
https://issues.apache.org/jira/browse/LUCENE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Areek Zillur updated LUCENE-6702:
-
Fix Version/s: 5.3
[suggest] Make Context Query and Field extensible
-
Key: LUCENE-6702
URL: https://issues.apache.org/jira/browse/LUCENE-6702
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: Trunk
Reporter: Areek Zillur
Assignee: Areek Zillur
Fix For: 5.3, Trunk
Attachments: LUCENE-6702.patch, LUCENE-6702.patch
ContextSuggestField indexes context information along with
suggestions, which can be used to filter and/or boost suggestions using
ContextQuery.
It would be useful to make ContextSuggestField extensible such that
subclasses
can inject context values at index-time, without having to specify the
contexts in its ctor.
ContextQuery can be made extensible by allowing sub-classes to override
how context automaton is created from provided query contexts.
Currently, ContextQuery uses a context value of * to consider all context
values,
It makes sense to have a dedicated {{addAllContexts()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6702) [suggest] Make Context Query and Field extensible
[
https://issues.apache.org/jira/browse/LUCENE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648239#comment-14648239
]
Areek Zillur commented on LUCENE-6702:
--
Thanks [~mikemccand] for the review!
[suggest] Make Context Query and Field extensible
-
Key: LUCENE-6702
URL: https://issues.apache.org/jira/browse/LUCENE-6702
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: Trunk
Reporter: Areek Zillur
Assignee: Areek Zillur
Fix For: 5.3, Trunk
Attachments: LUCENE-6702.patch, LUCENE-6702.patch
ContextSuggestField indexes context information along with
suggestions, which can be used to filter and/or boost suggestions using
ContextQuery.
It would be useful to make ContextSuggestField extensible such that
subclasses
can inject context values at index-time, without having to specify the
contexts in its ctor.
ContextQuery can be made extensible by allowing sub-classes to override
how context automaton is created from provided query contexts.
Currently, ContextQuery uses a context value of * to consider all context
values,
It makes sense to have a dedicated {{addAllContexts()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648288#comment-14648288 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693497 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1693497 ] SOLR-6625: Remove RequestInterceptor at the end of the test in BasicHttpSolrClientTest. It was interfering with other tests running the same JVM. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 252 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/252/ 1 tests failed. REGRESSION: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test Error Message: expected:0 but was:1 Stack Trace: java.lang.AssertionError: expected:0 but was:1 at __randomizedtesting.SeedInfo.seed([B1F9B6FF303C45E4:39AD89259EC0281C]: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.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648326#comment-14648326
]
Mikhail Khludnev commented on SOLR-6234:
[~jpountz][~thetaphi] thanks for your help!
[~thelabdude],[~ctargett], I hit cwiki, would you mind to check:
*
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=32604257selectedPageVersions=50selectedPageVersions=49
*
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=32604277selectedPageVersions=71selectedPageVersions=70
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234-javadocsfix.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch
it adds ability to call Lucene's JoinUtil by specifying local param, ie
\{!join score=...} It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till
SOLR-7814.
- -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise.
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7852) Angular main tab does not collapse cores menu
[ https://issues.apache.org/jira/browse/SOLR-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648212#comment-14648212 ] ASF subversion and git services commented on SOLR-7852: --- Commit 1693490 from [~upayavira] in branch 'dev/trunk' [ https://svn.apache.org/r1693490 ] SOLR-7852 Hide cores menu when dashboard link clicked Angular main tab does not collapse cores menu - Key: SOLR-7852 URL: https://issues.apache.org/jira/browse/SOLR-7852 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7852.patch A previous fix resolved the issue where main menu tabs (java properties, logging, core admin/etc) where not hiding the per-core menu when clicked. The fix was not applied to the topmost link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13666 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13666/ Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamingTest.streamTests Error Message: There are still nodes recoverying - waited for 30 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 30 seconds at __randomizedtesting.SeedInfo.seed([26626501524AFACF:DA394285F86303BA]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:834) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1391) at org.apache.solr.client.solrj.io.stream.StreamingTest.streamTests(StreamingTest.java:1059) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Updated] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-6625: --- Attachment: SOLR-6625-testfix.patch Removing the interceptors that were added during the BasicHttpSolrClientTest. This was interfering with the other tests, viz. TestSolrCloudClientConnections. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
cwiki.a.org edit right for mkhludnev
Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics http://www.griddynamics.com mkhlud...@griddynamics.com
[jira] [Resolved] (SOLR-7851) Angular analysis tab tweaks
[ https://issues.apache.org/jira/browse/SOLR-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-7851. - Resolution: Fixed Angular analysis tab tweaks --- Key: SOLR-7851 URL: https://issues.apache.org/jira/browse/SOLR-7851 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7851.patch The angular analysis tab lacks support for verbose and has a few other issues - e.g. the schema browser link does not work. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7852) Angular main tab does not collapse cores menu
[ https://issues.apache.org/jira/browse/SOLR-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648214#comment-14648214 ] ASF subversion and git services commented on SOLR-7852: --- Commit 1693491 from [~upayavira] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693491 ] SOLR-7852 Hide cores menu when dashboard link clicked Angular main tab does not collapse cores menu - Key: SOLR-7852 URL: https://issues.apache.org/jira/browse/SOLR-7852 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7852.patch A previous fix resolved the issue where main menu tabs (java properties, logging, core admin/etc) where not hiding the per-core menu when clicked. The fix was not applied to the topmost link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6702) [suggest] Make Context Query and Field extensible
[
https://issues.apache.org/jira/browse/LUCENE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648228#comment-14648228
]
ASF subversion and git services commented on LUCENE-6702:
-
Commit 1693493 from [~areek] in branch 'dev/trunk'
[ https://svn.apache.org/r1693493 ]
LUCENE-6702: Add a method to inject context values at index time in
ContextSuggestField and simplify ContextQuery and add dedicated method to
consider all contexts at query time
[suggest] Make Context Query and Field extensible
-
Key: LUCENE-6702
URL: https://issues.apache.org/jira/browse/LUCENE-6702
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: Trunk
Reporter: Areek Zillur
Assignee: Areek Zillur
Fix For: Trunk
Attachments: LUCENE-6702.patch, LUCENE-6702.patch
ContextSuggestField indexes context information along with
suggestions, which can be used to filter and/or boost suggestions using
ContextQuery.
It would be useful to make ContextSuggestField extensible such that
subclasses
can inject context values at index-time, without having to specify the
contexts in its ctor.
ContextQuery can be made extensible by allowing sub-classes to override
how context automaton is created from provided query contexts.
Currently, ContextQuery uses a context value of * to consider all context
values,
It makes sense to have a dedicated {{addAllContexts()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7852) Angular main tab does not collapse cores menu
[ https://issues.apache.org/jira/browse/SOLR-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-7852. - Resolution: Fixed Angular main tab does not collapse cores menu - Key: SOLR-7852 URL: https://issues.apache.org/jira/browse/SOLR-7852 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 5.2.1 Reporter: Upayavira Assignee: Upayavira Priority: Minor Fix For: 5.3 Attachments: SOLR-7852.patch A previous fix resolved the issue where main menu tabs (java properties, logging, core admin/etc) where not hiding the per-core menu when clicked. The fix was not applied to the topmost link. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648345#comment-14648345 ] Anshum Gupta commented on SOLR-6625: Thanks for confirming that Steve. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7808) MorphlineGoLiveMiniMRTest fails using YARN
[
https://issues.apache.org/jira/browse/SOLR-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob resolved SOLR-7808.
-
Resolution: Cannot Reproduce
No longer seems to be an issue... some other change in the past 2 weeks might
have taken care of it.
MorphlineGoLiveMiniMRTest fails using YARN
--
Key: SOLR-7808
URL: https://issues.apache.org/jira/browse/SOLR-7808
Project: Solr
Issue Type: Bug
Components: contrib - MapReduce
Reporter: Mike Drob
{noformat}
[junit4] Throwable #1: java.io.IOException: Failed on local
exception: java.io.IOException: Connection reset by peer; Host Details :
local host is: drob-rhel/172.25.10.46; destination host is:
drob-rhel:52807;
[junit4] at
__randomizedtesting.SeedInfo.seed([4D93EC191980246A:C5C7D3C3B77C4992]:0)
[junit4] at
org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
[junit4] at org.apache.hadoop.ipc.Client.call(Client.java:1472)
[junit4] at org.apache.hadoop.ipc.Client.call(Client.java:1399)
[junit4] at
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:232)
[junit4] at com.sun.proxy.$Proxy111.getClusterMetrics(Unknown
Source)
[junit4] at
org.apache.hadoop.yarn.api.impl.pb.client.ApplicationClientProtocolPBClientImpl.getClusterMetrics(ApplicationClientProtocolPBClientImpl.java:202)
[junit4] at
org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
[junit4] at
org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
[junit4] at com.sun.proxy.$Proxy112.getClusterMetrics(Unknown
Source)
[junit4] at
org.apache.hadoop.yarn.client.api.impl.YarnClientImpl.getYarnClusterMetrics(YarnClientImpl.java:461)
[junit4] at
org.apache.hadoop.mapred.ResourceMgrDelegate.getClusterMetrics(ResourceMgrDelegate.java:151)
[junit4] at
org.apache.hadoop.mapred.YARNRunner.getClusterMetrics(YARNRunner.java:179)
[junit4] at
org.apache.hadoop.mapreduce.Cluster.getClusterStatus(Cluster.java:246)
[junit4] at
org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:719)
[junit4] at
org.apache.hadoop.mapred.JobClient$3.run(JobClient.java:717)
[junit4] at java.security.AccessController.doPrivileged(Native
Method)
[junit4] at javax.security.auth.Subject.doAs(Subject.java:422)
[junit4] at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
[junit4] at
org.apache.hadoop.mapred.JobClient.getClusterStatus(JobClient.java:717)
[junit4] at
org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:645)
[junit4] at
org.apache.solr.hadoop.MapReduceIndexerTool.run(MapReduceIndexerTool.java:608)
[junit4] at
org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
[junit4] at
org.apache.solr.hadoop.MorphlineGoLiveMiniMRTest.test(MorphlineGoLiveMiniMRTest.java:400)
[junit4] at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
[junit4] at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
[junit4] at java.lang.Thread.run(Thread.java:745)
[junit4] Caused by: java.io.IOException: Connection reset by peer
[junit4] at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
[junit4] at
sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
[junit4] at
sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
[junit4] at sun.nio.ch.IOUtil.write(IOUtil.java:65)
[junit4] at
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
[junit4] at
org.apache.hadoop.net.SocketOutputStream$Writer.performIO(SocketOutputStream.java:63)
[junit4] at
org.apache.hadoop.net.SocketIOWithTimeout.doIO(SocketIOWithTimeout.java:142)
[junit4] at
org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:159)
[junit4] at
org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:117)
[junit4] at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
[junit4] at
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
[junit4] at
java.io.DataOutputStream.flush(DataOutputStream.java:123)
[junit4] at
org.apache.hadoop.ipc.Client$Connection$3.run(Client.java:1030)
[junit4]
[jira] [Commented] (LUCENE-6702) [suggest] Make Context Query and Field extensible
[
https://issues.apache.org/jira/browse/LUCENE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648231#comment-14648231
]
ASF subversion and git services commented on LUCENE-6702:
-
Commit 1693494 from [~areek] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693494 ]
LUCENE-6702: Add a method to inject context values at index time in
ContextSuggestField and simplify ContextQuery and add dedicated method to
consider all contexts at query time
[suggest] Make Context Query and Field extensible
-
Key: LUCENE-6702
URL: https://issues.apache.org/jira/browse/LUCENE-6702
Project: Lucene - Core
Issue Type: Improvement
Components: core/other
Affects Versions: Trunk
Reporter: Areek Zillur
Assignee: Areek Zillur
Fix For: Trunk
Attachments: LUCENE-6702.patch, LUCENE-6702.patch
ContextSuggestField indexes context information along with
suggestions, which can be used to filter and/or boost suggestions using
ContextQuery.
It would be useful to make ContextSuggestField extensible such that
subclasses
can inject context values at index-time, without having to specify the
contexts in its ctor.
ContextQuery can be made extensible by allowing sub-classes to override
how context automaton is created from provided query contexts.
Currently, ContextQuery uses a context value of * to consider all context
values,
It makes sense to have a dedicated {{addAllContexts()}} instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648289#comment-14648289 ] ASF subversion and git services commented on SOLR-6625: --- Commit 1693498 from [~anshumg] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693498 ] SOLR-6625: Remove RequestInterceptor at the end of the test in BasicHttpSolrClientTest. It was interfering with other tests running the same JVM.(merge from trunk) HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions
[
https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2522:
---
Description:
Initial request...
bq. Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
...this specific syntax has been spun off into SOLR-7853, but the underlying
functionality s being implemented here using a new optional second argument to
the {{field()}} function: {{field(multivalued_field_name,min)}} and
{{field(multivalued_field_name,max)}}.
was:
Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
Summary: add syntax for selecting the min or max of a multivalued field
in value source functions (was: Change max() and min() to work on multiValued
fields )
add syntax for selecting the min or max of a multivalued field in value
source functions
Key: SOLR-2522
URL: https://issues.apache.org/jira/browse/SOLR-2522
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Hoss Man
Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
Initial request...
bq. Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
...this specific syntax has been spun off into SOLR-7853, but the underlying
functionality s being implemented here using a new optional second argument
to the {{field()}} function: {{field(multivalued_field_name,min)}} and
{{field(multivalued_field_name,max)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648469#comment-14648469 ] Scott Blum commented on SOLR-5756: -- Also, what branch should I be working against? I have something in a basically working state I'd like feedback on. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13667 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13667/
Java: 64bit/jdk1.8.0_60-ea-b24 -XX:-UseCompressedOops -XX:+UseParallelGC
1 tests failed.
FAILED: org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test
Error Message:
Didn't see replicas [core_node1, core_node3] come up within 9 ms!
ClusterState: DocCollection(c8n_1x3_lf)={ replicationFactor:3,
shards:{shard1:{ range:8000-7fff, state:active,
replicas:{ core_node1:{
core:c8n_1x3_lf_shard1_replica2,
base_url:http://127.0.0.1:42710/_tg;,
node_name:127.0.0.1:42710__tg, state:recovering},
core_node2:{ core:c8n_1x3_lf_shard1_replica1,
base_url:http://127.0.0.1:38967/_tg;,
node_name:127.0.0.1:38967__tg, state:down},
core_node3:{ core:c8n_1x3_lf_shard1_replica3,
base_url:http://127.0.0.1:57256/_tg;,
node_name:127.0.0.1:57256__tg, state:active,
leader:true, router:{name:compositeId},
maxShardsPerNode:1, autoAddReplicas:false}
Stack Trace:
java.lang.AssertionError: Didn't see replicas [core_node1, core_node3] come up
within 9 ms! ClusterState: DocCollection(c8n_1x3_lf)={
replicationFactor:3,
shards:{shard1:{
range:8000-7fff,
state:active,
replicas:{
core_node1:{
core:c8n_1x3_lf_shard1_replica2,
base_url:http://127.0.0.1:42710/_tg;,
node_name:127.0.0.1:42710__tg,
state:recovering},
core_node2:{
core:c8n_1x3_lf_shard1_replica1,
base_url:http://127.0.0.1:38967/_tg;,
node_name:127.0.0.1:38967__tg,
state:down},
core_node3:{
core:c8n_1x3_lf_shard1_replica3,
base_url:http://127.0.0.1:57256/_tg;,
node_name:127.0.0.1:57256__tg,
state:active,
leader:true,
router:{name:compositeId},
maxShardsPerNode:1,
autoAddReplicas:false}
at
__randomizedtesting.SeedInfo.seed([F286CE0F22D44ACD:7AD2F1D58C282735]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.HttpPartitionTest.waitToSeeReplicasActive(HttpPartitionTest.java:565)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at
[jira] [Commented] (SOLR-7853) support min(multivalued_field_name) and max(multivalued_field_name) syntax
[
https://issues.apache.org/jira/browse/SOLR-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648602#comment-14648602
]
Hoss Man commented on SOLR-7853:
My Comments from SOLR-2522...
{quote}
The root complexity is that the ValueSourceParsers all delegate to
FunctionQParser.parseValueSource() (or parseValueSourceList()) when expecting
an argument that can be an arbitrary (nested) ValueSource -- this is how min
max work now. FQP.parseValueSource() handles the logic of figuring out what
hte argument is (literal, nested function, $variable, field name, etc...) and
if it's a field name, calls {{f.getType().getValueSource(f, this)}} on the
associated SchemaField -- which for multivalued fields throws an exception that
gets propogated up.
My initial thinking was that i could refactor parseValueSource() to support
another flag for either specifying the MultiValueSelector, or indicating that
we want a defered evaluation of the underlying SchemaFields (ie: return some
mock FieldBasedValueSource that doesn't call FieldType.getValueSource until
used, so the min/max functions can explicitly call getSingleValueSource()
instead if they encounter a single argument) but then i realized that because
of how FunctionQParser deals with $variable derefrencing -- and the QParser
abstraction (variables might refer to other queries, which get automatically
unwrapped if they are FunctionQueries) then even that type of refacotring
solution wouldn't work in simple use cases like this...
{noformat}
...
fl=id,min($my_f)
my_f=some_multi_valued_field_name
{noformat}
So I'm going to punt on getting the {{min(some_multi_valued_field_name)}} (and
{{max(some_multi_valued_field_name)}}) syntax working, and leave that as a
usibillitiy improvement for the future.
{quote}
support min(multivalued_field_name) and max(multivalued_field_name) syntax
--
Key: SOLR-7853
URL: https://issues.apache.org/jira/browse/SOLR-7853
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
The changes in SOLR-2522 are adding support for using
{{field(field_name,'min')}} and {{field(field_name,'max')}} as a way to use
the min/max of a multivalued docvalues field in functions at query time.
The ideal syntax would be to support this as a varient on the existing
{{min()}} and {{max()}} functions -- which would be more intuitive for users,
but getting this to work is non trivial, so it's been split out as a distinct
issue for future improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2522) Change max() and min() to work on multiValued fields
[ https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2522: --- Attachment: SOLR-2522.patch This patch cleans up the remaining nocommits in the test (ie: adding randomized tests and tests for good errors in unsupported situations). I plan on committing backporting tommorow unless anyone has any concerns Change max() and min() to work on multiValued fields - Key: SOLR-2522 URL: https://issues.apache.org/jira/browse/SOLR-2522 Project: Solr Issue Type: Improvement Reporter: Bill Bell Assignee: Hoss Man Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch Switch max() and min() functions to work on multiValued fields so we can do sort=min(fieldname) asc and the sort would work on multiValued fields... -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7853) support min(multivalued_field_name) and max(multivalued_field_name) syntax
Hoss Man created SOLR-7853:
--
Summary: support min(multivalued_field_name) and
max(multivalued_field_name) syntax
Key: SOLR-7853
URL: https://issues.apache.org/jira/browse/SOLR-7853
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
The changes in SOLR-2522 are adding support for using
{{field(field_name,'min')}} and {{field(field_name,'max')}} as a way to use the
min/max of a multivalued docvalues field in functions at query time.
The ideal syntax would be to support this as a varient on the existing
{{min()}} and {{max()}} functions -- which would be more intuitive for users,
but getting this to work is non trivial, so it's been split out as a distinct
issue for future improvement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648608#comment-14648608 ] Anshum Gupta commented on SOLR-5756: [~dragonsinth] people generally work on trunk and then merge/backport it to branch_5x. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13670 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13670/ Java: 32bit/jdk1.8.0_60-ea-b24 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.TestDistributedSearch.test Error Message: Error from server at https://127.0.0.1:59243//collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:42) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:748) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:731) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:410) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:649) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:453) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:198) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:59243//collection1: java.lang.NullPointerException at org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:42) at org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:748) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:731) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:410) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:649) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:453) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:198) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83) at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b24) - Build # 13671 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13671/ Java: 64bit/jdk1.8.0_60-ea-b24 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([FF2D41215DD9DB3D]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:472) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238) at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=5416, name=searcherExecutor-2424-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=5416, name=searcherExecutor-2424-thread-1, state=WAITING, group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([FF2D41215DD9DB3D]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=5416,
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648129#comment-14648129
]
Anshum Gupta commented on SOLR-6625:
I think in LBHttpSolrClient.java (L326)
{code}
HttpSolrClient client = makeSolrClient(serverStr);
{code}
for some reason fails to instantiate and return the SolrClient. Could be
because of systemDefaultHttpClientClass being not set for
HttpClientUtil.createHttpClient to construct the client.
Noble/Ishan: can you take a look? If there are a lot more test failures @
Jenkins, I suggest it'd be better to Ignore the test while actively working on
a fix.
HttpClient callback in HttpSolrServer
-
Key: SOLR-6625
URL: https://issues.apache.org/jira/browse/SOLR-6625
Project: Solr
Issue Type: Improvement
Components: SolrJ
Reporter: Gregory Chanan
Assignee: Noble Paul
Priority: Minor
Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch,
SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch
Some of our setups use Solr in a SPNego/kerberos setup (we've done this by
adding our own filters to the web.xml). We have an issue in that SPNego
requires a negotiation step, but some HttpSolrServer requests are not
repeatable, notably the PUT/POST requests. So, what happens is,
HttpSolrServer sends the requests, the server responds with a negotiation
request, and the request fails because the request is not repeatable. We've
modified our code to send a repeatable request beforehand in these cases.
It would be nicer if HttpSolrServer provided a pre/post callback when it was
making an httpclient request. This would allow administrators to make
changes to the request for authentication purposes, and would allow users to
make per-request changes to the httpclient calls (i.e. modify httpclient
requestconfig to modify the timeout on a per-request basis).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7795) Fold Interval Faceting into Range Faceting
[
https://issues.apache.org/jira/browse/SOLR-7795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647273#comment-14647273
]
Zack Liang commented on SOLR-7795:
--
I prevented both of them to be used at the same time for the same field in case
people misuse facet.range.set with other range params. I think we could support
both in the same request, but the documentation will need to be clear that
facet.range.set does not use any range param. I'll look into this.
For the response syntax, I was thinking of bringing this feature without
modifying too much code so I made use of the previous syntax. I agree it is
confusing, and I am glad to fix it.
Thanks for your feedback, Tomás!
Fold Interval Faceting into Range Faceting
--
Key: SOLR-7795
URL: https://issues.apache.org/jira/browse/SOLR-7795
Project: Solr
Issue Type: Task
Reporter: Tomás Fernández Löbbe
Fix For: 5.3, Trunk
Now that range faceting supports a filter and a dv method, and that
interval faceting is supported on fields with {{docValues=false}}, I think we
should make it so that interval faceting is just a different way of
specifying ranges in range faceting, allowing users to indicate specific
ranges.
I propose we use the same syntax for intervals, but under the range
parameter family:
{noformat}
facet.range=price
f.price.facet.range.set=[0,10]
f.price.facet.range.set=(10,100]
{noformat}
The counts for those ranges would come in the response also inside of the
range_facets section. I'm not sure if it's better to include the ranges in
the counts section, or in a different section (intervals?sets?buckets?).
I'm open to suggestions.
{code}
facet_ranges:{
price:{
counts:[
[0,10],3,
(10,100],2]
}
}
{code}
or…
{code}
facet_ranges:{
price:{
intervals:[
[0,10],3,
(10,100],2]
}
}
{code}
We should support people specifying both things on the same field.
Once this is done, interval faceting could be deprecated, as all it's
functionality is now possible through range queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6625) HttpClient callback in HttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-6625:
---
Attachment: SOLR-6625_interceptor.patch
Updated the patch, using the SolrRequestInfo from previous patch (thanks
[~noble.paul]). Now, instead of enforcing httpclient.execute(req, context),
added a SolrHttpClient (and within it SolrDefaultHttpClient and
SolrSystemDefaultHttpClient) that adds the request object from the
SolrRequestInfo into an overridden execute() method transparently.
[~noble.paul], in your previous patch (the SolrRequestInfo part), there are a
few exceptions/assertions logged:
{noformat}
6564 ERROR (searcherExecutor-17-thread-1-processing-x:collection1
snapshot.20150730163745674
//tmp//solr.handler.TestRestoreCore_21A69B2D533EDA15-001//tempDir-002
collection1) [x:collection1] o.a.s.c.SolrCore Previous SolrRequestInfo was
not closed!
req=location=/tmp/solr.handler.TestRestoreCore_21A69B2D533EDA15-001/tempDir-002command=restore
6564 ERROR (searcherExecutor-17-thread-1-processing-x:collection1
snapshot.20150730163745674
//tmp//solr.handler.TestRestoreCore_21A69B2D533EDA15-001//tempDir-002
collection1) [x:collection1] o.a.s.c.SolrCore java.lang.AssertionError
at
org.apache.solr.request.SolrRequestInfo.setRequestInfo(SolrRequestInfo.java:58)
at
org.apache.solr.search.SolrIndexSearcher.warm(SolrIndexSearcher.java:2206)
at org.apache.solr.core.SolrCore$4.call(SolrCore.java:1817)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:198)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Can you please have look at it? I've included it as is in this current patch,
and haven't looked into why this is happening, since the tests are passing
anyway.
HttpClient callback in HttpSolrServer
-
Key: SOLR-6625
URL: https://issues.apache.org/jira/browse/SOLR-6625
Project: Solr
Issue Type: Improvement
Components: SolrJ
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Priority: Minor
Attachments: SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch,
SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch,
SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch
Some of our setups use Solr in a SPNego/kerberos setup (we've done this by
adding our own filters to the web.xml). We have an issue in that SPNego
requires a negotiation step, but some HttpSolrServer requests are not
repeatable, notably the PUT/POST requests. So, what happens is,
HttpSolrServer sends the requests, the server responds with a negotiation
request, and the request fails because the request is not repeatable. We've
modified our code to send a repeatable request beforehand in these cases.
It would be nicer if HttpSolrServer provided a pre/post callback when it was
making an httpclient request. This would allow administrators to make
changes to the request for authentication purposes, and would allow users to
make per-request changes to the httpclient calls (i.e. modify httpclient
requestconfig to modify the timeout on a per-request basis).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Strange comment in CdcrReplicationHandlerTest.java
Yes, my apologies for this, I didn't catch this one when I reviewed the code before commit. -- Renaud Delbru On 29/07/15 23:29, Erick Erickson wrote: Standard apache license, this was just a couple of erroneous lines at the top, I suspect auto-added to by his IDE, I messed it too. Will fix this in the next week, I'm traveling right now. To Whit. /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the License); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ On Wed, Jul 29, 2015 at 4:27 PM, Uwe Schindler u...@thetaphi.de wrote: RAT would only fail if the license header is missing completely. I don't think it checks for copyright notices. If there is no license header, we should check our RAT config! What does it list as license for that file? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, July 29, 2015 7:36 PM To: dev@lucene.apache.org Subject: Re: Strange comment in CdcrReplicationHandlerTest.java Yeah, I wondered that myself. On Wed, Jul 29, 2015 at 1:35 PM, Ramkumar R. Aiyengar andyetitmo...@gmail.com wrote: Hmm.. I would have expected rat to fail this in precommit actually.. On 29 Jul 2015 18:01, Timothy Potter thelabd...@gmail.com wrote: Why is this in the code? /** * Copyright (c) 2015 Renaud Delbru. All Rights Reserved. */ package org.apache.solr.cloud; - 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 - 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] (LUCENE-6707) PhraseQuery.Builder methods should return this to allow chaining
[ https://issues.apache.org/jira/browse/LUCENE-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647863#comment-14647863 ] ASF subversion and git services commented on LUCENE-6707: - Commit 1693448 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1693448 ] LUCENE-6707: Make PhraseQuery.Builder methods return this to allow chaining. PhraseQuery.Builder methods should return this to allow chaining Key: LUCENE-6707 URL: https://issues.apache.org/jira/browse/LUCENE-6707 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Priority: Minor Attachments: LUCENE-6707.patch Currently they return void, so you can't chain. Returning this would make it consistent with BooleanQuery.Builder. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6625) HttpClient callback in HttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647874#comment-14647874
]
Steve Rowe commented on SOLR-6625:
--
I'm seeing reproducible {{TestCloudSolrClientConnections}} failures on trunk
and branch_5x on my Jenkins after commits on this issue. Here's the trunk one
([http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/1152/]):
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=C37B717A18417443 -Dtests.slow=true -Dtests.locale=bg_BG
-Dtests.timezone=SystemV/HST10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 7.12s J1 |
TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp
[junit4] Throwable #1: org.apache.solr.common.SolrException: A
SolrHttpContext object must be passed in as context. Context:
{http.request=org.apache.http.impl.client.RequestWrapper@eddf10a,
http.request-config=[expectContinueEnabled=false, proxy=null,
localAddress=null, cookieSpec=null, redirectsEnabled=true,
relativeRedirectsAllowed=true, maxRedirects=50, circularRedirectsAllowed=false,
authenticationEnabled=true, targetPreferredAuthSchemes=null,
proxyPreferredAuthSchemes=null, connectionRequestTimeout=0, connectTimeout=0,
socketTimeout=0, decompressionEnabled=true],
http.auth.proxy-scope=state:UNCHALLENGED;, http.auth.credentials-provider={},
http.scheme-registry=org.apache.http.conn.scheme.SchemeRegistry@4861e7d6,
http.cookie-spec=best-match, http.cookie-store=[],
http.connection=org.apache.http.impl.conn.ManagedClientConnectionImpl@771b321c,
http.auth.target-scope=state:UNCHALLENGED;,
http.cookiespec-registry=org.apache.http.cookie.CookieSpecRegistry@1b78f4d2,
http.target_host=https://127.0.0.1:51727,
http.route={s}-https://127.0.0.1:51727,
http.cookie-origin=[(secure)127.0.0.1:51727/solr/admin/collections],
http.authscheme-registry=org.apache.http.auth.AuthSchemeRegistry@7acc1316}
[junit4]at
__randomizedtesting.SeedInfo.seed([C37B717A18417443:D897F2DA4A5D5186]:0)
[junit4]at
org.apache.solr.client.solrj.impl.HttpClientConfigurer$1.process(HttpClientConfigurer.java:92)
[junit4]at
org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:132)
[junit4]at
org.apache.http.protocol.HttpRequestExecutor.preProcess(HttpRequestExecutor.java:166)
[junit4]at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:485)
[junit4]at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
[junit4]at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
[junit4]at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
[junit4]at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
[junit4]at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:465)
[junit4]at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
[junit4]at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
[junit4]at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
[junit4]at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
[junit4]at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
[junit4]at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
[junit4]at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
[junit4]at
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
[junit4]at
org.apache.solr.client.solrj.impl.TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp(TestCloudSolrClientConnections.java:57)
[junit4]at java.lang.Thread.run(Thread.java:745)
{noformat}
and the branch_5x one
([http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/892/]):
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestCloudSolrClientConnections
-Dtests.method=testCloudClientCanConnectAfterClusterComesUp
-Dtests.seed=FC64970124605306 -Dtests.slow=true -Dtests.locale=ar_LY
-Dtests.timezone=Asia/Vientiane -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 1.84s J1 |
TestCloudSolrClientConnections.testCloudClientCanConnectAfterClusterComesUp
[junit4] Throwable #1:
[jira] [Comment Edited] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647887#comment-14647887 ] Ishan Chattopadhyaya edited comment on SOLR-6625 at 7/30/15 4:24 PM: - Attaching the patch to fix it. was (Author: ichattopadhyaya): [~sar...@syr.edu] Thanks for the pointer (and to the super fast sarowe jenkins). I had missed it. Attaching the patch to fix it. HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6708) TopFieldCollector sometimes calls Scorer.score() several times on the same doc
[ https://issues.apache.org/jira/browse/LUCENE-6708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-6708: - Attachment: LUCENE-6708.patch Here is a patch. I also took opportunity of this change to reduce over-specialization of our 3 top-field collectors (non-scoring, scoring-no-max and scoring-max) by merging them into a single class. TopFieldCollector sometimes calls Scorer.score() several times on the same doc -- Key: LUCENE-6708 URL: https://issues.apache.org/jira/browse/LUCENE-6708 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6708.patch If the sort spec includes a sort field that needs scores, and if trackDocScores or trackMaxScore is set, then TopFieldCollectors may compute the score several times on the same document, once to check whether the hit is competitive, and once to update maxScore or to set the score on the ScoreDoc. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6609) FieldCacheSource (or it's subclasses) should override getSortField
[
https://issues.apache.org/jira/browse/LUCENE-6609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648066#comment-14648066
]
Hoss Man commented on LUCENE-6609:
--
I think the same thing would make sense for
{{SortedSetFieldSource.getSortField()}} -- it can return an instance of
{{SortedSetSortField}}.
FieldCacheSource (or it's subclasses) should override getSortField
--
Key: LUCENE-6609
URL: https://issues.apache.org/jira/browse/LUCENE-6609
Project: Lucene - Core
Issue Type: Improvement
Reporter: Hoss Man
{{ValueSource}} defines the following method...
{code}
public SortField getSortField(boolean reverse) {
return new ValueSourceSortField(reverse);
}
{code}
...where {{ValueSourceSortField}} builds up a {{ValueSourceComparator}}
containing a {{double[]}} based on the {{FunctionValues}} of the original
{{ValueSource}}.
meanwhile, the abstract {{FieldCacheSource}} exists as a base implementation
for classes like {{IntFieldSource}} and {{DoubleFieldSource}} which wrap a
{{ValueSource}} around {{DocValues}} for the specified field.
But neither {{FieldCacheSource}} nor any of it's subclasses override the
{{getSortField(boolean)}} method -- so attempting to sort on something like
an {{IntFieldSource}} winds up using a bunch of ram to build that
{{double[]}} to give users a less accurate sort (because of casting) then if
they just sorted directly on the field.
is there any good reason why {{FieldCacheSource}} subclases like
{{IntFieldSource}} shouldn't all override {{getSortField}} with something
like...
{code}
public SortField getSortField(boolean reverse) {
return new SortField(field, Type.INT, reverse);
}
{code}
?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-6709) Add RandomAccessOrds support to UninvertedReader's SortedSetDocValues impl (DocTermOrds.Iterator)
Hoss Man created LUCENE-6709: Summary: Add RandomAccessOrds support to UninvertedReader's SortedSetDocValues impl (DocTermOrds.Iterator) Key: LUCENE-6709 URL: https://issues.apache.org/jira/browse/LUCENE-6709 Project: Lucene - Core Issue Type: Improvement Reporter: Hoss Man UninvertedReader's SortedSetDocValues impl doesn't implement the RandomAccessOrds API, so it can't be used with SortedSetSelector. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6625) HttpClient callback in HttpSolrServer
[ https://issues.apache.org/jira/browse/SOLR-6625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-6625: --- Attachment: SOLR-6625-testfailure.log I got an NPE with the patch (log attached). HttpClient callback in HttpSolrServer - Key: SOLR-6625 URL: https://issues.apache.org/jira/browse/SOLR-6625 Project: Solr Issue Type: Improvement Components: SolrJ Reporter: Gregory Chanan Assignee: Noble Paul Priority: Minor Attachments: SOLR-6625-testfailure.log, SOLR-6625-testfix.patch, SOLR-6625-testfix.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625.patch, SOLR-6625_SolrReqPropogate.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_interceptor.patch, SOLR-6625_r1654079.patch, SOLR-6625_r1654079.patch Some of our setups use Solr in a SPNego/kerberos setup (we've done this by adding our own filters to the web.xml). We have an issue in that SPNego requires a negotiation step, but some HttpSolrServer requests are not repeatable, notably the PUT/POST requests. So, what happens is, HttpSolrServer sends the requests, the server responds with a negotiation request, and the request fails because the request is not repeatable. We've modified our code to send a repeatable request beforehand in these cases. It would be nicer if HttpSolrServer provided a pre/post callback when it was making an httpclient request. This would allow administrators to make changes to the request for authentication purposes, and would allow users to make per-request changes to the httpclient calls (i.e. modify httpclient requestconfig to modify the timeout on a per-request basis). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6709) Add RandomAccessOrds support to UninvertedReader's SortedSetDocValues impl (DocTermOrds.Iterator)
[ https://issues.apache.org/jira/browse/LUCENE-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648077#comment-14648077 ] Hoss Man commented on LUCENE-6709: -- NOTE: I have no idea if/how feasible this is, i mainly just wanted to file it as an open issue for linking as a blocker to some other issues. Add RandomAccessOrds support to UninvertedReader's SortedSetDocValues impl (DocTermOrds.Iterator) - Key: LUCENE-6709 URL: https://issues.apache.org/jira/browse/LUCENE-6709 Project: Lucene - Core Issue Type: Improvement Reporter: Hoss Man UninvertedReader's SortedSetDocValues impl doesn't implement the RandomAccessOrds API, so it can't be used with SortedSetSelector. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
