[jira] [Commented] (LUCENE-9317) Resolve package name conflicts for StandardAnalyzer to allow Java module system support
[
https://issues.apache.org/jira/browse/LUCENE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081672#comment-17081672
]
Tomoko Uchida commented on LUCENE-9317:
---
[~oobles] I just came here from the mail list. I just wanted to leave my
comments / suggestions for your question.
{quote}
I've checked out the master branch and starting to look at setting up the
development environment using Gradle to see if I can assist with a few items. I
notice Gradle hasn't been set up for Eclipse yet (maybe something I can help
with).
{quote}
Did you try "ant eclipse"? While Gradle build is already in a good shape, it is
ongoing project for now. Still we use Ant build as our first class build system
and it will help you when you see Gradle tasks doesn't work for you.
{quote}
My first roadblock to getting setup is understanding the cyclic dependencies
between core, codecs and the test-framework. Given IRC is not really used from
what I can see, and the slack channel is private to people with @apache.org
emails. Is there any good place to get basic help on getting started with the
codebase without spamming this email list?
{quote}
We are using Jira or Github PR as a general communication tool for specific
issues (discussion about design or implementation, questions, review requests,
or everything else). You can also get basic help here. I suggest you read the
contribution guide if you have not done so already:
https://cwiki.apache.org/confluence/display/solr/HowToContribute
I have a bit experience of analysis framework and I'm also sometimes annoyed
with its split package issue. Please feel free to mention me if you feel you
need "basic help" here.
> Resolve package name conflicts for StandardAnalyzer to allow Java module
> system support
> ---
>
> Key: LUCENE-9317
> URL: https://issues.apache.org/jira/browse/LUCENE-9317
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Affects Versions: master (9.0)
>Reporter: David Ryan
>Priority: Major
> Labels: build, features
>
>
> To allow Lucene to be modularised there are a few preparatory tasks to be
> completed prior to this being possible. The Java module system requires that
> jars do not use the same package name in different jars. The lucene-core and
> lucene-analyzers-common both share the package
> org.apache.lucene.analysis.standard.
> Possible resolutions to this issue are discussed by Uwe on the mailing list
> here:
>
> [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3CCAM21Rt8FHOq_JeUSELhsQJH0uN0eKBgduBQX4fQKxbs49TLqzA%40mail.gmail.com%3E]
> {quote}About StandardAnalyzer: Unfortunately I aggressively complained a
> while back when Mike McCandless wanted to move standard analyzer out of the
> analysis package into core (“for convenience”). This was a bad step, and IMHO
> we should revert that or completely rename the packages and everything. The
> problem here is: As the analysis services are only part of lucene-analyzers,
> we had to leave the factory classes there, but move the implementation
> classes in core. The package has to be the same. The only way around that is
> to move the analysis factory framework also to core (I would not be against
> that). This would include all factory base classes and the service loading
> stuff. Then we can move standard analyzer and some of the filters/tokenizers
> including their factories to core an that problem would be solved.
> {quote}
> There are two options here, either move factory framework into core or revert
> StandardAnalyzer back to lucene-analyzers. In the email, the solution lands
> on reverting back as per the task list:
> {quote}Add some preparatory issues to cleanup class hierarchy: Move Analysis
> SPI to core / remove StandardAnalyzer and related classes out of core back to
> anaysis
> {quote}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14291) OldAnalyticsRequestConverter should support fields names with dots
[
https://issues.apache.org/jira/browse/SOLR-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-14291:
---
Assignee: Mikhail Khludnev
> OldAnalyticsRequestConverter should support fields names with dots
> --
>
> Key: SOLR-14291
> URL: https://issues.apache.org/jira/browse/SOLR-14291
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search, SearchComponents - other
>Reporter: Anatolii Siuniaev
>Assignee: Mikhail Khludnev
>Priority: Trivial
> Attachments: SOLR-14291.patch, SOLR-14291.patch, SOLR-14291.patch
>
>
> If you send a query with range facets using old olap-style syntax (see pdf
> [here|https://issues.apache.org/jira/browse/SOLR-5302]),
> OldAnalyticsRequestConverter just silently (no exception thrown) omits
> parameters like
> {code:java}
> olap..rangefacet..start
> {code}
> in case if __ has dots inside (for instance field name is
> _Project.Value_). And thus no range facets are returned in response.
> Probably the same happens in case of field faceting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[ https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-9909: Attachment: SOLR-9909.patch > Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory > > > Key: SOLR-9909 > URL: https://issues.apache.org/jira/browse/SOLR-9909 > Project: Solr > Issue Type: Task >Reporter: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 6.7, 7.0 > > Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch, > SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch > > > DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same > code. Let's remove one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[ https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081693#comment-17081693 ] Shalin Shekhar Mangar commented on SOLR-9909: - Updated patch that adds the ASL to the new class. This will make the RAT check pass. > Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory > > > Key: SOLR-9909 > URL: https://issues.apache.org/jira/browse/SOLR-9909 > Project: Solr > Issue Type: Task >Reporter: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 6.7, 7.0 > > Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch, > SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch > > > DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same > code. Let's remove one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081734#comment-17081734 ] Dawid Weiss commented on LUCENE-9201: - Indeed I don't think documentation has been listed in LUCENE-9077; I don't think I even looked at it (although I knew the complexity is there). Please feel free to open a sub-issue, [~tomoko]. Task dependency looks good to me; the second probably better than the first (checks prior to rendering). Let me disable the current javadoc so that it doesn't conflict with renderJavadoc (we don't use it anyway). > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9278) Make javadoc folder structure follow Gradle project path
[ https://issues.apache.org/jira/browse/LUCENE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081737#comment-17081737 ] ASF subversion and git services commented on LUCENE-9278: - Commit fea1ce006211a5b22a29b74022d954fe3fe2c252 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fea1ce0 ] LUCENE-9278: move declaration calling getTemporaryDir inside the execution block closure so that gradlew clean renderJavadoc doesn't wipe out the temporary directory before the task has a chance to run. > Make javadoc folder structure follow Gradle project path > > > Key: LUCENE-9278 > URL: https://issues.apache.org/jira/browse/LUCENE-9278 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Current javadoc folder structure is derived from Ant project name. e.g.: > [https://lucene.apache.org/core/8_4_1/analyzers-icu/index.html] > [https://lucene.apache.org/solr/8_4_1/solr-solrj/index.html] > For Gradle build, it should also follow gradle project structure (path) > instead of ant one, to keep things simple to manage [1]. Hence, it will look > like this: > [https://lucene.apache.org/core/9_0_0/analysis/icu/index.html] > [https://lucene.apache.org/solr/9_0_0/solr/solrj/index.html] > [1] The change was suggested at the conversation between Dawid Weiss and I on > a github pr: [https://github.com/apache/lucene-solr/pull/1304] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081747#comment-17081747 ] Dawid Weiss commented on LUCENE-9201: - On the second thought I think we should keep the convention 'javadoc' task call 'renderJavadoc' so that people can still invoke ':foo:bar:javadoc' and it'll work. I'll do this change. Make all other task depend on renderJavadoc though (not javadoc). The difference is that gradle's javadoc first compiles stuff (we don't have to do that in renderJavadoc). > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-9201: -- Attachment: task_deps3.png Status: Open (was: Open) > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081750#comment-17081750 ] Tomoko Uchida commented on LUCENE-9201: --- Thank you for your feedback, I updated the dependency diagram. It's similar to my first one but "precommit" no longer depends on "javadoc". People still can call "javadoc" as ordinary gradle project (I agree with that we should keep the convention). Does this reflect what you are thinking? !task_deps3.png! > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081756#comment-17081756 ] ASF subversion and git services commented on LUCENE-9201: - Commit 9244558752e257d0436daef1f38df5de872192fc in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9244558 ] LUCENE-9201: remove javadoc task remnants. Make javadoc depend on renderJavadoc and skip the default gradle's implementation. > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081757#comment-17081757 ] Dawid Weiss commented on LUCENE-9201: - Yes! And I've just committed a small cleanup that implements renderJavadoc-javadoc dependency (took the liberty of just putting it in, without a PR). > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9316) Incorporate all :precommit tasks into :check
[ https://issues.apache.org/jira/browse/LUCENE-9316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9316. - Fix Version/s: master (9.0) Resolution: Fixed > Incorporate all :precommit tasks into :check > > > Key: LUCENE-9316 > URL: https://issues.apache.org/jira/browse/LUCENE-9316 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9316) Incorporate all :precommit tasks into :check
[ https://issues.apache.org/jira/browse/LUCENE-9316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081759#comment-17081759 ] ASF subversion and git services commented on LUCENE-9316: - Commit 7279190c897b5c554e2e1cbd090f4c392653a1bd in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7279190 ] LUCENE-9316: Incorporate all :precommit tasks into :check > Incorporate all :precommit tasks into :check > > > Key: LUCENE-9316 > URL: https://issues.apache.org/jira/browse/LUCENE-9316 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Minor > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081764#comment-17081764 ] Tomoko Uchida commented on LUCENE-9201: --- Thank you! I will open an issue for "documentation" task which will be built on renderJavadoc and look at the details of current ant implementation. > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > LUCENE-9201-missing-docs.patch, LUCENE-9201.patch, javadocGRADLE.png, > javadocHTML4.png, javadocHTML5.png, task_deps1.png, task_deps2.png, > task_deps3.png > > Time Spent: 4.5h > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9321) Port documentation task to gradle
Tomoko Uchida created LUCENE-9321: - Summary: Port documentation task to gradle Key: LUCENE-9321 URL: https://issues.apache.org/jira/browse/LUCENE-9321 Project: Lucene - Core Issue Type: Sub-task Components: general/build Reporter: Tomoko Uchida Assignee: Tomoko Uchida This is a placeholder issue for porting ant "documentation" task to gradle. The generated documents should be able to be published on lucene.apache.org web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9077) Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081807#comment-17081807 ] Erick Erickson commented on LUCENE-9077: [~dsmiley] I worked around the issue you raised on on 26-Feb by defining SOLR_HOME to be someplace outside the source tree. Right now I have SOLR_HOME hard coded outside all my source trees, and that will make it a little harder to work on multiple problems at once from different trees, but that's surmountable. > Gradle build > > > Key: LUCENE-9077 > URL: https://issues.apache.org/jira/browse/LUCENE-9077 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9077-javadoc-locale-en-US.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This task focuses on providing gradle-based build equivalent for Lucene and > Solr (on master branch). See notes below on why this respin is needed. > The code lives on *gradle-master* branch. It is kept with sync with *master*. > Try running the following to see an overview of helper guides concerning > typical workflow, testing and ant-migration helpers: > gradlew :help > A list of items that needs to be added or requires work. If you'd like to > work on any of these, please add your name to the list. Once you have a > patch/ pull request let me (dweiss) know - I'll try to coordinate the merges. > * (/) Apply forbiddenAPIs > * (/) Generate hardware-aware gradle defaults for parallelism (count of > workers and test JVMs). > * (/) Fail the build if --tests filter is applied and no tests execute > during the entire build (this allows for an empty set of filtered tests at > single project level). > * (/) Port other settings and randomizations from common-build.xml > * (/) Configure security policy/ sandboxing for tests. > * (/) test's console output on -Ptests.verbose=true > * (/) add a :helpDeps explanation to how the dependency system works > (palantir plugin, lockfile) and how to retrieve structured information about > current dependencies of a given module (in a tree-like output). > * (/) jar checksums, jar checksum computation and validation. This should be > done without intermediate folders (directly on dependency sets). > * (/) verify min. JVM version and exact gradle version on build startup to > minimize odd build side-effects > * (/) Repro-line for failed tests/ runs. > * (/) add a top-level README note about building with gradle (and the > required JVM). > * (/) add an equivalent of 'validate-source-patterns' > (check-source-patterns.groovy) to precommit. > * (/) add an equivalent of 'rat-sources' to precommit. > * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) > to precommit. > * (/) javadoc compilation > Hard-to-implement stuff already investigated: > * (/) (done) -*Printing console output of failed tests.* There doesn't seem > to be any way to do this in a reasonably efficient way. There are onOutput > listeners but they're slow to operate and solr tests emit *tons* of output so > it's an overkill.- > * (!) (LUCENE-9120) *Tests working with security-debug logs or other > JVM-early log output*. Gradle's test runner works by redirecting Java's > stdout/ syserr so this just won't work. Perhaps we can spin the ant-based > test runner for such corner-cases. > Of lesser importance: > * Add an equivalent of 'documentation-lint" to precommit. > * (/) Do not require files to be committed before running precommit. (staged > files are fine). > * (/) add rendering of javadocs (gradlew javadoc) > * Attach javadocs to maven publications. > * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid > it'll be difficult to run it sensibly because gradle doesn't offer cwd > separation for the forked test runners. > * if you diff solr packaged distribution against ant-created distribution > there are minor differences in library versions and some JARs are excluded/ > moved around. I didn't try to force these as everything seems to work (tests, > etc.) – perhaps these differences should be fixed in the ant build instead. > * (/) identify and port various "regenerate" tasks from ant builds (javacc, > precompiled automata, etc.) > * Fill in POM details in gradle/defaults-maven.gradle so that they reflect > the previous content better (dependencies aside). > * Add any IDE integration layers that should be added (I use IntelliJ and it > imports the project out of the box, without the need for any special tuning). > ** Remove idea task and just import from the gradle model? One less thing to > maintain. > * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; > currently XSLT.
[GitHub] [lucene-solr] dweiss opened a new pull request #1426: Do a bit count on 8 bytes from a long directly instead of reading 8 b…
dweiss opened a new pull request #1426: Do a bit count on 8 bytes from a long directly instead of reading 8 b… URL: https://github.com/apache/lucene-solr/pull/1426 Couldn't resist. Shows a marginal improvement in tight loops. @bruno-roustant ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9077) Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081815#comment-17081815 ] ASF subversion and git services commented on LUCENE-9077: - Commit f865c8af83e07434719e7355b9d7a110ca299bfd in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f865c8a ] LUCENE-9077: add a :solr:packaging:dev task that assembles a 'development' image of Solr from which nothing is removed upon consecutive rebuild. > Gradle build > > > Key: LUCENE-9077 > URL: https://issues.apache.org/jira/browse/LUCENE-9077 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9077-javadoc-locale-en-US.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This task focuses on providing gradle-based build equivalent for Lucene and > Solr (on master branch). See notes below on why this respin is needed. > The code lives on *gradle-master* branch. It is kept with sync with *master*. > Try running the following to see an overview of helper guides concerning > typical workflow, testing and ant-migration helpers: > gradlew :help > A list of items that needs to be added or requires work. If you'd like to > work on any of these, please add your name to the list. Once you have a > patch/ pull request let me (dweiss) know - I'll try to coordinate the merges. > * (/) Apply forbiddenAPIs > * (/) Generate hardware-aware gradle defaults for parallelism (count of > workers and test JVMs). > * (/) Fail the build if --tests filter is applied and no tests execute > during the entire build (this allows for an empty set of filtered tests at > single project level). > * (/) Port other settings and randomizations from common-build.xml > * (/) Configure security policy/ sandboxing for tests. > * (/) test's console output on -Ptests.verbose=true > * (/) add a :helpDeps explanation to how the dependency system works > (palantir plugin, lockfile) and how to retrieve structured information about > current dependencies of a given module (in a tree-like output). > * (/) jar checksums, jar checksum computation and validation. This should be > done without intermediate folders (directly on dependency sets). > * (/) verify min. JVM version and exact gradle version on build startup to > minimize odd build side-effects > * (/) Repro-line for failed tests/ runs. > * (/) add a top-level README note about building with gradle (and the > required JVM). > * (/) add an equivalent of 'validate-source-patterns' > (check-source-patterns.groovy) to precommit. > * (/) add an equivalent of 'rat-sources' to precommit. > * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) > to precommit. > * (/) javadoc compilation > Hard-to-implement stuff already investigated: > * (/) (done) -*Printing console output of failed tests.* There doesn't seem > to be any way to do this in a reasonably efficient way. There are onOutput > listeners but they're slow to operate and solr tests emit *tons* of output so > it's an overkill.- > * (!) (LUCENE-9120) *Tests working with security-debug logs or other > JVM-early log output*. Gradle's test runner works by redirecting Java's > stdout/ syserr so this just won't work. Perhaps we can spin the ant-based > test runner for such corner-cases. > Of lesser importance: > * Add an equivalent of 'documentation-lint" to precommit. > * (/) Do not require files to be committed before running precommit. (staged > files are fine). > * (/) add rendering of javadocs (gradlew javadoc) > * Attach javadocs to maven publications. > * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid > it'll be difficult to run it sensibly because gradle doesn't offer cwd > separation for the forked test runners. > * if you diff solr packaged distribution against ant-created distribution > there are minor differences in library versions and some JARs are excluded/ > moved around. I didn't try to force these as everything seems to work (tests, > etc.) – perhaps these differences should be fixed in the ant build instead. > * (/) identify and port various "regenerate" tasks from ant builds (javacc, > precompiled automata, etc.) > * Fill in POM details in gradle/defaults-maven.gradle so that they reflect > the previous content better (dependencies aside). > * Add any IDE integration layers that should be added (I use IntelliJ and it > imports the project out of the box, without the need for any special tuning). > ** Remove idea task and just import from the gradle model? One less thing to > maintain. > * Add Solr packaging for docs/* (see TODO in pa
[jira] [Commented] (LUCENE-9077) Gradle build
[
https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081817#comment-17081817
]
Dawid Weiss commented on LUCENE-9077:
-
I'm sorry, I forgot about this. I've added a task 'dev' which I mentioned
before. When you run:
{code}
gradlew -p solr/packaging dev
{code}
it'll assemble the distribution under {{packaging/build/dev}} (without any
version string to simplify
referencing in IDEs, etc.). Nothing is removed from that location on rebuild
(it is a copy, not a sync).
Will this work for you?
> Gradle build
>
>
> Key: LUCENE-9077
> URL: https://issues.apache.org/jira/browse/LUCENE-9077
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: LUCENE-9077-javadoc-locale-en-US.patch
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This task focuses on providing gradle-based build equivalent for Lucene and
> Solr (on master branch). See notes below on why this respin is needed.
> The code lives on *gradle-master* branch. It is kept with sync with *master*.
> Try running the following to see an overview of helper guides concerning
> typical workflow, testing and ant-migration helpers:
> gradlew :help
> A list of items that needs to be added or requires work. If you'd like to
> work on any of these, please add your name to the list. Once you have a
> patch/ pull request let me (dweiss) know - I'll try to coordinate the merges.
> * (/) Apply forbiddenAPIs
> * (/) Generate hardware-aware gradle defaults for parallelism (count of
> workers and test JVMs).
> * (/) Fail the build if --tests filter is applied and no tests execute
> during the entire build (this allows for an empty set of filtered tests at
> single project level).
> * (/) Port other settings and randomizations from common-build.xml
> * (/) Configure security policy/ sandboxing for tests.
> * (/) test's console output on -Ptests.verbose=true
> * (/) add a :helpDeps explanation to how the dependency system works
> (palantir plugin, lockfile) and how to retrieve structured information about
> current dependencies of a given module (in a tree-like output).
> * (/) jar checksums, jar checksum computation and validation. This should be
> done without intermediate folders (directly on dependency sets).
> * (/) verify min. JVM version and exact gradle version on build startup to
> minimize odd build side-effects
> * (/) Repro-line for failed tests/ runs.
> * (/) add a top-level README note about building with gradle (and the
> required JVM).
> * (/) add an equivalent of 'validate-source-patterns'
> (check-source-patterns.groovy) to precommit.
> * (/) add an equivalent of 'rat-sources' to precommit.
> * (/) add an equivalent of 'check-example-lucene-match-version' (solr only)
> to precommit.
> * (/) javadoc compilation
> Hard-to-implement stuff already investigated:
> * (/) (done) -*Printing console output of failed tests.* There doesn't seem
> to be any way to do this in a reasonably efficient way. There are onOutput
> listeners but they're slow to operate and solr tests emit *tons* of output so
> it's an overkill.-
> * (!) (LUCENE-9120) *Tests working with security-debug logs or other
> JVM-early log output*. Gradle's test runner works by redirecting Java's
> stdout/ syserr so this just won't work. Perhaps we can spin the ant-based
> test runner for such corner-cases.
> Of lesser importance:
> * Add an equivalent of 'documentation-lint" to precommit.
> * (/) Do not require files to be committed before running precommit. (staged
> files are fine).
> * (/) add rendering of javadocs (gradlew javadoc)
> * Attach javadocs to maven publications.
> * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid
> it'll be difficult to run it sensibly because gradle doesn't offer cwd
> separation for the forked test runners.
> * if you diff solr packaged distribution against ant-created distribution
> there are minor differences in library versions and some JARs are excluded/
> moved around. I didn't try to force these as everything seems to work (tests,
> etc.) – perhaps these differences should be fixed in the ant build instead.
> * (/) identify and port various "regenerate" tasks from ant builds (javacc,
> precompiled automata, etc.)
> * Fill in POM details in gradle/defaults-maven.gradle so that they reflect
> the previous content better (dependencies aside).
> * Add any IDE integration layers that should be added (I use IntelliJ and it
> imports the project out of the box, without the need for any special tuning).
> ** Remove idea task and just import from the gradle model? One less thing to
> maintain.
> * Add Solr packaging for docs/* (s
[jira] [Updated] (LUCENE-9314) Lucene monitor module uses ByteBuffersDirectory rather than MemoryIndex when matching a single document
[ https://issues.apache.org/jira/browse/LUCENE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Perron updated LUCENE-9314: -- Attachment: LUCENE-9314.patch > Lucene monitor module uses ByteBuffersDirectory rather than MemoryIndex when > matching a single document > --- > > Key: LUCENE-9314 > URL: https://issues.apache.org/jira/browse/LUCENE-9314 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Affects Versions: 8.2, 8.3, 8.4, 8.5 >Reporter: Pierre-Luc Perron >Priority: Minor > Labels: easyfix, performance, pull-request-available > Attachments: LUCENE-9314.patch, LUCENE-9314.patch, LUCENE-9314.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Lucene monitor function, [match single > document|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L276], > wraps a single document into a array of documents. Hence, it always calls > the function, [match many > documents|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L256], > which builds a > [MultiDocumentBatch|https://github.com/apache/lucene-solr/blob/71d335ff688982cef10a648c914623c81ced/lucene/monitor/src/java/org/apache/lucene/monitor/DocumentBatch.java#L56] > rather than a > [SingletonDocumentBatch|https://github.com/apache/lucene-solr/blob/71d335ff688982cef10a648c914623c81ced/lucene/monitor/src/java/org/apache/lucene/monitor/DocumentBatch.java#L46]. > The former uses ByteBuffersDirectory while later uses MemoryIndex. > As per documentation, > [MemoryIndex|https://lucene.apache.org/core/8_2_0/memory/index.html] is a > high-performance single-document main memory Apache Lucene fulltext search > index. Hence, Lucene monitor should use it when matching a single document. > The patch routes [match single > document|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L276] > to a SingletonDocumentBatch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9314) Lucene monitor module uses ByteBuffersDirectory rather than MemoryIndex when matching a single document
[ https://issues.apache.org/jira/browse/LUCENE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081828#comment-17081828 ] Pierre-Luc Perron commented on LUCENE-9314: --- I wrote the update. Let me know if something is amiss. > Lucene monitor module uses ByteBuffersDirectory rather than MemoryIndex when > matching a single document > --- > > Key: LUCENE-9314 > URL: https://issues.apache.org/jira/browse/LUCENE-9314 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/other >Affects Versions: 8.2, 8.3, 8.4, 8.5 >Reporter: Pierre-Luc Perron >Priority: Minor > Labels: easyfix, performance, pull-request-available > Attachments: LUCENE-9314.patch, LUCENE-9314.patch, LUCENE-9314.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Lucene monitor function, [match single > document|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L276], > wraps a single document into a array of documents. Hence, it always calls > the function, [match many > documents|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L256], > which builds a > [MultiDocumentBatch|https://github.com/apache/lucene-solr/blob/71d335ff688982cef10a648c914623c81ced/lucene/monitor/src/java/org/apache/lucene/monitor/DocumentBatch.java#L56] > rather than a > [SingletonDocumentBatch|https://github.com/apache/lucene-solr/blob/71d335ff688982cef10a648c914623c81ced/lucene/monitor/src/java/org/apache/lucene/monitor/DocumentBatch.java#L46]. > The former uses ByteBuffersDirectory while later uses MemoryIndex. > As per documentation, > [MemoryIndex|https://lucene.apache.org/core/8_2_0/memory/index.html] is a > high-performance single-document main memory Apache Lucene fulltext search > index. Hence, Lucene monitor should use it when matching a single document. > The patch routes [match single > document|https://github.com/apache/lucene-solr/blob/e376582e25d02f85b415eb1c0456f3fdc800fc84/lucene/monitor/src/java/org/apache/lucene/monitor/Monitor.java#L276] > to a SingletonDocumentBatch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[
https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081846#comment-17081846
]
Lucene/Solr QA commented on SOLR-9909:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 24 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
9s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
3s{color} | {color:green} tools in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
52s{color} | {color:green} analytics in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} prometheus-exporter in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 46m
35s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
1s{color} | {color:green} solrj in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 60m 26s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-9909 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12999691/SOLR-9909.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / f865c8af83e |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/736/testReport/ |
| modules | C: . lucene/tools solr/contrib/analytics
solr/contrib/prometheus-exporter solr/core solr/solrj solr/test-framework U: . |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/736/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
>
>
> Key: SOLR-9909
> URL: https://issues.apache.org/jira/browse/SOLR-9909
> Project: Solr
> Issue Type: Task
>Reporter: Shalin Shekhar Mangar
>Priority: Trivial
> Fix For: 6.7, 7.0
>
> Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch,
> SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch
>
>
> DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same
> code. Let's remove one of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw opened a new pull request #1427: LUCENE-9304: Fix IW#getMaxCompletedSequenceNumber()
s1monw opened a new pull request #1427: LUCENE-9304: Fix IW#getMaxCompletedSequenceNumber() URL: https://github.com/apache/lucene-solr/pull/1427 After recent refactorings on LUCENE-9304 `IW#getMaxCompletedSequenceNumber()` might return values that belong to non-completed operations if a full flush is running, a new delete queue is already in place but not all DWPTs that participate in the full flush have finished it's in-flight operation. This caused rare failures in `TestControlledRealTimeReopenThread#testControlledRealTimeReopenThread` were documents are not actually visible given the max completed seqNo. This change streamlines the delete queue advance, adds a dedicated testcase and ensures that a delete queues sequence Id space is never exhausted. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on issue #1427: LUCENE-9304: Fix IW#getMaxCompletedSequenceNumber()
s1monw commented on issue #1427: LUCENE-9304: Fix IW#getMaxCompletedSequenceNumber() URL: https://github.com/apache/lucene-solr/pull/1427#issuecomment-612664972 @dnhatn @mikemccand can you take a look 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14404) CoreContainer level custom requesthandlers
[
https://issues.apache.org/jira/browse/SOLR-14404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14404:
--
Description:
caveats:
* The class should be annotated with {{org.apache.solr.api.EndPoint}}. Which
means only V2 APIs are supported
* The path should have prefix {{/api/cluster}} or {{/api/node}}. It should not
conflict with any of the exiting handlers
add a plugin
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"add": {
"name":"myplugin", "class": "full.ClassName"
}
}' http://localhost:8983/api/cluster/plugins
{code}
remove a plugin
{code:java}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"remove": "myplugin"
}' http://localhost:8983/api/cluster/plugins
{code}
The configuration will be stored in the {{clusterprops.json}}
as
{code:java}
{
"plugins" : {
"myplugin" : {"class": "full.ClassName" }
}
}
{code}
was:
caveats:
* The class should implement {{org.apache.solr.api.Api}}. Which means only V2
APIs are supported
* The path should have prefix {{/api/cluster}} or {{/api/node}}. It should not
conflict with any of the exiting handlers
add a handler
{code}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"add-requesthandler": {
"name":"myhandler", "class": "full.ClassName"
}
}' http://localhost:8983/api/cluster
{code}
remove a handler
{code}
curl -X POST -H 'Content-type:application/json' --data-binary '
{
"remove-requesthandler": "myhandler"
}' http://localhost:8983/api/cluster
{code}
The configuration will be stored in the {{clusterprops.json}}
as
{code}
{
"requestHandler" : {
"myhandler" : {"class": "full.ClassName" }
}
}
{code}
> CoreContainer level custom requesthandlers
> --
>
> Key: SOLR-14404
> URL: https://issues.apache.org/jira/browse/SOLR-14404
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> caveats:
> * The class should be annotated with {{org.apache.solr.api.EndPoint}}.
> Which means only V2 APIs are supported
> * The path should have prefix {{/api/cluster}} or {{/api/node}}. It should
> not conflict with any of the exiting handlers
> add a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add": {
> "name":"myplugin", "class": "full.ClassName"
> }
> }' http://localhost:8983/api/cluster/plugins
> {code}
> remove a plugin
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "remove": "myplugin"
> }' http://localhost:8983/api/cluster/plugins
> {code}
> The configuration will be stored in the {{clusterprops.json}}
> as
> {code:java}
> {
> "plugins" : {
> "myplugin" : {"class": "full.ClassName" }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9077) Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081936#comment-17081936 ] David Smiley commented on LUCENE-9077: -- Thanks Dawid! I tried it out and it'll probably work well for me going forward. > Gradle build > > > Key: LUCENE-9077 > URL: https://issues.apache.org/jira/browse/LUCENE-9077 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9077-javadoc-locale-en-US.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > This task focuses on providing gradle-based build equivalent for Lucene and > Solr (on master branch). See notes below on why this respin is needed. > The code lives on *gradle-master* branch. It is kept with sync with *master*. > Try running the following to see an overview of helper guides concerning > typical workflow, testing and ant-migration helpers: > gradlew :help > A list of items that needs to be added or requires work. If you'd like to > work on any of these, please add your name to the list. Once you have a > patch/ pull request let me (dweiss) know - I'll try to coordinate the merges. > * (/) Apply forbiddenAPIs > * (/) Generate hardware-aware gradle defaults for parallelism (count of > workers and test JVMs). > * (/) Fail the build if --tests filter is applied and no tests execute > during the entire build (this allows for an empty set of filtered tests at > single project level). > * (/) Port other settings and randomizations from common-build.xml > * (/) Configure security policy/ sandboxing for tests. > * (/) test's console output on -Ptests.verbose=true > * (/) add a :helpDeps explanation to how the dependency system works > (palantir plugin, lockfile) and how to retrieve structured information about > current dependencies of a given module (in a tree-like output). > * (/) jar checksums, jar checksum computation and validation. This should be > done without intermediate folders (directly on dependency sets). > * (/) verify min. JVM version and exact gradle version on build startup to > minimize odd build side-effects > * (/) Repro-line for failed tests/ runs. > * (/) add a top-level README note about building with gradle (and the > required JVM). > * (/) add an equivalent of 'validate-source-patterns' > (check-source-patterns.groovy) to precommit. > * (/) add an equivalent of 'rat-sources' to precommit. > * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) > to precommit. > * (/) javadoc compilation > Hard-to-implement stuff already investigated: > * (/) (done) -*Printing console output of failed tests.* There doesn't seem > to be any way to do this in a reasonably efficient way. There are onOutput > listeners but they're slow to operate and solr tests emit *tons* of output so > it's an overkill.- > * (!) (LUCENE-9120) *Tests working with security-debug logs or other > JVM-early log output*. Gradle's test runner works by redirecting Java's > stdout/ syserr so this just won't work. Perhaps we can spin the ant-based > test runner for such corner-cases. > Of lesser importance: > * Add an equivalent of 'documentation-lint" to precommit. > * (/) Do not require files to be committed before running precommit. (staged > files are fine). > * (/) add rendering of javadocs (gradlew javadoc) > * Attach javadocs to maven publications. > * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid > it'll be difficult to run it sensibly because gradle doesn't offer cwd > separation for the forked test runners. > * if you diff solr packaged distribution against ant-created distribution > there are minor differences in library versions and some JARs are excluded/ > moved around. I didn't try to force these as everything seems to work (tests, > etc.) – perhaps these differences should be fixed in the ant build instead. > * (/) identify and port various "regenerate" tasks from ant builds (javacc, > precompiled automata, etc.) > * Fill in POM details in gradle/defaults-maven.gradle so that they reflect > the previous content better (dependencies aside). > * Add any IDE integration layers that should be added (I use IntelliJ and it > imports the project out of the box, without the need for any special tuning). > ** Remove idea task and just import from the gradle model? One less thing to > maintain. > * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; > currently XSLT...) > * I didn't bother adding Solr dist/test-framework to packaging (who'd use it > from a binary distribution? > * There is some python execution in check-broken-links and > check-missing-javadocs, not sure if it's been ported > * Ni
[jira] [Commented] (SOLR-14291) OldAnalyticsRequestConverter should support fields names with dots
[
https://issues.apache.org/jira/browse/SOLR-14291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081940#comment-17081940
]
Houston Putman commented on SOLR-14291:
---
[~mkhl] looks great to me!
> OldAnalyticsRequestConverter should support fields names with dots
> --
>
> Key: SOLR-14291
> URL: https://issues.apache.org/jira/browse/SOLR-14291
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search, SearchComponents - other
>Reporter: Anatolii Siuniaev
>Assignee: Mikhail Khludnev
>Priority: Trivial
> Attachments: SOLR-14291.patch, SOLR-14291.patch, SOLR-14291.patch
>
>
> If you send a query with range facets using old olap-style syntax (see pdf
> [here|https://issues.apache.org/jira/browse/SOLR-5302]),
> OldAnalyticsRequestConverter just silently (no exception thrown) omits
> parameters like
> {code:java}
> olap..rangefacet..start
> {code}
> in case if __ has dots inside (for instance field name is
> _Project.Value_). And thus no range facets are returned in response.
> Probably the same happens in case of field faceting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log.trace messages
[
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081966#comment-17081966
]
David Smiley commented on LUCENE-7788:
--
+0
I'm not plus one because I'm skeptical the problem is worth any of these
solutions.
How about {{//suppresswarnings}} to thus use the same terminology of the Java
{{@SuppressWarnings}} annotation?
> fail precommit on unparameterised log.trace messages
>
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use
> and once that is in place then this ticket's one-line change would be for
> 'ant precommit' to reject any future unparameterised log.trace message use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #1421: SOLR-14396: TaggerRequestHandler should not error on empty collection
dsmiley closed pull request #1421: SOLR-14396: TaggerRequestHandler should not error on empty collection URL: https://github.com/apache/lucene-solr/pull/1421 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14396) TaggerRequestHandler Should Not Error on Empty Collection
[ https://issues.apache.org/jira/browse/SOLR-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081973#comment-17081973 ] ASF subversion and git services commented on SOLR-14396: Commit 04f44399bad7ab1a3c857641faf0de8f2a683966 in lucene-solr's branch refs/heads/master from Trey Grainger [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=04f4439 ] SOLR-14396: TaggerRequestHandler should not error on empty index Fixes #1421 > TaggerRequestHandler Should Not Error on Empty Collection > - > > Key: SOLR-14396 > URL: https://issues.apache.org/jira/browse/SOLR-14396 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Grainger >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The TaggerRequestHandler (added in SOLR-12376) currently returns a 400 (Bad > Request) if used on a collection with no terms in the index. This probably > made sense for the use cases for which it was originally written (in the > OpenSextant project, before it was contributed to Solr) that focused on on > stand-alone document tagging, where the calling application expected there to > always be an index. > More and more use cases are emerging for using the TaggerRequestHandler in > real-time for user queries, however. For example, real-time phrase matching > and entity resolution in queries. In these cases, the data in the tagger > collection may be dynamically updated, and at times, the collection may even > be empty. > While it's certainly possible for the 400 error to be handled client-side for > empty collections, the incoming requests aren't really "bad" requests in my > opinion, the index just doesn't have any data yet. Sending the same request > subsequently once some documents are indexed would result in a success. > I'm proposing we remove the exception for empty indexes and simply return no > matched tags instead. > If it's important for anyone to preserve the current behavior, we could add a > parameter "errorOnEmptyCollection". Does anyone think preserving the error > here is needed? What say you [~dsmiley]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14396) TaggerRequestHandler Should Not Error on Empty Collection
[ https://issues.apache.org/jira/browse/SOLR-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081975#comment-17081975 ] ASF subversion and git services commented on SOLR-14396: Commit 4dece1ae17a2fccebd6478c059dd646c163aef4f in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4dece1a ] CHANGES.txt move SOLR-14396 oops! > TaggerRequestHandler Should Not Error on Empty Collection > - > > Key: SOLR-14396 > URL: https://issues.apache.org/jira/browse/SOLR-14396 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Grainger >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The TaggerRequestHandler (added in SOLR-12376) currently returns a 400 (Bad > Request) if used on a collection with no terms in the index. This probably > made sense for the use cases for which it was originally written (in the > OpenSextant project, before it was contributed to Solr) that focused on on > stand-alone document tagging, where the calling application expected there to > always be an index. > More and more use cases are emerging for using the TaggerRequestHandler in > real-time for user queries, however. For example, real-time phrase matching > and entity resolution in queries. In these cases, the data in the tagger > collection may be dynamically updated, and at times, the collection may even > be empty. > While it's certainly possible for the 400 error to be handled client-side for > empty collections, the incoming requests aren't really "bad" requests in my > opinion, the index just doesn't have any data yet. Sending the same request > subsequently once some documents are indexed would result in a success. > I'm proposing we remove the exception for empty indexes and simply return no > matched tags instead. > If it's important for anyone to preserve the current behavior, we could add a > parameter "errorOnEmptyCollection". Does anyone think preserving the error > here is needed? What say you [~dsmiley]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14396) TaggerRequestHandler Should Not Error on Empty Collection
[ https://issues.apache.org/jira/browse/SOLR-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081977#comment-17081977 ] ASF subversion and git services commented on SOLR-14396: Commit 61335141db553b74872ad82ea4080af9fd0eb56a in lucene-solr's branch refs/heads/branch_8x from Trey Grainger [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6133514 ] SOLR-14396: TaggerRequestHandler should not error on empty index Fixes #1421 (cherry picked from commit 04f44399bad7ab1a3c857641faf0de8f2a683966) > TaggerRequestHandler Should Not Error on Empty Collection > - > > Key: SOLR-14396 > URL: https://issues.apache.org/jira/browse/SOLR-14396 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Grainger >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The TaggerRequestHandler (added in SOLR-12376) currently returns a 400 (Bad > Request) if used on a collection with no terms in the index. This probably > made sense for the use cases for which it was originally written (in the > OpenSextant project, before it was contributed to Solr) that focused on on > stand-alone document tagging, where the calling application expected there to > always be an index. > More and more use cases are emerging for using the TaggerRequestHandler in > real-time for user queries, however. For example, real-time phrase matching > and entity resolution in queries. In these cases, the data in the tagger > collection may be dynamically updated, and at times, the collection may even > be empty. > While it's certainly possible for the 400 error to be handled client-side for > empty collections, the incoming requests aren't really "bad" requests in my > opinion, the index just doesn't have any data yet. Sending the same request > subsequently once some documents are indexed would result in a success. > I'm proposing we remove the exception for empty indexes and simply return no > matched tags instead. > If it's important for anyone to preserve the current behavior, we could add a > parameter "errorOnEmptyCollection". Does anyone think preserving the error > here is needed? What say you [~dsmiley]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14396) TaggerRequestHandler Should Not Error on Empty Collection
[ https://issues.apache.org/jira/browse/SOLR-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-14396. - Fix Version/s: 8.6 Assignee: David Smiley Resolution: Fixed > TaggerRequestHandler Should Not Error on Empty Collection > - > > Key: SOLR-14396 > URL: https://issues.apache.org/jira/browse/SOLR-14396 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Grainger >Assignee: David Smiley >Priority: Minor > Fix For: 8.6 > > Time Spent: 20m > Remaining Estimate: 0h > > The TaggerRequestHandler (added in SOLR-12376) currently returns a 400 (Bad > Request) if used on a collection with no terms in the index. This probably > made sense for the use cases for which it was originally written (in the > OpenSextant project, before it was contributed to Solr) that focused on on > stand-alone document tagging, where the calling application expected there to > always be an index. > More and more use cases are emerging for using the TaggerRequestHandler in > real-time for user queries, however. For example, real-time phrase matching > and entity resolution in queries. In these cases, the data in the tagger > collection may be dynamically updated, and at times, the collection may even > be empty. > While it's certainly possible for the 400 error to be handled client-side for > empty collections, the incoming requests aren't really "bad" requests in my > opinion, the index just doesn't have any data yet. Sending the same request > subsequently once some documents are indexed would result in a success. > I'm proposing we remove the exception for empty indexes and simply return no > matched tags instead. > If it's important for anyone to preserve the current behavior, we could add a > parameter "errorOnEmptyCollection". Does anyone think preserving the error > here is needed? What say you [~dsmiley]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9906) Use better check to validate if node recovered via PeerSync or Replication
[
https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081996#comment-17081996
]
ASF subversion and git services commented on SOLR-9906:
---
Commit 13f19f65559290a860df84fa1b5ac2db903b27ec in lucene-solr's branch
refs/heads/master from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=13f19f6 ]
SOLR-9906: SolrjNamedThreadFactory is deprecated in favor of
SolrNamedThreadFactory. DefaultSolrThreadFactory is removed from solr-core in
favor of SolrNamedThreadFactory in solrj package and all solr-core classes now
use SolrNamedThreadFactory
> Use better check to validate if node recovered via PeerSync or Replication
> --
>
> Key: SOLR-9906
> URL: https://issues.apache.org/jira/browse/SOLR-9906
> Project: Solr
> Issue Type: Improvement
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.4
>
> Attachments: SOLR-9906.patch, SOLR-9906.patch,
> SOLR-PeerSyncVsReplicationTest.diff
>
>
> Tests {{LeaderFailureAfterFreshStartTest}} and {{PeerSyncReplicationTest}}
> currently rely on number of requests made to the leader's replication handler
> to check if node recovered via PeerSync or replication. This check is not
> very reliable and we have seen failures in the past.
> While tinkering with different way to write a better test I found
> [SOLR-9859|SOLR-9859]. Now that SOLR-9859 is fixed, here is idea for better
> way to distinguish recovery via PeerSync vs Replication.
> * For {{PeerSyncReplicationTest}}, if node successfully recovers via
> PeerSync, then file {{replication.properties}} should not exist
> For {{LeaderFailureAfterFreshStartTest}}, if the freshly replicated node does
> not go into replication recovery after the leader failure, contents
> {{replication.properties}} should not change
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[ https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081997#comment-17081997 ] ASF subversion and git services commented on SOLR-9909: --- Commit 6b78330668a33c02551cedaaafa793dd2267b353 in lucene-solr's branch refs/heads/master from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b78330 ] SOLR-9909: Add the right Jira issue to CHANGES.txt > Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory > > > Key: SOLR-9909 > URL: https://issues.apache.org/jira/browse/SOLR-9909 > Project: Solr > Issue Type: Task >Reporter: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 6.7, 7.0 > > Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch, > SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch > > > DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same > code. Let's remove one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9906) Use better check to validate if node recovered via PeerSync or Replication
[
https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081998#comment-17081998
]
Shalin Shekhar Mangar commented on SOLR-9906:
-
Please ignore the above comment. It was intended for SOLR-9909.
> Use better check to validate if node recovered via PeerSync or Replication
> --
>
> Key: SOLR-9906
> URL: https://issues.apache.org/jira/browse/SOLR-9906
> Project: Solr
> Issue Type: Improvement
>Reporter: Pushkar Raste
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.4
>
> Attachments: SOLR-9906.patch, SOLR-9906.patch,
> SOLR-PeerSyncVsReplicationTest.diff
>
>
> Tests {{LeaderFailureAfterFreshStartTest}} and {{PeerSyncReplicationTest}}
> currently rely on number of requests made to the leader's replication handler
> to check if node recovered via PeerSync or replication. This check is not
> very reliable and we have seen failures in the past.
> While tinkering with different way to write a better test I found
> [SOLR-9859|SOLR-9859]. Now that SOLR-9859 is fixed, here is idea for better
> way to distinguish recovery via PeerSync vs Replication.
> * For {{PeerSyncReplicationTest}}, if node successfully recovers via
> PeerSync, then file {{replication.properties}} should not exist
> For {{LeaderFailureAfterFreshStartTest}}, if the freshly replicated node does
> not go into replication recovery after the leader failure, contents
> {{replication.properties}} should not change
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[
https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081999#comment-17081999
]
Shalin Shekhar Mangar commented on SOLR-9909:
-
I accidentally used the wrong issue number in the commit so the asf git message
went to another issue. Here's the commit:
{code}
Commit 13f19f65559290a860df84fa1b5ac2db903b27ec in lucene-solr's branch
refs/heads/master from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=13f19f6 ]
SOLR-9906: SolrjNamedThreadFactory is deprecated in favor of
SolrNamedThreadFactory. DefaultSolrThreadFactory is removed from solr-core in
favor of SolrNamedThreadFactory in solrj package and all solr-core classes now
use SolrNamedThreadFactory
{code}
> Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
>
>
> Key: SOLR-9909
> URL: https://issues.apache.org/jira/browse/SOLR-9909
> Project: Solr
> Issue Type: Task
>Reporter: Shalin Shekhar Mangar
>Priority: Trivial
> Fix For: 6.7, 7.0
>
> Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch,
> SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch
>
>
> DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same
> code. Let's remove one of them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9909) Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory
[ https://issues.apache.org/jira/browse/SOLR-9909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082001#comment-17082001 ] ASF subversion and git services commented on SOLR-9909: --- Commit 4df81f1d6de6087df13e2f0b1f228d0b9c7d37f4 in lucene-solr's branch refs/heads/master from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4df81f1 ] SOLR-9909: The deprecated SolrjNamedThreadFactory has been removed. Use SolrNamedThreadFactory instead. > Nuke one of DefaultSolrThreadFactory and SolrjNamedThreadFactory > > > Key: SOLR-9909 > URL: https://issues.apache.org/jira/browse/SOLR-9909 > Project: Solr > Issue Type: Task >Reporter: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 6.7, 7.0 > > Attachments: SOLR-9909-01.patch, SOLR-9909-02.patch, > SOLR-9909-03.patch, SOLR-9909.patch, SOLR-9909.patch, SOLR-9909.patch > > > DefaultSolrThreadFactory and SolrjNamedThreadFactory have exactly the same > code. Let's remove one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11960) Add collection level properties
[ https://issues.apache.org/jira/browse/SOLR-11960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17082070#comment-17082070 ] Marieromigs commented on SOLR-11960: Get instant response and good care of WiFi range extender for our highly talented experts. Available 24/7 365 days to provide you the best assistance and support for your wireless range extender. visit : [https://www.routerloginnet.tips/] > Add collection level properties > --- > > Key: SOLR-11960 > URL: https://issues.apache.org/jira/browse/SOLR-11960 > Project: Solr > Issue Type: New Feature >Reporter: Peter Rusko >Assignee: Tomas Eduardo Fernandez Lobbe >Priority: Blocker > Fix For: 7.3, 8.0 > > Attachments: SOLR-11960.patch, SOLR-11960.patch, SOLR-11960.patch, > SOLR-11960.patch, SOLR-11960.patch, SOLR-11960_2.patch > > > Solr has cluster properties, but no easy and extendable way of defining > properties that affect a single collection. Collection properties could be > stored in a single zookeeper node per collection, making it possible to > trigger zookeeper watchers for only those Solr nodes that have cores of that > collection. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
