[jira] [Commented] (SOLR-16471) Impossible to set bind host for Embedded Zookeeper in Solr9 docker image
[ https://issues.apache.org/jira/browse/SOLR-16471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620034#comment-17620034 ] Henrik commented on SOLR-16471: --- Thanks a lot for the tip about using volume bind bounds, that solved this issue for us :) We're using solrcloud and embedded zookeeper for feature tests, and when running our applications locally. Having the embedded zk available makes the setup slightly easier. > Impossible to set bind host for Embedded Zookeeper in Solr9 docker image > > > Key: SOLR-16471 > URL: https://issues.apache.org/jira/browse/SOLR-16471 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Henrik >Priority: Major > > Solr 9 switched clientPortAddress in solr/server/solr/zoo.cf from 0.0.0.0 to > 127.0.0.1. When using the solr9 docker images it is impossible to override > this value: > * The file is owned by root and cannot be overwritten > * The ZOOCFG and ZOOCFGDIR environment variables aren't read by > solr/core/src/java/org/apache/solr/cloud/SolrZkServer.java > The only workaround I have found is to duplicate solr's Dockerfile and build > an alternative solr9 docker image. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] tomglk commented on pull request #151: SOLR-15437: ReRanking/LTR does not work in combination with custom sort and SolrCloud
tomglk commented on PR #151: URL: https://github.com/apache/solr/pull/151#issuecomment-1283490516 I had to stop due to a lack of time. However, I can try to manage collaborating with you to finally fix this. Especially if you have questions regarding this solution. Maybe also to develop a new solution (cannot promise anything here). I definitely need a bit of time to get deep into the topic again to be able to have fruitful discussions. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16455) Migrate Jira to Github Issues and Github Projects
[ https://issues.apache.org/jira/browse/SOLR-16455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619993#comment-17619993 ] Ishan Chattopadhyaya commented on SOLR-16455: - Btw, I'm not opposed to migrating to ASF hosted GitLab, which has a very similar interface to GitHub. > Migrate Jira to Github Issues and Github Projects > - > > Key: SOLR-16455 > URL: https://issues.apache.org/jira/browse/SOLR-16455 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: github >Reporter: Jeb Nix >Priority: Trivial > Attachments: image-2022-10-11-02-25-04-799.png, > image-2022-10-11-02-38-52-609.png > > > Link to the mailing list disscussion thread: > [https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] > GitHub is where people are at when they lookup for Solr (or basically any > project). Most of the modern projects that have been started with Jira and > mailing lists have migrated to Github in the last few years. Lucene did that > just now for the Issues which has allowed me to explore much more of their > issues. GitHub works great and many think that it works even better. > In my opinion, when the issues are managed on Github, it is much simpler to > collaborate and they will get wider exposure since developers are spending > time on Github anyway (whether if it's for their projects or for looking at > the actual source code). It is also important to mention that it is pretty > cumbersome for a new contributor that wants to add stuff to Solr, to talk > about this via mail, then translate them to Jira of the issues, and just > after that submit a PR on Github. e.g. 3 different systems for each process. > Other advantages are in the area of integrating code with issues. Take a look > at a new issue that has been submitted to Lucene, in which one can point to a > specific line / introduce sophisticated code blocks: > !image-2022-10-11-02-25-04-799.png|width=886,height=288! > !image-2022-10-11-02-38-52-609.png|width=859,height=703! > These are just simple examples, but I can easily dive into all of the minor > and major advantages of writing issues on Github rather than in different > places. I'll only mention now that the ability to write MD files is much more > convenient to a user that writing MD on PRs, and using two different text > editors for mail and Jira. > The main advantages of migration are: > * Easier to evolve the community and expose Solr Issues to newbies > * Ability to integrate code with issues > * Using a unified format for writing text - Markdowns > * A more modern and comfortable UI > * A unified UI for everything regarding Solr > * Issues templates > * Wider and more understandable usage of votes and feelings (with emojis) > * All Solr contributors and most Solr users have a GitHub account. Not all > of them have a Jira ASF account. > * All Solr contributors and most Solr users are spending time on GitHub > anyway. > Actually, I thought such a great move (for me at least) would never happen in > Solr in the next years since I didn't think that the community sees & > understands the many advantages yet. But now that the Lucene guys did this, I > believe that it is possible for Solr too. As a reference, here's the relevant > LUCENE-10557 that suggested the migration. Note that this issue suggests a > wider migration - not only for GitHub Issues (and later Github Projects to > manage them) but also for Solr Operator is of course a great live example of > this. Currently, Solr Operator manages releases with milestones and labels > issues/ PRs. > Referencing the tool used by Lucene for performing the task > [https://github.com/apache/lucene-jira-archive]. This would be great for the > migration of issues. The major tasks would be: > * Get a consensus about the migration among committers > * Choose issues that should be moved to GitHub - We'll migrate all issues > towards an atomic switch to GitHub if no major technical obstacles show up. > * > ** Write a migration script > * Prepare a complete migration tool > ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a > reference for the Lucene's one > * Build the convention for issue label/milestone management > * > ** Do some experiments on a sandbox repository > [https://github.com/jebnix/sandbox-SOLR-16455] > ** Make documentation for metadata (label/milestone) management > * Enable Github issue on the Solr's repository > ** Raise an issue on INFRA > ** Set a mail hook to > [iss...@lucene.apache.org|mailto:iss...@lucene.apache.org] (many thanks to > the general mail group name) > * Set a schedule for migration > ** Give some time to committers to play around wi
[jira] [Commented] (SOLR-16455) Migrate Jira to Github Issues and Github Projects
[ https://issues.apache.org/jira/browse/SOLR-16455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619992#comment-17619992 ] Ishan Chattopadhyaya commented on SOLR-16455: - I'm -1 on GitHub being the sole way to contribute. I believe all interactions for an open source project at ASF should be done using ASF hosted services. If there's veto power, I'll use it. Otherwise, I'll have to waste my time lobbying against this bad idea. > Migrate Jira to Github Issues and Github Projects > - > > Key: SOLR-16455 > URL: https://issues.apache.org/jira/browse/SOLR-16455 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: github >Reporter: Jeb Nix >Priority: Trivial > Attachments: image-2022-10-11-02-25-04-799.png, > image-2022-10-11-02-38-52-609.png > > > Link to the mailing list disscussion thread: > [https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] > GitHub is where people are at when they lookup for Solr (or basically any > project). Most of the modern projects that have been started with Jira and > mailing lists have migrated to Github in the last few years. Lucene did that > just now for the Issues which has allowed me to explore much more of their > issues. GitHub works great and many think that it works even better. > In my opinion, when the issues are managed on Github, it is much simpler to > collaborate and they will get wider exposure since developers are spending > time on Github anyway (whether if it's for their projects or for looking at > the actual source code). It is also important to mention that it is pretty > cumbersome for a new contributor that wants to add stuff to Solr, to talk > about this via mail, then translate them to Jira of the issues, and just > after that submit a PR on Github. e.g. 3 different systems for each process. > Other advantages are in the area of integrating code with issues. Take a look > at a new issue that has been submitted to Lucene, in which one can point to a > specific line / introduce sophisticated code blocks: > !image-2022-10-11-02-25-04-799.png|width=886,height=288! > !image-2022-10-11-02-38-52-609.png|width=859,height=703! > These are just simple examples, but I can easily dive into all of the minor > and major advantages of writing issues on Github rather than in different > places. I'll only mention now that the ability to write MD files is much more > convenient to a user that writing MD on PRs, and using two different text > editors for mail and Jira. > The main advantages of migration are: > * Easier to evolve the community and expose Solr Issues to newbies > * Ability to integrate code with issues > * Using a unified format for writing text - Markdowns > * A more modern and comfortable UI > * A unified UI for everything regarding Solr > * Issues templates > * Wider and more understandable usage of votes and feelings (with emojis) > * All Solr contributors and most Solr users have a GitHub account. Not all > of them have a Jira ASF account. > * All Solr contributors and most Solr users are spending time on GitHub > anyway. > Actually, I thought such a great move (for me at least) would never happen in > Solr in the next years since I didn't think that the community sees & > understands the many advantages yet. But now that the Lucene guys did this, I > believe that it is possible for Solr too. As a reference, here's the relevant > LUCENE-10557 that suggested the migration. Note that this issue suggests a > wider migration - not only for GitHub Issues (and later Github Projects to > manage them) but also for Solr Operator is of course a great live example of > this. Currently, Solr Operator manages releases with milestones and labels > issues/ PRs. > Referencing the tool used by Lucene for performing the task > [https://github.com/apache/lucene-jira-archive]. This would be great for the > migration of issues. The major tasks would be: > * Get a consensus about the migration among committers > * Choose issues that should be moved to GitHub - We'll migrate all issues > towards an atomic switch to GitHub if no major technical obstacles show up. > * > ** Write a migration script > * Prepare a complete migration tool > ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a > reference for the Lucene's one > * Build the convention for issue label/milestone management > * > ** Do some experiments on a sandbox repository > [https://github.com/jebnix/sandbox-SOLR-16455] > ** Make documentation for metadata (label/milestone) management > * Enable Github issue on the Solr's repository > ** Raise an issue on INFRA > ** Set a mail hook to > [iss...@lucene.apache.org|mailto:
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1072: SOLR-16456: ZkNodeProps to implement MapWriter and DistributedQueue support MapWriter
sonatype-lift[bot] commented on code in PR #1072:
URL: https://github.com/apache/solr/pull/1072#discussion_r998933965
##
solr/core/src/java/org/apache/solr/cloud/ZkDistributedQueue.java:
##
@@ -307,6 +309,10 @@ public byte[] take() throws KeeperException,
InterruptedException {
}
}
+ public void offer(MapWriter mw) throws KeeperException, InterruptedException
{
+offer(Utils.toJSON(mw));
Review Comment:
*THREAD_SAFETY_VIOLATION:* Unprotected write. Non-private method
`ZkDistributedQueue.offer(...)` indirectly writes to field `this.isDirty`
outside of synchronization.
Reporting because another access to the same memory occurs on a background
thread, although this access may not.
---
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Was this a good recommendation?
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=346295320&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=346295320&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=346295320&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=346295320&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=346295320&lift_comment_rating=5)
]
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16464) Upgrade commons-text to 1.10.0
[ https://issues.apache.org/jira/browse/SOLR-16464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619990#comment-17619990 ] Rahul Verma commented on SOLR-16464: Are there any plans to release a 9.x patch release with this fix ? > Upgrade commons-text to 1.10.0 > -- > > Key: SOLR-16464 > URL: https://issues.apache.org/jira/browse/SOLR-16464 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Minor > Fix For: main (10.0), 8.11.3, 9.2 > > Time Spent: 50m > Remaining Estimate: 0h > > commons-text should be upgraded to 1.10.0 - > https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #953: SOLR-16311: Simplify assert statement
dsmiley commented on PR #953: URL: https://github.com/apache/solr/pull/953#issuecomment-1283405032 I just want to say "thank you" for an unexpectedly thorough review by @mkhludnev on a PR that many of us saw and passed on (I did). -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16455) Migrate Jira to Github Issues and Github Projects
[ https://issues.apache.org/jira/browse/SOLR-16455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619980#comment-17619980 ] David Smiley commented on SOLR-16455: - bq. I think there will be wired major/minor traps we didn't encounter or even notice when we migrate Lucene issue to GitHub "wired"? Was this a typo for "weird"? > Migrate Jira to Github Issues and Github Projects > - > > Key: SOLR-16455 > URL: https://issues.apache.org/jira/browse/SOLR-16455 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: github >Reporter: Jeb Nix >Priority: Trivial > Attachments: image-2022-10-11-02-25-04-799.png, > image-2022-10-11-02-38-52-609.png > > > Link to the mailing list disscussion thread: > [https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] > GitHub is where people are at when they lookup for Solr (or basically any > project). Most of the modern projects that have been started with Jira and > mailing lists have migrated to Github in the last few years. Lucene did that > just now for the Issues which has allowed me to explore much more of their > issues. GitHub works great and many think that it works even better. > In my opinion, when the issues are managed on Github, it is much simpler to > collaborate and they will get wider exposure since developers are spending > time on Github anyway (whether if it's for their projects or for looking at > the actual source code). It is also important to mention that it is pretty > cumbersome for a new contributor that wants to add stuff to Solr, to talk > about this via mail, then translate them to Jira of the issues, and just > after that submit a PR on Github. e.g. 3 different systems for each process. > Other advantages are in the area of integrating code with issues. Take a look > at a new issue that has been submitted to Lucene, in which one can point to a > specific line / introduce sophisticated code blocks: > !image-2022-10-11-02-25-04-799.png|width=886,height=288! > !image-2022-10-11-02-38-52-609.png|width=859,height=703! > These are just simple examples, but I can easily dive into all of the minor > and major advantages of writing issues on Github rather than in different > places. I'll only mention now that the ability to write MD files is much more > convenient to a user that writing MD on PRs, and using two different text > editors for mail and Jira. > The main advantages of migration are: > * Easier to evolve the community and expose Solr Issues to newbies > * Ability to integrate code with issues > * Using a unified format for writing text - Markdowns > * A more modern and comfortable UI > * A unified UI for everything regarding Solr > * Issues templates > * Wider and more understandable usage of votes and feelings (with emojis) > * All Solr contributors and most Solr users have a GitHub account. Not all > of them have a Jira ASF account. > * All Solr contributors and most Solr users are spending time on GitHub > anyway. > Actually, I thought such a great move (for me at least) would never happen in > Solr in the next years since I didn't think that the community sees & > understands the many advantages yet. But now that the Lucene guys did this, I > believe that it is possible for Solr too. As a reference, here's the relevant > LUCENE-10557 that suggested the migration. Note that this issue suggests a > wider migration - not only for GitHub Issues (and later Github Projects to > manage them) but also for Solr Operator is of course a great live example of > this. Currently, Solr Operator manages releases with milestones and labels > issues/ PRs. > Referencing the tool used by Lucene for performing the task > [https://github.com/apache/lucene-jira-archive]. This would be great for the > migration of issues. The major tasks would be: > * Get a consensus about the migration among committers > * Choose issues that should be moved to GitHub - We'll migrate all issues > towards an atomic switch to GitHub if no major technical obstacles show up. > * > ** Write a migration script > * Prepare a complete migration tool > ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a > reference for the Lucene's one > * Build the convention for issue label/milestone management > * > ** Do some experiments on a sandbox repository > [https://github.com/jebnix/sandbox-SOLR-16455] > ** Make documentation for metadata (label/milestone) management > * Enable Github issue on the Solr's repository > ** Raise an issue on INFRA > ** Set a mail hook to > [iss...@lucene.apache.org|mailto:iss...@lucene.apache.org] (many thanks to > the general mail group name) > * Set a schedule for migration > **
[jira] [Commented] (SOLR-16455) Migrate Jira to Github Issues and Github Projects
[ https://issues.apache.org/jira/browse/SOLR-16455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619976#comment-17619976 ] Tomoko Uchida commented on SOLR-16455: -- Hi, bq. Tomoko Uchida maybe you could validate the steps listed in the description? As for the steps, that looks good to me. And you could reuse some parts of the migration tools used in Lucene's issue migration. I think there will be wired major/minor traps we didn't encounter or even notice when we migrate Lucene issue to GitHub. All the best! > Migrate Jira to Github Issues and Github Projects > - > > Key: SOLR-16455 > URL: https://issues.apache.org/jira/browse/SOLR-16455 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: github >Reporter: Jeb Nix >Priority: Trivial > Attachments: image-2022-10-11-02-25-04-799.png, > image-2022-10-11-02-38-52-609.png > > > Link to the mailing list disscussion thread: > [https://lists.apache.org/thread/kdzl9v7byhj6dnkzwbvtyfb5dok33dbs] > GitHub is where people are at when they lookup for Solr (or basically any > project). Most of the modern projects that have been started with Jira and > mailing lists have migrated to Github in the last few years. Lucene did that > just now for the Issues which has allowed me to explore much more of their > issues. GitHub works great and many think that it works even better. > In my opinion, when the issues are managed on Github, it is much simpler to > collaborate and they will get wider exposure since developers are spending > time on Github anyway (whether if it's for their projects or for looking at > the actual source code). It is also important to mention that it is pretty > cumbersome for a new contributor that wants to add stuff to Solr, to talk > about this via mail, then translate them to Jira of the issues, and just > after that submit a PR on Github. e.g. 3 different systems for each process. > Other advantages are in the area of integrating code with issues. Take a look > at a new issue that has been submitted to Lucene, in which one can point to a > specific line / introduce sophisticated code blocks: > !image-2022-10-11-02-25-04-799.png|width=886,height=288! > !image-2022-10-11-02-38-52-609.png|width=859,height=703! > These are just simple examples, but I can easily dive into all of the minor > and major advantages of writing issues on Github rather than in different > places. I'll only mention now that the ability to write MD files is much more > convenient to a user that writing MD on PRs, and using two different text > editors for mail and Jira. > The main advantages of migration are: > * Easier to evolve the community and expose Solr Issues to newbies > * Ability to integrate code with issues > * Using a unified format for writing text - Markdowns > * A more modern and comfortable UI > * A unified UI for everything regarding Solr > * Issues templates > * Wider and more understandable usage of votes and feelings (with emojis) > * All Solr contributors and most Solr users have a GitHub account. Not all > of them have a Jira ASF account. > * All Solr contributors and most Solr users are spending time on GitHub > anyway. > Actually, I thought such a great move (for me at least) would never happen in > Solr in the next years since I didn't think that the community sees & > understands the many advantages yet. But now that the Lucene guys did this, I > believe that it is possible for Solr too. As a reference, here's the relevant > LUCENE-10557 that suggested the migration. Note that this issue suggests a > wider migration - not only for GitHub Issues (and later Github Projects to > manage them) but also for Solr Operator is of course a great live example of > this. Currently, Solr Operator manages releases with milestones and labels > issues/ PRs. > Referencing the tool used by Lucene for performing the task > [https://github.com/apache/lucene-jira-archive]. This would be great for the > migration of issues. The major tasks would be: > * Get a consensus about the migration among committers > * Choose issues that should be moved to GitHub - We'll migrate all issues > towards an atomic switch to GitHub if no major technical obstacles show up. > * > ** Write a migration script > * Prepare a complete migration tool > ** See [https://github.com/apache/lucene-jira-archive/issues/5] as a > reference for the Lucene's one > * Build the convention for issue label/milestone management > * > ** Do some experiments on a sandbox repository > [https://github.com/jebnix/sandbox-SOLR-16455] > ** Make documentation for metadata (label/milestone) management > * Enable Github issue on the Solr's repository > ** Raise an
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998873683
##
solr/solrj/src/test/org/apache/solr/client/solrj/request/SchemaTest.java:
##
@@ -869,7 +869,7 @@ public void testCopyFieldWithMaxCharsAccuracy() throws
Exception {
int currentMaxChars = (Integer) currentCopyField.get("maxChars");
MatcherAssert.assertThat(
currentDestFieldName, anyOf(is(equalTo(destFieldName1)),
is(equalTo(destFieldName2;
-assertTrue(maxChars == currentMaxChars);
+assertEquals((int) maxChars, currentMaxChars);
Review Comment:
Fixed in d59d4e9075a88dd6c44a9890e70ce00dfcac4ca7
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998869165
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/eval/ArrayEvaluatorTest.java:
##
@@ -54,12 +53,12 @@ public void arrayLongSortAscTest() throws IOException {
result = evaluator.evaluate(new Tuple(values));
-Assert.assertTrue(result instanceof List);
+assertTrue(result instanceof List);
-Assert.assertEquals(3, ((List) result).size());
Review Comment:
Fixed in 3e46998f859ac463dd68c75f35fe177fba1323a2
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998867130
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/graph/GraphExpressionTest.java:
##
@@ -1075,15 +1075,15 @@ public void testGatherNodesFriendsStream() throws
Exception {
tuples = getTuples(stream);
tuples.sort(new FieldComparator("node", ComparatorOrder.ASCENDING));
-assertTrue(tuples.size() == 4);
-assertTrue(tuples.get(0).getString("node").equals("bill"));
-assertTrue(tuples.get(0).getLong("level").equals(0L));
-assertTrue(tuples.get(1).getString("node").equals("jim"));
-assertTrue(tuples.get(1).getLong("level").equals(1L));
-assertTrue(tuples.get(2).getString("node").equals("max"));
-assertTrue(tuples.get(2).getLong("level").equals(1L));
-assertTrue(tuples.get(3).getString("node").equals("sam"));
-assertTrue(tuples.get(3).getLong("level").equals(1L));
+assertEquals(4, tuples.size());
+assertEquals("bill", tuples.get(0).getString("node"));
+assertEquals(0L, (long) tuples.get(0).getLong("level"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/MathExpressionTest.java:
##
@@ -1719,10 +1719,10 @@ public void testMatrix() throws Exception {
assertEquals(features.get(0).get(0), "col3");
assertEquals(features.get(1).get(0), "col1");
-assertTrue(tuples.get(0).getLong("f") == 2);
-assertTrue(tuples.get(0).getLong("g") == 3);
-assertTrue(tuples.get(0).getLong("h") == 1);
-assertTrue(tuples.get(0).getLong("i") == 2);
+assertEquals(2, (long) tuples.get(0).getLong("f"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998866952
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -2177,43 +2176,43 @@ public void testTimeSeriesGroupingFacet() throws
Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 6);
+assertEquals(6, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getLong("month_i") == 11);
-assert (tuple.getLong("day_i") == 8);
-assert (tuple.getDouble("EXPR$3") == 42); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -2308,43 +2308,43 @@ public void testParallelTimeSeriesGrouping() throws
Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 6);
+assertEquals(6, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getLong("month_i") == 11);
-assert (tuple.getLong("day_i") == 8);
-assert (tuple.getDouble("EXPR$3") == 42); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998866826
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -425,22 +424,22 @@ public void testBasicSelect() throws Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 3);
+assertEquals(3, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("myId") == 3);
-assert (tuple.getLong("myInt") == 20);
-assert (tuple.get("myString").equals("a"));
+assertEquals(3, (long) tuple.getLong("myId"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -1915,17 +1914,17 @@ public void testTimeSeriesGrouping() throws Exception {
List tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 2);
+assertEquals(2, tuples.size());
Tuple tuple;
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getDouble("EXPR$1") == 66); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
+assertEquals(66, tuple.getDouble("EXPR$1"), 0.0); // sum(item_i)
tuple = tuples.get(1);
-assert (tuple.getLong("year_i") == 2014);
-assert (tuple.getDouble("EXPR$1") == 7); // sum(item_i)
+assertEquals(2014, (long) tuple.getLong("year_i"));
Review Comment:
Hmmm so `tuple.getLong` returns a `Long` because it also returns `null`
sometimes. Changing to `long` can't be done for `tuple.getLong` since then
`null` can't be returned. `3L` is still a `long` and can't be compared with
`Long` apparently. I could change it to
```
assertEquals(Long.valueOf(3), tuple.getLong("myId"))
```
but that seems worse.
I don't have any other ideas right now :/
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998865282
##
solr/core/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java:
##
@@ -627,8 +627,8 @@ public void testThresholdTokenFrequency() throws Exception {
NamedList values = rsp.getValues();
NamedList spellCheck = (NamedList) values.get("spellcheck");
NamedList suggestions = (NamedList) spellCheck.get("suggestions");
-assertTrue(suggestions.get("suggestion") == null);
-assertTrue((Boolean) spellCheck.get("correctlySpelled") == false);
+assertNull(suggestions.get("suggestion"));
+assertFalse((boolean) (Boolean) spellCheck.get("correctlySpelled"));
Review Comment:
Fixed in c8f5620d11c39effa2edf94bb949c6d2413be6b0
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998865176
##
solr/core/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java:
##
@@ -640,7 +640,7 @@ public void testThresholdTokenFrequency() throws Exception {
values = rsp.getValues();
spellCheck = (NamedList) values.get("spellcheck");
suggestions = (NamedList) spellCheck.get("suggestions");
-assertTrue(suggestions.get("suggestion") == null);
-assertTrue((Boolean) spellCheck.get("correctlySpelled") == false);
+assertNull(suggestions.get("suggestion"));
+assertFalse((boolean) (Boolean) spellCheck.get("correctlySpelled"));
Review Comment:
Fixed in c8f5620d11c39effa2edf94bb949c6d2413be6b0
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16150) Provide correct bound zookeeper interface
[
https://issues.apache.org/jira/browse/SOLR-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619929#comment-17619929
]
ASF subversion and git services commented on SOLR-16150:
Commit a1dbab72bd1b3d0cf7877cdb7291580eb78dbaef in solr's branch
refs/heads/branch_9x from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a1dbab72bd1 ]
SOLR-16150 Provide correct bound zookeeper interface (#802)
Instead of always giving localhost, we can return the interface that ZK
actually listens on.
Co-authored-by: Kevin Risden
> Provide correct bound zookeeper interface
> -
>
> Key: SOLR-16150
> URL: https://issues.apache.org/jira/browse/SOLR-16150
> Project: Solr
> Issue Type: Test
> Components: Integration Tests, Tests
>Reporter: Mike Drob
>Assignee: Kevin Risden
>Priority: Major
> Fix For: main (10.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a lot of places internally where we try to connect to "localhost" and
> end up hitting the ipv6 interface for whatever reason. Is this an OS issue? A
> VPN issue?
> Regardless, the embedded ZK isn't listening on ipv6, so we fail and retry
> (sometimes multiple times). Each retry adds a second to our tests, but should
> be easy to give a more specific address to connect to.
> {noformat}
> 2022-04-11 21:54:54.682 WARN (main-SendThread(localhost:9983)) []
> o.a.z.ClientCnxn Session 0x0 for sever localhost/[0:0:0:0:0:0:0:1]:9983,
> Closing socket connection. Attempting reconnect except it is a
> SessionExpiredException. => java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
> at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:344)
> ~[?:?]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1280) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16150) Provide correct bound zookeeper interface
[
https://issues.apache.org/jira/browse/SOLR-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16150:
Fix Version/s: 9.2
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Provide correct bound zookeeper interface
> -
>
> Key: SOLR-16150
> URL: https://issues.apache.org/jira/browse/SOLR-16150
> Project: Solr
> Issue Type: Test
> Components: Integration Tests, Tests
>Reporter: Mike Drob
>Assignee: Kevin Risden
>Priority: Major
> Fix For: main (10.0), 9.2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a lot of places internally where we try to connect to "localhost" and
> end up hitting the ipv6 interface for whatever reason. Is this an OS issue? A
> VPN issue?
> Regardless, the embedded ZK isn't listening on ipv6, so we fail and retry
> (sometimes multiple times). Each retry adds a second to our tests, but should
> be easy to give a more specific address to connect to.
> {noformat}
> 2022-04-11 21:54:54.682 WARN (main-SendThread(localhost:9983)) []
> o.a.z.ClientCnxn Session 0x0 for sever localhost/[0:0:0:0:0:0:0:1]:9983,
> Closing socket connection. Attempting reconnect except it is a
> SessionExpiredException. => java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
> at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:344)
> ~[?:?]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1280) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
risdenk commented on code in PR #1032:
URL: https://github.com/apache/solr/pull/1032#discussion_r998863051
##
solr/core/src/test/org/apache/solr/cloud/TestSizeLimitedDistributedMap.java:
##
@@ -67,6 +74,58 @@ public void testCleanup() throws Exception {
}
}
+ public void testConcurrentCleanup() throws Exception {
+final Set expectedKeys = new HashSet<>();
+final List deletedItems = new LinkedList<>();
+int numResponsesToStore = TEST_NIGHTLY ? Overseer.NUM_RESPONSES_TO_STORE :
100;
+
+try (SolrZkClient zkClient = new SolrZkClient(zkServer.getZkHost(),
1)) {
+ String path = getAndMakeInitialPath(zkClient);
+ DistributedMap map =
+ new SizeLimitedDistributedMap(
+ zkClient, path, numResponsesToStore, (element) ->
deletedItems.add(element));
+ // fill the map to limit first
+ for (int i = 0; i < numResponsesToStore; i++) {
+map.put("xyz_" + i, new byte[0]);
+ }
+
+ // add more elements concurrently to trigger cleanup
+ final int THREAD_COUNT = Math.min(100, numResponsesToStore);
+ List> callables = new ArrayList<>();
+ for (int i = 0; i < THREAD_COUNT; i++) {
+final String key = "xyz_" + (numResponsesToStore + 1);
+expectedKeys.add(key);
+callables.add(
+() -> {
+ map.put(key, new byte[0]);
+ return null;
+});
+ }
+
+ ExecutorService executorService =
+ ExecutorUtil.newMDCAwareFixedThreadPool(
+ THREAD_COUNT, new
SolrNamedThreadFactory("test-concurrent-cleanup"));
+ List> futures = new ArrayList<>();
+ for (Callable callable : callables) {
+futures.add(executorService.submit(callable));
+ }
+ try {
+for (Future future : futures) {
+ future.get(); // none of them should throw exception
+}
+for (String expectedKey : expectedKeys) {
+ assertTrue(map.contains(expectedKey));
+}
+// there's no guarantees on exactly how many elements will be removed,
but it should at
+// least NOT throw exception
+assertTrue(!deletedItems.isEmpty());
+ } finally {
+executorService.shutdown();
Review Comment:
Specifically `ExecutorUtil#shutdownAndAwaitTermination` or
`ExecutorUtil#shutdownNowAndAwaitTermination`
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
risdenk commented on code in PR #1032:
URL: https://github.com/apache/solr/pull/1032#discussion_r998862676
##
solr/core/src/test/org/apache/solr/cloud/TestSizeLimitedDistributedMap.java:
##
@@ -67,6 +74,58 @@ public void testCleanup() throws Exception {
}
}
+ public void testConcurrentCleanup() throws Exception {
+final Set expectedKeys = new HashSet<>();
+final List deletedItems = new LinkedList<>();
+int numResponsesToStore = TEST_NIGHTLY ? Overseer.NUM_RESPONSES_TO_STORE :
100;
+
+try (SolrZkClient zkClient = new SolrZkClient(zkServer.getZkHost(),
1)) {
+ String path = getAndMakeInitialPath(zkClient);
+ DistributedMap map =
+ new SizeLimitedDistributedMap(
+ zkClient, path, numResponsesToStore, (element) ->
deletedItems.add(element));
+ // fill the map to limit first
+ for (int i = 0; i < numResponsesToStore; i++) {
+map.put("xyz_" + i, new byte[0]);
+ }
+
+ // add more elements concurrently to trigger cleanup
+ final int THREAD_COUNT = Math.min(100, numResponsesToStore);
+ List> callables = new ArrayList<>();
+ for (int i = 0; i < THREAD_COUNT; i++) {
+final String key = "xyz_" + (numResponsesToStore + 1);
+expectedKeys.add(key);
+callables.add(
+() -> {
+ map.put(key, new byte[0]);
+ return null;
+});
+ }
+
+ ExecutorService executorService =
+ ExecutorUtil.newMDCAwareFixedThreadPool(
+ THREAD_COUNT, new
SolrNamedThreadFactory("test-concurrent-cleanup"));
+ List> futures = new ArrayList<>();
+ for (Callable callable : callables) {
+futures.add(executorService.submit(callable));
+ }
+ try {
+for (Future future : futures) {
+ future.get(); // none of them should throw exception
+}
+for (String expectedKey : expectedKeys) {
+ assertTrue(map.contains(expectedKey));
+}
+// there's no guarantees on exactly how many elements will be removed,
but it should at
+// least NOT throw exception
+assertTrue(!deletedItems.isEmpty());
+ } finally {
+executorService.shutdown();
Review Comment:
Use ExecutorUtil to do this. It will handle things nicely.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] patsonluk commented on pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
patsonluk commented on PR #1032: URL: https://github.com/apache/solr/pull/1032#issuecomment-1283256758 @noblepaul Can have a review on this please? 😊 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
sonatype-lift[bot] commented on PR #1032: URL: https://github.com/apache/solr/pull/1032#issuecomment-1283253466 :warning: **312 God Classes** were detected by Lift in this project. [Visit the Lift web console](https://lift.sonatype.com/results/github.com/apache/solr/01GFPV4REF6BRMYYBW4EVPECFJ?tab=technical-debt&utm_source=github.com&utm_campaign=lift-comment&utm_content=apache\%20solr) for more details. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16466) Admin UI - Make it optional to sort list of commandline args
[ https://issues.apache.org/jira/browse/SOLR-16466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619907#comment-17619907 ] Shawn Heisey commented on SOLR-16466: - That screenshot has another little improvement I am looking at, needs its own issue. I add the text "(normal to be at or near 100%)" to the Physical Memory graph. Users tend to get very concerned when they see Physical Memory so heavily used, and in the vast majority of cases, that is not an issue. > Admin UI - Make it optional to sort list of commandline args > > > Key: SOLR-16466 > URL: https://issues.apache.org/jira/browse/SOLR-16466 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > Attachments: image-2022-10-18-17-55-33-446.png, > image-2022-10-18-17-56-36-230.png > > > It is sometimes detrimental to have the list of commandline arguments sorted > in the Admin UI dashboard. One of the things I do whenever I install or > upgrade Solr is to go into the javascript and remove the sort. I would like > to make it optional on the dashboard to sort the arguments. > I do not know how to go about doing this. My HTML/CSS/Javascript skills are > not adequate to accomplish it. It's easy enough to remove ".sort()" from the > javascript to turn it off, but making it optional (unchecking a checkbox and > having that trigger some javascript) is something I would struggle to > implement. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16466) Admin UI - Make it optional to sort list of commandline args
[ https://issues.apache.org/jira/browse/SOLR-16466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619893#comment-17619893 ] Shawn Heisey commented on SOLR-16466: - Yes, that is what I mean. Below is what it looks likeon my little Solr install without being sorted. If you're trying to solve a problem that comes from making changes to the actual scripts as well as modifying solr.in.sh or solr.in.cmd, the order that the arguments are passed can become critical. Sorting them, while it does make it easier to see if a particular option is in use, loses the ability to figure out which option is actually taking effect when it is being set to two different values. Rather than simply remove the sort, I would like both options to be available, and I would be fine with the default being to sort as it is now. I would prefer if the admin UI could remember the choice the user makes, but if that is difficult, don't try. !image-2022-10-18-17-56-36-230.png! > Admin UI - Make it optional to sort list of commandline args > > > Key: SOLR-16466 > URL: https://issues.apache.org/jira/browse/SOLR-16466 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > Attachments: image-2022-10-18-17-55-33-446.png, > image-2022-10-18-17-56-36-230.png > > > It is sometimes detrimental to have the list of commandline arguments sorted > in the Admin UI dashboard. One of the things I do whenever I install or > upgrade Solr is to go into the javascript and remove the sort. I would like > to make it optional on the dashboard to sort the arguments. > I do not know how to go about doing this. My HTML/CSS/Javascript skills are > not adequate to accomplish it. It's easy enough to remove ".sort()" from the > javascript to turn it off, but making it optional (unchecking a checkbox and > having that trigger some javascript) is something I would struggle to > implement. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16466) Admin UI - Make it optional to sort list of commandline args
[ https://issues.apache.org/jira/browse/SOLR-16466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-16466: Attachment: image-2022-10-18-17-56-36-230.png > Admin UI - Make it optional to sort list of commandline args > > > Key: SOLR-16466 > URL: https://issues.apache.org/jira/browse/SOLR-16466 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > Attachments: image-2022-10-18-17-55-33-446.png, > image-2022-10-18-17-56-36-230.png > > > It is sometimes detrimental to have the list of commandline arguments sorted > in the Admin UI dashboard. One of the things I do whenever I install or > upgrade Solr is to go into the javascript and remove the sort. I would like > to make it optional on the dashboard to sort the arguments. > I do not know how to go about doing this. My HTML/CSS/Javascript skills are > not adequate to accomplish it. It's easy enough to remove ".sort()" from the > javascript to turn it off, but making it optional (unchecking a checkbox and > having that trigger some javascript) is something I would struggle to > implement. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16472) Remove redundant state.json update For PRS collection creation
[ https://issues.apache.org/jira/browse/SOLR-16472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated SOLR-16472: -- Description: h2. Description It is found that the existing `CreateCollectionCmd` would update the [`state.json` per new replica|https://github.com/apache/solr/blob/c80cf5b03ac1b1307df65ebe37f6ffdb26611013/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L334]. This potentially creates a lot of unnecessary writes as only the last state.json with all the replicas matters. Take note that this actually is a problem for non PRS collection as well, but probably less problematic for non PRS as even if it does very similar operation per replica by sending the update to OS queue `ccc.offerStateUpdate(Utils.toJSON(props));`, at least OS would use the `ClusterStateUpdater` which uses `ZkStateWriter#enqueueUpdate` that likely batches up state.json update (only writes the latest entry every 2 secs by default) ; while for PRS, we use direct update which each call translates to an actual call to ZK. h2. Proposal We will move the `ZkClient#setData` statement out of the replica loop and only call it once outside was: h2. Description It is found that the existing `CreateCollectionCmd` would update the [`state.json` per new replica|https://github.com/apache/solr/blob/c80cf5b03ac1b1307df65ebe37f6ffdb26611013/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L334]. This potentially creates a lot of unnecessary writes as only the last state.json with all the replicas matters. Take note that this actually is a problem for non PRS collection as well, but probably less problematic for non PRS as even if it does very similar operation per replica by sending the update to OS queue `ccc.offerStateUpdate(Utils.toJSON(props));`, at least OS would use the `ClusterStateUpdater` which uses `ZkStateWriter#enqueueUpdate` that likely batches up state.json update (only writes the latest entry every 2 secs by default) ; while for PRS, we use directly update which each call translates to an actual call to ZK. h2. Proposal We will move the `ZkClient#setData` statement out of the replica loop and only call it once outside > Remove redundant state.json update For PRS collection creation > -- > > Key: SOLR-16472 > URL: https://issues.apache.org/jira/browse/SOLR-16472 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.0 >Reporter: Patson Luk >Priority: Minor > > h2. Description > It is found that the existing `CreateCollectionCmd` would update the > [`state.json` per new > replica|https://github.com/apache/solr/blob/c80cf5b03ac1b1307df65ebe37f6ffdb26611013/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L334]. > This potentially creates a lot of unnecessary writes as only the last > state.json with all the replicas matters. > Take note that this actually is a problem for non PRS collection as well, but > probably less problematic for non PRS as even if it does very similar > operation per replica by sending the update to OS queue > `ccc.offerStateUpdate(Utils.toJSON(props));`, at least OS would use the > `ClusterStateUpdater` which uses `ZkStateWriter#enqueueUpdate` that likely > batches up state.json update (only writes the latest entry every 2 secs by > default) ; while for PRS, we use direct update which each call translates to > an actual call to ZK. > h2. Proposal > We will move the `ZkClient#setData` statement out of the replica loop and > only call it once outside > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-16472) Remove redundant state.json update For PRS collection creation
Patson Luk created SOLR-16472: - Summary: Remove redundant state.json update For PRS collection creation Key: SOLR-16472 URL: https://issues.apache.org/jira/browse/SOLR-16472 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: SolrCloud Affects Versions: 9.0 Reporter: Patson Luk h2. Description It is found that the existing `CreateCollectionCmd` would update the [`state.json` per new replica|https://github.com/apache/solr/blob/c80cf5b03ac1b1307df65ebe37f6ffdb26611013/solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java#L334]. This potentially creates a lot of unnecessary writes as only the last state.json with all the replicas matters. Take note that this actually is a problem for non PRS collection as well, but probably less problematic for non PRS as even if it does very similar operation per replica by sending the update to OS queue `ccc.offerStateUpdate(Utils.toJSON(props));`, at least OS would use the `ClusterStateUpdater` which uses `ZkStateWriter#enqueueUpdate` that likely batches up state.json update (only writes the latest entry every 2 secs by default) ; while for PRS, we use directly update which each call translates to an actual call to ZK. h2. Proposal We will move the `ZkClient#setData` statement out of the replica loop and only call it once outside -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998774152
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -111,7 +108,7 @@ public static void assertVersions(SolrClient client1,
SolrClient client2) throws
Long maxVersionClient2 = getVersion(client2);
if (maxVersionClient1 > 0 && maxVersionClient2 > 0) {
- assertEquals(maxVersionClient1, maxVersionClient2);
+ SolrTestCaseJ4.assertEquals(maxVersionClient1, maxVersionClient2);
Review Comment:
This also goes for a few others (I think ~5 classes) that are test utils
only and seemed weird to make extend `SolrTestCase`.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998772357
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/eval/ArrayEvaluatorTest.java:
##
@@ -54,12 +53,12 @@ public void arrayLongSortAscTest() throws IOException {
result = evaluator.evaluate(new Tuple(values));
-Assert.assertTrue(result instanceof List);
+assertTrue(result instanceof List);
-Assert.assertEquals(3, ((List) result).size());
Review Comment:
I'll take a look
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998772151
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -2308,43 +2308,43 @@ public void testParallelTimeSeriesGrouping() throws
Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 6);
+assertEquals(6, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getLong("month_i") == 11);
-assert (tuple.getLong("day_i") == 8);
-assert (tuple.getDouble("EXPR$3") == 42); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
Review Comment:
I think so - I'll take a look
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/graph/GraphExpressionTest.java:
##
@@ -1075,15 +1075,15 @@ public void testGatherNodesFriendsStream() throws
Exception {
tuples = getTuples(stream);
tuples.sort(new FieldComparator("node", ComparatorOrder.ASCENDING));
-assertTrue(tuples.size() == 4);
-assertTrue(tuples.get(0).getString("node").equals("bill"));
-assertTrue(tuples.get(0).getLong("level").equals(0L));
-assertTrue(tuples.get(1).getString("node").equals("jim"));
-assertTrue(tuples.get(1).getLong("level").equals(1L));
-assertTrue(tuples.get(2).getString("node").equals("max"));
-assertTrue(tuples.get(2).getLong("level").equals(1L));
-assertTrue(tuples.get(3).getString("node").equals("sam"));
-assertTrue(tuples.get(3).getLong("level").equals(1L));
+assertEquals(4, tuples.size());
+assertEquals("bill", tuples.get(0).getString("node"));
+assertEquals(0L, (long) tuples.get(0).getLong("level"));
Review Comment:
I think so - I'll take a look
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/MathExpressionTest.java:
##
@@ -1719,10 +1719,10 @@ public void testMatrix() throws Exception {
assertEquals(features.get(0).get(0), "col3");
assertEquals(features.get(1).get(0), "col1");
-assertTrue(tuples.get(0).getLong("f") == 2);
-assertTrue(tuples.get(0).getLong("g") == 3);
-assertTrue(tuples.get(0).getLong("h") == 1);
-assertTrue(tuples.get(0).getLong("i") == 2);
+assertEquals(2, (long) tuples.get(0).getLong("f"));
Review Comment:
I think so - I'll take a look
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998772021
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -425,22 +424,22 @@ public void testBasicSelect() throws Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 3);
+assertEquals(3, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("myId") == 3);
-assert (tuple.getLong("myInt") == 20);
-assert (tuple.get("myString").equals("a"));
+assertEquals(3, (long) tuple.getLong("myId"));
Review Comment:
I think so - I'll take a look
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -1915,17 +1914,17 @@ public void testTimeSeriesGrouping() throws Exception {
List tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 2);
+assertEquals(2, tuples.size());
Tuple tuple;
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getDouble("EXPR$1") == 66); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
+assertEquals(66, tuple.getDouble("EXPR$1"), 0.0); // sum(item_i)
tuple = tuples.get(1);
-assert (tuple.getLong("year_i") == 2014);
-assert (tuple.getDouble("EXPR$1") == 7); // sum(item_i)
+assertEquals(2014, (long) tuple.getLong("year_i"));
Review Comment:
I think so - I'll take a look
##
solr/modules/sql/src/test/org/apache/solr/handler/sql/TestSQLHandler.java:
##
@@ -2177,43 +2176,43 @@ public void testTimeSeriesGroupingFacet() throws
Exception {
tuples = getTuples(sParams, baseUrl);
-assert (tuples.size() == 6);
+assertEquals(6, tuples.size());
tuple = tuples.get(0);
-assert (tuple.getLong("year_i") == 2015);
-assert (tuple.getLong("month_i") == 11);
-assert (tuple.getLong("day_i") == 8);
-assert (tuple.getDouble("EXPR$3") == 42); // sum(item_i)
+assertEquals(2015, (long) tuple.getLong("year_i"));
Review Comment:
I think so - I'll take a look
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998771803
##
solr/core/src/test/org/apache/solr/handler/TestSampleDocumentsLoader.java:
##
@@ -63,7 +58,7 @@ public void testJson() throws Exception {
@Test
public void testCsv() throws Exception {
ModifiableSolrParams params = new ModifiableSolrParams();
-params.set(CSV_MULTI_VALUE_DELIM_PARAM, "\\|");
+params.set(DefaultSampleDocumentsLoader.CSV_MULTI_VALUE_DELIM_PARAM,
"\\|");
Review Comment:
yea this was me just removing the static imports. It makes it clear that
this isn't a constant in the `TestSampleDocumentsLoader` class to me. Otherwise
it looks like a field in the class.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998771457
##
solr/solrj/src/test/org/apache/solr/client/solrj/request/SchemaTest.java:
##
@@ -869,7 +869,7 @@ public void testCopyFieldWithMaxCharsAccuracy() throws
Exception {
int currentMaxChars = (Integer) currentCopyField.get("maxChars");
MatcherAssert.assertThat(
currentDestFieldName, anyOf(is(equalTo(destFieldName1)),
is(equalTo(destFieldName2;
-assertTrue(maxChars == currentMaxChars);
+assertEquals((int) maxChars, currentMaxChars);
Review Comment:
I'll take a look
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16466) Admin UI - Make it optional to sort list of commandline args
[ https://issues.apache.org/jira/browse/SOLR-16466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619814#comment-17619814 ] Eric Pugh commented on SOLR-16466: -- Is this what you mean [~elyograg] ? I could see a toggle that you click "Sort Alphabetically" that is the original, and "Sort Original" that comes from how they are confgured? !image-2022-10-18-17-55-33-446.png! > Admin UI - Make it optional to sort list of commandline args > > > Key: SOLR-16466 > URL: https://issues.apache.org/jira/browse/SOLR-16466 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > Attachments: image-2022-10-18-17-55-33-446.png > > > It is sometimes detrimental to have the list of commandline arguments sorted > in the Admin UI dashboard. One of the things I do whenever I install or > upgrade Solr is to go into the javascript and remove the sort. I would like > to make it optional on the dashboard to sort the arguments. > I do not know how to go about doing this. My HTML/CSS/Javascript skills are > not adequate to accomplish it. It's easy enough to remove ".sort()" from the > javascript to turn it off, but making it optional (unchecking a checkbox and > having that trigger some javascript) is something I would struggle to > implement. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16466) Admin UI - Make it optional to sort list of commandline args
[ https://issues.apache.org/jira/browse/SOLR-16466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-16466: - Attachment: image-2022-10-18-17-55-33-446.png > Admin UI - Make it optional to sort list of commandline args > > > Key: SOLR-16466 > URL: https://issues.apache.org/jira/browse/SOLR-16466 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 9.0 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > Attachments: image-2022-10-18-17-55-33-446.png > > > It is sometimes detrimental to have the list of commandline arguments sorted > in the Admin UI dashboard. One of the things I do whenever I install or > upgrade Solr is to go into the javascript and remove the sort. I would like > to make it optional on the dashboard to sort the arguments. > I do not know how to go about doing this. My HTML/CSS/Javascript skills are > not adequate to accomplish it. It's easy enough to remove ".sort()" from the > javascript to turn it off, but making it optional (unchecking a checkbox and > having that trigger some javascript) is something I would struggle to > implement. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16364) Evaluate using a shared Inspection Profile in IntelliJ
[ https://issues.apache.org/jira/browse/SOLR-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-16364. -- Resolution: Abandoned Abandoning this idea because it appears we have a plethora of other tools to help us monitor code quality, and that this is also very intellj specific... Plus, my underlying reason for wanting this, the thousands of warnings, well, they are being chipped away! > Evaluate using a shared Inspection Profile in IntelliJ > -- > > Key: SOLR-16364 > URL: https://issues.apache.org/jira/browse/SOLR-16364 > Project: Solr > Issue Type: Sub-task > Components: Build >Affects Versions: main (10.0) >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Attachments: Gradle Default for Java test code.png, Screenshot at Aug > 31 12-22-03.png, Screenshot at Aug 31 13-03-25.png > > > IntelliJ uses a "Inspection Profile" to decide what to flag as problems. It > would be nice if we as a community used a shared one that reflected what we > think are problems and what are not... Similiar thinking as our use of code > style tooling or some of the decisions we've made around forbidden api's. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh closed pull request #991: Introduce a project inspection profile based on David Smiley's profile he uses.
epugh closed pull request #991: Introduce a project inspection profile based on David Smiley's profile he uses. URL: https://github.com/apache/solr/pull/991 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #991: Introduce a project inspection profile based on David Smiley's profile he uses.
epugh commented on PR #991: URL: https://github.com/apache/solr/pull/991#issuecomment-1283033347 i am somewhat leaning your way... I thought this would be really easy to do... Also, I think the underlying desire I had, which was to eliminate all the old code issues, may actually go away due to the work that you and others have done to clean up the source...I was thinking we would have to accept that the default config was never going to work for us due to all the warnings, and we'd have to ignore them. HOwever, now I'm feeling more excited that we could have minimal code quality issues, as flagged by the plain vanilla standard IntelliJ profile!I'm going to close this until there is a more compelling reason! -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on PR #953: URL: https://github.com/apache/solr/pull/953#issuecomment-1283004310 So @mkhludnev and @HoustonPutman thanks for the reviews. There are some benefits to using `SolrTestCase` as the base for these tests. The randomization of Locale, thread leak checks, and more. These checks are beneficial that we get some nice things without doing any extra work. SolrTestCase extends from Assert eventually so its easy to get all the static methods from there. The question about SolrTestCase vs TestCase vs SolrTestCase4j - I used SolrTestCase if there was no existing import for one and SolrTestCase4j if there was already an existing import using SolrTestCase4j. My theory being that `SolrTestCase4j` already was needed so extend from it. I didn't see any downside to doing this. Regarding the casting - I'll take a look and see what is possible here. Regarding the assert methods using `SolrTestCase4j` or `SolrTestCase` - I was trying to avoid static imports but can be swayed if this is important to not do this. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998708897
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -202,15 +199,16 @@ public static NamedList getDetails(SolrClient s)
throws Exception {
@SuppressWarnings("unchecked")
NamedList details = (NamedList) res.get("details");
-assertNotNull("null details", details);
+SolrTestCaseJ4.assertNotNull("null details", details);
return details;
}
public static void assertReplicationResponseSucceeded(NamedList response)
{
-assertNotNull("null response from server", response);
-assertNotNull("Expected replication response to have 'status' field",
response.get("status"));
-assertEquals("OK", response.get("status"));
+SolrTestCaseJ4.assertNotNull("null response from server", response);
Review Comment:
I'll take a look to see what can be done here.
##
solr/core/src/test/org/apache/solr/update/SoftAutoCommitTest.java:
##
@@ -637,6 +636,6 @@ public void clear() {
}
public void assertSaneOffers() {
-assertEquals("Failure of MockEventListener" + fail.toString(), 0,
fail.length());
+SolrTestCaseJ4.assertEquals("Failure of MockEventListener" +
fail.toString(), 0, fail.length());
Review Comment:
because this is in `MockEventListener` and doesn't extend anything with that
method. This uses `SolrTestCaseJ4` since it is the correct class in the chain
that was already imported. `SolrTestCaseJ4` ends up inheriting from Assert
anyway.
##
solr/core/src/test/org/apache/solr/handler/V2ClusterAPIMappingTest.java:
##
@@ -48,7 +47,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 API mappings found in {@link ClusterAPI} */
-public class V2ClusterAPIMappingTest {
+public class V2ClusterAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
`import static org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito;` was
there so this class was already relying on stuff from SolrTestCaseJ4 so used
SolrTestCaseJ4.
##
solr/core/src/test/org/apache/solr/response/TestRetrieveFieldsOptimizer.java:
##
@@ -616,7 +615,7 @@ List getValsForField() {
break;
default:
-fail("Found no case for field " + name + " type " + type);
+SolrTestCaseJ4.fail("Found no case for field " + name + " type " +
type);
Review Comment:
because this is in `RetrieveField` and doesn't extend anything with that
method. This uses `SolrTestCaseJ4` since it is the correct class in the chain
that was already imported. `SolrTestCaseJ4` ends up inheriting from Assert
anyway.
##
solr/core/src/test/org/apache/solr/handler/V2UpdateAPIMappingTest.java:
##
@@ -39,7 +38,7 @@
import org.junit.Test;
/** Unit tests for the v2 to v1 mapping logic in {@link UpdateAPI} */
-public class V2UpdateAPIMappingTest {
+public class V2UpdateAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
`import static org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito;` was
there so this class was already relying on stuff from SolrTestCaseJ4 so used
SolrTestCaseJ4.
##
solr/core/src/test/org/apache/solr/handler/admin/api/V2NodeAPIMappingTest.java:
##
@@ -55,7 +53,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 mapping for /node/ APIs. */
-public class V2NodeAPIMappingTest {
+public class V2NodeAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
`import static org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito;` was
there so this class was already relying on stuff from SolrTestCaseJ4 so used
SolrTestCaseJ4.
##
solr/core/src/test/org/apache/solr/parser/SolrQueryParserBaseTest.java:
##
@@ -26,19 +24,17 @@
import java.util.List;
import org.apache.lucene.queryparser.charstream.CharStream;
import org.apache.lucene.search.Query;
+import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.common.SolrException;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.schema.IndexSchema;
import org.apache.solr.search.QParser;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
-import org.junit.runner.RunWith;
-import org.mockito.Mock;
-import org.mockito.junit.MockitoJUnitRunner;
+import org.mockito.Mockito;
-@RunWith(MockitoJUnitRunner.class)
-public class SolrQueryParserBaseTest {
+public class SolrQueryParserBaseTest extends SolrTestCaseJ4 {
Review Comment:
`import static org.apache.solr.SolrTestCaseJ4.assumeWorkingMockito;` was
there so this class was already relying on stuff from SolrTestCaseJ4 so used
SolrTestCaseJ4.
the `super.setUp()` is checked by Lucene to ensure that things are properly
inherited if overrode.
--
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.
To unsub
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998704313
##
solr/core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java:
##
@@ -71,7 +66,8 @@ public static void beforeClass() {
}
@Before
- public void setUp() {
+ public void setUp() throws Exception {
+super.setUp();
Review Comment:
lucene checks this. and protects against future use of anything from ancestor
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998703961
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -111,7 +108,7 @@ public static void assertVersions(SolrClient client1,
SolrClient client2) throws
Long maxVersionClient2 = getVersion(client2);
if (maxVersionClient1 > 0 && maxVersionClient2 > 0) {
- assertEquals(maxVersionClient1, maxVersionClient2);
+ SolrTestCaseJ4.assertEquals(maxVersionClient1, maxVersionClient2);
Review Comment:
its a test helper. no real tests so seemed weird
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998703160
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/expr/InjectionDefenseTest.java:
##
@@ -17,12 +17,10 @@
package org.apache.solr.client.solrj.io.stream.expr;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertNotNull;
-
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
-public class InjectionDefenseTest {
+public class InjectionDefenseTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/eval/TemporalEvaluatorsTest.java:
##
@@ -54,7 +52,7 @@
import org.junit.Test;
/** Tests numeric Date/Time stream evaluators */
-public class TemporalEvaluatorsTest {
+public class TemporalEvaluatorsTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/eval/ConversionEvaluatorsTest.java:
##
@@ -32,7 +30,7 @@
import org.junit.Test;
/** Test ConversionEvaluators */
-public class ConversionEvaluatorsTest {
+public class ConversionEvaluatorsTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
HoustonPutman commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998493044
##
solr/core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java:
##
@@ -71,7 +66,8 @@ public static void beforeClass() {
}
@Before
- public void setUp() {
+ public void setUp() throws Exception {
+super.setUp();
Review Comment:
Is this necessary if it isn't using anything from the parent class?
##
solr/core/src/test/org/apache/solr/handler/V2UpdateAPIMappingTest.java:
##
@@ -39,7 +38,7 @@
import org.junit.Test;
/** Unit tests for the v2 to v1 mapping logic in {@link UpdateAPI} */
-public class V2UpdateAPIMappingTest {
+public class V2UpdateAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
Why not `SolrTestCase`?
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -111,7 +108,7 @@ public static void assertVersions(SolrClient client1,
SolrClient client2) throws
Long maxVersionClient2 = getVersion(client2);
if (maxVersionClient1 > 0 && maxVersionClient2 > 0) {
- assertEquals(maxVersionClient1, maxVersionClient2);
+ SolrTestCaseJ4.assertEquals(maxVersionClient1, maxVersionClient2);
Review Comment:
Why not just extend `SolrTestCase` like the other files?
##
solr/core/src/test/org/apache/solr/handler/V2ClusterAPIMappingTest.java:
##
@@ -48,7 +47,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 API mappings found in {@link ClusterAPI} */
-public class V2ClusterAPIMappingTest {
+public class V2ClusterAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
Why not `SolrTestCase`?
##
solr/core/src/test/org/apache/solr/handler/admin/api/V2NodeAPIMappingTest.java:
##
@@ -55,7 +53,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 mapping for /node/ APIs. */
-public class V2NodeAPIMappingTest {
+public class V2NodeAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
`SolrTestCase`
##
solr/core/src/test/org/apache/solr/parser/SolrQueryParserBaseTest.java:
##
@@ -26,19 +24,17 @@
import java.util.List;
import org.apache.lucene.queryparser.charstream.CharStream;
import org.apache.lucene.search.Query;
+import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.common.SolrException;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.schema.IndexSchema;
import org.apache.solr.search.QParser;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
-import org.junit.runner.RunWith;
-import org.mockito.Mock;
-import org.mockito.junit.MockitoJUnitRunner;
+import org.mockito.Mockito;
-@RunWith(MockitoJUnitRunner.class)
-public class SolrQueryParserBaseTest {
+public class SolrQueryParserBaseTest extends SolrTestCaseJ4 {
Review Comment:
Can this be `SolrTestCase`? Not sure why we need to do `super.setup()`
below...
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998702196
##
solr/solrj/src/test/org/apache/solr/common/util/URLUtilTest.java:
##
@@ -16,13 +16,10 @@
*/
package org.apache.solr.common.util;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertFalse;
-import static org.junit.Assert.assertTrue;
-
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
-public class URLUtilTest {
+public class URLUtilTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/request/TestUpdateRequest.java:
##
@@ -17,56 +17,55 @@
package org.apache.solr.client.solrj.request;
import java.util.Arrays;
+import org.apache.solr.SolrTestCase;
import org.apache.solr.common.SolrInputDocument;
-import org.junit.Assert;
import org.junit.Test;
-public class TestUpdateRequest {
+public class TestUpdateRequest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998701974
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/LBHttpSolrClientTest.java:
##
@@ -16,17 +16,15 @@
*/
package org.apache.solr.client.solrj.impl;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertNull;
-
import java.io.IOException;
import org.apache.http.impl.client.CloseableHttpClient;
+import org.apache.solr.SolrTestCase;
import org.apache.solr.client.solrj.ResponseParser;
import org.apache.solr.common.params.ModifiableSolrParams;
import org.junit.Test;
/** Test the LBHttpSolrClient. */
-public class LBHttpSolrClientTest {
+public class LBHttpSolrClientTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/LBSolrClientTest.java:
##
@@ -17,22 +17,19 @@
package org.apache.solr.client.solrj.impl;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertFalse;
-import static org.junit.Assert.assertTrue;
-
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import org.apache.lucene.tests.util.LuceneTestCase;
+import org.apache.solr.SolrTestCase;
import org.apache.solr.client.solrj.SolrServerException;
import org.apache.solr.client.solrj.request.QueryRequest;
import org.apache.solr.common.params.CommonParams;
import org.apache.solr.common.params.ModifiableSolrParams;
import org.junit.Test;
-public class LBSolrClientTest {
+public class LBSolrClientTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/SolrPortAwareCookieSpecTest.java:
##
@@ -21,11 +21,10 @@
import org.apache.http.cookie.MalformedCookieException;
import org.apache.http.impl.cookie.BasicClientCookie;
import org.apache.solr.SolrTestCaseJ4;
-import org.junit.Assert;
import org.junit.Test;
// Test cases imported from TestNetscapeCookieAttribHandlers of HttpClient
project
-public class SolrPortAwareCookieSpecTest {
+public class SolrPortAwareCookieSpecTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998701805
##
solr/prometheus-exporter/src/test/org/apache/solr/prometheus/collector/MetricSamplesTest.java:
##
@@ -27,9 +25,10 @@
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
-public class MetricSamplesTest {
+public class MetricSamplesTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/prometheus-exporter/src/test/org/apache/solr/prometheus/exporter/MetricsQueryTemplateTest.java:
##
@@ -36,7 +33,7 @@
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
-public class MetricsQueryTemplateTest {
+public class MetricsQueryTemplateTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/LBHttp2SolrClientTest.java:
##
@@ -16,19 +16,16 @@
*/
package org.apache.solr.client.solrj.impl;
-import static org.junit.Assert.assertArrayEquals;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertNull;
-
import java.io.IOException;
import java.util.HashSet;
import java.util.Set;
+import org.apache.solr.SolrTestCase;
import org.apache.solr.client.solrj.ResponseParser;
import org.apache.solr.client.solrj.request.RequestWriter;
import org.junit.Test;
/** Test the LBHttp2SolrClient. */
-public class LBHttp2SolrClientTest {
+public class LBHttp2SolrClientTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998701533
##
solr/modules/ltr/src/test/org/apache/solr/ltr/norm/TestMinMaxNormalizer.java:
##
@@ -16,17 +16,14 @@
*/
package org.apache.solr.ltr.norm;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertTrue;
-
import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;
import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.core.SolrResourceLoader;
import org.junit.Test;
-public class TestMinMaxNormalizer {
+public class TestMinMaxNormalizer extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/modules/ltr/src/test/org/apache/solr/ltr/norm/TestStandardNormalizer.java:
##
@@ -16,17 +16,14 @@
*/
package org.apache.solr.ltr.norm;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertTrue;
-
import java.nio.file.Paths;
import java.util.HashMap;
import java.util.Map;
import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.core.SolrResourceLoader;
import org.junit.Test;
-public class TestStandardNormalizer {
+public class TestStandardNormalizer extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998700173
##
solr/modules/langid/src/test/org/apache/solr/update/processor/SolrInputDocumentReaderTest.java:
##
@@ -16,21 +16,19 @@
*/
package org.apache.solr.update.processor;
-import static org.junit.Assert.assertArrayEquals;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertTrue;
-
import java.util.Arrays;
+import org.apache.solr.SolrTestCase;
import org.apache.solr.common.SolrInputDocument;
import org.junit.Before;
import org.junit.Test;
-public class SolrInputDocumentReaderTest {
+public class SolrInputDocumentReaderTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/modules/analytics/src/test/org/apache/solr/analytics/legacy/facet/LegacyFieldFacetCloudTest.java:
##
@@ -442,48 +440,48 @@ public void sumTest() throws Exception {
String responseStr = response.toString();
// Int Date
-Collection intDate =
+ArrayList intDate =
Review Comment:
Probably, but the method actually returns an ArrayList itself. I didn't
change the method response. The reason it can't be a collection is that is
ambiguous when comparing assertEquals - errorprone catches this.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998699376
##
solr/core/src/test/org/apache/solr/update/processor/SkipExistingDocumentsProcessorFactoryTest.java:
##
@@ -38,7 +36,7 @@
import org.junit.Test;
import org.mockito.Mockito;
-public class SkipExistingDocumentsProcessorFactoryTest {
+public class SkipExistingDocumentsProcessorFactoryTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/util/SolrCliUptimeTest.java:
##
@@ -16,11 +16,10 @@
*/
package org.apache.solr.util;
-import static org.junit.Assert.assertEquals;
-
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
-public class SolrCliUptimeTest {
+public class SolrCliUptimeTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/util/hll/NumberUtilTest.java:
##
@@ -16,13 +16,11 @@
*/
package org.apache.solr.util.hll;
-import static org.junit.Assert.assertTrue;
-
-import java.util.Arrays;
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
/** Tests {@link NumberUtil} */
-public class NumberUtilTest {
+public class NumberUtilTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998699192
##
solr/core/src/test/org/apache/solr/parser/SolrQueryParserBaseTest.java:
##
@@ -26,19 +24,17 @@
import java.util.List;
import org.apache.lucene.queryparser.charstream.CharStream;
import org.apache.lucene.search.Query;
+import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.common.SolrException;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.schema.IndexSchema;
import org.apache.solr.search.QParser;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
-import org.junit.runner.RunWith;
-import org.mockito.Mock;
-import org.mockito.junit.MockitoJUnitRunner;
+import org.mockito.Mockito;
-@RunWith(MockitoJUnitRunner.class)
-public class SolrQueryParserBaseTest {
+public class SolrQueryParserBaseTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
This is still using mocks just instead of the MockitoJUnitRunner uses the
Lucene runner. This also matches all other Mockito uses in the Solr project -
this is the ONLY class using MockitoJUnitRunner
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998698747
##
solr/core/src/test/org/apache/solr/metrics/DelegateRegistryTimerTest.java:
##
@@ -17,18 +17,16 @@
package org.apache.solr.metrics;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertTrue;
-
import com.codahale.metrics.Clock;
import com.codahale.metrics.MetricRegistry;
import com.codahale.metrics.Timer;
import java.time.Duration;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
-public class DelegateRegistryTimerTest {
+public class DelegateRegistryTimerTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998698569
##
solr/core/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java:
##
@@ -627,8 +627,8 @@ public void testThresholdTokenFrequency() throws Exception {
NamedList values = rsp.getValues();
NamedList spellCheck = (NamedList) values.get("spellcheck");
NamedList suggestions = (NamedList) spellCheck.get("suggestions");
-assertTrue(suggestions.get("suggestion") == null);
-assertTrue((Boolean) spellCheck.get("correctlySpelled") == false);
+assertNull(suggestions.get("suggestion"));
+assertFalse((boolean) (Boolean) spellCheck.get("correctlySpelled"));
Review Comment:
agreed will fix.
##
solr/core/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java:
##
@@ -640,7 +640,7 @@ public void testThresholdTokenFrequency() throws Exception {
values = rsp.getValues();
spellCheck = (NamedList) values.get("spellcheck");
suggestions = (NamedList) spellCheck.get("suggestions");
-assertTrue(suggestions.get("suggestion") == null);
-assertTrue((Boolean) spellCheck.get("correctlySpelled") == false);
+assertNull(suggestions.get("suggestion"));
+assertFalse((boolean) (Boolean) spellCheck.get("correctlySpelled"));
Review Comment:
agreed will fix.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998698318
##
solr/core/src/test/org/apache/solr/handler/V2ClusterAPIMappingTest.java:
##
@@ -48,7 +47,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 API mappings found in {@link ClusterAPI} */
-public class V2ClusterAPIMappingTest {
+public class V2ClusterAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/handler/V2UpdateAPIMappingTest.java:
##
@@ -39,7 +38,7 @@
import org.junit.Test;
/** Unit tests for the v2 to v1 mapping logic in {@link UpdateAPI} */
-public class V2UpdateAPIMappingTest {
+public class V2UpdateAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/handler/admin/SolrEnvironmentTest.java:
##
@@ -17,13 +17,11 @@
package org.apache.solr.handler.admin;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertNull;
-
+import org.apache.solr.SolrTestCase;
import org.apache.solr.common.SolrException;
import org.junit.Test;
-public class SolrEnvironmentTest {
+public class SolrEnvironmentTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/handler/admin/api/V2NodeAPIMappingTest.java:
##
@@ -55,7 +53,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 mapping for /node/ APIs. */
-public class V2NodeAPIMappingTest {
+public class V2NodeAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998697932
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -111,7 +108,7 @@ public static void assertVersions(SolrClient client1,
SolrClient client2) throws
Long maxVersionClient2 = getVersion(client2);
if (maxVersionClient1 > 0 && maxVersionClient2 > 0) {
- assertEquals(maxVersionClient1, maxVersionClient2);
+ SolrTestCaseJ4.assertEquals(maxVersionClient1, maxVersionClient2);
Review Comment:
This is the JUnit one technically. It avoids the extra import and shows it
comes through the underlying class heirarchy. LuceneTestCase extends Assert
##
solr/core/src/test/org/apache/solr/handler/TestSampleDocumentsLoader.java:
##
@@ -40,7 +35,7 @@
import org.junit.Before;
import org.junit.Test;
-public class TestSampleDocumentsLoader {
+public class TestSampleDocumentsLoader extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
risdenk commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998697319
##
solr/core/src/test/org/apache/solr/core/backup/BackupFilePathsTest.java:
##
@@ -16,16 +16,13 @@
*/
package org.apache.solr.core.backup;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertFalse;
-import static org.junit.Assert.assertTrue;
-
import java.util.List;
import java.util.Optional;
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
/** Unit tests for {@link BackupFilePaths} */
-public class BackupFilePathsTest {
+public class BackupFilePathsTest extends SolrTestCase {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
##
solr/core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java:
##
@@ -44,7 +39,7 @@
import org.junit.BeforeClass;
import org.junit.Test;
-public class BlobRepositoryMockingTest {
+public class BlobRepositoryMockingTest extends SolrTestCaseJ4 {
Review Comment:
Get all the benefits of the underlying randomization and thread leak checks
from Lucene. This ensures that all these tests have a common base. There are no
real downsides to doing this either.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] mkhludnev commented on a diff in pull request #953: SOLR-16311: Simplify assert statement
mkhludnev commented on code in PR #953:
URL: https://github.com/apache/solr/pull/953#discussion_r998298633
##
solr/core/src/test/org/apache/solr/core/BlobRepositoryMockingTest.java:
##
@@ -44,7 +39,7 @@
import org.junit.BeforeClass;
import org.junit.Test;
-public class BlobRepositoryMockingTest {
+public class BlobRepositoryMockingTest extends SolrTestCaseJ4 {
Review Comment:
Whu, so? it seems doubtful. I'd rather avoid this change
##
solr/core/src/test/org/apache/solr/core/backup/BackupFilePathsTest.java:
##
@@ -16,16 +16,13 @@
*/
package org.apache.solr.core.backup;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertFalse;
-import static org.junit.Assert.assertTrue;
-
import java.util.List;
import java.util.Optional;
+import org.apache.solr.SolrTestCase;
import org.junit.Test;
/** Unit tests for {@link BackupFilePaths} */
-public class BackupFilePathsTest {
+public class BackupFilePathsTest extends SolrTestCase {
Review Comment:
Still not getting why
##
solr/core/src/test/org/apache/solr/handler/TestSampleDocumentsLoader.java:
##
@@ -40,7 +35,7 @@
import org.junit.Before;
import org.junit.Test;
-public class TestSampleDocumentsLoader {
+public class TestSampleDocumentsLoader extends SolrTestCase {
Review Comment:
disagree
##
solr/core/src/test/org/apache/solr/handler/ReplicationTestHelper.java:
##
@@ -111,7 +108,7 @@ public static void assertVersions(SolrClient client1,
SolrClient client2) throws
Long maxVersionClient2 = getVersion(client2);
if (maxVersionClient1 > 0 && maxVersionClient2 > 0) {
- assertEquals(maxVersionClient1, maxVersionClient2);
+ SolrTestCaseJ4.assertEquals(maxVersionClient1, maxVersionClient2);
Review Comment:
Why not JUnit's one?
##
solr/core/src/test/org/apache/solr/handler/V2ClusterAPIMappingTest.java:
##
@@ -48,7 +47,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 API mappings found in {@link ClusterAPI} */
-public class V2ClusterAPIMappingTest {
+public class V2ClusterAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
again, why?
##
solr/core/src/test/org/apache/solr/handler/V2UpdateAPIMappingTest.java:
##
@@ -39,7 +38,7 @@
import org.junit.Test;
/** Unit tests for the v2 to v1 mapping logic in {@link UpdateAPI} */
-public class V2UpdateAPIMappingTest {
+public class V2UpdateAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
🥱
##
solr/core/src/test/org/apache/solr/handler/admin/api/V2NodeAPIMappingTest.java:
##
@@ -55,7 +53,7 @@
import org.mockito.ArgumentCaptor;
/** Unit tests for the v2 to v1 mapping for /node/ APIs. */
-public class V2NodeAPIMappingTest {
+public class V2NodeAPIMappingTest extends SolrTestCaseJ4 {
Review Comment:
why?
##
solr/core/src/test/org/apache/solr/parser/SolrQueryParserBaseTest.java:
##
@@ -26,19 +24,17 @@
import java.util.List;
import org.apache.lucene.queryparser.charstream.CharStream;
import org.apache.lucene.search.Query;
+import org.apache.solr.SolrTestCaseJ4;
import org.apache.solr.common.SolrException;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.schema.IndexSchema;
import org.apache.solr.search.QParser;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
-import org.junit.runner.RunWith;
-import org.mockito.Mock;
-import org.mockito.junit.MockitoJUnitRunner;
+import org.mockito.Mockito;
-@RunWith(MockitoJUnitRunner.class)
-public class SolrQueryParserBaseTest {
+public class SolrQueryParserBaseTest extends SolrTestCaseJ4 {
Review Comment:
Disagree with ancestor.
Why not @Mock, it seemed fine?
##
solr/core/src/test/org/apache/solr/handler/component/SpellCheckComponentTest.java:
##
@@ -640,7 +640,7 @@ public void testThresholdTokenFrequency() throws Exception {
values = rsp.getValues();
spellCheck = (NamedList) values.get("spellcheck");
suggestions = (NamedList) spellCheck.get("suggestions");
-assertTrue(suggestions.get("suggestion") == null);
-assertTrue((Boolean) spellCheck.get("correctlySpelled") == false);
+assertNull(suggestions.get("suggestion"));
+assertFalse((boolean) (Boolean) spellCheck.get("correctlySpelled"));
Review Comment:
(two) (casts)
##
solr/core/src/test/org/apache/solr/update/SoftAutoCommitTest.java:
##
@@ -637,6 +636,6 @@ public void clear() {
}
public void assertSaneOffers() {
-assertEquals("Failure of MockEventListener" + fail.toString(), 0,
fail.length());
+SolrTestCaseJ4.assertEquals("Failure of MockEventListener" +
fail.toString(), 0, fail.length());
Review Comment:
Why classname is added?
##
solr/core/src/test/org/apache/solr/util/hll/NumberUtilTest.java:
##
@@ -70,65 +68,62 @@ public class NumberUtilTest {
@Test
public void testLog2
[jira] [Commented] (SOLR-16150) Many tools try to connect to embedded ZK on IPV6
[
https://issues.apache.org/jira/browse/SOLR-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619781#comment-17619781
]
ASF subversion and git services commented on SOLR-16150:
Commit c80cf5b03ac1b1307df65ebe37f6ffdb26611013 in solr's branch
refs/heads/main from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c80cf5b03ac ]
SOLR-16150 Provide correct bound zookeeper interface (#802)
Instead of always giving localhost, we can return the interface that ZK
actually listens on.
Co-authored-by: Kevin Risden
> Many tools try to connect to embedded ZK on IPV6
>
>
> Key: SOLR-16150
> URL: https://issues.apache.org/jira/browse/SOLR-16150
> Project: Solr
> Issue Type: Test
> Components: Integration Tests, Tests
>Reporter: Mike Drob
>Assignee: Kevin Risden
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a lot of places internally where we try to connect to "localhost" and
> end up hitting the ipv6 interface for whatever reason. Is this an OS issue? A
> VPN issue?
> Regardless, the embedded ZK isn't listening on ipv6, so we fail and retry
> (sometimes multiple times). Each retry adds a second to our tests, but should
> be easy to give a more specific address to connect to.
> {noformat}
> 2022-04-11 21:54:54.682 WARN (main-SendThread(localhost:9983)) []
> o.a.z.ClientCnxn Session 0x0 for sever localhost/[0:0:0:0:0:0:0:1]:9983,
> Closing socket connection. Attempting reconnect except it is a
> SessionExpiredException. => java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
> at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:344)
> ~[?:?]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1280) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16150) Provide correct bound zookeeper interface
[
https://issues.apache.org/jira/browse/SOLR-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16150:
Fix Version/s: main (10.0)
> Provide correct bound zookeeper interface
> -
>
> Key: SOLR-16150
> URL: https://issues.apache.org/jira/browse/SOLR-16150
> Project: Solr
> Issue Type: Test
> Components: Integration Tests, Tests
>Reporter: Mike Drob
>Assignee: Kevin Risden
>Priority: Major
> Fix For: main (10.0)
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a lot of places internally where we try to connect to "localhost" and
> end up hitting the ipv6 interface for whatever reason. Is this an OS issue? A
> VPN issue?
> Regardless, the embedded ZK isn't listening on ipv6, so we fail and retry
> (sometimes multiple times). Each retry adds a second to our tests, but should
> be easy to give a more specific address to connect to.
> {noformat}
> 2022-04-11 21:54:54.682 WARN (main-SendThread(localhost:9983)) []
> o.a.z.ClientCnxn Session 0x0 for sever localhost/[0:0:0:0:0:0:0:1]:9983,
> Closing socket connection. Attempting reconnect except it is a
> SessionExpiredException. => java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
> at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:344)
> ~[?:?]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1280) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16150) Provide correct bound zookeeper interface
[
https://issues.apache.org/jira/browse/SOLR-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16150:
Summary: Provide correct bound zookeeper interface (was: Many tools try to
connect to embedded ZK on IPV6)
> Provide correct bound zookeeper interface
> -
>
> Key: SOLR-16150
> URL: https://issues.apache.org/jira/browse/SOLR-16150
> Project: Solr
> Issue Type: Test
> Components: Integration Tests, Tests
>Reporter: Mike Drob
>Assignee: Kevin Risden
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have a lot of places internally where we try to connect to "localhost" and
> end up hitting the ipv6 interface for whatever reason. Is this an OS issue? A
> VPN issue?
> Regardless, the embedded ZK isn't listening on ipv6, so we fail and retry
> (sometimes multiple times). Each retry adds a second to our tests, but should
> be easy to give a more specific address to connect to.
> {noformat}
> 2022-04-11 21:54:54.682 WARN (main-SendThread(localhost:9983)) []
> o.a.z.ClientCnxn Session 0x0 for sever localhost/[0:0:0:0:0:0:0:1]:9983,
> Closing socket connection. Attempting reconnect except it is a
> SessionExpiredException. => java.net.ConnectException: Connection refused
> at java.base/sun.nio.ch.Net.pollConnect(Native Method)
> java.net.ConnectException: Connection refused
> at sun.nio.ch.Net.pollConnect(Native Method) ~[?:?]
> at sun.nio.ch.Net.pollConnectNow(Net.java:672) ~[?:?]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:946) ~[?:?]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:344)
> ~[?:?]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1280) ~[?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk merged pull request #802: SOLR-16150 Provide correct bound zookeeper interface
risdenk merged PR #802: URL: https://github.com/apache/solr/pull/802 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16291) Decay function queries gauss,linear,exponential
[
https://issues.apache.org/jira/browse/SOLR-16291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16291:
Status: Patch Available (was: Open)
> Decay function queries gauss,linear,exponential
> ---
>
> Key: SOLR-16291
> URL: https://issues.apache.org/jira/browse/SOLR-16291
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers, search
>Affects Versions: 9.0
>Reporter: Dan Rosher
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Description
> This is a Solr version of the Decay functions [available in
> Elasticsearch|[https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html|https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html#function-decay]
> ]
> To see how the functions work [see
> here|https://www.desmos.com/calculator/a7i0bwz5ha]
> Decay functions score a document with a function that decays depending on the
> distance of a numeric field value of the document from a user given origin.
> This is similar to a range query, but with smooth edges instead of boxes.
> To use distance scoring on a query that has numerical fields, the user has to
> define an origin and a scale for each field. The origin is needed to define
> the “central point” from which the distance is calculated, and the scale to
> define the rate of decay. The decay function is specified as
>
> {code:java}
> (,scale,origin,offset,decay) for numerical/date
> field
> (,scale,origin_lat,origin_lon,offset,decay) for
> geo fields {code}
> * should be one of 'linear', 'exp', or 'gauss'
> * The must be a NumericFieldType, DatePointField, or
> LatLonPointSpatialField field, NOT multi-valued. e.g.
> linear("location","23km",52.0247, -0.490,"0km",0.5)
> In the above example, the field is a geo_point and origin can be provided in
> geo format. scale and offset must be given with a unit in this case. If your
> field is a date field, you can set scale and offset as days, hours, as with
> DateMath.
>
> e.g. gauss(pdate,"+2DAY+6HOUR","2021-07-20T00:00:00Z","+3DAY",0.5)
>
> pdate: DatePointField "+2DAY+6HOUR": range "2021-07-20T00:00:00Z: origin
> (defaults to NOW) "+3DAY: offset (defaults to zero) 0.5: decay{*}{{*}}
>
> * *origin* The point of origin used for calculating distance. Must be given
> as a number for numeric field, date for date fields and geo point for geo
> fields. Required for geo and numeric field. For date fields the default is
> NOW. Date math (for example NOW-1h) is supported for origin.
> * *scale* Required for all types. Defines the distance from origin + offset
> at which the computed score will equal decay parameter. For geo fields: Can
> be defined as number+unit (1km, 12m,...). Default unit is KM. For date
> fields: Can to be defined as a number+unit ("1h", "10d",…). For numeric
> field: Any number.
> * *offset* If an offset is defined, the decay function will only compute the
> decay function for documents with a distance greater than the defined offset.
> The default is 0.
> * *decay* The decay parameter defines how documents are scored at the
> distance given at scale. If no decay is defined, documents at the distance
> scale will be scored 0.5.
>
> To get a feel for how these function work you can see [here on
> desmos|https://www.desmos.com/calculator/a7i0bwz5ha] . Adjust origin, offset,
> scale and decay to get a feel of how these parameters adjust the equation for
> gauss, exp or linear.
> h3. Supported decay functions
>
> The DECAY_FUNCTION determines the shape of the decay:
> *gauss* Normal decay, computed as:
> score(doc) = exp(- (max(0,|doc.val - origin| - offset)^2)/2sig^2)
> where sig is computed to assure that the score takes the value decay at
> distance scale from origin+-offset
> sig^2 = -scale^2/(2.ln(decay))
> *exp* Exponential decay, computed as:
> score(doc) = exp(lmda . max(0,|doc.val - origin| - offset))
> lmda = ln(decay)/scale
> where again the parameter lambda is computed to assure that the score takes
> the value decay at distance scale from origin+-offset
> *linear* Linear decay, computed as:
> score(doc) = max((s-v)/s,0)
> where: v = max(0,|doc.val - origin| - offset) s = scale(1.0-decay))
> where again the parameter s is computed to assure that the score takes the
> value decay at distance scale from origin+-offset
> In contrast to the normal and exponential decay, this function actually sets
> the score to 0 if the field value exceeds twice the user given scale value.
> For single functions the three decay functions together with their parameters
> can be visualized like this (the field in this example called "age"):
>
[GitHub] [solr] risdenk commented on pull request #1039: SOLR-16427: Evaluate and fix errorprone rules - part 2
risdenk commented on PR #1039: URL: https://github.com/apache/solr/pull/1039#issuecomment-1282941670 I'm going to come back to this after https://github.com/apache/solr/pull/953 is merged. I'm expecting some conflicts based on changes I shouldn't have made in this PR that are made in https://github.com/apache/solr/pull/953 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on a diff in pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
janhoy commented on code in PR #1084: URL: https://github.com/apache/solr/pull/1084#discussion_r998651789 ## solr/docker/templates/Dockerfile.body.template: ## @@ -71,7 +71,7 @@ RUN set -ex; \ RUN set -ex; \ apt-get update; \ -apt-get -y install acl dirmngr lsof procps wget netcat gosu tini jattach; \ +apt-get -y install acl lsof procps wget netcat gosu tini jattach; \ Review Comment: I ran `gradlew testDocker` and all tests passed even without `dirmngr` in the image. So I removed it... -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
HoustonPutman commented on PR #1084: URL: https://github.com/apache/solr/pull/1084#issuecomment-1282927034 Ahh didn't see your last change. But I don't remember off the top of my head. Probably test related, but I'm not confident. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
janhoy commented on PR #1084: URL: https://github.com/apache/solr/pull/1084#issuecomment-1282919985 @HoustonPutman do you recall why we have `dirmngr` in the last RUN command? I think perhaps it is a leftover from when splitting Dockerfile into templates for local and prod. Then you moved the `apt-get` from top of the old Dockerfile to later in the body. I'm going to try to remove it ans run all integration tests... -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
janhoy commented on PR #1084: URL: https://github.com/apache/solr/pull/1084#issuecomment-1282917311 > I think at some point it is very useful to have a tool inside the container, either wget or curl, that lets us debug issues with Solr. Agree very much. Now we have both. `wget` weighs less than 1Mb so not worth the effort to convert all scripts to using cURL I think. But it could be done if one wanted. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[ https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-16454. - Resolution: Duplicate Thanks, here's a active issue: SOLR-16412 > Fixed race condition that trigger error on SizeLimitedDistributedMap … > -- > > Key: SOLR-16454 > URL: https://issues.apache.org/jira/browse/SOLR-16454 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Hitesh Khamesra >Assignee: Ishan Chattopadhyaya >Priority: Major > > here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94] > > We should catch zk exception, as it can lead wired race condirions. > > [~patson] Can you please add the details -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya reassigned SOLR-16412:
---
Assignee: Ishan Chattopadhyaya
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619744#comment-17619744 ] ASF subversion and git services commented on SOLR-16450: Commit 74f09064947f76b9a6d17dcd0290022860ae049d in solr's branch refs/heads/branch_9_1 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=74f09064947 ] SOLR-16450: waitForState to cleanly unregister watches if there is a failure > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Fix For: 9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[ https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619743#comment-17619743 ] Patson Luk commented on SOLR-16454: --- There's already another Jira https://issues.apache.org/jira/browse/SOLR-16412 opened earlier with corresponding PR [https://github.com/apache/solr/pull/1032] Perhaps we can mark this as a duplicate and work on that one instead? Since most of the work was already done there :) > Fixed race condition that trigger error on SizeLimitedDistributedMap … > -- > > Key: SOLR-16454 > URL: https://issues.apache.org/jira/browse/SOLR-16454 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Hitesh Khamesra >Assignee: Ishan Chattopadhyaya >Priority: Major > > here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94] > > We should catch zk exception, as it can lead wired race condirions. > > [~patson] Can you please add the details -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619742#comment-17619742 ] ASF subversion and git services commented on SOLR-16450: Commit 97a7e5df6163452872a516a0b507a9669d1d9ea3 in solr's branch refs/heads/branch_9x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=97a7e5df616 ] SOLR-16450: waitForState to cleanly unregister watches if there is a failure > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Fix For: 9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619741#comment-17619741 ] ASF subversion and git services commented on SOLR-16450: Commit 32e0f68a9bc380905746eec0e7d392594ec132fb in solr's branch refs/heads/main from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=32e0f68a9bc ] SOLR-16450: waitForState to cleanly unregister watches if there is a failure > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Fix For: 9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16471) Impossible to set bind host for Embedded Zookeeper in Solr9 docker image
[ https://issues.apache.org/jira/browse/SOLR-16471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-16471. Resolution: Not A Bug > Impossible to set bind host for Embedded Zookeeper in Solr9 docker image > > > Key: SOLR-16471 > URL: https://issues.apache.org/jira/browse/SOLR-16471 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Henrik >Priority: Major > > Solr 9 switched clientPortAddress in solr/server/solr/zoo.cf from 0.0.0.0 to > 127.0.0.1. When using the solr9 docker images it is impossible to override > this value: > * The file is owned by root and cannot be overwritten > * The ZOOCFG and ZOOCFGDIR environment variables aren't read by > solr/core/src/java/org/apache/solr/cloud/SolrZkServer.java > The only workaround I have found is to duplicate solr's Dockerfile and build > an alternative solr9 docker image. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16471) Impossible to set bind host for Embedded Zookeeper in Solr9 docker image
[
https://issues.apache.org/jira/browse/SOLR-16471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619737#comment-17619737
]
Jan Høydahl commented on SOLR-16471:
Embedded ZK is not for production use, so I don't see the use case. If you want
to hack a multi-node system with embedded zk, you are on your own, but you have
at least to ways to do it:
Place your zoo.cfg of choice in $SOLR_HOME (which is typically a volume mount)
or mount just that one config file when starting solr
{code:java}
docker run -v /path/to/my/zzoo.cfg:/opt/solr/server/solr/zoo.cfg
{code}
> Impossible to set bind host for Embedded Zookeeper in Solr9 docker image
>
>
> Key: SOLR-16471
> URL: https://issues.apache.org/jira/browse/SOLR-16471
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Henrik
>Priority: Major
>
> Solr 9 switched clientPortAddress in solr/server/solr/zoo.cf from 0.0.0.0 to
> 127.0.0.1. When using the solr9 docker images it is impossible to override
> this value:
> * The file is owned by root and cannot be overwritten
> * The ZOOCFG and ZOOCFGDIR environment variables aren't read by
> solr/core/src/java/org/apache/solr/cloud/SolrZkServer.java
> The only workaround I have found is to duplicate solr's Dockerfile and build
> an alternative solr9 docker image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
HoustonPutman commented on PR #1084: URL: https://github.com/apache/solr/pull/1084#issuecomment-1282850908 I think at some point it is very useful to have a tool inside the container, either wget or curl, that lets us debug issues with Solr. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16416) Fix silently failing Overseer Election joinAtHead during testDesignatedOverseerRestarts
[
https://issues.apache.org/jira/browse/SOLR-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619735#comment-17619735
]
Houston Putman commented on SOLR-16416:
---
So looking at the errors, the issue is that the {{JettySolrRunner}} has not
registered the Solr handlers when the OverseerNodePrioritizer decides to send
the overseer request to it. This NodePrioritization stems from an overseer
action sent from the end of {{CoreContainer.load()}}. If we make sure that the
{{JettySolrRunner}} has registered the Solr handlers as soon as this is called,
we should be safe.
I see you've done a lot of work here [~gus], any suggestions?
> Fix silently failing Overseer Election joinAtHead during
> testDesignatedOverseerRestarts
> ---
>
> Key: SOLR-16416
> URL: https://issues.apache.org/jira/browse/SOLR-16416
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Houston Putman
>Priority: Major
>
> OverseerRolesTest.testDesignatedOverseerRestarts has been failing
> consistently (around 2.5% of the time). I think this is because
> LeaderElection.joinElection does not respect the joinAtHead flag, if
> connectionIssues happen while setting the leader election nodes.
> LeaderElection does not use the automatic retryOnConnLoss flags when doing zk
> operations. Instead, it waits for an error to come back, and it handles the
> retry itself. This is fine for the normal case, because it checks if node is
> represented in the leaderElection child nodes, and if so it ignores the
> connection loss. However when doing joinAtHead, if the childNode exists, but
> isn't at the place it should be, then the manual retry should be exercised.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[ https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reassigned SOLR-16454: --- Assignee: Ishan Chattopadhyaya > Fixed race condition that trigger error on SizeLimitedDistributedMap … > -- > > Key: SOLR-16454 > URL: https://issues.apache.org/jira/browse/SOLR-16454 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Hitesh Khamesra >Assignee: Ishan Chattopadhyaya >Priority: Major > > here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94] > > We should catch zk exception, as it can lead wired race condirions. > > [~patson] Can you please add the details -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[ https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619725#comment-17619725 ] Ishan Chattopadhyaya commented on SOLR-16454: - Oh, sorry, my bad. This hasn't been merged at all upstream. Lets open a PR for main and merge there :-) > Fixed race condition that trigger error on SizeLimitedDistributedMap … > -- > > Key: SOLR-16454 > URL: https://issues.apache.org/jira/browse/SOLR-16454 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Hitesh Khamesra >Priority: Major > > here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94] > > We should catch zk exception, as it can lead wired race condirions. > > [~patson] Can you please add the details -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[ https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619724#comment-17619724 ] Ishan Chattopadhyaya commented on SOLR-16454: - This was merged to 8.8 branch, but not the 9x or main. Any reason for that, or just an oversight? [~patson] / [~noblepaul]? > Fixed race condition that trigger error on SizeLimitedDistributedMap … > -- > > Key: SOLR-16454 > URL: https://issues.apache.org/jira/browse/SOLR-16454 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 9.1 >Reporter: Hitesh Khamesra >Priority: Major > > here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94] > > We should catch zk exception, as it can lead wired race condirions. > > [~patson] Can you please add the details -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16454) Fixed race condition that trigger error on SizeLimitedDistributedMap …
[
https://issues.apache.org/jira/browse/SOLR-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619723#comment-17619723
]
Patson Luk commented on SOLR-16454:
---
The details can be found in
[https://github.com/fullstorydev/lucene-solr/pull/142] :)
Quick summary:
The {{org.apache.zookeeper.KeeperException$NoNodeException}} is triggered
sometimes from {{completedMap}} field of type {{SizeLimitedDistributedMap}} in
{{{}OverseerTaskProcessor{}}}, while performing clean up in
[here|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L91-L98]
The reason - multiple threads can enter the same code block and try to delete
the same list of children which the slower threads can delete on child node
that no longer exists.
The proposed solution is to be a bit more forgiving with such exception with a
catch block such as
{{} catch (KeeperException.NoNodeException e) {}}
{{//this could happen if multiple threads try to clean the same map}}
{{}}}
> Fixed race condition that trigger error on SizeLimitedDistributedMap …
> --
>
> Key: SOLR-16454
> URL: https://issues.apache.org/jira/browse/SOLR-16454
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 9.1
>Reporter: Hitesh Khamesra
>Priority: Major
>
> here
> [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L94]
>
> We should catch zk exception, as it can lead wired race condirions.
>
> [~patson] Can you please add the details
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] janhoy commented on a diff in pull request #1084: Remove gpg and wget binaries from image, slimming it down some 8,5Mb
janhoy commented on code in PR #1084:
URL: https://github.com/apache/solr/pull/1084#discussion_r998545994
##
solr/docker/templates/Dockerfile.official.header.template:
##
@@ -85,5 +85,6 @@ RUN set -ex; \
{ command -v gpgconf; gpgconf --kill all || :; }; \
rm -r "$GNUPGHOME"; \
tar -C /opt --extract --preserve-permissions --file
"/opt/solr-$SOLR_VERSION.tgz"; \
- rm "/opt/solr-$SOLR_VERSION.tgz"*;
+ rm "/opt/solr-$SOLR_VERSION.tgz"*; \
+ apt -y remove wget gpg dirmngr && apt -y autoremove;
Review Comment:
No need to remove wget here when we install it again later. Use `apt-get`
instead of `apt` for consistency within the file.
```suggestion
apt-get -y remove gpg dirmngr && apt-get -y autoremove;
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #1085: SOLR-16459: Remove 'invoke' /admin/cores command
gerlowskija commented on PR #1085: URL: https://github.com/apache/solr/pull/1085#issuecomment-1282783600 'check' passes locally. Will merge later this week if there's no additional review. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] chriswininger commented on pull request #1076: Disable lift god classes
chriswininger commented on PR #1076: URL: https://github.com/apache/solr/pull/1076#issuecomment-1282755707 > Well interestingly #1083 doesn't have this god classes message and didn't have `refactor-first` - https://lift.sonatype.com/results/github.com/apache/solr/01GFKERWM0GPHVJMB30065RC6D?tab=tool-results. So maybe it is disabled but some PRs pickup the old changes... Yes, there are some minor issues with how lift handles cases where the toml is different between the source and target branch. This is an existing issue on our board. I suspect once this change is in main/master and the prs are up to date with it you will stop seeing the message. Sorry for the confusion and thanks for reaching out. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on pull request #1085: SOLR-16459: Remove 'invoke' /admin/cores command
gerlowskija commented on PR #1085: URL: https://github.com/apache/solr/pull/1085#issuecomment-1282707791 > Looks good - not sure why all the imports moved around but 🤷 There's something wrong with my IntelliJ settings, but I'm really struggling to figure it out : ( -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-16450: Priority: Blocker (was: Major) > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Fix For: 9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16451) PRS: Don't fetch the prs state, while registering the collection watch
[ https://issues.apache.org/jira/browse/SOLR-16451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619677#comment-17619677 ] ASF subversion and git services commented on SOLR-16451: Commit 52c587211685dfa8a6eb487b5b6861f41f63ac4f in solr's branch refs/heads/branch_9_1 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=solr.git;h=52c58721168 ] SOLR-16451: removed unused method > PRS: Don't fetch the prs state, while registering the collection watch > -- > > Key: SOLR-16451 > URL: https://issues.apache.org/jira/browse/SOLR-16451 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Fix For: 9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Solr fetches prs state inside watch registration here > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1857] > > which is un necessary, and it affects the perf -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Reopened] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reopened SOLR-16450: - [~hiteshkhamesra] Ah, thanks. Re-opening for this fix. CC [~noble.paul]. > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Major > Fix For: 9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija opened a new pull request, #1085: SOLR-16459: Remove 'invoke' /admin/cores command
gerlowskija opened a new pull request, #1085: URL: https://github.com/apache/solr/pull/1085 https://issues.apache.org/jira/browse/SOLR-16459 # Description This internal API command was added in support of a feature (Rule based Replica placement) that has since been deprecated and removed. The API command itself was missed, but can be safely removed without fear of breaking backcompat (as it was internal and undocumented). # Solution API command and associated code have been removed. # Tests N/A; existing tests continue to pass. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-11028) Create a v2 API equivalent for REPLACENODE API
[
https://issues.apache.org/jira/browse/SOLR-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619671#comment-17619671
]
Joshua Ouma commented on SOLR-11028:
{quote}The way this type of v2 API is written, it's mostly "just" a wrapper
that reorganizes the inputs into the format v1 expects, and then calls into the
v1 codepath. So in terms of validating that the (e.g.) REPLACENODE
functionality actually works as its supposed to - I think we can rely on the
existing v1 tests for that. So the main thing that needs tests IMO is the
"reorganizes the inputs into the format v1 expects" bit. Essentially, given a
v2 API with inputs A, B, and C, do those values get modified (if necessary) and
passed on down to the v1 code correctly.{quote}
According to my understanding REPLACENODE API is used for recreating replicas
in one node (the source) on another node(s) (the target). Would a testcase that
lists replicas in the target node be sufficient? I'm not sure if thoughts are
on the right track
> Create a v2 API equivalent for REPLACENODE API
> --
>
> Key: SOLR-11028
> URL: https://issues.apache.org/jira/browse/SOLR-11028
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud, v2 API
>Reporter: Shalin Shekhar Mangar
>Priority: Major
>
> The REPLACENODE API is only implemented as part of the v1 collections API.
> There should be an equivalent call in the v2 paradigm.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16425) NullPointerException in SimplePlacementFactory: PlacementRequest.getCollection() is null
[
https://issues.apache.org/jira/browse/SOLR-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619666#comment-17619666
]
Ishan Chattopadhyaya edited comment on SOLR-16425 at 10/18/22 3:51 PM:
---
I'm resolving this issue for now, since I wasn't able to reproduce it all day
of beasting those two tests. I'm pretty sure they were resolved as part of
SOLR-16440.
was (Author: ichattopadhyaya):
I'm resolving this issue for now, since I wasn't able to reproduce it all day
of beasting those two tests. I'm pretty sure they were resolve as part of
SOLR-16440.
> NullPointerException in SimplePlacementFactory:
> PlacementRequest.getCollection() is null
>
>
> Key: SOLR-16425
> URL: https://issues.apache.org/jira/browse/SOLR-16425
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> I noticed that both {{CloudSolrClientTest.testPerReplicaStateCollection}} and
> {{PerReplicaStatesIntegrationTest.testPerReplicaStateCollection}} have
> similar jenkins failure rates – and are written in a similar way – so i went
> looking at the logs to see if i could spot an obviously copy/pasted test bug.
> What i found is that when these tests fail, they (usually) fail with an NPE
> in SimplePlacementFactory – these NPEs occur during some stream processing,
> and thanks to improvements in recent JDKs, some of the jobs from Uwe's
> machines give us the details on what is null..
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.lambda$computePlacements$1(SimplePlacementFactory.java:88)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> java.util.Comparator.lambda$comparingInt$7b0bb60$1(Comparator.java:494) ~[?:?]
> 2>at
> java.util.Comparator.lambda$thenComparing$36697e65$1(Comparator.java:220)
> ~[?:?]
> 2>at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:?]
> 2>at java.util.TimSort.sort(TimSort.java:220) ~[?:?]
> 2>at java.util.Arrays.sort(Arrays.java:1307) ~[?:?]
> 2>at
> java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:353) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> ~[?:?]
> 2>at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
> 2>at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:91)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:64)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:431)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:552)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:240)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot b
> {code}
> ...slightly diff example i found...
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:107)
> ~[main/:?]
[jira] [Resolved] (SOLR-16425) NullPointerException in SimplePlacementFactory: PlacementRequest.getCollection() is null
[
https://issues.apache.org/jira/browse/SOLR-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya resolved SOLR-16425.
-
Resolution: Cannot Reproduce
I'm resolving this issue for now, since I wasn't able to reproduce it all day
of beasting those two tests. I'm pretty sure they were resolve as part of
SOLR-16440.
> NullPointerException in SimplePlacementFactory:
> PlacementRequest.getCollection() is null
>
>
> Key: SOLR-16425
> URL: https://issues.apache.org/jira/browse/SOLR-16425
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> I noticed that both {{CloudSolrClientTest.testPerReplicaStateCollection}} and
> {{PerReplicaStatesIntegrationTest.testPerReplicaStateCollection}} have
> similar jenkins failure rates – and are written in a similar way – so i went
> looking at the logs to see if i could spot an obviously copy/pasted test bug.
> What i found is that when these tests fail, they (usually) fail with an NPE
> in SimplePlacementFactory – these NPEs occur during some stream processing,
> and thanks to improvements in recent JDKs, some of the jobs from Uwe's
> machines give us the details on what is null..
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.lambda$computePlacements$1(SimplePlacementFactory.java:88)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> java.util.Comparator.lambda$comparingInt$7b0bb60$1(Comparator.java:494) ~[?:?]
> 2>at
> java.util.Comparator.lambda$thenComparing$36697e65$1(Comparator.java:220)
> ~[?:?]
> 2>at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:?]
> 2>at java.util.TimSort.sort(TimSort.java:220) ~[?:?]
> 2>at java.util.Arrays.sort(Arrays.java:1307) ~[?:?]
> 2>at
> java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:353) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> ~[?:?]
> 2>at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
> 2>at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:91)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:64)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:431)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:552)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:240)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot b
> {code}
> ...slightly diff example i found...
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:107)
> ~[main/:?]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:74)
> ~[main/:?]
> 2>at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:432)
> ~[main/:?]
> 2>at
[jira] [Commented] (SOLR-16425) NullPointerException in SimplePlacementFactory: PlacementRequest.getCollection() is null
[
https://issues.apache.org/jira/browse/SOLR-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619664#comment-17619664
]
Ishan Chattopadhyaya commented on SOLR-16425:
-
There were cases where PRS collections were not visible soon enough and
getCollection() calls were failing in another test. We fixed it here:
https://issues.apache.org/jira/browse/SOLR-16440 (14th October)
That also coincides with no longer seeing the failure for this one in Jenkins,
so wondering if that fixed it.
> NullPointerException in SimplePlacementFactory:
> PlacementRequest.getCollection() is null
>
>
> Key: SOLR-16425
> URL: https://issues.apache.org/jira/browse/SOLR-16425
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> I noticed that both {{CloudSolrClientTest.testPerReplicaStateCollection}} and
> {{PerReplicaStatesIntegrationTest.testPerReplicaStateCollection}} have
> similar jenkins failure rates – and are written in a similar way – so i went
> looking at the logs to see if i could spot an obviously copy/pasted test bug.
> What i found is that when these tests fail, they (usually) fail with an NPE
> in SimplePlacementFactory – these NPEs occur during some stream processing,
> and thanks to improvements in recent JDKs, some of the jobs from Uwe's
> machines give us the details on what is null..
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.lambda$computePlacements$1(SimplePlacementFactory.java:88)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> java.util.Comparator.lambda$comparingInt$7b0bb60$1(Comparator.java:494) ~[?:?]
> 2>at
> java.util.Comparator.lambda$thenComparing$36697e65$1(Comparator.java:220)
> ~[?:?]
> 2>at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:?]
> 2>at java.util.TimSort.sort(TimSort.java:220) ~[?:?]
> 2>at java.util.Arrays.sort(Arrays.java:1307) ~[?:?]
> 2>at
> java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:353) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> ~[?:?]
> 2>at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
> 2>at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:91)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:64)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:431)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:552)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:240)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot b
> {code}
> ...slightly diff example i found...
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:107)
> ~[main/:?]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(Plac
[jira] [Commented] (SOLR-16425) NullPointerException in SimplePlacementFactory: PlacementRequest.getCollection() is null
[
https://issues.apache.org/jira/browse/SOLR-16425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619659#comment-17619659
]
Houston Putman commented on SOLR-16425:
---
So I looked into this before I went on break, but was unable to come up with a
culprit.
Basically in {{PlacementPluginAssignStrategy.assign()}}, the following is
called, which turns into the null collection:
{{placementContext.getCluster().getCollection(assignRequest.collectionName)}}.
This call ultimately boils down to a {{ClusterState.getCollectionOrNull()}},
which is obviously returning a null.
The logic for creating the collection in {{CreateCollectionCmd.call()}} is
different between PRS and non-PRS, so I assume that the PRS logic doesn't
necessarily wait until the collection is actually available via the
ClusterState, so sometimes its not available. Do you have some more information
on this [~noblepaul] [~ichattopadhyaya]?
> NullPointerException in SimplePlacementFactory:
> PlacementRequest.getCollection() is null
>
>
> Key: SOLR-16425
> URL: https://issues.apache.org/jira/browse/SOLR-16425
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> I noticed that both {{CloudSolrClientTest.testPerReplicaStateCollection}} and
> {{PerReplicaStatesIntegrationTest.testPerReplicaStateCollection}} have
> similar jenkins failure rates – and are written in a similar way – so i went
> looking at the logs to see if i could spot an obviously copy/pasted test bug.
> What i found is that when these tests fail, they (usually) fail with an NPE
> in SimplePlacementFactory – these NPEs occur during some stream processing,
> and thanks to improvements in recent JDKs, some of the jobs from Uwe's
> machines give us the details on what is null..
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.solr.cluster.SolrCollection.getName()" because the return value
> of "org.apache.solr.cluster.placement.PlacementRequest.getCollection()" is
> null
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.lambda$computePlacements$1(SimplePlacementFactory.java:88)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> java.util.Comparator.lambda$comparingInt$7b0bb60$1(Comparator.java:494) ~[?:?]
> 2>at
> java.util.Comparator.lambda$thenComparing$36697e65$1(Comparator.java:220)
> ~[?:?]
> 2>at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) ~[?:?]
> 2>at java.util.TimSort.sort(TimSort.java:220) ~[?:?]
> 2>at java.util.Arrays.sort(Arrays.java:1307) ~[?:?]
> 2>at
> java.util.stream.SortedOps$SizedRefSortingSink.end(SortedOps.java:353) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:510) ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
> ~[?:?]
> 2>at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
> ~[?:?]
> 2>at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
> 2>at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
> 2>at
> org.apache.solr.cluster.placement.plugins.SimplePlacementFactory$SimplePlacementPlugin.computePlacements(SimplePlacementFactory.java:91)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cluster.placement.impl.PlacementPluginAssignStrategy.assign(PlacementPluginAssignStrategy.java:64)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.Assign$AssignStrategy.assign(Assign.java:431)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.buildReplicaPositions(CreateCollectionCmd.java:552)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot build, details omitted]]
> 2>at
> org.apache.solr.cloud.api.collections.CreateCollectionCmd.call(CreateCollectionCmd.java:240)
> ~[solr-core-10.0.0-SNAPSHOT.jar:10.0.0-SNAPSHOT
> 619a30863170f7a80c435082f2193d7297c5393c [snapshot b
> {code}
> ...slightly diff example i found...
> {code:java}
> 2> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.ap
[jira] [Commented] (SOLR-16459) Deprecate and remove /admin/cores?action=INVOKE
[
https://issues.apache.org/jira/browse/SOLR-16459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619657#comment-17619657
]
Jason Gerlowski commented on SOLR-16459:
I started a thread a week back about this on the dev@ mailing list
("Deprecation/Backcompat for Internal+Undocumented APIs") and got two +1's for
removing the API without concern for backcompat, with no one disagreeing. I'll
take that as lazy consensus and create a PR removing this API.
It'd be awesome if we had our backcompat/deprecation policy written up
somewhere that covered the exceptions and edge cases like this - maybe in our
dev-docs? Maybe I'll consider that as an additional follow-up here.
> Deprecate and remove /admin/cores?action=INVOKE
> ---
>
> Key: SOLR-16459
> URL: https://issues.apache.org/jira/browse/SOLR-16459
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.11.2, 9.1
>Reporter: Jason Gerlowski
>Priority: Major
>
> SOLR-6220 added an "INVOKE" action to CoreAdminHandler as a means to
> implement the old form of rule-based replica placement. The API itself
> iterates over an arbitrary number of class names, instantiating each one and
> calling its "invoke" method via reflection.
> Now that the old form of rule-based replica placement was removed in 9,
> nothing uses this API "action" anymore and it should be removed: both for
> complexity/maintenance reasons, and for potential security issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15749) Create a v2 equivalent of v1 'RENAME'
[
https://issues.apache.org/jira/browse/SOLR-15749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619642#comment-17619642
]
Anakhe Ajayi commented on SOLR-15749:
-
Noted. All recommendations implemented, test passed
[PR|http://github.com/apache/solr/pull/1080] ready for review
> Create a v2 equivalent of v1 'RENAME'
> -
>
> Key: SOLR-15749
> URL: https://issues.apache.org/jira/browse/SOLR-15749
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: V2
>
> Solr's 'RENAME' command under the v1 \{{/solr/admin/collections}} endpoint
> has no v2 equivalent. This should be remedied to inch v2 closer to parity
> with v1 in preparation for eventual v1 deprecation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16467) semver4j fails with some locales
[ https://issues.apache.org/jira/browse/SOLR-16467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619641#comment-17619641 ] ASF subversion and git services commented on SOLR-16467: Commit 54f157577bae693dcf0a7e50add096e083464f19 in solr's branch refs/heads/branch_9x from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=solr.git;h=54f157577ba ] SOLR-16467: Add check for working locale in PackageManagerCLITest > semver4j fails with some locales > > > Key: SOLR-16467 > URL: https://issues.apache.org/jira/browse/SOLR-16467 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Blocker > Fix For: 9.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SOLR-15910 upgrades the semver library and Solr tests found that semver4j has > issues with some Locales. I don't see an easy way to address this in Solr - > so fixing upstream: https://github.com/semver4j/semver4j/pull/85 > Once fixed upstream this should be a simple library upgrade. In the meantime > I will annotate the test awaits fix or limit the locales. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15748) Create v2 equivalent of v1 'CLUSTERSTATUS' (or document alternatives)
[
https://issues.apache.org/jira/browse/SOLR-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619636#comment-17619636
]
ASF subversion and git services commented on SOLR-15748:
Commit 79fba55c269d3eecca1753addb74cccaf853aac5 in solr's branch
refs/heads/main from Joshua Ouma
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=79fba55c269 ]
SOLR-15748 : Created v2 equivalent of v1 'CLUSTERSTATUS' command (#1061)
> Create v2 equivalent of v1 'CLUSTERSTATUS' (or document alternatives)
> -
>
> Key: SOLR-15748
> URL: https://issues.apache.org/jira/browse/SOLR-15748
> Project: Solr
> Issue Type: Sub-task
> Components: v2 API
>Affects Versions: 9.1
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Labels: V2
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Solr's 'CLUSTERSTATUS' command under the v1 {{/solr/admin/collections}}
> endpoint has no v2 equivalent. This should be remedied to inch v2 closer to
> parity with v1 in preparation for eventual v1 deprecation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16467) semver4j fails with some locales
[ https://issues.apache.org/jira/browse/SOLR-16467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17619635#comment-17619635 ] ASF subversion and git services commented on SOLR-16467: Commit 58617724d48f23848264fd41ed94cf7af391d345 in solr's branch refs/heads/main from Kevin Risden [ https://gitbox.apache.org/repos/asf?p=solr.git;h=58617724d48 ] SOLR-16467: Add check for working locale in PackageManagerCLITest > semver4j fails with some locales > > > Key: SOLR-16467 > URL: https://issues.apache.org/jira/browse/SOLR-16467 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Package Manager >Affects Versions: 9.2 >Reporter: Kevin Risden >Assignee: Kevin Risden >Priority: Blocker > Fix For: 9.2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SOLR-15910 upgrades the semver library and Solr tests found that semver4j has > issues with some Locales. I don't see an easy way to address this in Solr - > so fixing upstream: https://github.com/semver4j/semver4j/pull/85 > Once fixed upstream this should be a simple library upgrade. In the meantime > I will annotate the test awaits fix or limit the locales. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija merged pull request #1061: SOLR-15748 : Created v2 equivalent of v1 'CLUSTERSTATUS' command
gerlowskija merged PR #1061: URL: https://github.com/apache/solr/pull/1061 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
