[jira] [Commented] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127362#comment-17127362
]
ASF subversion and git services commented on SOLR-14442:
Commit d456e0bfcef0a7fedf7598009d3407a1bbe57fcc in lucene-solr's branch
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d456e0b ]
SOLR-14442: add improvement to CHANGES.txt
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13169) Move Replica Docs need improvement (V1 and V2 introspect)
[
https://issues.apache.org/jira/browse/SOLR-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127217#comment-17127217
]
Gus Heck commented on SOLR-13169:
-
Looks like SourceNode is also ignored if replica is supplied, and the node
chosen is done by this code:
{code:java}
Collections.shuffle(sliceReplicas,
OverseerCollectionMessageHandler.RANDOM);
replica = sliceReplicas.iterator().next();
{code}
Neither {{CollectionOperation.MOVEREPLICA_OP}} nor
{{ModifyCollectionCommand#moveReplica}} appear have code consulting
auto-scaling, but I'm still trying to sort out whether or not the eventual sub
call to {{AddReplicaCmd#addReplica}} can then be influenced by auto-scaling in
some way. If so I think we'd have a bug with the current design, though if so
it would also seem that the destination node could have been optional (with
that usage meaning "find the optimal place for this replica and make it so").
> Move Replica Docs need improvement (V1 and V2 introspect)
> -
>
> Key: SOLR-13169
> URL: https://issues.apache.org/jira/browse/SOLR-13169
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Gus Heck
>Priority: Major
> Attachments: testing.txt
>
>
> At a minimum required parameters should be noted equally in both places.
> Conversation with [~ab] indicates that there are also some discrepancies in
> what is and is not actually required in docs vs code. ("in MoveReplicaCmd if
> you specify “replica” then “shard” is completely ignored")
> Also in v2 it seems shard might be inferred from the URL and in that case
> it's not clear if the URL or the json takes precedence.
> From introspect:
> {code:java}
> "move-replica": {
> "type": "object",
> "documentation":
> "https://lucene.apache.org/solr/guide/collections-api.html#movereplica";,
> "description": "This command moves a replica from one
> node to a new node. In case of shared filesystems the `dataDir` and `ulogDir`
> may be reused.",
> "properties": {
> "replica": {
> "type": "string",
> "description": "The name of the replica"
> },
> "shard": {
> "type": "string",
> "description": "The name of the shard"
> },
> "sourceNode": {
> "type": "string",
> "description": "The name of the node that
> contains the replica."
> },
> "targetNode": {
> "type": "string",
> "description": "The name of the destination node.
> This parameter is required."
> },
> "waitForFinalState": {
> "type": "boolean",
> "default": "false",
> "description": "Wait for the moved replica to
> become active."
> },
> "timeout": {
> "type": "integer",
> "default": 600,
> "description": "Timeout to wait for replica to
> become active. For very large replicas this may need to be increased."
> },
> "inPlaceMove": {
> "type": "boolean",
> "default": "true",
> "description": "For replicas that use shared
> filesystems allow 'in-place' move that reuses shared data."
> }
> {code}
> From ref guide for V1:
> MOVEREPLICA Parameters
> collection
> The name of the collection. This parameter is required.
> shard
> The name of the shard that the replica belongs to. This parameter is required.
> replica
> The name of the replica. This parameter is required.
> sourceNode
> The name of the node that contains the replica. This parameter is required.
> targetNode
> The name of the destination node. This parameter is required.
> async
> Request ID to track this action which will be processed asynchronously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127361#comment-17127361
]
ASF subversion and git services commented on SOLR-14442:
Commit a60f17dc0a03e05fb7406a60423af5edf88b03ec in lucene-solr's branch
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a60f17d ]
SOLR-14442: add improvement to CHANGES.txt
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13169) Move Replica Docs need improvement (V1 and V2 introspect)
[
https://issues.apache.org/jira/browse/SOLR-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck updated SOLR-13169:
Attachment: screenshot-1.png
> Move Replica Docs need improvement (V1 and V2 introspect)
> -
>
> Key: SOLR-13169
> URL: https://issues.apache.org/jira/browse/SOLR-13169
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Gus Heck
>Priority: Major
> Attachments: screenshot-1.png, testing.txt
>
>
> At a minimum required parameters should be noted equally in both places.
> Conversation with [~ab] indicates that there are also some discrepancies in
> what is and is not actually required in docs vs code. ("in MoveReplicaCmd if
> you specify “replica” then “shard” is completely ignored")
> Also in v2 it seems shard might be inferred from the URL and in that case
> it's not clear if the URL or the json takes precedence.
> From introspect:
> {code:java}
> "move-replica": {
> "type": "object",
> "documentation":
> "https://lucene.apache.org/solr/guide/collections-api.html#movereplica";,
> "description": "This command moves a replica from one
> node to a new node. In case of shared filesystems the `dataDir` and `ulogDir`
> may be reused.",
> "properties": {
> "replica": {
> "type": "string",
> "description": "The name of the replica"
> },
> "shard": {
> "type": "string",
> "description": "The name of the shard"
> },
> "sourceNode": {
> "type": "string",
> "description": "The name of the node that
> contains the replica."
> },
> "targetNode": {
> "type": "string",
> "description": "The name of the destination node.
> This parameter is required."
> },
> "waitForFinalState": {
> "type": "boolean",
> "default": "false",
> "description": "Wait for the moved replica to
> become active."
> },
> "timeout": {
> "type": "integer",
> "default": 600,
> "description": "Timeout to wait for replica to
> become active. For very large replicas this may need to be increased."
> },
> "inPlaceMove": {
> "type": "boolean",
> "default": "true",
> "description": "For replicas that use shared
> filesystems allow 'in-place' move that reuses shared data."
> }
> {code}
> From ref guide for V1:
> MOVEREPLICA Parameters
> collection
> The name of the collection. This parameter is required.
> shard
> The name of the shard that the replica belongs to. This parameter is required.
> replica
> The name of the replica. This parameter is required.
> sourceNode
> The name of the node that contains the replica. This parameter is required.
> targetNode
> The name of the destination node. This parameter is required.
> async
> Request ID to track this action which will be processed asynchronously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13169) Move Replica Docs need improvement (V1 and V2 introspect)
[
https://issues.apache.org/jira/browse/SOLR-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127368#comment-17127368
]
Gus Heck commented on SOLR-13169:
-
hmm, maybe we should document this tidbit:
{code:java}
if (createNodeList != null) { // Overrides petty considerations about
maxShardsPerNode
{code}
It does indeed seem to be the case that MOVEREPLICA can be used to violate
maxShardsPerNode. This happens in the add replica code that move replica
invokes, so while this was intentional there, it's not clear if it's a bug with
respect to move replica...
I created a collection with 1 per node, and moved a replica to one of the other
nodes successfully:
!screenshot-1.png!
> Move Replica Docs need improvement (V1 and V2 introspect)
> -
>
> Key: SOLR-13169
> URL: https://issues.apache.org/jira/browse/SOLR-13169
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Gus Heck
>Priority: Major
> Attachments: screenshot-1.png, testing.txt
>
>
> At a minimum required parameters should be noted equally in both places.
> Conversation with [~ab] indicates that there are also some discrepancies in
> what is and is not actually required in docs vs code. ("in MoveReplicaCmd if
> you specify “replica” then “shard” is completely ignored")
> Also in v2 it seems shard might be inferred from the URL and in that case
> it's not clear if the URL or the json takes precedence.
> From introspect:
> {code:java}
> "move-replica": {
> "type": "object",
> "documentation":
> "https://lucene.apache.org/solr/guide/collections-api.html#movereplica";,
> "description": "This command moves a replica from one
> node to a new node. In case of shared filesystems the `dataDir` and `ulogDir`
> may be reused.",
> "properties": {
> "replica": {
> "type": "string",
> "description": "The name of the replica"
> },
> "shard": {
> "type": "string",
> "description": "The name of the shard"
> },
> "sourceNode": {
> "type": "string",
> "description": "The name of the node that
> contains the replica."
> },
> "targetNode": {
> "type": "string",
> "description": "The name of the destination node.
> This parameter is required."
> },
> "waitForFinalState": {
> "type": "boolean",
> "default": "false",
> "description": "Wait for the moved replica to
> become active."
> },
> "timeout": {
> "type": "integer",
> "default": 600,
> "description": "Timeout to wait for replica to
> become active. For very large replicas this may need to be increased."
> },
> "inPlaceMove": {
> "type": "boolean",
> "default": "true",
> "description": "For replicas that use shared
> filesystems allow 'in-place' move that reuses shared data."
> }
> {code}
> From ref guide for V1:
> MOVEREPLICA Parameters
> collection
> The name of the collection. This parameter is required.
> shard
> The name of the shard that the replica belongs to. This parameter is required.
> replica
> The name of the replica. This parameter is required.
> sourceNode
> The name of the node that contains the replica. This parameter is required.
> targetNode
> The name of the destination node. This parameter is required.
> async
> Request ID to track this action which will be processed asynchronously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14541) Insure classes that implement equals implement hashCode or suppress warnings
Erick Erickson created SOLR-14541: - Summary: Insure classes that implement equals implement hashCode or suppress warnings Key: SOLR-14541 URL: https://issues.apache.org/jira/browse/SOLR-14541 Project: Solr Issue Type: Sub-task Reporter: Erick Erickson Assignee: Erick Erickson While looking at warnings, I found that the following classes generate this warning: *overrides equals, but neither it nor any superclass overrides hashCode method* I can suppress the warning, but this has been a source of errors in the past so I'm reluctant to just do that blindly. NOTE: The Lucene one should probably be it's own Jira if it's going to have hashCode implemented, but here for triage. What I need for each method is for someone who has a clue about that particular code to render an opinion that we can safely suppress the warning or to provide a hashCode method. Some of these have been here for a very long time and were implemented by people no longer active... lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14541) Insure classes that implement equals implement hashCode or suppress warnings
[ https://issues.apache.org/jira/browse/SOLR-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14541: -- Description: While looking at warnings, I found that the following classes generate this warning: *overrides equals, but neither it nor any superclass overrides hashCode method* I can suppress the warning, but this has been a source of errors in the past so I'm reluctant to just do that blindly. NOTE: The Lucene one should probably be it's own Jira if it's going to have hashCode implemented, but here for triage. What I need for each method is for someone who has a clue about that particular code to render an opinion that we can safely suppress the warning or to provide a hashCode method. Some of these have been here for a very long time and were implemented by people no longer active... lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 was: While looking at warnings, I found that the following classes generate this warning: *overrides equals, but neither it nor any superclass overrides hashCode method* I can suppress the warning, but this has been a source of errors in the past so I'm reluctant to just do that blindly. NOTE: The Lucene one should probably be it's own Jira if it's going to have hashCode implemented, but here for triage. What I need for each method is for someone who has a clue about that particular code to render an opinion that we can safely suppress the warning or to provide a hashCode method. Some of these have been here for a very long time and were implemented by people no longer active... lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 solr/core/src/java/org/apache/solr/clo
[jira] [Commented] (SOLR-14525) For components loaded from packages SolrCoreAware, ResourceLoaderAware are not honored
[ https://issues.apache.org/jira/browse/SOLR-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127326#comment-17127326 ] Erick Erickson commented on SOLR-14525: --- [~noble.paul] Can this be closed now? > For components loaded from packages SolrCoreAware, ResourceLoaderAware are > not honored > -- > > Key: SOLR-14525 > URL: https://issues.apache.org/jira/browse/SOLR-14525 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: packages >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > inform() methods are not invoked if the plugins are loaded from packages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13132) Improve JSON "terms" facet performance when sorted by relatedness
[
https://issues.apache.org/jira/browse/SOLR-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127197#comment-17127197
]
Chris M. Hostetter commented on SOLR-13132:
---
Hey Michael - a couple of questions/thoughts...
Re: GIT:61befab60696dc4267ab9c96e36bc266c93a2fc3
This is definitely awkward and tricky, and not at all something i'd really
considered in SOLR-14467 when advocating for the introduction of
{{SlotContext.isAllBucket()}}.
I want to think about this some more... at the moment 2 straw man ideas occur
to me, but they feel like baby-bear/papa-bear solutions (too little / too
much)...
* (baby-bear) - disable sweeping if allBuckets is used.
* (papa-bear) - add a SlotContext param to {{CountSlotAcc.incrementCount()}}
and rework {{SKGSlotAcc.registerSweepingAccs()}} use custom {{CountSlotAcc}}
instances that ~ "skip & track" the allBuckets slot in some way that
SweepSKGSlotAcc can later ignore? maybe?
As much as a dislike the sort of hackish solution you put in place with the
nocommits, it's simple and by comparison both of those "cleaner" ideas seem too
heavy handed, in either direction.
Although ... An idea that just occured to me as i type this: would it be viable
to have {{SKGSlotAcc.registerSweepingAccs()}} actually return the new
{{SweepSKGSlotAcc}} instance it registers, and modify the {{collect}} methods
of that class to be No-Ops except for noting & tracking the allBucketsSlot?
(although as i say that i, again, feel like it may be a heavy handed change to
what you have for such a niche special circumstance)
Re: a6b1c60e61563535d7ba67c17d74f2bada6f80a2
What motivated this change?
I don't think this is a good idea, largely because of the answer to the
question you asked in your commit message...
{quote}what was the point of the "if countAcc == null"?
{quote}
...this is explained in the javadocs of the methods you modified (and in the
class level javadocs)
{quote}By default, this class assumes subclasses can support sweeping
collection unless subclasses initialize countAcc directly in their
constructors.
{quote}
{quote}This impl first initializes countAcc as a \{@link
SweepingCountSlotAcc} if null.
{quote}
{{Although on apache/master it's un-explained in this particular
class's/method's javadocs, the general convention of why processors use the "
if (null == countAcc)}}{{{ countAcc = .. } }}" pattern is touched on in a
comment in FacetFieldProcessor:
{code:java}
// allow a custom count acc to be used
if (countAcc == null) {
countAcc = new SlotAcc.CountSlotArrAcc(fcontext, slotCount);
{code}
...the fact that FacetFieldProcessor doesn't hard code an assumption about how
countAcc works is one of the reasons the current SweepingCountSlotAcc approach
works in FacetFieldProcessorByArray.
I don't know if it's a good idea to *force* (future) subclasses to use sweeping
by wrapping whatever "original" {{countAcc}} they init in a
SweepingCountSlotAcc ... if you think there's a reason why it might make sense
for a future subclass to use a SweepingCountSlotAcc that wraps an arbitrary
CountSlotAcc then i'm all ears, but I'd rather the design _allow_ subclasses to
override FacetFieldProcessorByArray's behavior by letting them init a
SweepingCountSlotAcc that wraps a CountSlotAcc directly, rather then by
_forcing_ the subclass to provide a CountSlotAcc that "gets wrapped" by their
superclass.
I pushed a small change to replace TestCloudJSONFacetSKGSweep with equivilent
improvements to the TestCloudJSONFacetSKGEquiv from upstream in the hopes of
doing some heavy test beasting of all the json.facet tests on your branch – but
almost immediately ran into a failure from TestCloudJSONFacetSKG...
{noformat}
[junit4] 2> 5919 ERROR (qtp1172942992-67) [n:127.0.0.1:41317_solr
c:org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection s:shard2
r:core_node4
x:org.apache.solr.search.facet.TestCloudJSONFacetSKG_collection_shard2_replica_n2
] o.a.s.s.HttpSolrCall null:java.lang.ArrayIndexOutOfBoundsException: Index 8
out of bounds for length 1
[junit4] 2>at
org.apache.solr.search.facet.SlotAcc$CountSlotArrAcc.incrementCount(SlotAcc.java:841)
[junit4] 2>at
org.apache.solr.search.facet.UnInvertedField.collectDocsGeneric(UnInvertedField.java:462)
[junit4] 2>at
org.apache.solr.search.facet.UnInvertedField.collectDocs(UnInvertedField.java:437)
[junit4] 2>at
org.apache.solr.search.facet.FacetFieldProcessorByArrayUIF.collectDocs(FacetFieldProcessorByArrayUIF.java:70)
[junit4] 2>at
org.apache.solr.search.facet.FacetFieldProcessorByArray.calcFacets(FacetFieldProcessorByArray.java:121)
[junit4] 2>at
org.apache.solr.search.facet.FacetFieldProcessorByArray.process(FacetFieldProcessorByArray.java:89)
[junit4] 2>at
org.apache.solr.search.facet.FacetRequest.process(F
[jira] [Commented] (LUCENE-9383) Port benchmark module Ant build to Gradle
[ https://issues.apache.org/jira/browse/LUCENE-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127116#comment-17127116 ] ASF subversion and git services commented on LUCENE-9383: - Commit 89784ad7be45640ad835fe41981becfc91e62349 in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=89784ad ] LUCENE-9383: benchmark module: Gradle conversion (#1550) > Port benchmark module Ant build to Gradle > - > > Key: LUCENE-9383 > URL: https://issues.apache.org/jira/browse/LUCENE-9383 > Project: Lucene - Core > Issue Type: Sub-task > Components: modules/benchmark >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Time Spent: 1h 40m > Remaining Estimate: 0h > > The benchmark's build is more than a conventional build, it also has scripts > to fetch sample data for perf testing, and a task to run a perf test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9383) Port benchmark module Ant build to Gradle
[ https://issues.apache.org/jira/browse/LUCENE-9383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-9383. -- Fix Version/s: master (9.0) Resolution: Fixed Thanks so much for your help [~dweiss]! My gradle skills rusted a bit in the 3 years since I last touched it. > Port benchmark module Ant build to Gradle > - > > Key: LUCENE-9383 > URL: https://issues.apache.org/jira/browse/LUCENE-9383 > Project: Lucene - Core > Issue Type: Sub-task > Components: modules/benchmark >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: master (9.0) > > Time Spent: 2h > Remaining Estimate: 0h > > The benchmark's build is more than a conventional build, it also has scripts > to fetch sample data for perf testing, and a task to run a perf test. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
[ https://issues.apache.org/jira/browse/SOLR-14540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127120#comment-17127120 ] Mikhail Khludnev commented on SOLR-14540: - [~ctargett], can you suggest where to put his snippet in the ref guide? > Ref Guide: Document how-to for Block Join Facets via Query DSL > -- > > Key: SOLR-14540 > URL: https://issues.apache.org/jira/browse/SOLR-14540 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Major > > Solr has an old good feature > https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. > I'd like to document similar solution/snippet for > https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes > in Query DSL. This solution combines several elements, so it's not clear > where to put it. Does it deserve separate page or just a paragraph somewhere? > Snippet is already > [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] > it just needs some tweaks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14540) Ref Guide: Document how-to for Block Join Facets via Query DSL
Mikhail Khludnev created SOLR-14540: --- Summary: Ref Guide: Document how-to for Block Join Facets via Query DSL Key: SOLR-14540 URL: https://issues.apache.org/jira/browse/SOLR-14540 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Mikhail Khludnev Solr has an old good feature https://lucene.apache.org/solr/guide/8_5/faceting.html#tagging-and-excluding-filters. I'd like to document similar solution/snippet for https://lucene.apache.org/solr/guide/8_5/json-faceting-domain-changes.html#block-join-domain-changes in Query DSL. This solution combines several elements, so it's not clear where to put it. Does it deserve separate page or just a paragraph somewhere? Snippet is already [there|https://issues.apache.org/jira/browse/SOLR-14419?focusedCommentId=17112869&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17112869] it just needs some tweaks. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14536) Fix or suppress warnings in apache/solr/common
[ https://issues.apache.org/jira/browse/SOLR-14536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127341#comment-17127341 ] ASF subversion and git services commented on SOLR-14536: Commit 6d5b1ae7f4bf02f8d0a4a193af08d0ec0cd0b0aa in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6d5b1ae ] SOLR-14536: Fix or suppress warnings in apache/solr/common > Fix or suppress warnings in apache/solr/common > -- > > Key: SOLR-14536 > URL: https://issues.apache.org/jira/browse/SOLR-14536 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14536) Fix or suppress warnings in apache/solr/common
[ https://issues.apache.org/jira/browse/SOLR-14536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127342#comment-17127342 ] ASF subversion and git services commented on SOLR-14536: Commit d639aa912fef52c8d39aa6196bf79927970bd171 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d639aa9 ] SOLR-14536: Fix or suppress warnings in apache/solr/common > Fix or suppress warnings in apache/solr/common > -- > > Key: SOLR-14536 > URL: https://issues.apache.org/jira/browse/SOLR-14536 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127328#comment-17127328
]
Mikhail Khludnev commented on SOLR-14442:
-
oh.. I forgot to add CHANGES.txt, will fix it soon.
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13132) Improve JSON "terms" facet performance when sorted by relatedness
[
https://issues.apache.org/jira/browse/SOLR-13132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127126#comment-17127126
]
Michael Gibney commented on SOLR-13132:
---
Merge went well, just pushed, all tests passed for me. There were a couple of
cleanup commits subsequent to the merge, and I think there are still some
SOLR-14467-related tests to re-enable. The last commit
(61befab60696dc4267ab9c96e36bc266c93a2fc3) highlights the awkwardness of
identifying the allBuckets slot (and responding appropriately) in a sweep
context ... I'm still thinking about how best to do that (probably _not_ what I
did initially?).
> Improve JSON "terms" facet performance when sorted by relatedness
> --
>
> Key: SOLR-13132
> URL: https://issues.apache.org/jira/browse/SOLR-13132
> Project: Solr
> Issue Type: Improvement
> Components: Facet Module
>Affects Versions: 7.4, master (9.0)
>Reporter: Michael Gibney
>Priority: Major
> Attachments: SOLR-13132-with-cache-01.patch,
> SOLR-13132-with-cache.patch, SOLR-13132.patch, SOLR-13132_testSweep.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When sorting buckets by {{relatedness}}, JSON "terms" facet must calculate
> {{relatedness}} for every term.
> The current implementation uses a standard uninverted approach (either
> {{docValues}} or {{UnInvertedField}}) to get facet counts over the domain
> base docSet, and then uses that initial pass as a pre-filter for a
> second-pass, inverted approach of fetching docSets for each relevant term
> (i.e., {{count > minCount}}?) and calculating intersection size of those sets
> with the domain base docSet.
> Over high-cardinality fields, the overhead of per-term docSet creation and
> set intersection operations increases request latency to the point where
> relatedness sort may not be usable in practice (for my use case, even after
> applying the patch for SOLR-13108, for a field with ~220k unique terms per
> core, QTime for high-cardinality domain docSets were, e.g.: cardinality
> 1816684=9000ms, cardinality 5032902=18000ms).
> The attached patch brings the above example QTimes down to a manageable
> ~300ms and ~250ms respectively. The approach calculates uninverted facet
> counts over domain base, foreground, and background docSets in parallel in a
> single pass. This allows us to take advantage of the efficiencies built into
> the standard uninverted {{FacetFieldProcessorByArray[DV|UIF]}}), and avoids
> the per-term docSet creation and set intersection overhead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14536) Fix or suppress warnings in apache/solr/common
[ https://issues.apache.org/jira/browse/SOLR-14536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14536. --- Fix Version/s: 8.6 Resolution: Fixed > Fix or suppress warnings in apache/solr/common > -- > > Key: SOLR-14536 > URL: https://issues.apache.org/jira/browse/SOLR-14536 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14480) Fix or suppress warnings in solr/cloud/api
[ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson reassigned SOLR-14480: - Assignee: Erick Erickson (was: Atri Sharma) > Fix or suppress warnings in solr/cloud/api > -- > > Key: SOLR-14480 > URL: https://issues.apache.org/jira/browse/SOLR-14480 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~atri] Here's one for you! > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the second subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14419) Query DLS {"param":"ref"}
[
https://issues.apache.org/jira/browse/SOLR-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14419:
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Query DLS {"param":"ref"}
> -
>
> Key: SOLR-14419
> URL: https://issues.apache.org/jira/browse/SOLR-14419
> Project: Solr
> Issue Type: Improvement
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14419-refguide.patch, SOLR-14419.patch,
> SOLR-14419.patch, SOLR-14419.patch
>
>
> What we can do with plain params:
> {{q=\{!parent which=$prnts}...&prnts=type:parent}}
> obviously I want to have something like this in Query DSL:
> {code}
> { "query": { "parents":{ "which":{"param":"prnts"}, "query":"..."}}
> "params": {
> "prnts":"type:parent"
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127308#comment-17127308
]
ASF subversion and git services commented on SOLR-14442:
Commit c8e43346928b6d989d9e4d82c0334b322664c69a in lucene-solr's branch
refs/heads/master from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c8e4334 ]
SOLR-14442: call jstack before force kill; force kill regardles of open port.
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14442) bin/solr to attempt jstack before killing hung Solr instance
[
https://issues.apache.org/jira/browse/SOLR-14442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127309#comment-17127309
]
ASF subversion and git services commented on SOLR-14442:
Commit 7ab160b6e4594bf00d740c9c85a664b04e8abe77 in lucene-solr's branch
refs/heads/branch_8x from Mikhail Khludnev
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7ab160b ]
SOLR-14442: call jstack before force kill; force kill regardles of open port.
> bin/solr to attempt jstack before killing hung Solr instance
>
>
> Key: SOLR-14442
> URL: https://issues.apache.org/jira/browse/SOLR-14442
> Project: Solr
> Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14442.patch, SOLR-14442.patch, SOLR-14442.patch,
> screenshot-1.png
>
>
> If a Solr instance did not respond to the 'stop' command in a timely manner
> then the {{bin/solr}} script will attempt to forcefully kill it:
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L859]
> Gathering of information (e.g. a jstack of the java process) before the kill
> command may be helpful in determining why the instance did not stop as
> expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14539) Query DSL {!bool filter=$ref} to resolve multiple param values
[
https://issues.apache.org/jira/browse/SOLR-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127392#comment-17127392
]
Mikhail Khludnev commented on SOLR-14539:
-
it's also worth to pull {{excludeTags}} from {{\{!filters ... }.. }} as well.
> Query DSL {!bool filter=$ref} to resolve multiple param values
> ---
>
> Key: SOLR-14539
> URL: https://issues.apache.org/jira/browse/SOLR-14539
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: newbie
>
> It's continuation of Query DSL improvements SOLR-14419, SOLR-9510.
> Let {{\{!bool .. }...}} repeat {{\{!filters ..}..}} trick resolve parameter
> refs to many values. Now if there are many params under the same name it
> picks the first one that awkward.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on pull request #1543: LUCENE-9378: Disable compression on binary values whose length is less than 32.
jpountz commented on pull request #1543: URL: https://github.com/apache/lucene-solr/pull/1543#issuecomment-640112234 @mikemccand With `HighTermTitleBDVSort`, almost every match requires decoding a new block of 32 values, which is a worst-case scenario. On the other hand `MatchAllBDVSort` and the faceting tasks need many documents per block, so the cost of decoding the block is amortized across several documents. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14542) Fix or suppress warnings in solr/handler/dataimport
Erick Erickson created SOLR-14542: - Summary: Fix or suppress warnings in solr/handler/dataimport Key: SOLR-14542 URL: https://issues.apache.org/jira/browse/SOLR-14542 Project: Solr Issue Type: Sub-task Reporter: Erick Erickson Assignee: Erick Erickson -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14543) Fix or suppress warnings in apache/solr/search
Erick Erickson created SOLR-14543: - Summary: Fix or suppress warnings in apache/solr/search Key: SOLR-14543 URL: https://issues.apache.org/jira/browse/SOLR-14543 Project: Solr Issue Type: Sub-task Reporter: Erick Erickson Assignee: Erick Erickson -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14480) Fix or suppress warnings in solr/cloud/api
[ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127439#comment-17127439 ] ASF subversion and git services commented on SOLR-14480: Commit 3cbb1e0b4f9a49df1ff53e62ad0930f1cf4e7def in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3cbb1e0 ] SOLR-14480: Fix or suppress warnings in solr/cloud/api > Fix or suppress warnings in solr/cloud/api > -- > > Key: SOLR-14480 > URL: https://issues.apache.org/jira/browse/SOLR-14480 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~atri] Here's one for you! > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the second subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14480) Fix or suppress warnings in solr/cloud/api
[ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14480. --- Fix Version/s: 8.6 Resolution: Fixed > Fix or suppress warnings in solr/cloud/api > -- > > Key: SOLR-14480 > URL: https://issues.apache.org/jira/browse/SOLR-14480 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > > [~atri] Here's one for you! > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the second subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14480) Fix or suppress warnings in solr/cloud/api
[ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127440#comment-17127440 ] ASF subversion and git services commented on SOLR-14480: Commit f0683090797d3e0d3bb1799f2bdd3038f9114d79 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f068309 ] SOLR-14480: Fix or suppress warnings in solr/cloud/api > Fix or suppress warnings in solr/cloud/api > -- > > Key: SOLR-14480 > URL: https://issues.apache.org/jira/browse/SOLR-14480 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~atri] Here's one for you! > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the second subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14525) For components loaded from packages SolrCoreAware, ResourceLoaderAware are not honored
[ https://issues.apache.org/jira/browse/SOLR-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-14525. --- Resolution: Fixed > For components loaded from packages SolrCoreAware, ResourceLoaderAware are > not honored > -- > > Key: SOLR-14525 > URL: https://issues.apache.org/jira/browse/SOLR-14525 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: packages >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 8.6 > > Time Spent: 40m > Remaining Estimate: 0h > > inform() methods are not invoked if the plugins are loaded from packages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14525) For components loaded from packages SolrCoreAware, ResourceLoaderAware are not honored
[ https://issues.apache.org/jira/browse/SOLR-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-14525: -- Fix Version/s: 8.6 > For components loaded from packages SolrCoreAware, ResourceLoaderAware are > not honored > -- > > Key: SOLR-14525 > URL: https://issues.apache.org/jira/browse/SOLR-14525 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: packages >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 8.6 > > Time Spent: 40m > Remaining Estimate: 0h > > inform() methods are not invoked if the plugins are loaded from packages -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14532) Add iml file to gitignore
[
https://issues.apache.org/jira/browse/SOLR-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17127527#comment-17127527
]
Dawid Weiss commented on SOLR-14532:
bq. Dawid, are you saying that devs really shouldn't be using {{./gradlew
idea}} anymore to generate IntelliJ configs and should instead just do a normal
import-as-gradle from the IDE?
Use whatever works for you; I just mentioned that the plain idea import is
recommended over project-file generation by gradle idea plugin authors [1].
[https://docs.gradle.org/current/userguide/idea_plugin.html]
> Add iml file to gitignore
> -
>
> Key: SOLR-14532
> URL: https://issues.apache.org/jira/browse/SOLR-14532
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Trivial
> Attachments: SOLR-14532.patch
>
>
> If I execute {{gradlew idea}} in my {{lucene-solr-upstream}} directory, it
> will create three files in the root directory:
> {noformat}
> lucene-solr-upstream.iml
> lucene-solr-upstream.ipr
> lucene-solr-upstream.iws
> {noformat}
> Git will ignore the {{ipr}} and the {{iws}} file, but it lists the iml file
> as a new file. We should also ignore that one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
