[jira] [Commented] (SOLR-10798) Add support for different replica types in the new policy framework
[
https://issues.apache.org/jira/browse/SOLR-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032549#comment-16032549
]
Noble Paul commented on SOLR-10798:
---
[~tomasflobbe] pls comment
> Add support for different replica types in the new policy framework
> ---
>
> Key: SOLR-10798
> URL: https://issues.apache.org/jira/browse/SOLR-10798
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>
> The current syntax is for
> example
> {code}
> //ensures that at least 2 replicas go to servers with port 8983
> {"replica":">1", "shard":"#ANY" ,"port":8983}
> {code}
> We should add an implicit attribute called {{type}} and the value of {{type}}
> can be {{NRT}} (default) , {{TLOG}} or {{PULL}}
> so a policy would look as follows
> {code}
> {"replica":"1", "shard":"#ANY" ,"port":8983, "type":"NRT"}
> {"replica":"1", "shard":"#ANY" ,"port":7574, "type":"PULL"}
> {"replica":"1", "shard":"#ANY" ,"port":7573, "type":"TLOG"}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10798) Add support for different replica types in the new policy framework
Noble Paul created SOLR-10798:
-
Summary: Add support for different replica types in the new policy
framework
Key: SOLR-10798
URL: https://issues.apache.org/jira/browse/SOLR-10798
Project: Solr
Issue Type: Sub-task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
The current syntax is for
example
{code}
//ensures that at least 2 replicas go to servers with port 8983
{"replica":">1", "shard":"#ANY" ,"port":8983}
{code}
We should add an implicit attribute called {{type}} and the value of {{type}}
can be {{NRT}} (default) , {{TLOG}} or {{PULL}}
so a policy would look as follows
{code}
{"replica":"1", "shard":"#ANY" ,"port":8983, "type":"NRT"}
{"replica":"1", "shard":"#ANY" ,"port":7574, "type":"PULL"}
{"replica":"1", "shard":"#ANY" ,"port":7573, "type":"TLOG"}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10733) Rule-based Replica Placement not working correct
[
https://issues.apache.org/jira/browse/SOLR-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032537#comment-16032537
]
Noble Paul commented on SOLR-10733:
---
[~befehl] The rule {{shard:shard1,replica:<2,port:8983}} means the no:of
replicas in port 8983 could be zero
I guess the rule that you wanted to have is
{{shard:shard1,replica:>0,port:8983}}
> Rule-based Replica Placement not working correct
>
>
> Key: SOLR-10733
> URL: https://issues.apache.org/jira/browse/SOLR-10733
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Rules, SolrCloud
>Affects Versions: 6.5.1
>Reporter: Bernd Fehling
>Assignee: Noble Paul
> Attachments: SOLR-10733.patch, SOLR-10733.patch
>
>
> A setup of a SolrCloud with 6 nodes on 3 server e.g.:
> {code}
> server1:8983 , server1:7574
> server2:8983 , server2:7574
> server3:8983 , server3:7574
> {code}
> and a command for creating a new collection with rule:
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE&name=boss&;
> collection.configName=boss_configs&numShards=3&replicationFactor=2&
> maxShardsPerNode=1&rule=shard:shard1,replica:<2,port:8983
> {code}
> should create a collection with 3 shards and least a shard1 with two
> different nodes running on port 8983.
> {code}
> shard1 --> server_x:8983 , server_y:8983
> {code}
> A even more restrictive rule like
> {code}
> rule=shard:shard1,replica:<2,port:8983&rule=shard:shard3,replica:<2,port:7574
> {code}
> should also resolve to a solution because if it really checks all
> permutations accross shards/replicas/ports and available nodes it should be
> able to solve this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7213) Upgrade to latest Noggit
[ https://issues.apache.org/jira/browse/SOLR-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-7213. -- Resolution: Duplicate > Upgrade to latest Noggit > > > Key: SOLR-7213 > URL: https://issues.apache.org/jira/browse/SOLR-7213 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley > Fix For: 6.0, 5.2 > > > Noggit 0.7 is the latest released version and includes support for trailing > commas. For example [1,2,3,] is equivalent to [1,2,3] -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10744) Update noggit to newer version (0.8)
[ https://issues.apache.org/jira/browse/SOLR-10744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-10744. --- Resolution: Fixed > Update noggit to newer version (0.8) > > > Key: SOLR-10744 > URL: https://issues.apache.org/jira/browse/SOLR-10744 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: master (7.0) > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10744) Update noggit to newer version (0.8)
[ https://issues.apache.org/jira/browse/SOLR-10744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032482#comment-16032482 ] ASF subversion and git services commented on SOLR-10744: Commit 57fe80d8a054d84ba15e91c9854d5adb8207f772 in lucene-solr's branch refs/heads/master from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=57fe80d ] SOLR-10744: Update noggit to newer version (0.8) > Update noggit to newer version (0.8) > > > Key: SOLR-10744 > URL: https://issues.apache.org/jira/browse/SOLR-10744 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: master (7.0) > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10528) Use docvalue for range faceting in JSON facet API
[ https://issues.apache.org/jira/browse/SOLR-10528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kensho Hirasawa updated SOLR-10528: --- Attachment: SOLR-10528.patch I added tests and fixed two bugs found by the tests. The fixed bugs are the following. * When sub facet have a domain parameter with excludeTags, sub facets of buckets with zero count are not executed. * When hardend is true, the document with the same value as end is collected to a wrong bucket. > Use docvalue for range faceting in JSON facet API > - > > Key: SOLR-10528 > URL: https://issues.apache.org/jira/browse/SOLR-10528 > Project: Solr > Issue Type: Improvement > Components: Facet Module >Affects Versions: 6.5 >Reporter: Kensho Hirasawa >Priority: Minor > Attachments: SOLR-10528.patch, SOLR-10528.patch, SOLR-10528.patch > > > Range faceting in JSON facet API has only one implementation. In the > implementation, all buckets are allocated and then range queries are executed > for all the buckets. Therefore, memory usage and computational cost of range > facet can be very high if range is wide and gap is narrow. > I think range faceting in JSON facet should have the implementation which > uses DocValues instead of inverted indices. By scanning DocValues, we can > execute range facets much more efficiently especially when the number of > buckets is large. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7860) PackedQuadCell need not eagerly pre-compute the term bytes
[ https://issues.apache.org/jira/browse/LUCENE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-7860: - Attachment: LUCENE_7860__PackedQuadCell_refactor.patch This patch is WIP; last I checked tests failed so I'm not sure what I missed. I'm not sure if I'll return to it. I had done some of this while addressing LUCENE-7859 but then backed off a bit to focus narrowly on that bug. FYI [~nknize] > PackedQuadCell need not eagerly pre-compute the term bytes > -- > > Key: LUCENE-7860 > URL: https://issues.apache.org/jira/browse/LUCENE-7860 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: David Smiley > Attachments: LUCENE_7860__PackedQuadCell_refactor.patch > > > PackedQuadCell is eagerly computing the term bytes, and I don't think it > should bother -- it might not even be used. It also extends LegacyCell, > which it needn't; it has legacy baggage and term bytes that can be omitted. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7860) PackedQuadCell need not eagerly pre-compute the term bytes
David Smiley created LUCENE-7860: Summary: PackedQuadCell need not eagerly pre-compute the term bytes Key: LUCENE-7860 URL: https://issues.apache.org/jira/browse/LUCENE-7860 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial-extras Reporter: David Smiley PackedQuadCell is eagerly computing the term bytes, and I don't think it should bother -- it might not even be used. It also extends LegacyCell, which it needn't; it has legacy baggage and term bytes that can be omitted. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10744) Update noggit to newer version (0.8)
[ https://issues.apache.org/jira/browse/SOLR-10744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-10744: -- Fix Version/s: master (7.0) > Update noggit to newer version (0.8) > > > Key: SOLR-10744 > URL: https://issues.apache.org/jira/browse/SOLR-10744 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: master (7.0) > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7845) spatial RPT optimization when query by point or common date range
[ https://issues.apache.org/jira/browse/LUCENE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-7845. -- Resolution: Fixed I found and fixed and committed the bug fix: LUCENE-7859 I also beast-ed that for a bit. > spatial RPT optimization when query by point or common date range > - > > Key: LUCENE-7845 > URL: https://issues.apache.org/jira/browse/LUCENE-7845 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: David Smiley >Assignee: David Smiley > Fix For: master (7.0) > > Attachments: LUCENE_7845_query_by_point_optimization.patch > > > If the query to an RPT index is a 2D point, or if using > NumerBrangePrefixTreeStrategy / DateRangePrefixTree (Solr DateRangeField) if > the query is a grid cell (a common date range unit like some particular day), > then we can do some optimizations, especially if the data is pointsOnly. If > the data is pointsOnly the strategy can return a TermQuery, if the data isn't > then we can at least tweak the prefixGridScanLevel. This is motivated by two > scenarios: > * indexing polygons and doing lookups by a point (AKA reverse geocoding) > * indexing date instances and doing date range faceting. Solr's code for this > has a fast path for a TermQuery, although more is needed beyond this issue to > get there. > _This development was funded by the Harvard Center for Geographic Analysis as > part of the HHypermap project_ -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10793) BlobHandler should have a well-known permission name
[
https://issues.apache.org/jira/browse/SOLR-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-10793.
---
Resolution: Fixed
Assignee: Noble Paul
Fix Version/s: master (7.0)
> BlobHandler should have a well-known permission name
> -
>
> Key: SOLR-10793
> URL: https://issues.apache.org/jira/browse/SOLR-10793
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: master (7.0)
>
> Attachments: SOLR-10793.patch
>
>
> Users should be able to restrict access to blobstore with the below
> permissions
> {code}
> {
> "set-permission" : {"name":"update", "collection" : ".system",
> "role":"admin"}
> "set-permission" : {"name":"read", "collection" : ".system", "role":"guest"}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7859) PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
[
https://issues.apache.org/jira/browse/LUCENE-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-7859.
--
Resolution: Fixed
> PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
> -
>
> Key: LUCENE-7859
> URL: https://issues.apache.org/jira/browse/LUCENE-7859
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial-extras
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
>
> PackedQuadCell.getTokenBytesNoLeaf and PackedQuadCell.getTokenBytesWithLeaf
> have a couple issues that were exposed in LUCENE-7845. One is that the
> WithLeaf version actually modifies the state ({{long term}}) which it
> shouldn't. Another is that if the BytesRef is null, it can compute a
> different result than if it's not null, which is definitely wrong.
> It _appears_ that these problems are only revealing themselves in practice
> with the LUCENE-7845 optimization since there has been no PackedQuad test
> failure before, and RandomSpatialOpFuzzyPrefixTreeTest really hammers the
> prefix tree.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7859) PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
[
https://issues.apache.org/jira/browse/LUCENE-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032457#comment-16032457
]
ASF subversion and git services commented on LUCENE-7859:
-
Commit 38741ece587f2bfb4a2f6393ea84684f44a52dd5 in lucene-solr's branch
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=38741ec ]
LUCENE-7859: PackedQuadPrefixTree getTokenBytes bug
> PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
> -
>
> Key: LUCENE-7859
> URL: https://issues.apache.org/jira/browse/LUCENE-7859
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial-extras
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
>
> PackedQuadCell.getTokenBytesNoLeaf and PackedQuadCell.getTokenBytesWithLeaf
> have a couple issues that were exposed in LUCENE-7845. One is that the
> WithLeaf version actually modifies the state ({{long term}}) which it
> shouldn't. Another is that if the BytesRef is null, it can compute a
> different result than if it's not null, which is definitely wrong.
> It _appears_ that these problems are only revealing themselves in practice
> with the LUCENE-7845 optimization since there has been no PackedQuad test
> failure before, and RandomSpatialOpFuzzyPrefixTreeTest really hammers the
> prefix tree.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7859) PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
David Smiley created LUCENE-7859:
Summary: PackedQuadCell.getTokenBytesNoLeaf bug when null BytesRef
Key: LUCENE-7859
URL: https://issues.apache.org/jira/browse/LUCENE-7859
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial-extras
Reporter: David Smiley
Assignee: David Smiley
Fix For: master (7.0)
PackedQuadCell.getTokenBytesNoLeaf and PackedQuadCell.getTokenBytesWithLeaf
have a couple issues that were exposed in LUCENE-7845. One is that the WithLeaf
version actually modifies the state ({{long term}}) which it shouldn't. Another
is that if the BytesRef is null, it can compute a different result than if it's
not null, which is definitely wrong.
It _appears_ that these problems are only revealing themselves in practice with
the LUCENE-7845 optimization since there has been no PackedQuad test failure
before, and RandomSpatialOpFuzzyPrefixTreeTest really hammers the prefix tree.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_131) - Build # 3635 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3635/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([3677784A92508F17:5CA54725CAB35FD8]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895) at org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers(TestMaxTokenLenTokenizer.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 09 request was:q=letter0:lett&wt=xml at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:888) ... 40 more Build Log: [...truncated 11044 lines...]
[jira] [Commented] (SOLR-10793) BlobHandler should have a well-known permission name
[
https://issues.apache.org/jira/browse/SOLR-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032412#comment-16032412
]
ASF subversion and git services commented on SOLR-10793:
Commit 4a378eb0ad9963579ebc45e4b3755f378e7500cc in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4a378eb ]
SOLR-10793: BlobHandler should have a well-known permission name
> BlobHandler should have a well-known permission name
> -
>
> Key: SOLR-10793
> URL: https://issues.apache.org/jira/browse/SOLR-10793
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
> Attachments: SOLR-10793.patch
>
>
> Users should be able to restrict access to blobstore with the below
> permissions
> {code}
> {
> "set-permission" : {"name":"update", "collection" : ".system",
> "role":"admin"}
> "set-permission" : {"name":"read", "collection" : ".system", "role":"guest"}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10781) Remove innerText of
[ https://issues.apache.org/jira/browse/SOLR-10781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032405#comment-16032405 ] Erick Erickson edited comment on SOLR-10781 at 6/1/17 3:59 AM: --- Is this a Tika issue, or possibly config options for Tika? Solr just indexes what you give it. The next user might _want_ this stuff indexed so making Solr do this automagically seems wrong. P.S. Please raise issues like this on the user's list first. If consensus is reached that this is something that should go in Solr, _then_ raise a JIRA. was (Author: erickerickson): Is this a Tika issue, or possibly config options for Tika? Solr just indexes what you give it. The next user might _want_ this stuff indexed so making Solr do this automagically seems wrong. > Remove innerText of
[jira] [Commented] (SOLR-10781) Remove innerText of
[ https://issues.apache.org/jira/browse/SOLR-10781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032405#comment-16032405 ] Erick Erickson commented on SOLR-10781: --- Is this a Tika issue, or possibly config options for Tika? Solr just indexes what you give it. The next user might _want_ this stuff indexed so making Solr do this automagically seems wrong. > Remove innerText of
[jira] [Commented] (SOLR-10749) Should ref guide asciidoc files' line length be limited?
[
https://issues.apache.org/jira/browse/SOLR-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032398#comment-16032398
]
Erick Erickson commented on SOLR-10749:
---
-1 on enforcing line length. The argument that we enforce line wrapping in code
is apples-oranges IMO. In code both readability and correctness are sensitive
to line breaks
someObject.getSomethng().dosomething()
or
someObject.getSomethng().
dosomething()
or even
someObject.getSomething()
.dosomething()
all hang together.
But
someObject.get
Somethng().dosomething()
not only is hard to follow, it fails compilation.
Text is a different beast. If I have to adjust all of the lines in a paragraph
because I want to add three words to the first sentence I'll go mad. Requiring
each new sentence to start after a hard break would make very spaced-out
documents or ones that are visually unappealing. Isn't the usual standard here
that hard breaks do a 1.5 spacing where soft breaks are 1.0? So new paragraphs
have a bit of extra space from the last sentence of the previous paragraph.
Besides, a single sentence could easily go over 120 characters (or whatever the
limit would be), does that now require a hard line break too? How would that be
distinguished from the user-entered hard breaks at the end of sentences? Line
length is really a null concept in flowed text, paragraphs are what count.
I confess that I don't particularly like the vertical pane splitting in the
IntelliJ IDE, haven't figured out how to make it horizontal instead, but even
so seeing the text appear in its final format as I type is _really_ helpful...
> Should ref guide asciidoc files' line length be limited?
>
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.6-Linux (64bit/jdk1.8.0_131) - Build # 40 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/40/ Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([EB75E1A81290B930:6321DE72BC6CD4C8]:0) at org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test(TestSolrConfigHandlerConcurrent.java:109) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11898 lines...] [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerConcurrent [junit4] 2> Creating da
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+171) - Build # 19753 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19753/ Java: 32bit/jdk-9-ea+171 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.rule.RulesTest.doIntegrationTest Error Message: Error from server at http://127.0.0.1:37113/solr: delete the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:37113/solr: delete the collection time out:180s at __randomizedtesting.SeedInfo.seed([4EA60B115771BB6D:AB954C904B05496F]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:610) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:237) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1129) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:805) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177) at org.apache.solr.cloud.MiniSolrCloudCluster.deleteAllCollections(MiniSolrCloudCluster.java:442) at org.apache.solr.cloud.rule.RulesTest.removeCollections(RulesTest.java:63) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:965) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apach
Re: [JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+171) - Build # 3629 - Still Unstable!
Do note that we understand where this is coming from and are working on a fix that should be in place soon See LUCENE-7857 Sorry for the noise meanwhile. Erick On Wed, May 31, 2017 at 3:22 AM, Policeman Jenkins Server wrote: > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3629/ > Java: 32bit/jdk-9-ea+171 -client -XX:+UseConcMarkSweepGC > > 1 tests failed. > FAILED: > org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers > > Error Message: > Exception during query > > Stack Trace: > java.lang.RuntimeException: Exception during query > at > __randomizedtesting.SeedInfo.seed([6A12DFC046B6CA7B:C0E0AF1E551AB4]:0) > at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895) > at > org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers(TestMaxTokenLenTokenizer.java:104) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:563) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) > at > org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) > at > com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) > at > com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) > at > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) > at > org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) > at > org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) > at > org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) > at > com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) > at > com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java
Re: Replica naming changed.
I like (2) best. And IMO we don't need to do it until necessary. I agree it could be "interesting", OTOH it may be super simple. Once the state.json file is re-read it may all just be OK. For (3) I'd need to see a compelling use-case, I'd hate to try to debug the problems from messing up the pattern. I suppose we could barf if, say, they had already used the name for anything in the collection so maybe it wouldn't be too bad. But I don't think I'd like to do anything on that up front. And I think we actually _do_ allow replica naming if you ADDREPLICA with a property.name=whatever. But I so don't want to deal with the ramifications that I'm not even going to try it to see. ;) Erick On Wed, May 31, 2017 at 10:30 AM, Tomas Fernandez Lobbe wrote: > Thanks for the summary Erick. I’m also in favor of leaving the type as part > of the name. In the future if we provide the option of changing the type of a > replica I can see three options: > 1) We do nothing with the name. The user who does replica type changes will > have to know that this character is meaningless for them. Not the best > option, specially if we provide an automated way to change the type. > 2) We change the name of the replica to reflect the new type. May not be too > easy, not sure how other parts of Solr will react to this, but may be the > best approach. > 3) We provide a way for users to define their own naming scheme for replicas > (I’m thinking something like log4j logging pattern). Not sure if this will be > needed really, it depends on how internal we consider the replica naming to > be. > > Tomás > >> On May 30, 2017, at 10:32 AM, Erick Erickson wrote: >> >> Tomás: >> >> Thought that might be the case. I'm not opposed to the naming change >> as long as it serves a purpose as this one does. People shouldn't >> write scripts that assume hard-coded names anyway ;). >> >> Ishan: >> >> I give long odds that we _will_ need the capability to reassign >> replica roles. One of the points of this work is that people need to >> fine-tune how nodes on the cluster are utilized, which I'd imagine >> means reassigning replica functions. >> >> All: >> >> I rather like that the node name gives us information about the role. >> having to go to the state.json file to find some other property is >> onerous, especially in very large installations. >> >> Proposal: >> >> Let's keep the naming convention with the n, t, and p notation. If in >> the future we want to reassign a replica's role we can rename the node >> when its role changes. >> >> On Tue, May 30, 2017 at 10:12 AM, Ishan Chattopadhyaya >> wrote: >>> Do we shut ourselves out of the possibility to ever re-assigning the replica >>> types, by using this naming convention? >>> For example, is there any conceivable scenario in future whereby an NRT >>> replica can become a TLOG replica? >>> Never mind my asking if this flexibility is something we're sure we'll never >>> need. >>> >>> On Tue, May 30, 2017 at 9:49 PM, Tomas Fernandez Lobbe >>> wrote: Hi Erick, This change is part of replica types. I mentioned this in SOLR-10233, but you are right, I should have mentioned probably in the dev list to get to more people. The last character represents the type of replica (n->NRT, t->TLOG, p->PULL). This is certainly not required and can be reverted back if people has concerns. I found it very useful when developing and I think it will also be helpful in prod, since the replica name is present in most log entries (since the MDC logging changes). Tomás > On May 30, 2017, at 8:54 AM, Erick Erickson > wrote: > > I noticed recently that our replica names are changing (master only?) > to collection_shard1_replica_n1. Why? > > Mostly I wan to be sure we consider whether this change is worth the > confusion before it gets out into the wild. If it's just an aesthetic > change I question whether it's worth the confusion it'll generate. If > it serves a real purpose, that's another story.. > > Erick > > - > 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] (SOLR-10239) MOVEREPLICA API
[
https://issues.apache.org/jira/browse/SOLR-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032312#comment-16032312
]
ASF subversion and git services commented on SOLR-10239:
Commit 5d0aa603d724f4e2d9aa2a62883c240b0631f2dd in lucene-solr's branch
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5d0aa60 ]
SOLR-10239: Adding documentation for MoveReplica
> MOVEREPLICA API
> ---
>
> Key: SOLR-10239
> URL: https://issues.apache.org/jira/browse/SOLR-10239
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Cao Manh Dat
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10239.patch, SOLR-10239.patch, SOLR-10239.patch
>
>
> To move a replica from a node to another node, there should be an API
> command. This should be better than having to do ADDREPLICA and DELETEREPLICA.
> The API will like this
> {code}
> /admin/collections?action=MOVEREPLICA&collection=collection&shard=shard&replica=replica&node=nodeName&toNode=nodeName
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3634 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3634/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([9B58DB541240BF31:F18AE43B4AA36FFE]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895) at org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers(TestMaxTokenLenTokenizer.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=letter0:lett&wt=xml at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:888) ... 40 more Build Log: [...truncated 13288 lines...] [junit4] S
[jira] [Created] (SOLR-10797) Numeric PointsFields: test ranges with IndexOrDocValuesQuery
Steve Rowe created SOLR-10797: - Summary: Numeric PointsFields: test ranges with IndexOrDocValuesQuery Key: SOLR-10797 URL: https://issues.apache.org/jira/browse/SOLR-10797 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe TestPointFields.testIndexOrDocValuesQuery() tests that IndexOrDocValuesQuery is created under the appropriate circumstances, but these queries are not functionally tested. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10796) TestPointsField: increase randomized testing of non-trivial values
Steve Rowe created SOLR-10796: - Summary: TestPointsField: increase randomized testing of non-trivial values Key: SOLR-10796 URL: https://issues.apache.org/jira/browse/SOLR-10796 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe A lot of TestPointsField code just uses positive nums, or only ranodmizes values between -100 and 100, etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
Steve Rowe created SOLR-10795: - Summary: Numeric PointsFields: test multivalued sort using field(name, min|max) syntax Key: SOLR-10795 URL: https://issues.apache.org/jira/browse/SOLR-10795 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe TestMinMaxOnMultiValuedField tests Trie types for this case, should also test Points -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10794) Numeric PointsFields: need more testing of sorting/boosting by numeric functions
[ https://issues.apache.org/jira/browse/SOLR-10794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-10794: -- Issue Type: Sub-task (was: Task) Parent: SOLR-9995 > Numeric PointsFields: need more testing of sorting/boosting by numeric > functions > > > Key: SOLR-10794 > URL: https://issues.apache.org/jira/browse/SOLR-10794 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > > Places to audit for points testing: TestQueryTypes, SortByFunctionTest, > TestFunctionQuery -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10794) Numeric PointsFields: need more testing of sorting/boosting by numeric functions
Steve Rowe created SOLR-10794: - Summary: Numeric PointsFields: need more testing of sorting/boosting by numeric functions Key: SOLR-10794 URL: https://issues.apache.org/jira/browse/SOLR-10794 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Steve Rowe Assignee: Steve Rowe Places to audit for points testing: TestQueryTypes, SortByFunctionTest, TestFunctionQuery -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10793) BlobHandler should have a well-known permission name
[
https://issues.apache.org/jira/browse/SOLR-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-10793:
--
Attachment: SOLR-10793.patch
> BlobHandler should have a well-known permission name
> -
>
> Key: SOLR-10793
> URL: https://issues.apache.org/jira/browse/SOLR-10793
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
> Attachments: SOLR-10793.patch
>
>
> Users should be able to restrict access to blobstore with the below
> permissions
> {code}
> {
> "set-permission" : {"name":"update", "collection" : ".system",
> "role":"admin"}
> "set-permission" : {"name":"read", "collection" : ".system", "role":"guest"}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10793) BlobHandler should have a well-known permission name
[
https://issues.apache.org/jira/browse/SOLR-10793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-10793:
--
Summary: BlobHandler should have a well-known permission name (was:
BlobHandler should have a special permission name)
> BlobHandler should have a well-known permission name
> -
>
> Key: SOLR-10793
> URL: https://issues.apache.org/jira/browse/SOLR-10793
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>
> Users should be able to restrict access to blobstore with the below
> permissions
> {code}
> {
> "set-permission" : {"name":"update", "collection" : ".system",
> "role":"admin"}
> "set-permission" : {"name":"read", "collection" : ".system", "role":"guest"}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10733) Rule-based Replica Placement not working correct
[
https://issues.apache.org/jira/browse/SOLR-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-10733:
-
Assignee: Noble Paul (was: Bernd Fehling)
> Rule-based Replica Placement not working correct
>
>
> Key: SOLR-10733
> URL: https://issues.apache.org/jira/browse/SOLR-10733
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Rules, SolrCloud
>Affects Versions: 6.5.1
>Reporter: Bernd Fehling
>Assignee: Noble Paul
> Attachments: SOLR-10733.patch, SOLR-10733.patch
>
>
> A setup of a SolrCloud with 6 nodes on 3 server e.g.:
> {code}
> server1:8983 , server1:7574
> server2:8983 , server2:7574
> server3:8983 , server3:7574
> {code}
> and a command for creating a new collection with rule:
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE&name=boss&;
> collection.configName=boss_configs&numShards=3&replicationFactor=2&
> maxShardsPerNode=1&rule=shard:shard1,replica:<2,port:8983
> {code}
> should create a collection with 3 shards and least a shard1 with two
> different nodes running on port 8983.
> {code}
> shard1 --> server_x:8983 , server_y:8983
> {code}
> A even more restrictive rule like
> {code}
> rule=shard:shard1,replica:<2,port:8983&rule=shard:shard3,replica:<2,port:7574
> {code}
> should also resolve to a solution because if it really checks all
> permutations accross shards/replicas/ports and available nodes it should be
> able to solve this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10793) BlobHandler should have a special permission name
Noble Paul created SOLR-10793:
-
Summary: BlobHandler should have a special permission name
Key: SOLR-10793
URL: https://issues.apache.org/jira/browse/SOLR-10793
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
Users should be able to restrict access to blobstore with the below permissions
{code}
{
"set-permission" : {"name":"update", "collection" : ".system", "role":"admin"}
"set-permission" : {"name":"read", "collection" : ".system", "role":"guest"}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3633 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3633/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([4022B6CCAD7E5F29:2AF089A3F59D8FE6]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895) at org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers(TestMaxTokenLenTokenizer.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=letter0:lett&wt=xml at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:888) ... 40 more Build Log: [...truncated 13295 lines...] [junit4] S
[jira] [Resolved] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-10137. Resolution: Fixed Fix Version/s: 6.7 master (7.0) > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre >Assignee: Mark Miller > Fix For: master (7.0), 6.7 > > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10792) Deprecate & remove "OldLuceneQParser"
[ https://issues.apache.org/jira/browse/SOLR-10792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10792: Attachment: SOLR-10792.patch forgot to 'git add' the ref guide changes in the last patch. > Deprecate & remove "OldLuceneQParser" > - > > Key: SOLR-10792 > URL: https://issues.apache.org/jira/browse/SOLR-10792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: master (7.0) > > Attachments: SOLR-10792.patch, SOLR-10792.patch > > > Somehow, even though it was already "Old" before Solr was contributed to > Apache 11 freaking years ago, we have never gotten around to officially > deprecating the "OldLuceneQParser" (which has a really hacky syntax that > predates being able to send multiple request params to solr). > we should: > * officially mark this "deprecated" in 7.0 > * remove mentions of it from the ref gude > * delete from master (once we have a branch_7) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032051#comment-16032051 ] ASF subversion and git services commented on SOLR-10137: Commit 7015fdc56309f66455aef0a1049d61b0a0745193 in lucene-solr's branch refs/heads/branch_6x from [~mark.mil...@oblivion.ch] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7015fdc ] SOLR-10137: Ensure that ConfigSets created via API are mutable. > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre >Assignee: Mark Miller > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032050#comment-16032050 ] ASF subversion and git services commented on SOLR-10137: Commit 7da9e9d7352083060d45c1a10430a3a17fdeefbe in lucene-solr's branch refs/heads/master from [~mark.mil...@oblivion.ch] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7da9e9d ] SOLR-10137: Ensure that ConfigSets created via API are mutable. > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre >Assignee: Mark Miller > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10792) Deprecate & remove "OldLuceneQParser"
[ https://issues.apache.org/jira/browse/SOLR-10792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-10792: Attachment: SOLR-10792.patch patch actually takes things one step further then i originally suggested... In addition to deprecating OldLuceneQParserPlugin It also removes OldLuceneQParserPlugin from the list of default QParsers, so that if anyone is still using it they'll need to explicitly register it in solrconfig.xml. Patch also includes an update to the (oldest) test solrconfig.xml showing that this registration works and allows the handful of tests that care about "lucenePlusSort" to pass. > Deprecate & remove "OldLuceneQParser" > - > > Key: SOLR-10792 > URL: https://issues.apache.org/jira/browse/SOLR-10792 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: master (7.0) > > Attachments: SOLR-10792.patch > > > Somehow, even though it was already "Old" before Solr was contributed to > Apache 11 freaking years ago, we have never gotten around to officially > deprecating the "OldLuceneQParser" (which has a really hacky syntax that > predates being able to send multiple request params to solr). > we should: > * officially mark this "deprecated" in 7.0 > * remove mentions of it from the ref gude > * delete from master (once we have a branch_7) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10290) New Publication Model for Solr Reference Guide
[ https://issues.apache.org/jira/browse/SOLR-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031970#comment-16031970 ] ASF subversion and git services commented on SOLR-10290: Commit fc8be1c1620363793b7e280645ca589e27041c9a in lucene-solr's branch refs/heads/branch_6x from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fc8be1c ] SOLR-10290: Replace the bright green in the bottom nav links with a lighter tone of the header > New Publication Model for Solr Reference Guide > -- > > Key: SOLR-10290 > URL: https://issues.apache.org/jira/browse/SOLR-10290 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Attachments: sitemap.patch, sitemap.patch > > > The current Solr Ref Guide is hosted at cwiki.apache.org, a Confluence > installation. There are numerous reasons to be dissatisfied with the current > setup, a few of which are: > * Confluence as a product is no longer designed for our use case and our type > of content. > * The writing/editing experience is painful and a barrier for all users, who > need to learn a lot of Confluence-specific syntax just to help out with some > content. > * Non-committers can't really help improve documentation except to point out > problems and hope someone else fixes them. > * We really can't maintain online documentation for different versions. Users > on versions other than the one that hasn't been released yet are only given a > PDF to work with. > I made a proposal in Aug 2016 ([email > link|http://mail-archives.apache.org/mod_mbox/lucene-dev/201608.mbox/%3CCAKrJsP%3DqMLVZhb8xR2C27mfNFfEJ6b%3DPcjxPz4f3fq7G371B_g%40mail.gmail.com%3E]) > to move the Ref Guide from Confluence to a new system that relies on > asciidoc-formatted text files integrated with the Solr source code. > This is an umbrella issue for the sub-tasks and related decisions to make > that proposal a reality. A lot of work has already been done as part of a > proof-of-concept, but there are many things left to do. Some of the items to > be completed include: > * Creation of a branch and moving the early POC work I've done to the project > * Conversion the content and clean up of unavoidable post-conversion issues > * Decisions about location of source files, branching strategy and hosting > for online versions > * Meta-documentation for publication process, beginner tips, etc. (whatever > else people need or want) > * Integration of build processes with the broader project > For reference, a demo of what the new ref guide might look like is currently > online at http://people.apache.org/~ctargett/RefGuidePOC/. > Creation of sub-tasks to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10290) New Publication Model for Solr Reference Guide
[ https://issues.apache.org/jira/browse/SOLR-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031972#comment-16031972 ] ASF subversion and git services commented on SOLR-10290: Commit 41268b175c0ef41cba36442bbc76d3ea787d93cd in lucene-solr's branch refs/heads/branch_6_6 from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=41268b1 ] SOLR-10290: Replace the bright green in the bottom nav links with a lighter tone of the header > New Publication Model for Solr Reference Guide > -- > > Key: SOLR-10290 > URL: https://issues.apache.org/jira/browse/SOLR-10290 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Attachments: sitemap.patch, sitemap.patch > > > The current Solr Ref Guide is hosted at cwiki.apache.org, a Confluence > installation. There are numerous reasons to be dissatisfied with the current > setup, a few of which are: > * Confluence as a product is no longer designed for our use case and our type > of content. > * The writing/editing experience is painful and a barrier for all users, who > need to learn a lot of Confluence-specific syntax just to help out with some > content. > * Non-committers can't really help improve documentation except to point out > problems and hope someone else fixes them. > * We really can't maintain online documentation for different versions. Users > on versions other than the one that hasn't been released yet are only given a > PDF to work with. > I made a proposal in Aug 2016 ([email > link|http://mail-archives.apache.org/mod_mbox/lucene-dev/201608.mbox/%3CCAKrJsP%3DqMLVZhb8xR2C27mfNFfEJ6b%3DPcjxPz4f3fq7G371B_g%40mail.gmail.com%3E]) > to move the Ref Guide from Confluence to a new system that relies on > asciidoc-formatted text files integrated with the Solr source code. > This is an umbrella issue for the sub-tasks and related decisions to make > that proposal a reality. A lot of work has already been done as part of a > proof-of-concept, but there are many things left to do. Some of the items to > be completed include: > * Creation of a branch and moving the early POC work I've done to the project > * Conversion the content and clean up of unavoidable post-conversion issues > * Decisions about location of source files, branching strategy and hosting > for online versions > * Meta-documentation for publication process, beginner tips, etc. (whatever > else people need or want) > * Integration of build processes with the broader project > For reference, a demo of what the new ref guide might look like is currently > online at http://people.apache.org/~ctargett/RefGuidePOC/. > Creation of sub-tasks to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10290) New Publication Model for Solr Reference Guide
[ https://issues.apache.org/jira/browse/SOLR-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031968#comment-16031968 ] ASF subversion and git services commented on SOLR-10290: Commit f34155fb2014393da50a836a1b78416c406b0dfd in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f34155f ] SOLR-10290: Replace the bright green in the bottom nav links with a lighter tone of the header > New Publication Model for Solr Reference Guide > -- > > Key: SOLR-10290 > URL: https://issues.apache.org/jira/browse/SOLR-10290 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Attachments: sitemap.patch, sitemap.patch > > > The current Solr Ref Guide is hosted at cwiki.apache.org, a Confluence > installation. There are numerous reasons to be dissatisfied with the current > setup, a few of which are: > * Confluence as a product is no longer designed for our use case and our type > of content. > * The writing/editing experience is painful and a barrier for all users, who > need to learn a lot of Confluence-specific syntax just to help out with some > content. > * Non-committers can't really help improve documentation except to point out > problems and hope someone else fixes them. > * We really can't maintain online documentation for different versions. Users > on versions other than the one that hasn't been released yet are only given a > PDF to work with. > I made a proposal in Aug 2016 ([email > link|http://mail-archives.apache.org/mod_mbox/lucene-dev/201608.mbox/%3CCAKrJsP%3DqMLVZhb8xR2C27mfNFfEJ6b%3DPcjxPz4f3fq7G371B_g%40mail.gmail.com%3E]) > to move the Ref Guide from Confluence to a new system that relies on > asciidoc-formatted text files integrated with the Solr source code. > This is an umbrella issue for the sub-tasks and related decisions to make > that proposal a reality. A lot of work has already been done as part of a > proof-of-concept, but there are many things left to do. Some of the items to > be completed include: > * Creation of a branch and moving the early POC work I've done to the project > * Conversion the content and clean up of unavoidable post-conversion issues > * Decisions about location of source files, branching strategy and hosting > for online versions > * Meta-documentation for publication process, beginner tips, etc. (whatever > else people need or want) > * Integration of build processes with the broader project > For reference, a demo of what the new ref guide might look like is currently > online at http://people.apache.org/~ctargett/RefGuidePOC/. > Creation of sub-tasks to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7834) BlockTree's terms index should be loaded into memory lazily
[
https://issues.apache.org/jira/browse/LUCENE-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031955#comment-16031955
]
David Smiley commented on LUCENE-7834:
--
I can move this to a boolean option on BlockTreeTermsReader. When the option is
disabled (thus eager), I can also have the constructor eagerly close the
IndexInput for the index as it won't be needed (one less file handle).
Alternatively, I could add a method to eager load them (and close that
IndexInput) that can be called immediately after construction by
Lucene50PostingsFormat. Any opinion?
> BlockTree's terms index should be loaded into memory lazily
> ---
>
> Key: LUCENE-7834
> URL: https://issues.apache.org/jira/browse/LUCENE-7834
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: LUCENE_7834_BlockTreeLazyFST.patch
>
>
> I propose that BlockTree delay loading the FST prefix terms index into memory
> until {{terms(String)}} is first called. This seems like how it should work
> since if someone wants to eager load then they can use {{IndexReaderWarmer}}.
> By making the FST lazy load, we can be more NRT friendly (if some fields are
> rarely used), and also save memory (if some fields are rarely used).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10773) Add support for replica types in V2 API
[ https://issues.apache.org/jira/browse/SOLR-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe resolved SOLR-10773. -- Resolution: Fixed Assignee: Tomás Fernández Löbbe > Add support for replica types in V2 API > --- > > Key: SOLR-10773 > URL: https://issues.apache.org/jira/browse/SOLR-10773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe >Assignee: Tomás Fernández Löbbe > Attachments: SOLR-10773.patch, SOLR-10773.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10773) Add support for replica types in V2 API
[ https://issues.apache.org/jira/browse/SOLR-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031938#comment-16031938 ] ASF subversion and git services commented on SOLR-10773: Commit 22c2ed070a821efa3c5a81ca03312d4034fcb878 in lucene-solr's branch refs/heads/master from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=22c2ed0 ] SOLR-10773: Add support for replica types in V2 API > Add support for replica types in V2 API > --- > > Key: SOLR-10773 > URL: https://issues.apache.org/jira/browse/SOLR-10773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe > Attachments: SOLR-10773.patch, SOLR-10773.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
SolrMetricReporter init/validate logic
Hi Everyone, If anyone has a few minutes, I'd appreciate further input and/or code reviews for https://issues.apache.org/jira/browse/SOLR-10671 logic tweaks. Thanks, Christine
[jira] [Assigned] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-10137: -- Assignee: Mark Miller > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre >Assignee: Mark Miller > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031885#comment-16031885 ] Mark Miller commented on SOLR-10137: Looks like it may have been some unrelated issue. I'm running the tests again after seeing a successful run. > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10792) Deprecate & remove "OldLuceneQParser"
Hoss Man created SOLR-10792: --- Summary: Deprecate & remove "OldLuceneQParser" Key: SOLR-10792 URL: https://issues.apache.org/jira/browse/SOLR-10792 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Hoss Man Assignee: Hoss Man Fix For: master (7.0) Somehow, even though it was already "Old" before Solr was contributed to Apache 11 freaking years ago, we have never gotten around to officially deprecating the "OldLuceneQParser" (which has a really hacky syntax that predates being able to send multiple request params to solr). we should: * officially mark this "deprecated" in 7.0 * remove mentions of it from the ref gude * delete from master (once we have a branch_7) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031839#comment-16031839 ] Karl Wright commented on LUCENE-7853: - Anything that helps is great! > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10791) remove SSLTestConfig deprecations
[
https://issues.apache.org/jira/browse/SOLR-10791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10791:
Attachment: SOLR-10791.patch
straight forward patch.
> remove SSLTestConfig deprecations
> -
>
> Key: SOLR-10791
> URL: https://issues.apache.org/jira/browse/SOLR-10791
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10791.patch
>
>
> remove methods & constants deprecated in SOLR-8970, as well the
> {{solrtest.keystore}} file which is no longer needed now that these
> methods/constants are removed (since 6.0.1 solr tests have used a keystore
> loaded from test-framework's jar - the file was only left in place for
> backcompat if anyone downstream was using the deprecated methods & constnats)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10791) remove SSLTestConfig deprecations
Hoss Man created SOLR-10791:
---
Summary: remove SSLTestConfig deprecations
Key: SOLR-10791
URL: https://issues.apache.org/jira/browse/SOLR-10791
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: master (7.0)
remove methods & constants deprecated in SOLR-8970, as well the
{{solrtest.keystore}} file which is no longer needed now that these
methods/constants are removed (since 6.0.1 solr tests have used a keystore
loaded from test-framework's jar - the file was only left in place for
backcompat if anyone downstream was using the deprecated methods & constnats)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10749) Should ref guide asciidoc files' line length be limited?
[
https://issues.apache.org/jira/browse/SOLR-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031814#comment-16031814
]
Steve Rowe commented on SOLR-10749:
---
FYI I just added a key mapping in IntelliJ to toggle soft wrapping (I used
ctrl-option-command-backslash), so toggling soft wraps is now sub-second for me.
> Should ref guide asciidoc files' line length be limited?
>
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10779) JavaBinCodec's close/finish pattern is trappy
[ https://issues.apache.org/jira/browse/SOLR-10779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-10779: -- Attachment: SOLR-10779.patch First cut at a patch so people can see what kinds of effort it might take. > JavaBinCodec's close/finish pattern is trappy > - > > Key: SOLR-10779 > URL: https://issues.apache.org/jira/browse/SOLR-10779 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-10779.patch > > > Having the marshal() code call finish which in turn calls close() is trappy. > The marshal code is not robust anyway since if there's an exception before > the try loop, it will not close the resource. > Sub task of SOLR-10778 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[
https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031796#comment-16031796
]
Christine Poerschke commented on LUCENE-7853:
-
LUCENE-7858 to refine the 'broken links' message provided by {{ant
documentation-lint}} which is part of {{ant precommit}} logic. What do you
think?
> Request to change visibility of classes in geo3d
>
>
> Key: LUCENE-7853
> URL: https://issues.apache.org/jira/browse/LUCENE-7853
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE-7853.patch
>
>
> I am creating my own spatial context by wrapping the objects in lucene geo3d
> library and implement my own query which mixes the recursive and the
> serialized strategy to add precision to searches.
>
> I had the following issue specially with polygons: The factory for creating
> polygons is slow and when serializing shapes, I already know if I am dealing
> with convex or concave polygons (in my case they are always concave). So when
> de-serializing a polygon I do not want to go through the factory to decide
> the type of polygon to create.
>
> Wouldn't make sense to add the possibility to create a type of polygon
> directly? you cannot create the polygons directly as they are protected in
> the package. My suggestion request would be either to add methods in the
> polygon factory to create a type of polygons with no checking (e.g.
> makeConcavePolygon(…)) or change the visibility of the classes so that they
> can be instantiated directly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7858) checkJavadocLinks.py to mention common root causes of broken links
[ https://issues.apache.org/jira/browse/LUCENE-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated LUCENE-7858: Attachment: LUCENE-7858.patch Attaching proposed patch. > checkJavadocLinks.py to mention common root causes of broken links > -- > > Key: LUCENE-7858 > URL: https://issues.apache.org/jira/browse/LUCENE-7858 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: LUCENE-7858.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7858) checkJavadocLinks.py to mention common root causes of broken links
Christine Poerschke created LUCENE-7858: --- Summary: checkJavadocLinks.py to mention common root causes of broken links Key: LUCENE-7858 URL: https://issues.apache.org/jira/browse/LUCENE-7858 Project: Lucene - Core Issue Type: Improvement Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+171) - Build # 3632 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3632/ Java: 64bit/jdk-9-ea+171 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([3CF104AF1CE1BA:6AEECE6BF7FF3175]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895) at org.apache.solr.util.TestMaxTokenLenTokenizer.testSingleFieldSameAnalyzers(TestMaxTokenLenTokenizer.java:104) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:563) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=letter0:lett&wt=xml at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:888) ... 39 more Build Log: [...truncated 13300 lines...] [junit4] Suite: org.apache.so
[jira] [Commented] (LUCENE-7854) Indexing custom term frequencies
[
https://issues.apache.org/jira/browse/LUCENE-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031770#comment-16031770
]
Uwe Schindler commented on LUCENE-7854:
---
Hi,
Looks fine. Just one question: Why is the attribute called
TermDocFrequencyAttribute and the inner value termFrequency? IMHO, the
attribute should be called TermFrequencyAttribute.
If there is a good reason for this, I am +1 to commit! Great progress!
> Indexing custom term frequencies
>
>
> Key: LUCENE-7854
> URL: https://issues.apache.org/jira/browse/LUCENE-7854
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: LUCENE-7854.patch, LUCENE-7854.patch, LUCENE-7854.patch,
> LUCENE-7854.patch, LUCENE-7854.patch, LUCENE-7854.patch
>
>
> When you index a field with {{IndexOptions.DOCS_AND_FREQS}}, Lucene will
> store just the docID and term frequency (how many times that term occurred in
> that document) for all documents that have a given term.
> We compute that term frequency by counting how many times a given token
> appeared in the field during analysis.
> But it can be useful, in expert use cases, to customize what Lucene stores as
> the term frequency, e.g. to hold custom scoring signals that are a function
> of term and document (this is my use case). Users have also asked for this
> before, e.g. see
> https://stackoverflow.com/questions/26605090/lucene-overwrite-term-frequency-at-index-time.
> One way to do this today is to stuff your custom data into a {{byte[]}}
> payload. But that's quite inefficient, forcing you to index positions, and
> pay the overhead of retrieving payloads at search time.
> Another approach is "token stuffing": just enumerate the same token N times
> where N is the custom number you want to store, but that's also inefficient
> when N gets high.
> I think we can make this simple to do in Lucene. I have a working version,
> using my own custom indexing chain, but the required changes are quite simple
> so I think we can add it to Lucene's default indexing chain?
> I created a new token attribute, {{TermDocFrequencyAttribute}}, and tweaked
> the indexing chain to use that attribute's value as the term frequency if
> it's present, and if the index options are {{DOCS_AND_FREQS}} for that field.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031768#comment-16031768 ] Hoss Man commented on LUCENE-7853: -- bq. Precommit is complaining about references from GeoPoint etc. documentation-lint is very explicit when it complains -- it doesn't complain about _classes_ it complains about _documentation_ -- specifically broken links in the documentation. If the link is manually created that's one problem. if the link is generated automatically by javadoc then that's an indirect indication of other problems (like referring to package protected classes in public method sigs) but you have to actually *look* at the details of the errors. In this specfic case, all of the errors stem from the root problem i specifically drew your attention to. the other broken links are all in "class-use" pages, where all methods that refer to a class are listed. Whether the GeoPoint _class_ has been modified in a very long time is irrelevant to the question of why links on it's "class-use" page might be broken -- what matters is if any methods that refer to GeoPoint have been added/removed/modified and result in broken links. Bottom line: we shouldn't just ignore documentation-lint errors because it looks like it's refering to classes that haven't changed "in a very long time" If you actually look at check the exact errors & html files it directs you to, the root cause is usually very clear. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031751#comment-16031751 ] ASF subversion and git services commented on LUCENE-7853: - Commit 01c7bf1fc3b3f13943193af66749c0f733d102e2 in lucene-solr's branch refs/heads/branch_6x from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=01c7bf1 ] LUCENE-7853: Return the public interface, not the private implementation > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10778) Ant precommit task WARNINGS about unclosed resources
[
https://issues.apache.org/jira/browse/SOLR-10778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031750#comment-16031750
]
Erick Erickson commented on SOLR-10778:
---
Oh, the poorly named "notclosed.txt" file contains _all_ of the warnings, not
just the 386 number came from grepping for "closed" and counting. There are
other lint warnings in there as [~cpoerschke] points out in SOLR-10790.
> Ant precommit task WARNINGS about unclosed resources
>
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 4.6
>Reporter: Andrew Musselman
>Priority: Minor
> Attachments: notclosed.txt
>
>
> During precommit we are seeing lots of warnings about resources that aren't
> being closed, which could pose problems based on chat amongst the team. Log
> snippet for example:
> [mkdir] Created dir:
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
> [ecj-lint] Compiling 419 source files to
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
> [ecj-lint] --
> [ecj-lint] 1. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
> (at line 920)
> [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient,
> solrServerUrls) :
> [ecj-lint]
> ^^^
> [ecj-lint] Resource leak: '' is never closed
> [ecj-lint] --
> [ecj-lint] --
> [ecj-lint] 2. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingBinaryResponseParser.java
> (at line 49)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
> [ecj-lint] --
> [ecj-lint] --
> [ecj-lint] 3. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
> (at line 90)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec();
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
> [ecj-lint] --
> [ecj-lint] 4. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
> (at line 113)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031746#comment-16031746 ] ASF subversion and git services commented on LUCENE-7853: - Commit 08ea9a787e624db4440c57b882afcfecddecc86b in lucene-solr's branch refs/heads/master from [~kwri...@metacarta.com] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08ea9a7 ] LUCENE-7853: Return the public interface, not the private implementation > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031719#comment-16031719 ] Karl Wright commented on LUCENE-7853: - [~hossman]: If that's the problem it is unclear from precommit's output. Precommit is complaining about references from GeoPoint etc. which were *not* updated in any way in a very long time, and GeoPoint does *not* return package-private classes either. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10782) Improve error handling and tests for Snitch and subclasses
[ https://issues.apache.org/jira/browse/SOLR-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-10782: - Attachment: SOLR-10782.patch Patch adds exception handling to ImplicitSnitch as well as tests. I also fixed a bug where an exception on reading roles.json from zk can cause an empty roles Map to be cached. > Improve error handling and tests for Snitch and subclasses > -- > > Key: SOLR-10782 > URL: https://issues.apache.org/jira/browse/SOLR-10782 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: master (7.0) > > Attachments: SOLR-10782.patch > > > Snitch has very little exception handling when communication to zookeeper or > other node breaks. It can do with some cleanup and tests. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated LUCENE-7853: Comment: was deleted (was: Looks like the javadoc is now being invoked in a way where it doesn't permit package-local to package-local references. I don't know when this happened but somebody should have fixed these then. I am closing this ticket and opening another one since this is unrelated to the changes that were committed. ) > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright resolved LUCENE-7853. - Resolution: Fixed > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10773) Add support for replica types in V2 API
[ https://issues.apache.org/jira/browse/SOLR-10773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe updated SOLR-10773: - Attachment: SOLR-10773.patch Here is a patch with some more tests > Add support for replica types in V2 API > --- > > Key: SOLR-10773 > URL: https://issues.apache.org/jira/browse/SOLR-10773 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomás Fernández Löbbe > Attachments: SOLR-10773.patch, SOLR-10773.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031704#comment-16031704 ] Karl Wright commented on LUCENE-7853: - Looks like the javadoc is now being invoked in a way where it doesn't permit package-local to package-local references. I don't know when this happened but somebody should have fixed these then. I am closing this ticket and opening another one since this is unrelated to the changes that were committed. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031666#comment-16031666 ] Hoss Man commented on LUCENE-7853: -- Huh? You just changed GeoPolygonFactory a few hours ago, and added new public methods that refer to classes like GeoConcavePolygon and GeoConvexPolygon in the new method sigs -- but those classes are not public, so the links in the generated javadocs are broken. I suggest rolling this change back until there's clarity on what exactly should be public ... public methods method declaring that they return package hidden classes makes no sense. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031648#comment-16031648 ] Karl Wright commented on LUCENE-7853: - [~hossman]: This is odd because it's complaining about stuff that hasn't changed in a year. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: master (7.0), 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #173: [SOLR-10360] Remove an extra space from Hadoo...
Github user asfgit closed the pull request at: https://github.com/apache/lucene-solr/pull/173 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error
[
https://issues.apache.org/jira/browse/SOLR-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-10360.
Resolution: Fixed
Assignee: Mark Miller
Fix Version/s: 6.7
master (7.0)
Thanks Hrishikesh!
> Solr HDFS snapshot export fails due to FileNotFoundException error
> --
>
> Key: SOLR-10360
> URL: https://issues.apache.org/jira/browse/SOLR-10360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.3
> Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master (7.0), 6.7
>
>
> The Solr snapshot export command (implemented in the snapshotscli.sh) uses
> Hadoop distcp tool to copy the Solr index files to the desired location. When
> the cluster is configured with MR1 framework (instead of YARN), this command
> fails with following error,
> {noformat}
> Err:With failures, global counters are inaccurate; consider running with -i
> Copy failed: java.io.FileNotFoundException: File does not exist:
> /user/systest/ /backups/mysnap/copylistings/shard1
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
> {noformat}
> During investigation I found that an extra space in the distcp command was
> causing this failure. For example,
> This command fails with the error mentioned above,
> {noformat}
> hadoop distcp -f ' /backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
> Removing the space from the copylisting directory path fixes this issue.
> {noformat}
> hadoop distcp -f '/backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error
[
https://issues.apache.org/jira/browse/SOLR-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031638#comment-16031638
]
ASF GitHub Bot commented on SOLR-10360:
---
Github user asfgit closed the pull request at:
https://github.com/apache/lucene-solr/pull/173
> Solr HDFS snapshot export fails due to FileNotFoundException error
> --
>
> Key: SOLR-10360
> URL: https://issues.apache.org/jira/browse/SOLR-10360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.3
> Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master (7.0), 6.7
>
>
> The Solr snapshot export command (implemented in the snapshotscli.sh) uses
> Hadoop distcp tool to copy the Solr index files to the desired location. When
> the cluster is configured with MR1 framework (instead of YARN), this command
> fails with following error,
> {noformat}
> Err:With failures, global counters are inaccurate; consider running with -i
> Copy failed: java.io.FileNotFoundException: File does not exist:
> /user/systest/ /backups/mysnap/copylistings/shard1
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
> {noformat}
> During investigation I found that an extra space in the distcp command was
> causing this failure. For example,
> This command fails with the error mentioned above,
> {noformat}
> hadoop distcp -f ' /backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
> Removing the space from the copylisting directory path fixes this issue.
> {noformat}
> hadoop distcp -f '/backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error
[
https://issues.apache.org/jira/browse/SOLR-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031635#comment-16031635
]
ASF subversion and git services commented on SOLR-10360:
Commit 499291a94f7a92fd01459274e8104b5fd038c100 in lucene-solr's branch
refs/heads/branch_6x from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=499291a ]
SOLR-10360: Solr HDFS snapshot export fails due to FileNotFoundException error
when using MR1 instead of yarn.
This closes #173
> Solr HDFS snapshot export fails due to FileNotFoundException error
> --
>
> Key: SOLR-10360
> URL: https://issues.apache.org/jira/browse/SOLR-10360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.3
> Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> The Solr snapshot export command (implemented in the snapshotscli.sh) uses
> Hadoop distcp tool to copy the Solr index files to the desired location. When
> the cluster is configured with MR1 framework (instead of YARN), this command
> fails with following error,
> {noformat}
> Err:With failures, global counters are inaccurate; consider running with -i
> Copy failed: java.io.FileNotFoundException: File does not exist:
> /user/systest/ /backups/mysnap/copylistings/shard1
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
> {noformat}
> During investigation I found that an extra space in the distcp command was
> causing this failure. For example,
> This command fails with the error mentioned above,
> {noformat}
> hadoop distcp -f ' /backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
> Removing the space from the copylisting directory path fixes this issue.
> {noformat}
> hadoop distcp -f '/backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10360) Solr HDFS snapshot export fails due to FileNotFoundException error
[
https://issues.apache.org/jira/browse/SOLR-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031632#comment-16031632
]
ASF subversion and git services commented on SOLR-10360:
Commit 872b0dba2d383255ffc020a2b429e395d9817175 in lucene-solr's branch
refs/heads/master from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=872b0db ]
SOLR-10360: Solr HDFS snapshot export fails due to FileNotFoundException error
when using MR1 instead of yarn.
This closes #173
> Solr HDFS snapshot export fails due to FileNotFoundException error
> --
>
> Key: SOLR-10360
> URL: https://issues.apache.org/jira/browse/SOLR-10360
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.3
> Environment: SOLR deployed along with a HADOOP cluster (HDFS +M/R 1).
>Reporter: Hrishikesh Gadre
>Priority: Minor
>
> The Solr snapshot export command (implemented in the snapshotscli.sh) uses
> Hadoop distcp tool to copy the Solr index files to the desired location. When
> the cluster is configured with MR1 framework (instead of YARN), this command
> fails with following error,
> {noformat}
> Err:With failures, global counters are inaccurate; consider running with -i
> Copy failed: java.io.FileNotFoundException: File does not exist:
> /user/systest/ /backups/mysnap/copylistings/shard1
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
> at
> org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:56)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:2007)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1977)
> at
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1890)
> at
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getBlockLocations(NameNodeRpcServer.java:572)
> {noformat}
> During investigation I found that an extra space in the distcp command was
> causing this failure. For example,
> This command fails with the error mentioned above,
> {noformat}
> hadoop distcp -f ' /backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
> Removing the space from the copylisting directory path fixes this issue.
> {noformat}
> hadoop distcp -f '/backups/mysnap/copylistings/shard1'
> /backups/mysnap/snapshot.shard1
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-7853) Request to change visibility of classes in geo3d
[
https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reopened LUCENE-7853:
--
precommit failures from documentation-lint...
{noformat}
[echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
[delete] Deleting directory /home/hossman/lucene/dev/lucene/build/jtidy_tmp
[echo] Checking for broken links...
[exec]
[exec] Crawl/parse...
[exec]
[exec] Verify...
[exec]
[exec]
file:///build/docs/spatial3d/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec]
[exec]
file:///build/docs/spatial3d/org/apache/lucene/spatial3d/geom/class-use/GeoPoint.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec]
[exec]
file:///build/docs/spatial3d/org/apache/lucene/spatial3d/geom/class-use/GeoPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec]
[exec]
file:///build/docs/spatial3d/org/apache/lucene/spatial3d/geom/class-use/PlanetModel.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConcavePolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec] BROKEN LINK:
file:///build/docs/core/org/apache/lucene/spatial3d.geom.GeoConvexPolygon.html
[exec]
[exec] Broken javadocs links were found!
{noformat}
> Request to change visibility of classes in geo3d
>
>
> Key: LUCENE-7853
> URL: https://issues.apache.org/jira/browse/LUCENE-7853
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE-7853.patch
>
>
> I am creating my own spatial context by wrapping the objects in lucene geo3d
> library and implement my own query which mixes the recursive and the
> serialized strategy to add precision to searches.
>
> I had the following issue specially with polygons: The factory for creating
> polygons is slow and when serializing shapes, I already know if I am dealing
> with convex or concave polygons (in my case they are always concave). So when
> de-serializing a polygon I do not want to go through the factory to decide
> the type of polygon to create.
>
> Wouldn't make sense to add the possibility to create a type of polygon
> directly? you cannot create the polygons directly as they are protected in
> the package. My suggestion request would be either to add methods in the
> polygon factory to create a type of polygons with no checking (e.g.
> makeConcavePolygon(…)) or change the visibility of the classes so that they
> can be instantiated directly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Release planning for 7.0
We can certainly hold back cutting the branch, and/or release. I'm headed to Berlin Buzzwords next week so I'd most probably be cutting the branch over the next weekend or during the conference. I'll keep everyone posted about the 'when' and if there are more contributors who want me to hold back for valid reasons, I'd be happy to do so :). I'm tracking all blockers (and critical JIRAs) for 7.0, and if anyone thinks there's something that must be a part of 7.0, kindly mark the issue as a blocker for 7.0. -Anshum On Tue, May 30, 2017 at 9:27 AM Christine Poerschke (BLOOMBERG/ LONDON) < cpoersc...@bloomberg.net> wrote: > Hi Everyone, > > Just to say that https://issues.apache.org/jira/browse/SOLR-8668 for > removal should complete later this week, hopefully. > > And on an unrelated note, does anyone have any history or experience with > the NOTICE.txt files? Including > https://issues.apache.org/jira/browse/LUCENE-7852 in 7.0 would be good i > think (though it being a small change the issue would not need to block > branch_7x branch cutting). > > Thanks, > Christine > > From: dev@lucene.apache.org At: 05/03/17 16:56:09 > To: dev@lucene.apache.org > Subject: Re:Release planning for 7.0 > > Hi, > > It's May already, and with 6.6 lined up, I think we should start planning > on how we want to proceed with 7.0, in terms of both - the timeline, and > what it would likely contain. > > I am not suggesting we start the release process right away, but just > wanted to start a discussion around the above mentioned lines. > > With 6.6 in the pipeline, I think sometime in June would be a good time to > cut a release branch. What do all of you think? > > P.S: This email is about 'discussion' and 'planning', so if someone wants > to volunteer to be the release manager, please go ahead. I can't remember > if someone did explicit volunteer to wear this hat for 7.0. If no one > volunteers, I will take it up. > > -Anshum > >
Re: [1/2] lucene-solr:master: LUCENE-7853: Add methods for people to use who know their polygon's characteristics
Karl: this broke precommit due to broken documentation links
: Date: Wed, 31 May 2017 11:56:30 -
: From: kwri...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [1/2] lucene-solr:master: LUCENE-7853: Add methods for people to use
: who know their polygon's characteristics
:
: Repository: lucene-solr
: Updated Branches:
: refs/heads/master c824b097b -> 97693234d
:
:
: LUCENE-7853: Add methods for people to use who know their polygon's
characteristics
:
:
: Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/71411df0
: Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/71411df0
: Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/71411df0
:
: Branch: refs/heads/master
: Commit: 71411df0cfec385fbd0fcd0f0291c6a06c05a428
: Parents: fed7343
: Author: Karl Wright
: Authored: Wed May 31 07:55:53 2017 -0400
: Committer: Karl Wright
: Committed: Wed May 31 07:55:53 2017 -0400
:
: --
: .../spatial3d/geom/GeoPolygonFactory.java | 63
: .../lucene/spatial3d/geom/GeoPolygonTest.java | 63
: 2 files changed, 126 insertions(+)
: --
:
:
:
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/71411df0/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
: --
: diff --git
a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
: index 97bc230..4c1850e 100755
: ---
a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
: +++
b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
: @@ -49,6 +49,34 @@ public class GeoPolygonFactory {
: return makeGeoPolygon(planetModel, pointList, null);
:}
:
: + /** Create a GeoConcavePolygon using the specified points. The polygon
must have
: + * a maximum extent larger than PI. The siding of the polygon is chosen so
that any
: + * adjacent point to a segment provides an exterior measurement and
therefore,
: + * the polygon is a truly concave polygon. Note that this method should
only be used when there is certainty
: + * that we are dealing with a concave polygon, e.g. the polygon has been
serialized.
: + * If there is not such certainty, please refer to @{@link
GeoPolygonFactory#makeGeoPolygon(PlanetModel, List)}.
: + * @param pointList is a list of the GeoPoints to build an arbitrary
polygon out of.
: + * @return a GeoConcavePolygon corresponding to what was specified.
: + */
: + public static GeoConcavePolygon makeGeoConcavePolygon(final PlanetModel
planetModel,
: +final List
pointList) {
: +return new GeoConcavePolygon(planetModel, pointList);
: + }
: +
: + /** Create a GeoConvexPolygon using the specified points. The polygon must
have
: + * a maximum extent no larger than PI. The siding of the polygon is chosen
so that any adjacent
: + * point to a segment provides an interior measurement and therefore
: + * the polygon is a truly convex polygon. Note that this method should
only be used when
: + * there is certainty that we are dealing with a convex polygon, e.g. the
polygon has been serialized.
: + * If there is not such certainty, please refer to @{@link
GeoPolygonFactory#makeGeoPolygon(PlanetModel, List)}.
: + * @param pointList is a list of the GeoPoints to build an arbitrary
polygon out of.
: + * @return a GeoConvexPolygon corresponding to what was specified.
: + */
: + public static GeoConvexPolygon makeGeoConvexPolygon(final PlanetModel
planetModel,
: + final List
pointList) {
: +return new GeoConvexPolygon(planetModel, pointList);
: + }
: +
:/** Create a GeoPolygon using the specified points and holes, using order
to determine
: * siding of the polygon. Much like ESRI, this method uses clockwise to
indicate the space
: * on the same side of the shape as being inside, and counter-clockwise to
indicate the
: @@ -66,6 +94,41 @@ public class GeoPolygonFactory {
: final List holes) {
: return makeGeoPolygon(planetModel, pointList, holes, 0.0);
:}
: +
: +
: + /** Create a GeoConcavePolygon using the specified points and holes. The
polygon must have
: + * a maximum extent larger than PI. The siding of the polygon is chosen so
that any adjacent
: + * point to a segment provides an exterior measurement and therefore
: + * the polygon is a truly concave polygon. Note that this method should
only be used when
: + * there is certainty that we are
[jira] [Updated] (SOLR-10790) fix 6 (Recovered) WARNINGs
[
https://issues.apache.org/jira/browse/SOLR-10790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-10790:
---
Attachment: SOLR-10790.patch
Attaching patch with proposed (two line) fix.
> fix 6 (Recovered) WARNINGs
> --
>
> Key: SOLR-10790
> URL: https://issues.apache.org/jira/browse/SOLR-10790
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10790.patch
>
>
> In [~erickerickson]'s notclosed.txt attachment for SOLR-10778 these warnings
> not about unclosed resources caught my attention:
> {code}
> [ecj-lint] 1. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
> [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> [ecj-lint] --
> [ecj-lint] 2. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
> [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> [ecj-lint] --
> [ecj-lint] 3. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
> (at line 101)
> [ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> [ecj-lint] --
> [ecj-lint] --
> [ecj-lint] 4. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
> (at line 214)
> [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> [ecj-lint] --
> [ecj-lint] 5. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
> (at line 214)
> [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> [ecj-lint] --
> [ecj-lint] 6. WARNING in
> /Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
> (at line 214)
> [ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
> [ecj-lint] ^^^
> [ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
> analysis
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10790) fix 6 (Recovered) WARNINGs
Christine Poerschke created SOLR-10790:
--
Summary: fix 6 (Recovered) WARNINGs
Key: SOLR-10790
URL: https://issues.apache.org/jira/browse/SOLR-10790
Project: Solr
Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
In [~erickerickson]'s notclosed.txt attachment for SOLR-10778 these warnings
not about unclosed resources caught my attention:
{code}
[ecj-lint] 1. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
(at line 101)
[ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
[ecj-lint]^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
[ecj-lint] --
[ecj-lint] 2. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
(at line 101)
[ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
[ecj-lint]^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
[ecj-lint] --
[ecj-lint] 3. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/Assign.java
(at line 101)
[ecj-lint] Collections.sort(shardIdNames, (o1, o2) -> {
[ecj-lint]^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
(at line 214)
[ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
[ecj-lint] ^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
[ecj-lint] --
[ecj-lint] 5. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
(at line 214)
[ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
[ecj-lint] ^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
[ecj-lint] --
[ecj-lint] 6. WARNING in
/Users/Erick/apache/solrJiras/jiramaster/solr/core/src/java/org/apache/solr/cloud/rule/ReplicaAssigner.java
(at line 214)
[ecj-lint] Collections.sort(sortedLiveNodes, (n1, n2) -> {
[ecj-lint] ^^^
[ecj-lint] (Recovered) Internal inconsistency detected during lambda shape
analysis
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
[ https://issues.apache.org/jira/browse/SOLR-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031599#comment-16031599 ] Erik Hatcher commented on SOLR-10789: - Surely it wasn't intentional to prohibit any `pf` to be used with collation queries - and the logic to remove params should be moved above the override to allow explicit setting of these parameters for collation query customization. > SpellCheckCollator prohibits setting several query parser params > > > Key: SOLR-10789 > URL: https://issues.apache.org/jira/browse/SOLR-10789 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher > Fix For: master (7.0) > > > SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. > There is a mechanism to allow the collator to inherit global params, and > override them even (via `spellcheck.collateParam.*`), but then it eats the > aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
[ https://issues.apache.org/jira/browse/SOLR-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-10789: Fix Version/s: master (7.0) > SpellCheckCollator prohibits setting several query parser params > > > Key: SOLR-10789 > URL: https://issues.apache.org/jira/browse/SOLR-10789 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher > Fix For: master (7.0) > > > SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. > There is a mechanism to allow the collator to inherit global params, and > override them even (via `spellcheck.collateParam.*`), but then it eats the > aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10789) SpellCheckCollator prohibits setting several query parser params
Erik Hatcher created SOLR-10789: --- Summary: SpellCheckCollator prohibits setting several query parser params Key: SOLR-10789 URL: https://issues.apache.org/jira/browse/SOLR-10789 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Erik Hatcher SpellCheckCollator eats tie, pf, pf2, pf3, bq, and bf. There is a mechanism to allow the collator to inherit global params, and override them even (via `spellcheck.collateParam.*`), but then it eats the aforementioned ones regardless. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7857) CharTokenizer-derived tokenizers and KeywordTokenizer emit multiple tokens when the max length is exceeded
[ https://issues.apache.org/jira/browse/LUCENE-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031588#comment-16031588 ] Erick Erickson commented on LUCENE-7857: OK, then to paraphrase: The behavior is correct, fix the tests ;) > CharTokenizer-derived tokenizers and KeywordTokenizer emit multiple tokens > when the max length is exceeded > -- > > Key: LUCENE-7857 > URL: https://issues.apache.org/jira/browse/LUCENE-7857 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > > Assigning to myself to not lose track of it. > LUCENE-7705 introduced the ability to define the allowable token length for > these tokenizers other than hard-code it to 255. It's always been the case > that when the hard-coded limit was exceeded, multiple tokens would be > emitted. However, the tests for LUCENE-7705 exposed a problem. > Suppose the max length is 3 and the doc contains "letter". Two tokens are > emitted and indexed: "let" and "ter". > Now suppose the search is for "lett". If the default operator is AND or > phrase queries are constructed the query fails since the tokens emitted are > "let" and "t". Only if the operator is OR is the document found, and even > then it won't be correct since searching for "lett" would match a document > indexed with "bett" because it would match on the bare "t". > Proposal: > The remainder of the token should be ignored when maxTokenLen is exceeded. > [~rcmuir][~steve_rowe][~tomasflobbe] comments? Again, this behavior was not > introduced by LUCENE-7705, it's just that it would be very hard to notice > with the default 255 char limit. > I'm not quite sure why master generates a parsed query of: > field:let field:t > and 6x generates > field:"let t" > so the tests succeeded on master but not on 6x -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+171) - Build # 19750 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19750/ Java: 32bit/jdk-9-ea+171 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=3568, name=testExecutor-2018-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=3568, name=testExecutor-2018-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] at __randomizedtesting.SeedInfo.seed([F284E696B53B6475:7AD0D94C1BC7098D]:0) Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:43031 at __randomizedtesting.SeedInfo.seed([F284E696B53B6475]:0) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:412) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1161) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:844) Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:43031 at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:621) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:237) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:410) ... 4 more Caused by: java.net.SocketTimeoutException: Read timed out at java.base/java.net.SocketInputStream.socketRead0(Native Method) at java.base/java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:171) at java.base/java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:513) ... 8 more Build Log: [...truncated 11560 lines...] [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.UnloadDistributedZkTest_F284E696B53B6475-001/init-core-data-001 [junit4] 2> 285859 WARN (SUITE-UnloadDistributedZkTest-seed#[F284E696B53B6475]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2 [junit4] 2> 285859 INFO (SUITE-UnloadDistributedZkTest-seed#[F284E696B53B6475]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields [junit4] 2> 285859 INFO (SUITE-UnloadDistributedZkTest-seed#[F284E696B53B6475]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientA
Re: Replica naming changed.
Thanks for the summary Erick. I’m also in favor of leaving the type as part of the name. In the future if we provide the option of changing the type of a replica I can see three options: 1) We do nothing with the name. The user who does replica type changes will have to know that this character is meaningless for them. Not the best option, specially if we provide an automated way to change the type. 2) We change the name of the replica to reflect the new type. May not be too easy, not sure how other parts of Solr will react to this, but may be the best approach. 3) We provide a way for users to define their own naming scheme for replicas (I’m thinking something like log4j logging pattern). Not sure if this will be needed really, it depends on how internal we consider the replica naming to be. Tomás > On May 30, 2017, at 10:32 AM, Erick Erickson wrote: > > Tomás: > > Thought that might be the case. I'm not opposed to the naming change > as long as it serves a purpose as this one does. People shouldn't > write scripts that assume hard-coded names anyway ;). > > Ishan: > > I give long odds that we _will_ need the capability to reassign > replica roles. One of the points of this work is that people need to > fine-tune how nodes on the cluster are utilized, which I'd imagine > means reassigning replica functions. > > All: > > I rather like that the node name gives us information about the role. > having to go to the state.json file to find some other property is > onerous, especially in very large installations. > > Proposal: > > Let's keep the naming convention with the n, t, and p notation. If in > the future we want to reassign a replica's role we can rename the node > when its role changes. > > On Tue, May 30, 2017 at 10:12 AM, Ishan Chattopadhyaya > wrote: >> Do we shut ourselves out of the possibility to ever re-assigning the replica >> types, by using this naming convention? >> For example, is there any conceivable scenario in future whereby an NRT >> replica can become a TLOG replica? >> Never mind my asking if this flexibility is something we're sure we'll never >> need. >> >> On Tue, May 30, 2017 at 9:49 PM, Tomas Fernandez Lobbe >> wrote: >>> >>> Hi Erick, >>> This change is part of replica types. I mentioned this in SOLR-10233, but >>> you are right, I should have mentioned probably in the dev list to get to >>> more people. The last character represents the type of replica (n->NRT, >>> t->TLOG, p->PULL). This is certainly not required and can be reverted back >>> if people has concerns. I found it very useful when developing and I think >>> it will also be helpful in prod, since the replica name is present in most >>> log entries (since the MDC logging changes). >>> >>> Tomás >>> On May 30, 2017, at 8:54 AM, Erick Erickson wrote: I noticed recently that our replica names are changing (master only?) to collection_shard1_replica_n1. Why? Mostly I wan to be sure we consider whether this change is worth the confusion before it gets out into the wild. If it's just an aesthetic change I question whether it's worth the confusion it'll generate. If it serves a real purpose, that's another story.. Erick - 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] (SOLR-10778) Ant precommit task WARNINGS about unclosed resources
[
https://issues.apache.org/jira/browse/SOLR-10778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031538#comment-16031538
]
David Smiley commented on SOLR-10778:
-
I'm looking forward to seeing this addressed in some way. We should be using
try-finally wherever reasonably possible... and avoid having code expectations
where it's some collaborator's job to close a resource that it didn't itself
create. +1 overall to Erick's sentiments.
> Ant precommit task WARNINGS about unclosed resources
>
>
> Key: SOLR-10778
> URL: https://issues.apache.org/jira/browse/SOLR-10778
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 4.6
>Reporter: Andrew Musselman
>Priority: Minor
> Attachments: notclosed.txt
>
>
> During precommit we are seeing lots of warnings about resources that aren't
> being closed, which could pose problems based on chat amongst the team. Log
> snippet for example:
> [mkdir] Created dir:
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
> [ecj-lint] Compiling 419 source files to
> /var/folders/5p/6b46rm_94dzc5m8d4v56tds4gp/T/ecj1165341501
> [ecj-lint] --
> [ecj-lint] 1. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java
> (at line 920)
> [ecj-lint] new LBHttpSolrClient(httpSolrClientBuilder, httpClient,
> solrServerUrls) :
> [ecj-lint]
> ^^^
> [ecj-lint] Resource leak: '' is never closed
> [ecj-lint] --
> [ecj-lint] --
> [ecj-lint] 2. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/impl/StreamingBinaryResponseParser.java
> (at line 49)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
> [ecj-lint] --
> [ecj-lint] --
> [ecj-lint] 3. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
> (at line 90)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec();
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
> [ecj-lint] --
> [ecj-lint] 4. WARNING in
> /path/to/lucene-solr/solr/solrj/src/java/org/apache/solr/client/solrj/request/JavaBinUpdateRequestCodec.java
> (at line 113)
> [ecj-lint] JavaBinCodec codec = new JavaBinCodec() {
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'codec' is never closed
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031536#comment-16031536 ] Hrishikesh Gadre commented on SOLR-10137: - [~markrmil...@gmail.com] Can you please post the parameters of failed tests so that I can take a look? > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10757) cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest
[ https://issues.apache.org/jira/browse/SOLR-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-10757. - Resolution: Fixed > cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest > -- > > Key: SOLR-10757 > URL: https://issues.apache.org/jira/browse/SOLR-10757 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10757.patch > > > spinning off of SOLR-10755... > * CollectionAdminRequest > ** has roughly double the number of deprecations of all other solrj classes > combined > ** many of the deprecated methods/constructors are still used in a lot of > places in tests > ** in many cases the non-deprecated "constructor" versions aren't validating > the same way the deprecated setters do > ** in at least one case i see obvious bugs in the non-deprecated methods (see > ForceLeader constructors) > ** once many of these deprecated setters are removed, a lot of member > variables should become final -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10295) Decide online location for Ref Guide HTML pages
[
https://issues.apache.org/jira/browse/SOLR-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-10295.
--
Resolution: Fixed
Assignee: Cassandra Targett
> Decide online location for Ref Guide HTML pages
> ---
>
> Key: SOLR-10295
> URL: https://issues.apache.org/jira/browse/SOLR-10295
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>
> One of the biggest decisions we need to make is where to put the new Solr Ref
> Guide. Confluence at least had the whole web-hosting bits figured out; we
> have to figure that out on our own.
> An obvious (maybe only to me) choice is to integrate the Ref Guide with the
> Solr Website. However, due to the size of the Solr Ref Guide (nearly 200
> pages), I believe trying to publish it solely with existing CMS tools will
> create problems similar to those described in the Lucene ReleaseTodo when it
> comes to publishing the Lucene/Solr javadocs (see
> https://wiki.apache.org/lucene-java/ReleaseTodo#Website_.2B-.3D_javadocs).
> A solution exists already, and it's what is done for the javadocs. From the
> above link:
> {quote}
> The solution: skip committing javadocs to the source tree, then staging, then
> publishing, and instead commit javadocs directly to the production tree.
> Ordinarily this would be problematic, because the CMS wants to keep the
> production tree in sync with the staging tree, so anything it finds in the
> production tree that's not in the staging tree gets nuked. However, the CMS
> has a built-in mechanism to allow exceptions to the
> keep-production-in-sync-with-staging rule: extpaths.txt.
> {quote}
> This solution (for those who don't know already) is to provide a static text
> file (extpaths.txt) that includes the javadoc paths that should be presented
> in production, but which won't exist in CMS staging environments. This way,
> we can publish HTML files directly to production and they will be preserved
> when the staging-production trees are synced.
> The rest of the process would be quite similar to what is documented in the
> ReleaseTodo in sections following the link above - use SVN to update the CMS
> production site and update extpaths.txt properly. We'd do this in the
> {{solr}} section of the CMS obviously, and not the {{lucene}} section.
> A drawback to this approach is that we won't have a staging area to view the
> Guide before publication. Files would be generated and go to production
> directly. We may want to put a process in place to give some additional
> confidence that things look right first (someone's people.apache.org
> directory? a pre-pub validation script that tests...something...?), and agree
> on what we'd be voting on when a vote to release comes up. However, the CMS
> is pretty much the only option that I can think of...other ideas are welcome
> if they might work.
> We also need to agree on URL paths that make sense, considering we'll have a
> new "site" for each major release - something like
> {{http://lucene.apache.org/solr/ref-guide/6_1}} might work? Other thoughts
> are welcome on this point also.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10757) cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest
[ https://issues.apache.org/jira/browse/SOLR-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031519#comment-16031519 ] ASF subversion and git services commented on SOLR-10757: Commit 7a5261a2228b52d6b29d1d6c147ce08f43e917cb in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7a5261a ] SOLR-10757: Merge remote-tracking branch 'refs/remotes/origin/master' Conflicts: solr/CHANGES.txt > cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest > -- > > Key: SOLR-10757 > URL: https://issues.apache.org/jira/browse/SOLR-10757 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10757.patch > > > spinning off of SOLR-10755... > * CollectionAdminRequest > ** has roughly double the number of deprecations of all other solrj classes > combined > ** many of the deprecated methods/constructors are still used in a lot of > places in tests > ** in many cases the non-deprecated "constructor" versions aren't validating > the same way the deprecated setters do > ** in at least one case i see obvious bugs in the non-deprecated methods (see > ForceLeader constructors) > ** once many of these deprecated setters are removed, a lot of member > variables should become final -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10757) cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest
[ https://issues.apache.org/jira/browse/SOLR-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031517#comment-16031517 ] ASF subversion and git services commented on SOLR-10757: Commit ee33f38bd1b4c039dc0d054ccf0eb2904fc9ea92 in lucene-solr's branch refs/heads/master from Chris Hostetter [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee33f38 ] SOLR-10757: delete/refactor/cleanup CollectionAdminRequest deprecations > cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest > -- > > Key: SOLR-10757 > URL: https://issues.apache.org/jira/browse/SOLR-10757 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10757.patch > > > spinning off of SOLR-10755... > * CollectionAdminRequest > ** has roughly double the number of deprecations of all other solrj classes > combined > ** many of the deprecated methods/constructors are still used in a lot of > places in tests > ** in many cases the non-deprecated "constructor" versions aren't validating > the same way the deprecated setters do > ** in at least one case i see obvious bugs in the non-deprecated methods (see > ForceLeader constructors) > ** once many of these deprecated setters are removed, a lot of member > variables should become final -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10757) cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest
[ https://issues.apache.org/jira/browse/SOLR-10757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031508#comment-16031508 ] Hoss Man commented on SOLR-10757: - created SOLR-10788 to track making more variables final > cleanup/refactor/fix deprecated methods/constructors in CollectionAdminRequest > -- > > Key: SOLR-10757 > URL: https://issues.apache.org/jira/browse/SOLR-10757 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Assignee: Hoss Man >Priority: Blocker > Fix For: master (7.0) > > Attachments: SOLR-10757.patch > > > spinning off of SOLR-10755... > * CollectionAdminRequest > ** has roughly double the number of deprecations of all other solrj classes > combined > ** many of the deprecated methods/constructors are still used in a lot of > places in tests > ** in many cases the non-deprecated "constructor" versions aren't validating > the same way the deprecated setters do > ** in at least one case i see obvious bugs in the non-deprecated methods (see > ForceLeader constructors) > ** once many of these deprecated setters are removed, a lot of member > variables should become final -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10749) Should ref guide asciidoc files' line length be limited?
[
https://issues.apache.org/jira/browse/SOLR-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031506#comment-16031506
]
Jason Gerlowski edited comment on SOLR-10749 at 5/31/17 4:55 PM:
-
Another point that I haven't heard yet is how enforcing a line length would
affect diff/patch readability.
Imagine an *.adoc paragraph of 10 source lines, each close to the max-length.
Adding a phrase in the second line will cause a cascade of words onto all the
subsequent lines in the paragraph. A diff will show 8 lines changed. This is
noisy, and might make actual changes in substance/content hard to pick out.
Especially when there is more than one change per paragraph.
Some diff viewers/editors might mitigate this somewhat. So take it for what
it's worth. Just wanted to mention it as I hadn't heard anyone bring it up yet.
was (Author: gerlowskija):
Another point that I haven't heard yet is how enforcing a line length would
affect diff/patch readability.
Imagine an *.adoc paragraph of 10 source lines, each close to the line length.
Adding a phrase in the second line will
cause a cascade of words onto all the subsequent lines in the paragraph. A
diff will show 8 lines changed. This is noisy, and might make actual changes
in substance/content hard to pick out.
Some diff viewers/editors might mitigate this somewhat. So take it for what
it's worth. Just wanted to mention it as I hadn't heard anyone mention it yet.
> Should ref guide asciidoc files' line length be limited?
>
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10749) Should ref guide asciidoc files' line length be limited?
[
https://issues.apache.org/jira/browse/SOLR-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031506#comment-16031506
]
Jason Gerlowski commented on SOLR-10749:
Another point that I haven't heard yet is how enforcing a line length would
affect diff/patch readability.
Imagine an *.adoc paragraph of 10 source lines, each close to the line length.
Adding a phrase in the second line will
cause a cascade of words onto all the subsequent lines in the paragraph. A
diff will show 8 lines changed. This is noisy, and might make actual changes
in substance/content hard to pick out.
Some diff viewers/editors might mitigate this somewhat. So take it for what
it's worth. Just wanted to mention it as I hadn't heard anyone mention it yet.
> Should ref guide asciidoc files' line length be limited?
>
>
> Key: SOLR-10749
> URL: https://issues.apache.org/jira/browse/SOLR-10749
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Priority: Minor
>
> From [~dsmiley] and [~janhoy] on SOLR-10290:
> {quote}
> David: Can we auto-linewrap the asciidoc content we've imported somehow? The
> lines are super-long in my IDE (IntelliJ). I can toggle the active editor's
> "soft wrap" at least (View menu, then Active Editor menu).
> Jan: Yea, those lines are long
> {quote}
> From a conversation [~ctargett] and I had on SOLR-10379:
> {quote}
> Steve: I updated the ref guide docs. While I was at it, I installed and used
> the IntelliJ plugin named "Wrap To Column" to wrap at 120 chars (a.k.a. "fill
> paragraph") in the two .adoc files I edited.
> Cassandra: What is the point of this, or even, the big deal about asking your
> IDE to do soft wraps instead?
> Steve: Not all editors support soft-wrapping. There is project consensus to
> wrap code at 120-chars; why make an exception for these doc files?
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10788) make more CollectionAdminRequest variables final
Hoss Man created SOLR-10788: --- Summary: make more CollectionAdminRequest variables final Key: SOLR-10788 URL: https://issues.apache.org/jira/browse/SOLR-10788 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: clients - java Reporter: Hoss Man As part of the deprecation cleanup in SOLR-10757, many "setter" methods were removed for variables that can now only be specified by the constructors of these inner classes. We should now be able to make these variables final. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10137) Configsets created via API should always be mutable
[ https://issues.apache.org/jira/browse/SOLR-10137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031460#comment-16031460 ] Mark Miller commented on SOLR-10137: I think this causes some fails as is - going to look a little deeper. > Configsets created via API should always be mutable > --- > > Key: SOLR-10137 > URL: https://issues.apache.org/jira/browse/SOLR-10137 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hrishikesh Gadre > > Please refer to this discussion for details, > https://marc.info/?l=solr-dev&m=148679049516375&w=4 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
