[jira] [Commented] (SOLR-14779) Solr collections gets wiped on restart
[ https://issues.apache.org/jira/browse/SOLR-14779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186320#comment-17186320 ] Antonio Dinis commented on SOLR-14779: -- The email to verify was indeed in the spam folder, but not the answers > Solr collections gets wiped on restart > --- > > Key: SOLR-14779 > URL: https://issues.apache.org/jira/browse/SOLR-14779 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.3 >Reporter: Antonio Dinis >Priority: Major > > Hello, > We have a 3 node Solr cluster (ensemble) with apache-zookeeper 3.5.5. > It works fine until we need to restart one of the nodes. Then all the content > of the collection gets deleted. > This is a production environment, and every time there is a restart or a > crash in one of the services/servers we loose lots of time restoring the > collection and work. > This is the way we start the nodes: > su - ipls004p -c "/applis/24374-iplsp-00/IPLS/solr-8.3.0/bin/solr start > -cloud -p 8987 -h s01vl9918254 -s > /applis/24374-iplsp-00/IPLS/solr-8.3.0/cloud/node1/solr -z > s01vl9918254:2181,s01vl9918256:2181,s01vl9918258:2181 -force" > This is the zoo.cfg: > # The number of milliseconds of each tick > tickTime=2000 > # The number of ticks that the initial > # synchronization phase can take > initLimit=10 > # The number of ticks that can pass between > # sending a request and getting an acknowledgement > syncLimit=5 > # the directory where the snapshot is stored. > # do not use /tmp for storage, /tmp here is just > # example sakes. > dataDir=/applis/24374-iplsp-00/IPLS/apache-zookeeper-3.5.5-bin/temp > # the port at which the clients will connect > clientPort=2181 > # the maximum number of client connections. > # increase this if you need to handle more clients > #maxClientCnxns=60 > # > # Be sure to read the maintenance section of the > # administrator guide before turning on autopurge. > # > # http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance > # > # The number of snapshots to retain in dataDir > #autopurge.snapRetainCount=3 > # Purge task interval in hours > # Set to "0" to disable auto purge feature > #autopurge.purgeInterval=1 > 4lw.commands.whitelist=mntr,conf,ruok > server.1=s01vl9918256:3889:3888 > server.2=s01vl9918258:3889:3888 > server.3=s01vl9918254:3889:3888 > #server.4=s01vl9918255:3889:3888 > > > Thanks in advance > -- 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-14783) Remove DIH from 9.0
[
https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186331#comment-17186331
]
Jan Høydahl commented on SOLR-14783:
{quote}Lets leave it in. It is the deregisterDriver permission which is totally
fine to keep it, would be an ugly deal breaker if we were to have DIH users add
it by hand.
{quote}
Do I sense the need for Solr packages to be able to amend Java security policy?
What would that look like? How could the user make an informed choice of
whether that's tolerable?
> Remove DIH from 9.0
> ---
>
> Key: SOLR-14783
> URL: https://issues.apache.org/jira/browse/SOLR-14783
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - DataImportHandler
>Affects Versions: master (9.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can
> be removed in next major version (9)
--
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] janhoy commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
janhoy commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r478902761 ## File path: solr/solr-ref-guide/src/uploading-structured-data-store-data-with-the-data-import-handler.adoc ## @@ -1,1077 +0,0 @@ -= Uploading Structured Data Store Data with the Data Import Handler Review comment: Should this page stay in 9.x as a placeholder, but with a text explaining that DIH is no longer maintained by the project, pointing to the 3rd party package? Or should such references be in a totally new RefGuide page where all deprecated/removed features that are now packages, are listed? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on pull request #1794: SOLR-14783: Remove DIH from 9.0
janhoy commented on pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#issuecomment-682385545 Great work btw, Alexandre. DIH seems to be sprinkled in everywhere, must have been a ton of work! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1792: LUCENE-9485: Check early if Solr port 8983 is available
janhoy merged pull request #1792: URL: https://github.com/apache/lucene-solr/pull/1792 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9485) Smoke tester could abort early if Solr port 8983 is not available
[ https://issues.apache.org/jira/browse/LUCENE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186365#comment-17186365 ] ASF subversion and git services commented on LUCENE-9485: - Commit 18e5f211784d2b595c71e052c135207ae2fffad4 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=18e5f21 ] LUCENE-9485: Check early if Solr port 8983 is available (#1792) > Smoke tester could abort early if Solr port 8983 is not available > - > > Key: LUCENE-9485 > URL: https://issues.apache.org/jira/browse/LUCENE-9485 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Just a small improvement, if you have something running on port 8983, the > smoketester will not detect that until all the lucene tests are run, and you > waste time :) -- 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-9485) Smoke tester could abort early if Solr port 8983 is not available
[ https://issues.apache.org/jira/browse/LUCENE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186367#comment-17186367 ] ASF subversion and git services commented on LUCENE-9485: - Commit 1a7e53654cb644af3e4aa15aada6b915b7176331 in lucene-solr's branch refs/heads/branch_8x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1a7e536 ] LUCENE-9485: Check early if Solr port 8983 is available (#1792) (cherry picked from commit 18e5f211784d2b595c71e052c135207ae2fffad4) > Smoke tester could abort early if Solr port 8983 is not available > - > > Key: LUCENE-9485 > URL: https://issues.apache.org/jira/browse/LUCENE-9485 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Just a small improvement, if you have something running on port 8983, the > smoketester will not detect that until all the lucene tests are run, and you > waste time :) -- 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-9485) Smoke tester could abort early if Solr port 8983 is not available
[ https://issues.apache.org/jira/browse/LUCENE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-9485: Fix Version/s: 8.7 > Smoke tester could abort early if Solr port 8983 is not available > - > > Key: LUCENE-9485 > URL: https://issues.apache.org/jira/browse/LUCENE-9485 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Just a small improvement, if you have something running on port 8983, the > smoketester will not detect that until all the lucene tests are run, and you > waste time :) -- 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-9485) Smoke tester could abort early if Solr port 8983 is not available
[ https://issues.apache.org/jira/browse/LUCENE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved LUCENE-9485. - Resolution: Fixed Thanks for review [~houston] > Smoke tester could abort early if Solr port 8983 is not available > - > > Key: LUCENE-9485 > URL: https://issues.apache.org/jira/browse/LUCENE-9485 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Just a small improvement, if you have something running on port 8983, the > smoketester will not detect that until all the lucene tests are run, and you > waste time :) -- 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] janhoy commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
janhoy commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-682393007 Ok, will give it another try soon. Btw - should we set `SOLR_JETTY_HOST` as an `ENV` or `ARG` or something? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9447) Make BEST_COMPRESSION compress more aggressively?
[ https://issues.apache.org/jira/browse/LUCENE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186392#comment-17186392 ] ASF subversion and git services commented on LUCENE-9447: - Commit 4787042f3eaef2aa364fdd43b967e93dcedf2c19 in lucene-solr's branch refs/heads/master from Simon Willnauer [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4787042 ] LUCENE-9447: suppress DeflateWithPresetCompressingStoredFieldsData since it doesn't add any attributes > Make BEST_COMPRESSION compress more aggressively? > - > > Key: LUCENE-9447 > URL: https://issues.apache.org/jira/browse/LUCENE-9447 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 50m > Remaining Estimate: 0h > > The Lucene86 codec supports setting a "Mode" for stored fields compression, > that is either "BEST_SPEED", which translates to blocks of 16kB or 128 > documents (whichever is hit first) compressed with LZ4, or > "BEST_COMPRESSION", which translates to blocks of 60kB or 512 documents > compressed with DEFLATE with default compression level (6). > After looking at indices that spent most disk space on stored fields > recently, I noticed that there was quite some room for improvement by > increasing the block size even further: > ||Block size||Stored fields size|| > |60kB|168412338| > |128kB|130813639| > |256kB|113587009| > |512kB|104776378| > |1MB|100367095| > |2MB|98152464| > |4MB|97034425| > |8MB|96478746| > For this specific dataset, I had 1M documents that each had about 2kB of > stored fields each and quite some redundancy. > This makes me want to look into bumping this block size to maybe 256kB. It > would be interesting to re-do the experiments we did on LUCENE-6100 to see > how this affects the merging speed. That said I don't think it would be > terrible if the merging time increased a bit given that we already offer the > BEST_SPEED option for CPU-savvy users. -- 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-9447) Make BEST_COMPRESSION compress more aggressively?
[ https://issues.apache.org/jira/browse/LUCENE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186394#comment-17186394 ] ASF subversion and git services commented on LUCENE-9447: - Commit f5252621970077b5996d575ee91cfc07fc0243af in lucene-solr's branch refs/heads/branch_8x from Simon Willnauer [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f525262 ] LUCENE-9447: suppress DeflateWithPresetCompressingStoredFieldsData since it doesn't add any attributes > Make BEST_COMPRESSION compress more aggressively? > - > > Key: LUCENE-9447 > URL: https://issues.apache.org/jira/browse/LUCENE-9447 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 50m > Remaining Estimate: 0h > > The Lucene86 codec supports setting a "Mode" for stored fields compression, > that is either "BEST_SPEED", which translates to blocks of 16kB or 128 > documents (whichever is hit first) compressed with LZ4, or > "BEST_COMPRESSION", which translates to blocks of 60kB or 512 documents > compressed with DEFLATE with default compression level (6). > After looking at indices that spent most disk space on stored fields > recently, I noticed that there was quite some room for improvement by > increasing the block size even further: > ||Block size||Stored fields size|| > |60kB|168412338| > |128kB|130813639| > |256kB|113587009| > |512kB|104776378| > |1MB|100367095| > |2MB|98152464| > |4MB|97034425| > |8MB|96478746| > For this specific dataset, I had 1M documents that each had about 2kB of > stored fields each and quite some redundancy. > This makes me want to look into bumping this block size to maybe 256kB. It > would be interesting to re-do the experiments we did on LUCENE-6100 to see > how this affects the merging speed. That said I don't think it would be > terrible if the merging time increased a bit given that we already offer the > BEST_SPEED option for CPU-savvy users. -- 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-14785) Update synonyms by API and reload collection in Solr
[
https://issues.apache.org/jira/browse/SOLR-14785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-14785.
---
Resolution: Invalid
Please raise questions like this on the user's list, we try to reserve JIRAs
for known bugs/enhancements rather than usage questions or a support portal.
See:
http://lucene.apache.org/solr/community.html#mailing-lists-irc there are links
to both Lucene and Solr mailing lists there.
A _lot_ more people will see your question on that list and may be able to help
more quickly.
You might want to review:
https://wiki.apache.org/solr/UsingMailingLists
If it's determined that this really is a code issue or enhancement to Lucene or
Solr and not a configuration/usage problem, we can raise a new JIRA or reopen
this one.
It's usually not required to have synonyms at both index and query time, so
that's a bit odd but I doubt it's your problem.
I'd start by using the admin UI to see if you've updated the schema you think
you did as a sanity check. You should be able to view it through the admin UI.
Then I'd add "&debug=query" to the URL and see how the query is actually
parsed, perhaps that'll give you a hint.
> Update synonyms by API and reload collection in Solr
>
>
> Key: SOLR-14785
> URL: https://issues.apache.org/jira/browse/SOLR-14785
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 8.6.1
>Reporter: Gitterh
>Priority: Major
>
> I am using Solr 8.6.1, started in solrcloud mode.
> The field type is
> ```
> {
> "add-field-type" : {
> "name":"articleTitle",
> "positionIncrementGap":100,
> "multiValued":false,
> "class":"solr.TextField",
> "indexAnalyzer":{
> "tokenizer":\{ "class":"solr.StandardTokenizerFactory" },
> "filters":[
> \{ "class":"solr.LowerCaseFilterFactory" },
> \{ "class":"solr.ManagedStopFilterFactory", "managed":"english" },
> \{ "class":"solr.ManagedSynonymGraphFilterFactory", "managed":"english" },
> \{ "class":"solr.FlattenGraphFilterFactory" },
> \{ "class":"solr.PorterStemFilterFactory" }
> ]
> },
> "queryAnalyzer":{
> "tokenizer":\{ "class":"solr.StandardTokenizerFactory" },
> "filters":[
> \{ "class":"solr.LowerCaseFilterFactory" },
> \{ "class":"solr.ManagedStopFilterFactory", "managed":"english" },
> \{ "class":"solr.ManagedSynonymGraphFilterFactory", "managed":"english" },
> \{ "class":"solr.PorterStemFilterFactory" }
> ]
> }
> }
> }
> ```
> After I add a document
> ```
> {
> "id": 100,
> "articleTitle": "Best smartphone"
> }
> ```
> I update the synonyms list by API
> ```
> curl -X PUT -H 'Content-type:application/json' --data-binary '["iphone",
> "smartphone"]'
> "http://localhost:8983/solr/articles/schema/analysis/synonyms/english";
> ```
> and reload the collection by API
> ```
> http://localhost:8983/solr/admin/collections?action=RELOAD&name=articles
> ```
> However when I try to search the documents don't pop-up.
> ```
> http://localhost:8983/solr/articles/select?q=articleTitle:iphone
> ```
> No result are returned. I expected that added document will be returned.
> It works only if I first update the synonyms list and after that add the
> document into collection.
> How to configure Solr to find the documents by synonyms if the synonyms are
> changed after documents are created?
--
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] arafalov commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
arafalov commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479248434 ## File path: solr/solr-ref-guide/src/uploading-structured-data-store-data-with-the-data-import-handler.adoc ## @@ -1,1077 +0,0 @@ -= Uploading Structured Data Store Data with the Data Import Handler Review comment: @ctargett , your opinion would be very valued on the documentation part. Currently, the patch deletes all DIH references and pages except for history and new mention in significant-changes. I did it to make sure I did not leave any dangling cross-references or files. We can put it back or cross-link somewhere else as you think is best. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9487) add a null check on BooleanWeight
Jehyun Lee created LUCENE-9487: -- Summary: add a null check on BooleanWeight Key: LUCENE-9487 URL: https://issues.apache.org/jira/browse/LUCENE-9487 Project: Lucene - Core Issue Type: Bug Reporter: Jehyun Lee There is no null check for scorer in BooleanWeight.explain() scorer() method is nullable, but the result of the method do not check it. -- 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-9487) Add a null check on BooleanWeight
[ https://issues.apache.org/jira/browse/LUCENE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jehyun Lee updated LUCENE-9487: --- Summary: Add a null check on BooleanWeight (was: add a null check on BooleanWeight) > Add a null check on BooleanWeight > - > > Key: LUCENE-9487 > URL: https://issues.apache.org/jira/browse/LUCENE-9487 > Project: Lucene - Core > Issue Type: Bug >Reporter: Jehyun Lee >Priority: Major > > There is no null check for scorer in BooleanWeight.explain() > scorer() method is nullable, but the result of the method do not check it. -- 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] jeng832 opened a new pull request #1795: LUCENE-9487: Add a null check on BooleanWeight
jeng832 opened a new pull request #1795: URL: https://github.com/apache/lucene-solr/pull/1795 There is no null check for scorer in BooleanWeight.explain() Signed-off-by: jeng832 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] 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. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] 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) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9487) Add a null check on BooleanWeight
[ https://issues.apache.org/jira/browse/LUCENE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jehyun Lee updated LUCENE-9487: --- Description: There is no null check for scorer in BooleanWeight.explain() scorer() method is nullable, but the result of the method do not check it. [https://github.com/apache/lucene-solr/pull/1795] was: There is no null check for scorer in BooleanWeight.explain() scorer() method is nullable, but the result of the method do not check it. > Add a null check on BooleanWeight > - > > Key: LUCENE-9487 > URL: https://issues.apache.org/jira/browse/LUCENE-9487 > Project: Lucene - Core > Issue Type: Bug >Reporter: Jehyun Lee >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is no null check for scorer in BooleanWeight.explain() > scorer() method is nullable, but the result of the method do not check it. > > [https://github.com/apache/lucene-solr/pull/1795] -- 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-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186540#comment-17186540 ] ASF subversion and git services commented on LUCENE-9433: - Commit 69fa5a00fb3671d375997eedb864992811e676c5 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=69fa5a0 ] LUCENE-9433: Remove Ant support from trunk > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14786) Delete SOLR-2452.patch.hack.pl
Alexandre Rafalovitch created SOLR-14786:
Summary: Delete SOLR-2452.patch.hack.pl
Key: SOLR-14786
URL: https://issues.apache.org/jira/browse/SOLR-14786
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Components: scripts and tools
Reporter: Alexandre Rafalovitch
Assignee: Alexandre Rafalovitch
{color:#1d1c1d}dev-tools/scripts/SOLR-2452.patch.hack.pl is a script leftover
from file system reorganization 9 years ago (SOLR-2452, Solr 3.4).
{color}
{color:#1d1c1d}It is definitely not needed, especially as we try to clean up
packages and it keeps showing up in path/component searches.{color}
--
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-9432) Use LinkedList instead of manual array re-sizing for better throughput.
[
https://issues.apache.org/jira/browse/LUCENE-9432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186544#comment-17186544
]
Mohammad Sadiq commented on LUCENE-9432:
I haven't abandoned this effort. Have been side-tracked with some other work.
I'll get around to this in September.
> Use LinkedList instead of manual array re-sizing for better throughput.
> ---
>
> Key: LUCENE-9432
> URL: https://issues.apache.org/jira/browse/LUCENE-9432
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Reporter: Mohammad Sadiq
>Priority: Minor
> Labels: patch-available, performance, pull-request-available
> Attachments: LUCENE-9432.patch
>
>
> I observed that using {{LinkedList}} instead of manually re-sizing and
> copying {{SegmentTermEnumFrame}}s improves red-line QPS. Does it make sense
> to include this?
--
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-9487) Add a null check on BooleanWeight
[ https://issues.apache.org/jira/browse/LUCENE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-9487. -- Resolution: Invalid In the place where you added the null check we already confirmed that the query matched, so the scorer can't be null. > Add a null check on BooleanWeight > - > > Key: LUCENE-9487 > URL: https://issues.apache.org/jira/browse/LUCENE-9487 > Project: Lucene - Core > Issue Type: Bug >Reporter: Jehyun Lee >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is no null check for scorer in BooleanWeight.explain() > scorer() method is nullable, but the result of the method do not check it. > > [https://github.com/apache/lucene-solr/pull/1795] -- 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-9487) Add a null check on BooleanWeight
[ https://issues.apache.org/jira/browse/LUCENE-9487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186554#comment-17186554 ] Alan Woodward commented on LUCENE-9487: --- It is indeed nullable, but all the cases where it could be null are actually dealt with earlier in the method (a match on a MUST_NOT clause, no matches on sub clauses, or too few matches to meet minimum-should-match requirements) > Add a null check on BooleanWeight > - > > Key: LUCENE-9487 > URL: https://issues.apache.org/jira/browse/LUCENE-9487 > Project: Lucene - Core > Issue Type: Bug >Reporter: Jehyun Lee >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is no null check for scorer in BooleanWeight.explain() > scorer() method is nullable, but the result of the method do not check it. > > [https://github.com/apache/lucene-solr/pull/1795] -- 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-9447) Make BEST_COMPRESSION compress more aggressively?
[ https://issues.apache.org/jira/browse/LUCENE-9447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186556#comment-17186556 ] Adrien Grand commented on LUCENE-9447: -- Thanks [~simonw]! > Make BEST_COMPRESSION compress more aggressively? > - > > Key: LUCENE-9447 > URL: https://issues.apache.org/jira/browse/LUCENE-9447 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Fix For: 8.7 > > Time Spent: 50m > Remaining Estimate: 0h > > The Lucene86 codec supports setting a "Mode" for stored fields compression, > that is either "BEST_SPEED", which translates to blocks of 16kB or 128 > documents (whichever is hit first) compressed with LZ4, or > "BEST_COMPRESSION", which translates to blocks of 60kB or 512 documents > compressed with DEFLATE with default compression level (6). > After looking at indices that spent most disk space on stored fields > recently, I noticed that there was quite some room for improvement by > increasing the block size even further: > ||Block size||Stored fields size|| > |60kB|168412338| > |128kB|130813639| > |256kB|113587009| > |512kB|104776378| > |1MB|100367095| > |2MB|98152464| > |4MB|97034425| > |8MB|96478746| > For this specific dataset, I had 1M documents that each had about 2kB of > stored fields each and quite some redundancy. > This makes me want to look into bumping this block size to maybe 256kB. It > would be interesting to re-do the experiments we did on LUCENE-6100 to see > how this affects the merging speed. That said I don't think it would be > terrible if the merging time increased a bit given that we already offer the > BEST_SPEED option for CPU-savvy users. -- 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-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-9433: --- Description: Items that may need to be addressed: * -Testing with OpenJDK early access releases- * Mavenizing * Test speed (?) * -Update any mentions of ant in the ref guide- (on EOE fork) * -Update Confluence, in particular "how to contribute"- * -Update Jenkins to not try to run ant anything- * -make an eclipse task (netbeans too?)- * -various documentation (e.g. README/INSTALL) files still needs to be converted to gradle- (on EOE fork) * fix some relative links in javadocs which contain ant module names * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, and some in the README.md. This one should probably be its own JIRA since it'll require quite a bit of verification... * Make "the best damn beasting script in the world" work with the Gradle build. was: Items that may need to be addressed: * -Testing with OpenJDK early access releases- * Mavenizing * Test speed (?) * -Update any mentions of ant in the ref guide- (on EOE fork) * Update Confluence, in particular "how to contribute" * Update Jenkins to not try to run ant anything * make an eclipse task (netbeans too?) * -various documentation (e.g. README/INSTALL) files still needs to be converted to gradle- (on EOE fork) * fix some relative links in javadocs which contain ant module names * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, and some in the README.md. This one should probably be its own JIRA since it'll require quite a bit of verification... * Make "the best damn beasting script in the world" work with the Gradle build. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * -Update Confluence, in particular "how to contribute"- > * -Update Jenkins to not try to run ant anything- > * -make an eclipse task (netbeans too?)- > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- 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-14784) Reproducible failure for DirectUpdateHandlerTest
[ https://issues.apache.org/jira/browse/SOLR-14784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186560#comment-17186560 ] Adrien Grand commented on SOLR-14784: - This suggests that there is a file that doesn't get closed on all paths. I'll dig. > Reproducible failure for DirectUpdateHandlerTest > > > Key: SOLR-14784 > URL: https://issues.apache.org/jira/browse/SOLR-14784 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Affects Versions: master (9.0) >Reporter: Erick Erickson >Priority: Major > Attachments: DirectUpdateHandlerTest-fail.txt, > DirectUpdateHandlerTest-success.xml > > > This is rather weird. It apparently was introduced by LUCENE-9456, but that > seems odd. Although I do note that that push may do some different error > handling, perhaps Solr needs to accommodate that. > Of course it doesn't necessarily reproduce with other seeds. > [~jpountz] do you have any hints? > Reproduce 100% with: > ./gradlew :solr:core:test --tests > "org.apache.solr.update.DirectUpdateHandlerTest" > -Ptests.seed=2BE3A8682E5E346D -Ptests.multiplier=2 -Ptests.badapples=false > -Ptests.file.encoding=US-ASCII > -- 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-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-9433. Fix Version/s: master (9.0) Resolution: Fixed I pushed this again just now. See LUCENE-9475 for additional cleanup items. > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * -Update any mentions of ant in the ref guide- (on EOE fork) > * -Update Confluence, in particular "how to contribute"- > * -Update Jenkins to not try to run ant anything- > * -make an eclipse task (netbeans too?)- > * -various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle- (on EOE fork) > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... > * Make "the best damn beasting script in the world" work with the Gradle > build. -- 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] HoustonPutman commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
HoustonPutman commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-682594992 Its currently set as an ENV, the last line of the large ENV section. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14787) Inequality support in Payload Check query parser
Kevin Watters created SOLR-14787:
Summary: Inequality support in Payload Check query parser
Key: SOLR-14787
URL: https://issues.apache.org/jira/browse/SOLR-14787
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Kevin Watters
The goal of this ticket/pull request is to support a richer set of matching and
filtering based on term payloads. This patch extends the
PayloadCheckQueryParser to add a new local param for "op"
The value of OP could be one of the following
* gt - greater than
* gte - greater than or equal
* lt - less than
* lte - less than or equal
default value for "op" if not specified is to be the current behavior of equals.
Additionally to the operation you can specify a threshold local parameter
This will provide the ability to search for the term "cat" so long as the
payload has a value of greater than 0.75.
One use case is to classify a document into various categories with an
associated confidence or probability that the classification is correct. That
can be indexed into a delimited payload field. The searches can find and match
documents that were tagged with the "cat" category with a confidence of greater
than 0.5.
Example Document
{code:java}
{
"id":"doc_1",
"classifications_payload":["cat|0.75 dog|2.0"]
}
{code}
Example Syntax
{code:java}
{!payload_check f=classifications_payload payloads='1' op='gt'
threshold='0.5'}cat {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] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-9475:
---
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven.
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* Move Jenkins over to use Gradle only
** Nightlies
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs which contain ant module names (?)
> * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
> and some in the README.md. This one should probably be its own JIRA since
> it'll require quite a bit of verification...
> * Make "the best damn beasting script in the world" work with the Gradle
> build.
> * Update the release documentation to reflect Gradle (LUCENE-9488)
--
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
[jira] [Created] (LUCENE-9488) Update release process to work with Gradle.
Erick Erickson created LUCENE-9488: -- Summary: Update release process to work with Gradle. Key: LUCENE-9488 URL: https://issues.apache.org/jira/browse/LUCENE-9488 Project: Lucene - Core Issue Type: Improvement Components: general/build Reporter: Erick Erickson The release process needs to reflect using Gradle rather than Ant. I suspect this will be a significant task, thus it has its own JIRA -- 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-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186564#comment-17186564
]
ASF subversion and git services commented on LUCENE-9475:
-
Commit da8ea70682669ca3045f9a6ec26b0d1f6b7837e2 in lucene-solr's branch
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=da8ea70 ]
LUCENE-9475: Enhance the Gradle build as necessary after removing Ant support
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs which contain ant module names (?)
> * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
> and some in the README.md. This one should probably be its own JIRA since
> it'll require quite a bit of verification...
> * Make "the best damn beasting script in the world" work with the Gradle
> build.
> * Update the release documentation to reflect Gradle (LUCENE-9488)
--
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] thelabdude commented on a change in pull request #1769: SOLR-11245: Absorb the docker-solr repo.
thelabdude commented on a change in pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#discussion_r479380781 ## File path: solr/docker/docs/docker-networking.md ## @@ -0,0 +1,249 @@ +Example of Zookeeper and Solr cluster with Docker networking + + +_Note: this article dates from Jan 2016. While this approach would still work, in Jan 2019 this would typically done with Docker cluster and orchestration tools like Kubernetes. See for example [this blog post](https://lucidworks.com/2019/02/07/running-solr-on-kubernetes-part-1/)._ + +In this example I'll create a cluster with 3 ZooKeeper nodes and 3 Solr nodes, distributed over 3 machines (trinity10, trinity20, trinity30). +I'll use an overlay network, specify fixed IP addresses when creating containers, and I'll pass in explicit `/etc/hosts` entries to make sure they are available even when nodes are down. +I won't show the configuration of the key-value store to configuration to enable networking, see [the docs](https://docs.docker.com/engine/userguide/networking/get-started-overlay/) for that. +I'll not use Docker Swarm in this example, but specifically place and configure containers where I want them by ssh'ing into the appropriate Docker host. + +To make this example easier to understand I'll just use shell commands. +For actual use you may want to use a fancier deployment tool like [Fabric](http://www.fabfile.org). + +Note: this example requires Docker 1.10. + +I'll run these commands from the first machine, trinity10. + +Create a network named "netzksolr" for this cluster. The `--ip-range` specifies the range of +addresses to use for containers, whereas the `--subnet` specifies all possible addresses in this +network. So effectively, addresses in the subnet but outside the range are reserved for containers +that specifically use the `--ip` option. + +``` +docker network create --driver=overlay --subnet 192.168.22.0/24 --ip-range=192.168.22.128/25 netzksolr +``` + +As a simple test, check the automatic assignment and specific assignment work: + +``` +mak@trinity10:~$ docker run -i --rm --net=netzksolr busybox ip -4 addr show eth0 | grep inet Review comment: let's remove `mak@trinity10:~$` from the commands This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14788) Solr: The Next Big Thing
Mark Robert Miller created SOLR-14788: - Summary: Solr: The Next Big Thing Key: SOLR-14788 URL: https://issues.apache.org/jira/browse/SOLR-14788 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Robert Miller I have stolen this title from Ishan or Noble and Ishan. This issue is meant to capture the work of a small team that is forming to push Solr and SolrCloud to the next phase. I have kicked off the work with an effort to create a very fast and solid base. That work is not 100% done, but it's ready to join the fight. Tim Potter has started giving me a tremendous hand in finishing up. Ishan and Noble have already contributed support and testing and have plans for additional work to shore up some of our current shortcomings. Others have expressed an interest in helping and hopefully they will pop up here as well. Let's organize and discuss our efforts here and in various sub issues. -- 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] [Closed] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller closed SOLR-14636.
-
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
> h2. Getting Started with the Solr Reference Branch
> [AYoungLadysIllustratedPrimer|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
> # Book One: [The 10 Minute
> Introduction|https://www.dropbox.com/s/x9k1m3zmjucc422/Book%20One%3A%20The%2010%20Minute%20Introduction.mp4?dl=0]
> # Book Two: A Brief, High Level Overview of the Changes
> <{color:#de350b}*_WORK IN PROGRESS_*{color}>
> ## Book Two: Process Intro: Section 1: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 1-2: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/a1ipp0n3gtbf29m/Book%20Two%3A%20Process%20Intro%3A%20Section%202-2%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
> Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
> XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
> ## Book Two: Process Intro: Section 4: [Back to a Few Broad
> Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 4-2: [Back to a Few Broad
> Problem|https://www.dropbox.com/s/1olr1v99t73uoml/Book%20Two%3A%20Process%20Intro%3A%20Section%204-2%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 6: [Step 5, Own the
> World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
> # Book Three: Diving In: Section1: [LifeCycle, LifeCycle,
> LifeCycle|https://www.dropbox.com/s/zno3qftzekyo3ac/Book%20Three%3A%20Diving%20In%3A%20Section%201%3A%20LifeCycle%2C%2CLifeCycle%2CLifeCycle.m4v?dl=0]
> # Book Three: Diving In: Section 2-1: [Thread
> Managment|https://www.dropbox.com/s/myds10jju7qfvi5/Book%20Three%3A%20Diving%20In%3A%20Section%202-1%3A%20Thread%20Managment.mp4?dl=0]
> # Book Three: Div
[jira] [Resolved] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Robert Miller resolved SOLR-14636.
---
Resolution: Staged
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
> h2. Getting Started with the Solr Reference Branch
> [AYoungLadysIllustratedPrimer|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
> # Book One: [The 10 Minute
> Introduction|https://www.dropbox.com/s/x9k1m3zmjucc422/Book%20One%3A%20The%2010%20Minute%20Introduction.mp4?dl=0]
> # Book Two: A Brief, High Level Overview of the Changes
> <{color:#de350b}*_WORK IN PROGRESS_*{color}>
> ## Book Two: Process Intro: Section 1: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 1-2: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/a1ipp0n3gtbf29m/Book%20Two%3A%20Process%20Intro%3A%20Section%202-2%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
> Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
> XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl=0]
> ## Book Two: Process Intro: Section 4: [Back to a Few Broad
> Problems|https://www.dropbox.com/s/tmeayi23p0rmgda/Book%20Two%3A%20Process%20Intro%3A%20Section%204%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 4-2: [Back to a Few Broad
> Problem|https://www.dropbox.com/s/1olr1v99t73uoml/Book%20Two%3A%20Process%20Intro%3A%20Section%204-2%3A%20Back%20to%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 6: [Step 5, Own the
> World|https://www.dropbox.com/s/usdki6wb1qy6fy9/Book%20Two%3A%20Process%20Intro%3A%20Section%206%3A%20Step%205%2C%20Own%20World.m4v?dl=0]
> # Book Three: Diving In: Section1: [LifeCycle, LifeCycle,
> LifeCycle|https://www.dropbox.com/s/zno3qftzekyo3ac/Book%20Three%3A%20Diving%20In%3A%20Section%201%3A%20LifeCycle%2C%2CLifeCycle%2CLifeCycle.m4v?dl=0]
> # Book Three: Diving In: Section 2-1: [Thread
> Managment|https://www.dropbox.com/s/myds10jju7qfvi5/Book%20Three%3A%20Diving%20In%3A%20Section%202-1%3A%20Thread%20Managment.mp4
[jira] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-9475:
---
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * Verify reference guide build works under Gradle
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs which contain ant module names (?)
> * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
> and some in the README.md. T
[jira] [Commented] (SOLR-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186646#comment-17186646 ] Cassandra Targett commented on SOLR-14616: -- I’m one of the ones who said something early on about being clear about a “replacement” for CDCR, but I didn’t mean "replace with code". My point was only that users ask about how to approach Solr disaster recovery/failover *all the time*. Today the unfortunate answer is CDCR. When we remove CDCR, we still have the question. If we replaced the CDCR section in the Ref Guide with a single page that discussed the available options for roll-your-own DR/failover, we can answer the question and the problem, such as it is, IMO is resolved. Instead of looking for contributors to "own" CDCR as a plugin - really, the design is flawed - I feel we should encourage contributions to develop plugins that make rolling your own DR easier. For example, one alternative is to have an ETL process write to a Kafka queue that can be consumed by separate DCs - can Solr easily ingest a Kafka queue? If not, let's see if we can encourage someone to make a plugin to make that easier. I agree with Ishan it's better to get rid of it sooner rather than later (but I feel it should be 9.0, not 8.7) - the longer it stays around the more people will try it and a few will become dependent on it. While people are in production with it today, as Erick points out they've had to do a ton of heavy lifting to get it right. While removing it in 9.0 will make the migration from 8.x to 9.0 harder for those people initially, in the end it will make the Ops of Solr easier because they can drop at least some of the custom stuff they had to put in place just to have a functional system with CDCR. We only need to be clear on this point in docs and messaging. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 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] (SOLR-14788) Solr: The Next Big Thing
[ https://issues.apache.org/jira/browse/SOLR-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186647#comment-17186647 ] Mark Robert Miller commented on SOLR-14788: --- Current development is happening at: [https://github.com/apache/lucene-solr/tree/reference_impl_dev] I have a local Jenkins cluster that runs with some real hardware and a variety of VM's on OSX with access from 1 to 4 processors. There are currently two branches so that one branch can remain more stable perhaps and the dev branch can be run through the Jenkins cluster a bit before getting promoted. The promotion branch is: [https://github.com/apache/lucene-solr/tree/reference_impl] It's not critical, but I have been marking commits with an incrementing ID. The main help of this is when cherry picking to the stable branch - it's easier to track what you have and need to get with an id to line up. We don't need a universal incremental id, each could use their own, even of their own scheme, but having something simple prepending the commit message helps track merges. We can also, of course, discuss shaking this process up a bit, but that is currently the state of the world. > Solr: The Next Big Thing > > > Key: SOLR-14788 > URL: https://issues.apache.org/jira/browse/SOLR-14788 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Robert Miller >Priority: Critical > > I have stolen this title from Ishan or Noble and Ishan. > This issue is meant to capture the work of a small team that is forming to > push Solr and SolrCloud to the next phase. > I have kicked off the work with an effort to create a very fast and solid > base. That work is not 100% done, but it's ready to join the fight. > Tim Potter has started giving me a tremendous hand in finishing up. Ishan and > Noble have already contributed support and testing and have plans for > additional work to shore up some of our current shortcomings. > Others have expressed an interest in helping and hopefully they will pop up > here as well. > Let's organize and discuss our efforts here and in various sub issues. -- 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-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186659#comment-17186659 ] Ishan Chattopadhyaya commented on SOLR-14616: - Thanks for your thoughtful response. bq. If we replaced the CDCR section in the Ref Guide with a single page that discussed the available options for roll-your-own DR/failover, we can answer the question and the problem, such as it is, IMO is resolved. I shall attempt to put together a page describing DR best practices that I have learnt from the field. Shall seek review and consensus on that before adding it on our reference guide so others can add their ideas as well. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 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
[GitHub] [lucene-solr] ErickErickson opened a new pull request #1796: LUCENE-9475: Enhance the Gradle build as necessary after removing Ant…
ErickErickson opened a new pull request #1796: URL: https://github.com/apache/lucene-solr/pull/1796 This PR is just a starting point. I grepped through the source code to try to find all the references to "ant". Do you have any idea how many words in our code have "ant" in them? Like constant, spanTerm, ;) Over 7,000 if you're curious. Anyway, I pared all those down and there are a few files (23 or so) that reference ant legitimately. I fixed some that were simple, things like how to run a particular test, but for a number of them I just added //nocommit so we can find them easily. Here are some examples of things I punted on and just added //nocommits for: - The lucene/benchmarks. - UnicodeProps.java references an "ant unicode-data" target. - TokebnInfoDictionaryTest has a reference to an "ant test-tools" target etc. I'll check against the 8x version for the targets I didn't immediately see a corresponding Gradle task for, and if the are missing on ant I'll feel safe to remove them. Also I haven't poked around (yet) in the gradle build for tasks that weren't named the same but did the same thing. I'll start working on some of the nocommits, any hints welcome. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
ctargett commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479437696 ## File path: solr/solr-ref-guide/src/major-changes-in-solr-9.adoc ## @@ -122,6 +122,8 @@ _(raw; not yet edited)_ and "follower". This includes API calls for the replication handler and metrics. For rolling upgrades into 9.0, you need to be on Solr version 8.7 or greater. Some metrics also changed, alerts and monitors on Solr KPIs that mention "master" or "slave" will also now be "leader" and "follower" + +* SOLR-14783: Data Imprort Handler (DIH) has been removed from Solr. The community package is available at: https://github.com/rohitbemax/dataimporthandler (Alexandre Rafalovitch) Review comment: Typo in "Imprort" here This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
epugh commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479440152 ## File path: solr/README.md ## @@ -142,8 +141,7 @@ server/ example/ Contains example documents and an alternative Solr home - directory containing examples of how to use the Data Import Handler, - see example/example-DIH/README.md for more information. + directory containing variours examples. Review comment: One more typo ;-) "various" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on pull request #1769: SOLR-11245: Absorb the docker-solr repo.
HoustonPutman commented on pull request #1769: URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-682977355 Thanks for reviewing the docs as well. I plan on migrating a lot of the docs to the ref guide, but I think we should probably leave a bulk of that work to a separate PR. The earlier we get this PR merged, the easier it will be to break up the work we want to do into separate JIRAs that can be attacked independently. (more extensive documentation, reduction of the scripts, make it solr more "cloud native", a plan for release images, etc) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ctargett commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
ctargett commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479452123 ## File path: solr/solr-ref-guide/src/uploading-structured-data-store-data-with-the-data-import-handler.adoc ## @@ -1,1077 +0,0 @@ -= Uploading Structured Data Store Data with the Data Import Handler Review comment: It's an interesting question, and I don't have an answer. I dislike trying to keep a mostly blank page around, because each version of the Guide should stand by itself and be for the version it describes - 9.0 won't have DIH so the page shouldn't be there. That's a general principle. But, the reality is people will look for it and may be lost when they don't find it. I don't have an ideal solution generally, but in this case I coincidentally happen to be planning a mass re-org of the entire Ref Guide (SOLR-1) for 9.0. One of the things I'm considering is to consolidate the content of some pages which will remove some. Other pages I intend to rename. So, I'll need to find an answer to the problem. I'm keeping track of these changes in a spreadsheet, in case we need it for however we choose to handle it. Right now I've added this page to my list of changes (with other 9.0 removals that have happened), so I'm OK if you go forward removing it with this effort. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14444) Ref Guide Redesign Phase 2: Page Organization Overhaul
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186741#comment-17186741 ] Alexandre Rafalovitch commented on SOLR-1: -- This is exciting! I don't have specific deep thoughts yet, but I certainly have some things that I find confusing. One example is that I think solrconfig.xml is buried too deep currently. Mostly because of the request handlers and schemaless mode. It should be explained/referenced much earlier as people need to understand what that final part of the URL is and that they can create their own query end points with defaults. As a counter-point to myself, maybe if we have very little in solrconfig.xml and the rest in the overlay, we could drive the conversation there instead. But something along these lines. > Ref Guide Redesign Phase 2: Page Organization Overhaul > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Major > > SOLR-14173 changed the look & feel of the Ref Guide, and left one glaring > problem unresolved: our top-level categories are far too many for that sort > of design. > This issue will track a full reconsideration of the Ref Guide organization. I > have a couple of thoughts and will update this issue with those when I get > started on it; for now this is a placeholder issue for future work. -- 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-14783) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186744#comment-17186744 ] David Eric Pugh commented on SOLR-14783: [~arafalov] [~rohitbemax] it would be nice if at the same time we are removing these docs about DIH from the Solr Ref Guide, that we moved over the deleted pages to the https://github.com/rohitbemax/dataimporthandler project. I checked and it looks like GitHub formats a .adoc file nicely! > Remove DIH from 9.0 > --- > > Key: SOLR-14783 > URL: https://issues.apache.org/jira/browse/SOLR-14783 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: master (9.0) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can > be removed in next major version (9) -- 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-14783) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186747#comment-17186747 ] Cassandra Targett commented on SOLR-14783: -- bq. it would be nice if at the same time we are removing these docs about DIH from the Solr Ref Guide, that we moved over the deleted pages to the https://github.com/rohitbemax/dataimporthandler project. Shouldn't that have already happened when the code was spun out? > Remove DIH from 9.0 > --- > > Key: SOLR-14783 > URL: https://issues.apache.org/jira/browse/SOLR-14783 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: master (9.0) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can > be removed in next major version (9) -- 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-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186751#comment-17186751 ] Cassandra Targett commented on SOLR-14616: -- bq. I shall attempt to put together a page describing DR best practices that I have learnt from the field That's great, thanks. I'll keep my eye out for it to help. I don't think we need to be extremely detailed with step-by-step instructions for each alternative. I think that would be unnecessarily limiting for users and really hard for us to maintain. General info about the concepts and links to tools that we've seen used would be sufficient to start with IMO. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 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
[GitHub] [lucene-solr] dsmiley opened a new pull request #1797: LUCENE ExitableReaderException public constructor
dsmiley opened a new pull request #1797: URL: https://github.com/apache/lucene-solr/pull/1797 And cross-link javadocs with TimeLimitingCollector This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett updated LUCENE-9475:
--
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* Verify reference guide build works under Gradle
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs which contain ant module names (?)
> * de
[jira] [Commented] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186752#comment-17186752
]
Cassandra Targett commented on LUCENE-9475:
---
Crossed off the Verify Reference Guide builds item. That's been working fine
for a few days now; Uwe is still working through other issues in LUCENE-9474,
though.
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs which contain ant module names (?)
> * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
> and some in the README.md. This one should probably be its own JIRA since
> it'll require quite a bit of verification...
> * Make "the best damn beasting script in the world" work with the Gradle
> build.
> * Update the release documentation to reflect Gradle (LUCENE-9488)
> * Clean up anything in lucene/tools
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
Houston Putman created SOLR-14789: - Summary: Absorb and maintain docker-solr functionality for Solr 9.0+ Key: SOLR-14789 URL: https://issues.apache.org/jira/browse/SOLR-14789 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Components: Docker Affects Versions: master (9.0) Reporter: Houston Putman Assignee: Houston Putman Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. -- 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-11245) Make Solr and it's Dockerfile more cloud native
[ https://issues.apache.org/jira/browse/SOLR-11245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-11245: -- Summary: Make Solr and it's Dockerfile more cloud native (was: Cloud native Dockerfile) > Make Solr and it's Dockerfile more cloud native > --- > > Key: SOLR-11245 > URL: https://issues.apache.org/jira/browse/SOLR-11245 > Project: Solr > Issue Type: New Feature > Components: Build >Affects Versions: 6.6 >Reporter: jay vyas >Assignee: Houston Putman >Priority: Major > Labels: docker > Time Spent: 3h 20m > Remaining Estimate: 0h > > SOLR Should have its own Dockerfile, ideally one that is cloud native (i.e. > doesn't expect anything special from the operating system in terms of user > IDs, etc), for deployment, that we can curate and submit changes to as part > of the official ASF process, rather then externally. The idea here is that > testing SOLR regression, as a microservice, is something we should be doing > as part of our continuous integration, rather then something done externally. > We have a team here that would be more then happy to do the work to port > whatever existing SOLR dockerfiles are out there into something that is ASF > maintainable, and cloud native, and easily testable, as well. -- 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-11245) Make Solr and it's Dockerfile more cloud native
[ https://issues.apache.org/jira/browse/SOLR-11245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186754#comment-17186754 ] Houston Putman commented on SOLR-11245: --- Sorry [~jayunit100] I didn't mean to highjack your issue, since it's not exactly what I am working on right now. Once SOLR-14789 get's merged, we would love your insight on and help with making Solr more cloud native. Splitting the other efforts mentioned here into separate issues under the Umbrella Solr Docker issue (SOLR-14168) > Make Solr and it's Dockerfile more cloud native > --- > > Key: SOLR-11245 > URL: https://issues.apache.org/jira/browse/SOLR-11245 > Project: Solr > Issue Type: New Feature > Components: Build >Affects Versions: 6.6 >Reporter: jay vyas >Assignee: Houston Putman >Priority: Major > Labels: docker > Time Spent: 3h 20m > Remaining Estimate: 0h > > SOLR Should have its own Dockerfile, ideally one that is cloud native (i.e. > doesn't expect anything special from the operating system in terms of user > IDs, etc), for deployment, that we can curate and submit changes to as part > of the official ASF process, rather then externally. The idea here is that > testing SOLR regression, as a microservice, is something we should be doing > as part of our continuous integration, rather then something done externally. > We have a team here that would be more then happy to do the work to port > whatever existing SOLR dockerfiles are out there into something that is ASF > maintainable, and cloud native, and easily testable, as well. -- 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-14783) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186753#comment-17186753 ] David Eric Pugh commented on SOLR-14783: Maybe it should have, but it didn't. Once we start directing people over to https://github.com/rohitbemax/dataimporthandler to answer questions about DIH etc (unless we still answer those questions on the solr-user mailing list?) then having clean up to date docs will become more important! > Remove DIH from 9.0 > --- > > Key: SOLR-14783 > URL: https://issues.apache.org/jira/browse/SOLR-14783 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: master (9.0) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can > be removed in next major version (9) -- 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-11245) Make Solr and it's Dockerfile more cloud native
[ https://issues.apache.org/jira/browse/SOLR-11245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-11245: -- Affects Version/s: (was: 6.6) master (9.0) > Make Solr and it's Dockerfile more cloud native > --- > > Key: SOLR-11245 > URL: https://issues.apache.org/jira/browse/SOLR-11245 > Project: Solr > Issue Type: New Feature > Components: Build >Affects Versions: master (9.0) >Reporter: jay vyas >Assignee: Houston Putman >Priority: Major > Labels: docker > Time Spent: 3h 20m > Remaining Estimate: 0h > > SOLR Should have its own Dockerfile, ideally one that is cloud native (i.e. > doesn't expect anything special from the operating system in terms of user > IDs, etc), for deployment, that we can curate and submit changes to as part > of the official ASF process, rather then externally. The idea here is that > testing SOLR regression, as a microservice, is something we should be doing > as part of our continuous integration, rather then something done externally. > We have a team here that would be more then happy to do the work to port > whatever existing SOLR dockerfiles are out there into something that is ASF > maintainable, and cloud native, and easily testable, as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14790) Migrate solr/docker usage documentation to the ref-guide
Houston Putman created SOLR-14790: - Summary: Migrate solr/docker usage documentation to the ref-guide Key: SOLR-14790 URL: https://issues.apache.org/jira/browse/SOLR-14790 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Docker Reporter: Houston Putman -- 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-14790) Migrate solr/docker usage documentation to the ref-guide
[ https://issues.apache.org/jira/browse/SOLR-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14790: -- Component/s: documentation Affects Version/s: master (9.0) Description: Documentation of the Solr docker image usage is currently provided in markdown files under solr/docker. These were mainly copied from the [https://github.com/docker-solr/docker-solr] repository. This documentation should be modernized and migrated to live in the ref guide so that users have easy access to the information. > Migrate solr/docker usage documentation to the ref-guide > > > Key: SOLR-14790 > URL: https://issues.apache.org/jira/browse/SOLR-14790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker, documentation >Affects Versions: master (9.0) >Reporter: Houston Putman >Priority: Major > > Documentation of the Solr docker image usage is currently provided in > markdown files under solr/docker. These were mainly copied from the > [https://github.com/docker-solr/docker-solr] repository. > This documentation should be modernized and migrated to live in the ref guide > so that users have easy access to the information. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14791) Add docker building functionality to Solr 8.x
Houston Putman created SOLR-14791: - Summary: Add docker building functionality to Solr 8.x Key: SOLR-14791 URL: https://issues.apache.org/jira/browse/SOLR-14791 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Docker Affects Versions: 8.7 Reporter: Houston Putman Solr 8.x should contain the necessary pieces to build a docker image that is somewhat compatible with the official image. This doesn't necessarily need integrated tests or extensive documentation, since it will be replaced with the official Solr docker strategy in 9.0. The [docker-solr repo|[https://github.com/docker-solr/docker-solr]] will continue to handle all remaining 8.x.y releases, so this does not need to support the functionality of handling releases or pushing to docker hub. It would be nice to backport this functionality to previous major solr branches as well (7_x, etc), to allow users the ability to build custom docker images of those versions as well. -- 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-14790) Migrate solr/docker usage documentation to the ref-guide
[ https://issues.apache.org/jira/browse/SOLR-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186761#comment-17186761 ] Cassandra Targett commented on SOLR-14790: -- I sort of keep saying this so maybe everyone knows and I'm like a broken record, but it could be part of the Ref Guide _today_ if the source file was in .adoc format. If it's easier to convert it to .adoc format while it still permanently lives in docker-solr and migrate the file itself later if/when we migrate the full code, that's a totally viable option and I can help. > Migrate solr/docker usage documentation to the ref-guide > > > Key: SOLR-14790 > URL: https://issues.apache.org/jira/browse/SOLR-14790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker, documentation >Affects Versions: master (9.0) >Reporter: Houston Putman >Priority: Major > > Documentation of the Solr docker image usage is currently provided in > markdown files under solr/docker. These were mainly copied from the > [https://github.com/docker-solr/docker-solr] repository. > This documentation should be modernized and migrated to live in the ref guide > so that users have easy access to the information. -- 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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14789: -- Priority: Blocker (was: Major) > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. -- 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-14783) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186764#comment-17186764 ] Alexandre Rafalovitch commented on SOLR-14783: -- Given the magic of version control system, those two can be parallel processes. And hopefully this issue makes it easier to identify the content that needs to be migrated. I've added the link to the specific commit to [the - already existing - issue|https://github.com/rohitbemax/dataimporthandler/issues/10] on their queue. > Remove DIH from 9.0 > --- > > Key: SOLR-14783 > URL: https://issues.apache.org/jira/browse/SOLR-14783 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: master (9.0) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can > be removed in next major version (9) -- 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-14783) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186768#comment-17186768 ] David Eric Pugh commented on SOLR-14783: Thanks [~arafalov]that totally addresses my concern! > Remove DIH from 9.0 > --- > > Key: SOLR-14783 > URL: https://issues.apache.org/jira/browse/SOLR-14783 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - DataImportHandler >Affects Versions: master (9.0) >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now that Data Import Handler (SOLR-14066) has been depreciated in 8.6, it can > be removed in next major version (9) -- 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-14790) Migrate solr/docker usage documentation to the ref-guide
[ https://issues.apache.org/jira/browse/SOLR-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186770#comment-17186770 ] Houston Putman commented on SOLR-14790: --- [~ctargett], the first step is certainly converting the existing documentation to .adoc format. At that point, whether the files live in docker-solr or solr-ref-guide doesn't matter much to me for 8.x. I think the documentation should certainly be fully migrated to the ref guide for 9.0, since that's what we are targeting for the official handover from docker-solr to lucene-solr. Since it wouldn't be much extra effort, I would vote to go ahead and put the docs into the ref guide for 8.x as well. That way any improvements we make for 9.0 can easily be backported without going to a separate repo. But I can also see the reasoning behind keeping the docs where the code lives, and for 8.x that will be docker-solr. > Migrate solr/docker usage documentation to the ref-guide > > > Key: SOLR-14790 > URL: https://issues.apache.org/jira/browse/SOLR-14790 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker, documentation >Affects Versions: master (9.0) >Reporter: Houston Putman >Priority: Major > > Documentation of the Solr docker image usage is currently provided in > markdown files under solr/docker. These were mainly copied from the > [https://github.com/docker-solr/docker-solr] repository. > This documentation should be modernized and migrated to live in the ref guide > so that users have easy access to the information. -- 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-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186773#comment-17186773 ] Cassandra Targett commented on SOLR-14656: -- [~ichattopadhyaya], since autoscaling is removed already in 9.0 but no 8.x deprecations have happened, what do you picture the deprecation in branch_8x to look like? Is it just a doc update, or would there be some code changes to make? > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- 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] dweiss commented on a change in pull request #1796: LUCENE-9475: Enhance the Gradle build as necessary after removing Ant…
dweiss commented on a change in pull request #1796:
URL: https://github.com/apache/lucene-solr/pull/1796#discussion_r479496521
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/util/UnicodeProps.java
##
@@ -1,4 +1,5 @@
// DO NOT EDIT THIS FILE! Use "ant unicode-data" to recreate.
+//nocommit do we have such a target?
Review comment:
I don't think so. If we don't then did we miss it somehow?
##
File path: solr/core/src/java/org/apache/solr/handler/export/ExportWriter.java
##
@@ -210,7 +210,7 @@ public void write(OutputStream os) throws IOException {
// That causes the totalHits and export entries in the context to _not_
get set.
// The only time that really matters is when we search against an _empty_
set. That's too obscure
// a condition to handle as part of this patch, if someone wants to pursue
it it can be reproduced with:
-// ant test -Dtestcase=StreamingTest
-Dtests.method=testAllValidExportTypes -Dtests.seed=10F13879D0D1D6AD
-Dtests.slow=true -Dtests.locale=es-PA -Dtests.timezone=America/Bahia_Banderas
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
+// gradlew test --tests *testAllValidExportTypes*
-Ptests.seed=10F13879D0D1D6AD -Ptests.slow=true -Ptests.locale=es-PA
-Ptests.timezone=America/Bahia_Banderas -Ptests.asserts=true
-Ptests.file.encoding=ISO-8859-1
Review comment:
I think this should be a qualified class.method reference (much like I
showed above).
##
File path:
lucene/backward-codecs/src/test/org/apache/lucene/index/TestManyPointsInOldIndex.java
##
@@ -36,7 +36,7 @@
//
// Compile:
// 1) temporarily remove 'extends LuceneTestCase' above (else java doesn't
see our static void main)
Review comment:
I'd look as to what this class actually does... seems weird. Classpath
below (under "run") is wrong for gradle.
##
File path:
lucene/backward-codecs/src/test/org/apache/lucene/index/TestBackwardsCompatibility.java
##
@@ -168,7 +169,7 @@ public void testCreateMoreTermsIndex() throws Exception {
Thread.sleep(10);
}
- // ant test -Dtestcase=TestBackwardsCompatibility
-Dtestmethod=testCreateSortedIndex -Dtests.codec=default
-Dtests.useSecurityManager=false -Dtests.bwcdir=/tmp/sorted
+ // gradlew -p lucene/backward-codecs test --tests *testCreateSortedIndex*
-Ptests.bwcdir=/tmp/sorted -Ptests.codec=default
-Ptests.useSecurityManager=false
Review comment:
should be --tests TestBackwardsCompatibility.testCreateSortedIndex.
A prefix wildcard may be needed (*TestBackwards...)?
##
File path:
lucene/analysis/kuromoji/src/test/org/apache/lucene/analysis/ja/dict/TokenInfoDictionaryTest.java
##
@@ -35,6 +35,7 @@
import static
org.apache.lucene.analysis.ja.dict.BinaryDictionary.ResourceScheme;
+//nocommit
Review comment:
"test-tools" shouldn't be a task. I don't know what it was doing but it
should be a regular test, perhaps grouped under a test group (and enabled by a
property).
##
File path: solr/test-framework/src/java/org/apache/solr/SolrTestCase.java
##
@@ -130,6 +131,7 @@ public static void
checkSyspropForceBeforeClassAssumptionFailure() {
*/
@Before
public void checkSyspropForceBeforeAssumptionFailure() {
+// nocommit, don't see an equivalent Gradle parameter
Review comment:
I think -Ptests.jvmargs=-Dtests.force...=true should work (didn't check).
##
File path: lucene/core/src/test/org/apache/lucene/index/Test2BPoints.java
##
@@ -31,7 +31,7 @@
import com.carrotsearch.randomizedtesting.annotations.TimeoutSuite;
// e.g. run like this: ant test -Dtestcase=Test2BPoints -Dtests.nightly=true
-Dtests.verbose=true -Dtests.monster=true
-//
+// nocommit, I don't see how to set the heap size, set in gradle.properties?
Set to 4G?
Review comment:
-Ptests.heapsize=6g
##
File path:
lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java
##
@@ -459,6 +459,7 @@
public static final boolean LEAVE_TEMPORARY;
static {
boolean defaultValue = false;
+//nocommit
Review comment:
You can remove reference to ant, but keep the rest.
##
File path:
solr/core/src/test/org/apache/solr/search/facet/SpatialHeatmapFacetsTest.java
##
@@ -39,6 +39,7 @@ public static void beforeSuperClass() throws Exception {
schemaString = "schema-spatial.xml";
configString = "solrconfig-basic.xml";
+//nocommit are we sure we do this in Gradle
Review comment:
We do. See defaults-tests.gradle.
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
-
[jira] [Resolved] (SOLR-14617) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch resolved SOLR-14617. -- Resolution: Duplicate > Remove DIH from 9.0 > --- > > Key: SOLR-14617 > URL: https://issues.apache.org/jira/browse/SOLR-14617 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > > Remove DIH from 9.0. This was deprecated in SOLR-14066. -- 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] [Closed] (SOLR-14617) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch closed SOLR-14617. To avoid confusion for others searching. > Remove DIH from 9.0 > --- > > Key: SOLR-14617 > URL: https://issues.apache.org/jira/browse/SOLR-14617 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > > Remove DIH from 9.0. This was deprecated in SOLR-14066. -- 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-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-9475:
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* Make "the best damn beasting script in the world" work with the Gradle build.
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build files (obsolete with Gradle)
> * Hoss's test rollups?
> * Enable javadocs after ant stops being used (LUCENE-9441)
> * fix some relative links in javadocs w
[jira] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-9475:
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of
post-ant cleanup, I'll do it).
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}}
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 build which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part
> of post-ant cleanup, I'll do it).
> * Remove obsolete files in root dirs of lucene and solr (like
> version.properties, now integrated into gradle)
> * Remove Maven build fi
[jira] [Created] (SOLR-14792) Remove VelocityResponseWriter from Solr 9
Erik Hatcher created SOLR-14792: --- Summary: Remove VelocityResponseWriter from Solr 9 Key: SOLR-14792 URL: https://issues.apache.org/jira/browse/SOLR-14792 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 9 Reporter: Erik Hatcher VelocityResponseWriter was deprecated in SOLR-14065. It can now be removed from 9's code branch. -- 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-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-9475:
---
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 release which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of
post-ant cleanup, I'll do it).
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 build which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of
post-ant cleanup, I'll do it).
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 release which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part
> of post-ant cleanup, I'll do it).
> * Remove obsolete files in root dirs of lucene and solr (like
> version.prop
[jira] [Commented] (SOLR-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186806#comment-17186806 ] ASF subversion and git services commented on SOLR-14616: Commit d84977eb5cde00f0e92f71837bdf9cee25e0b54a in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d84977e ] SOLR-14616: Remove CDCR > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 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] [Resolved] (SOLR-14616) Remove CDCR from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-14616. - Resolution: Fixed Thanks for all who helped, esp [~erickerickson]. I'll write up a ref guide page soon on possible high level alternatives as Cassandra suggested. > Remove CDCR from 9.0 > > > Key: SOLR-14616 > URL: https://issues.apache.org/jira/browse/SOLR-14616 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > This was deprecated in SOLR-14022 and should be removed in 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] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186810#comment-17186810
]
Cassandra Targett commented on SOLR-14656:
--
[~ab], [~ilan] - Ishan said in Slack that he thought docs were all that are
required for deprecating this since it's removed in 9.0. What do you both think
about a simple message like this on the top of all autoscaling pages in the ref
guide ({{solr-autoscaling*.adoc}}) that reads simply:
{noformat}
The autoscaling framework in its current form is deprecated and will be removed
in Solr 9.0.
A new design for this feature is currently under development in SOLR-14656 with
a goal for release with Solr 9.0.
{noformat}
When 8.7 goes out we could add something like this to the Release Notes (or
send it separately to the user list at any time):
{noformat}
As of 8.7, the autoscaling framework in Solr today has been deprecated and will
be removed in Solr 9.0.
As the framework was adopted among our user base, we discovered fundamental
flaws in its design that made continuing to support it unsustainable for our
developer community. Issues with scaling collection placement calculations and
a complex rule syntax were becoming more and more difficult to solve.
A new design and implementation of this feature is underway, with a goal of
making it available in Solr 9.0. This design will make it possible to have
autoscaling implementations available as plugins to suit various use cases and
needs (see also SOLR-14656 for details). The first plugin will be similar to
the autoscaling framework as it exists today, and other plugins are planned for
the future for larger clusters and those who would like different
implementations.
{noformat}
The 3rd paragraph there could be revised to be more or less specific, but
that's the gist of it. We could also say something about regretting the
inconvenience, etc., that's up to you guys.
Let me know if you like the Ref Guide changes, and I'll make those in branch_8x.
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
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] [Comment Edited] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186810#comment-17186810
]
Cassandra Targett edited comment on SOLR-14656 at 8/28/20, 8:55 PM:
[~ab], [~ilan] - Ishan said in Slack that he thought docs were all that are
required for deprecating this since it's removed in 9.0. What do you both think
about a simple message like this on the top of all autoscaling pages in the ref
guide ({{solr-autoscaling*.adoc}}) that reads simply:
{quote}
The autoscaling framework in its current form is deprecated and will be removed
in Solr 9.0.
A new design for this feature is currently under development in SOLR-14656 with
a goal for release with Solr 9.0.
{quote}
When 8.7 goes out we could add something like this to the Release Notes (or
send it separately to the user list at any time):
{quote}
As of 8.7, the autoscaling framework in Solr today has been deprecated and will
be removed in Solr 9.0.
As the framework was adopted among our user base, we discovered fundamental
flaws in its design that made continuing to support it unsustainable for our
developer community. Issues with scaling collection placement calculations and
a complex rule syntax were becoming more and more difficult to solve.
A new design and implementation of this feature is underway, with a goal of
making it available in Solr 9.0. This design will make it possible to have
autoscaling implementations available as plugins to suit various use cases and
needs (see also SOLR-14656 for details). The first plugin will be similar to
the autoscaling framework as it exists today, and other plugins are planned for
the future for larger clusters and those who would like different
implementations.
{quote}
The 3rd paragraph there could be revised to be more or less specific, but
that's the gist of it. We could also say something about regretting the
inconvenience, etc., that's up to you guys.
Let me know if you like the Ref Guide changes, and I'll make those in branch_8x.
was (Author: ctargett):
[~ab], [~ilan] - Ishan said in Slack that he thought docs were all that are
required for deprecating this since it's removed in 9.0. What do you both think
about a simple message like this on the top of all autoscaling pages in the ref
guide ({{solr-autoscaling*.adoc}}) that reads simply:
{noformat}
The autoscaling framework in its current form is deprecated and will be removed
in Solr 9.0.
A new design for this feature is currently under development in SOLR-14656 with
a goal for release with Solr 9.0.
{noformat}
When 8.7 goes out we could add something like this to the Release Notes (or
send it separately to the user list at any time):
{noformat}
As of 8.7, the autoscaling framework in Solr today has been deprecated and will
be removed in Solr 9.0.
As the framework was adopted among our user base, we discovered fundamental
flaws in its design that made continuing to support it unsustainable for our
developer community. Issues with scaling collection placement calculations and
a complex rule syntax were becoming more and more difficult to solve.
A new design and implementation of this feature is underway, with a goal of
making it available in Solr 9.0. This design will make it possible to have
autoscaling implementations available as plugins to suit various use cases and
needs (see also SOLR-14656 for details). The first plugin will be similar to
the autoscaling framework as it exists today, and other plugins are planned for
the future for larger clusters and those who would like different
implementations.
{noformat}
The 3rd paragraph there could be revised to be more or less specific, but
that's the gist of it. We could also say something about regretting the
inconvenience, etc., that's up to you guys.
Let me know if you like the Ref Guide changes, and I'll make those in branch_8x.
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
This message was se
[jira] [Comment Edited] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186810#comment-17186810
]
Cassandra Targett edited comment on SOLR-14656 at 8/28/20, 8:56 PM:
[~ab], [~ilan] - Ishan said in Slack that he thought docs were all that are
required for deprecating this since it's removed in 9.0. What do you both think
about a simple message like this on the top of all autoscaling pages in the ref
guide ({{solr-autoscaling*.adoc}}) that reads simply:
{quote}
The autoscaling framework in its current form is deprecated and will be removed
in Solr 9.0.
A new design for this feature is currently under development in SOLR-14613 with
a goal for release with Solr 9.0.
{quote}
When 8.7 goes out we could add something like this to the Release Notes (or
send it separately to the user list at any time):
{quote}
As of 8.7, the autoscaling framework in Solr today has been deprecated and will
be removed in Solr 9.0.
As the framework was adopted among our user base, we discovered fundamental
flaws in its design that made continuing to support it unsustainable for our
developer community. Issues with scaling collection placement calculations and
a complex rule syntax were becoming more and more difficult to solve.
A new design and implementation of this feature is underway, with a goal of
making it available in Solr 9.0. This design will make it possible to have
autoscaling implementations available as plugins to suit various use cases and
needs (see also SOLR-14613 for details). The first plugin will be similar to
the autoscaling framework as it exists today, and other plugins are planned for
the future for larger clusters and those who would like different
implementations.
{quote}
The 3rd paragraph there could be revised to be more or less specific, but
that's the gist of it. We could also say something about regretting the
inconvenience, etc., that's up to you guys.
Let me know if you like the Ref Guide changes, and I'll make those in branch_8x.
was (Author: ctargett):
[~ab], [~ilan] - Ishan said in Slack that he thought docs were all that are
required for deprecating this since it's removed in 9.0. What do you both think
about a simple message like this on the top of all autoscaling pages in the ref
guide ({{solr-autoscaling*.adoc}}) that reads simply:
{quote}
The autoscaling framework in its current form is deprecated and will be removed
in Solr 9.0.
A new design for this feature is currently under development in SOLR-14656 with
a goal for release with Solr 9.0.
{quote}
When 8.7 goes out we could add something like this to the Release Notes (or
send it separately to the user list at any time):
{quote}
As of 8.7, the autoscaling framework in Solr today has been deprecated and will
be removed in Solr 9.0.
As the framework was adopted among our user base, we discovered fundamental
flaws in its design that made continuing to support it unsustainable for our
developer community. Issues with scaling collection placement calculations and
a complex rule syntax were becoming more and more difficult to solve.
A new design and implementation of this feature is underway, with a goal of
making it available in Solr 9.0. This design will make it possible to have
autoscaling implementations available as plugins to suit various use cases and
needs (see also SOLR-14656 for details). The first plugin will be similar to
the autoscaling framework as it exists today, and other plugins are planned for
the future for larger clusters and those who would like different
implementations.
{quote}
The 3rd paragraph there could be revised to be more or less specific, but
that's the gist of it. We could also say something about regretting the
inconvenience, etc., that's up to you guys.
Let me know if you like the Ref Guide changes, and I'll make those in branch_8x.
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
This message was sent by Atlass
[jira] [Updated] (LUCENE-9475) Enhance the Gradle build as necessary after removing Ant support
[
https://issues.apache.org/jira/browse/LUCENE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated LUCENE-9475:
---
Description:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 release which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of
post-ant cleanup, I'll do it).
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
* Clean up Confluence, in particular any page that mentions IDEs. The "How to
Contribute" page has several links to various bits and pieces of how to use
IDEs, and some mention ant.
was:
Once the bulk of the Ant build system is removed, stuff will come bubbling up
out of the cracks, especially as we try the first 9.0 release which will be
Gradle only. Here we list some of the areas we'll have to be aware of. Please
add as you see fit. Assigning to myself to track, but I certainly don't want
hog all the fun.
* Remove Maven support and replace with "The Gradle Way" of doing Maven. See
LUCENE-9077 (Dawid)
*
** Remove all of dev-tools/maven?
** Other dev-tools files no longer used, check if any Gradle build file
references and remove if not.
* -Move Jenkins over to use Gradle only-
* -Verify reference guide build works under Gradle-
* Smoke tester
* Remove anything having to to with Clover (obsolete as of Java 11)
* -Remove all of {{lucene/tools}} (Ivy, forbiddenapis,...}} - (this is part of
post-ant cleanup, I'll do it).
* Remove obsolete files in root dirs of lucene and solr (like
version.properties, now integrated into gradle)
* Remove Maven build files (obsolete with Gradle)
* Hoss's test rollups?
* Enable javadocs after ant stops being used (LUCENE-9441)
* fix some relative links in javadocs which contain ant module names (?)
* dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files,
and some in the README.md. This one should probably be its own JIRA since it'll
require quite a bit of verification...
* -Make "the best damn beasting script in the world" work with the Gradle
build.- (see LUCENE-9465, LUCENE-9472 for alternatives)
* Update the release documentation to reflect Gradle (LUCENE-9488)
* Clean up anything in lucene/tools
> Enhance the Gradle build as necessary after removing Ant support
>
>
> Key: LUCENE-9475
> URL: https://issues.apache.org/jira/browse/LUCENE-9475
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Affects Versions: master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Once the bulk of the Ant build system is removed, stuff will come bubbling up
> out of the cracks, especially as we try the first 9.0 release which will be
> Gradle only. Here we list some of the areas we'll have to be aware of. Please
> add as you see fit. Assigning to myself to track, but I certainly don't want
> hog all the fun.
> * Remove Maven support and replace with "The Gradle Way" of doing Maven. See
> LUCENE-9077 (Dawid)
> *
> ** Remove all of dev-tools/maven?
> ** Other dev-tools files no longer used, check if any Gradle build file
> references and remove if not.
> * -Move Jenkins over to use Gradle only-
> * -Verify reference guide build works under Gradle-
> * Smoke tester
> * Remove anything having to to with Clover (obsolete as of Java 11)
> * -Rem
[jira] [Commented] (SOLR-14654) Remove plugin loading from .system collection (for 9.0)
[
https://issues.apache.org/jira/browse/SOLR-14654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186815#comment-17186815
]
Cassandra Targett commented on SOLR-14654:
--
[~noble.paul], I found one more place where I think this still lingers in the
Ref Guide. The page {{blob-store-api.adoc}} mentions a parameter {{runtimeLib}}
if one wants to use an uploaded blob. Should that be removed & the example
fixed? Is that the only part of this page that needs to be edited after this
change?
> Remove plugin loading from .system collection (for 9.0)
> ---
>
> Key: SOLR-14654
> URL: https://issues.apache.org/jira/browse/SOLR-14654
> Project: Solr
> Issue Type: Task
>Reporter: Noble Paul
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This code must go from master
> all places where "runtimeLib" can be used will be removed from 9.0 . With
> the new package system in place we don;t need this anymore
--
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-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reassigned SOLR-14774:
Assignee: Tomas Eduardo Fernandez Lobbe
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnect
[jira] [Created] (LUCENE-9489) Compilation failure due to broken link reference in javadoc
Ankur created LUCENE-9489:
-
Summary: Compilation failure due to broken link reference in
javadoc
Key: LUCENE-9489
URL: https://issues.apache.org/jira/browse/LUCENE-9489
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: master (9.0)
Reporter: Ankur
Javadoc for method
{code:java}
org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
IntsRef ordinals){code}
has a broken link reference in javadoc causing compilation error.
--
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-9489) Compilation failure due to broken link reference in javadoc
[
https://issues.apache.org/jira/browse/LUCENE-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankur updated LUCENE-9489:
--
Attachment: LUCENE-9489.patch
Fix Version/s: master (9.0)
Lucene Fields: New,Patch Available (was: New)
Status: Open (was: Open)
> Compilation failure due to broken link reference in javadoc
> ---
>
> Key: LUCENE-9489
> URL: https://issues.apache.org/jira/browse/LUCENE-9489
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: master (9.0)
>Reporter: Ankur
>Priority: Trivial
> Fix For: master (9.0)
>
> Attachments: LUCENE-9489.patch
>
>
> Javadoc for method
> {code:java}
> org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
> IntsRef ordinals){code}
> has a broken link reference in javadoc causing compilation error.
--
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-9489) Compilation failure due to broken link reference in javadoc
[
https://issues.apache.org/jira/browse/LUCENE-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankur updated LUCENE-9489:
--
Description:
Javadoc for method
{code:java}
org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
IntsRef ordinals){code}
has a broken link reference causing compilation failure.
was:
Javadoc for method
{code:java}
org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
IntsRef ordinals){code}
has a broken link reference causing compilation error.
> Compilation failure due to broken link reference in javadoc
> ---
>
> Key: LUCENE-9489
> URL: https://issues.apache.org/jira/browse/LUCENE-9489
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: master (9.0)
>Reporter: Ankur
>Priority: Trivial
> Fix For: master (9.0)
>
> Attachments: LUCENE-9489.patch
>
>
> Javadoc for method
> {code:java}
> org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
> IntsRef ordinals){code}
> has a broken link reference causing compilation failure.
--
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-9489) Compilation failure due to broken link reference in javadoc
[
https://issues.apache.org/jira/browse/LUCENE-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankur updated LUCENE-9489:
--
Status: Patch Available (was: Open)
> Compilation failure due to broken link reference in javadoc
> ---
>
> Key: LUCENE-9489
> URL: https://issues.apache.org/jira/browse/LUCENE-9489
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: master (9.0)
>Reporter: Ankur
>Priority: Trivial
> Fix For: master (9.0)
>
> Attachments: LUCENE-9489.patch
>
>
> Javadoc for method
> {code:java}
> org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
> IntsRef ordinals){code}
> has a broken link reference in javadoc causing compilation error.
--
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-9489) Compilation failure due to broken link reference in javadoc
[
https://issues.apache.org/jira/browse/LUCENE-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankur updated LUCENE-9489:
--
Description:
Javadoc for method
{code:java}
org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
IntsRef ordinals){code}
has a broken link reference causing compilation error.
was:
Javadoc for method
{code:java}
org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
IntsRef ordinals){code}
has a broken link reference in javadoc causing compilation error.
> Compilation failure due to broken link reference in javadoc
> ---
>
> Key: LUCENE-9489
> URL: https://issues.apache.org/jira/browse/LUCENE-9489
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
>Affects Versions: master (9.0)
>Reporter: Ankur
>Priority: Trivial
> Fix For: master (9.0)
>
> Attachments: LUCENE-9489.patch
>
>
> Javadoc for method
> {code:java}
> org.apache.lucene.facet.taxonomy.DocValuesOrdinalsReader.decode(BytesRef buf,
> IntsRef ordinals){code}
> has a broken link reference causing compilation error.
--
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] tflobbe merged pull request #1774: SOLR-14774: Create HealthCheckHandler in CoreContainer
tflobbe merged pull request #1774: URL: https://github.com/apache/lucene-solr/pull/1774 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186841#comment-17186841
]
ASF subversion and git services commented on SOLR-14774:
Commit 59d087f0b391b740491839acb48390f3d08030de in lucene-solr's branch
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=59d087f ]
SOLR-14774: Create HealthCheckHandler in CoreContainer (#1774)
This commit does two things:
* Allow users to plug-in different implementations of the handler (they must
extend HealthCheckHandler)
* Remove the HealthCheckHandler from the implicit SolrCore plugins
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.ecl
[jira] [Updated] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe updated SOLR-14774:
-
Issue Type: Bug (was: Improvement)
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
>
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186843#comment-17186843
]
ASF subversion and git services commented on SOLR-14774:
Commit 1dfd899a02526e2475a94dc448b212a65be65871 in lucene-solr's branch
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1dfd899 ]
SOLR-14774: Create HealthCheckHandler in CoreContainer (#1774)
This commit does two things:
* Allow users to plug-in different implementations of the handler (they must
extend HealthCheckHandler)
* Remove the HealthCheckHandler from the implicit SolrCore plugins
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclips
[jira] [Resolved] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14774.
--
Fix Version/s: 8.7
master (9.0)
Resolution: Fixed
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
>
[GitHub] [lucene-solr] tflobbe opened a new pull request #1798: Remove and Github Action
tflobbe opened a new pull request #1798: URL: https://github.com/apache/lucene-solr/pull/1798 `ant` no longer in master branch This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186852#comment-17186852
]
Ilan Ginzburg commented on SOLR-14656:
--
[~ctargett] your proposal makes sense. Works for me. Thanks.
Minor change: In the 8.7 section you write "The first plugin will be similar to
the autoscaling framework as it exists today".
I'd rather have it read "The first plugin will be similar to
*{color:#de350b}the default configuration of{color}* the autoscaling framework
as it exists today"
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
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] tflobbe commented on pull request #1798: Remove ant Github Action
tflobbe commented on pull request #1798: URL: https://github.com/apache/lucene-solr/pull/1798#issuecomment-683207769 We have an action for gradle that's running `./gradlew precommit`. See https://github.com/apache/lucene-solr/blob/master/.github/workflows/gradle-precommit.yml#L24 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186865#comment-17186865
]
Mark Robert Miller commented on SOLR-14636:
---
So I chose to call this the reference branch for a couple reasons. For one,
it's a bit ambiguous, and I love that. Not good for group productivity though
;) It could mean, hey all you peons, here is how you really do it, this is the
reference implementation from which various distributors can take and put their
own spin on. But of course, it's actually meant as, here is a branch full of
lots of improvements and fixes and speed ups, and a minimum that can come out
of it is a great code base to reference. As I often reference the half baked
stuff I'm left with from my previous attempts at this work.
At some point you take stock of the past however long, and you do a little
introspection. And you might think, while I was coasting the ride in 2016,
Lin-Manuel Miranda is sitting there creating Hamilton while creating a disney
sound track with two others, you know, just kind of on the side. And you think,
now there is someday building race cars like they have a penchant for racing
cars.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg, jenkins.png, solr-ref-branch.gif
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: developer alpha, on the verge of developer beta
> *speed*: ludicrous
> *tests***:
> * *core*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: *extremely stable* with {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: *extremely stable* with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*extremely stable*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*extremely
> stable*{color} with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*extremely
> stable*{color} with {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*extremely stable*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*extremely stable*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
> h2. Getting Started with the Solr Reference Branch
> [AYoungLadysIllustratedPrimer|https://www.dropbox.com/sh/prnw0gpdoi0j9me/AABF2gPDoer6uL0ghXfEzbzja?dl=0]
> # Book One: [The 10 Minute
> Introduction|https://www.dropbox.com/s/x9k1m3zmjucc422/Book%20One%3A%20The%2010%20Minute%20Introduction.mp4?dl=0]
> # Book Two: A Brief, High Level Overview of the Changes
> <{color:#de350b}*_WORK IN PROGRESS_*{color}>
> ## Book Two: Process Intro: Section 1: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/96owizh57i5vd8w/Book%20Two%3A%20Process%20Intro%3A%20Section%201%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 1-2: [A Quick Look at the Practical
> Process|https://www.dropbox.com/s/a1ipp0n3gtbf29m/Book%20Two%3A%20Process%20Intro%3A%20Section%202-2%3A%20A%20Quick%20Look%20at%20the%20Practical%20Process.m4v?dl=0]
> ## Book Two: Process Intro: Section 2: [A Brief Look at a Few Broad
> Problems|https://www.dropbox.com/s/kmkp1lu1tfits1p/Book%20Two%3A%20Process%20Intro%3A%20Section%202%3A%20A%20Brief%20Look%20at%20a%20Few%20Broad%20Problems.m4v?dl=0]
> ## Book Two: Process Intro: Section 3: [Die, Die, Die Solr
> XML|https://www.dropbox.com/s/hi452cpjjx1h880/Book%20Two%3A%20Process%20Intro%3A%20Section%203%3A%20Die%2C%20Die%2C%20Die%20Solr%20XML.m4v?dl
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
arafalov commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479592961 ## File path: solr/solr-ref-guide/src/major-changes-in-solr-9.adoc ## @@ -122,6 +122,8 @@ _(raw; not yet edited)_ and "follower". This includes API calls for the replication handler and metrics. For rolling upgrades into 9.0, you need to be on Solr version 8.7 or greater. Some metrics also changed, alerts and monitors on Solr KPIs that mention "master" or "slave" will also now be "leader" and "follower" + +* SOLR-14783: Data Imprort Handler (DIH) has been removed from Solr. The community package is available at: https://github.com/rohitbemax/dataimporthandler (Alexandre Rafalovitch) Review comment: Fixed. Thank you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
arafalov commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479592970 ## File path: solr/README.md ## @@ -142,8 +141,7 @@ server/ example/ Contains example documents and an alternative Solr home - directory containing examples of how to use the Data Import Handler, - see example/example-DIH/README.md for more information. + directory containing variours examples. Review comment: Not mine, but fixed anyway. Thank you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] arafalov commented on a change in pull request #1794: SOLR-14783: Remove DIH from 9.0
arafalov commented on a change in pull request #1794: URL: https://github.com/apache/lucene-solr/pull/1794#discussion_r479593096 ## File path: solr/solr-ref-guide/src/uploading-structured-data-store-data-with-the-data-import-handler.adoc ## @@ -1,1077 +0,0 @@ -= Uploading Structured Data Store Data with the Data Import Handler Review comment: Ok. I'll keep it removed. Maybe in the next version of the Ref Guide, we can feed the section headers into the search as well and DIH could be in the title of one of the sections to find. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] tflobbe merged pull request #1798: Remove ant Github Action
tflobbe merged pull request #1798: URL: https://github.com/apache/lucene-solr/pull/1798 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14774) HealthCheckHandler shouldn't be an implicit SolrCore level handler and should be configurable
[
https://issues.apache.org/jira/browse/SOLR-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186877#comment-17186877
]
Noble Paul commented on SOLR-14774:
---
I'm unhappy about the fact that this thing has gone into {{solr.xml}} .
Can we just revert the changes being put into {{solr.xml}}
> HealthCheckHandler shouldn't be an implicit SolrCore level handler and should
> be configurable
> -
>
> Key: SOLR-14774
> URL: https://issues.apache.org/jira/browse/SOLR-14774
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to use the HealthCheckHandler I noticed that:
> * CoreContainer has some logic to read config from {{solr.xml}}, however,
> this is never used, and the handler is constructed explicitly inside
> {{InfoHandler}}. This means you can't plugin a different implementation.
> * Also noticed that it was added as an implicit plugin to the {{SolrCore}}.
> which means one could access the handler like
> {{//admin/health}}, however, this will never work, since
> it uses a parameterless constructor, which leaves the handler in an invalid
> state [1]. I honestly don't know why it's being added to the {{SolrCore}},
> this is supposed to be a node level handler, and for SolrCore one could use
> the {{PingRequestHandler}}
>
> [1]
> {noformat}
> 2020-08-21 21:14:06.094 ERROR (qtp599782425-18) [c:test s:shard1 r:core_node4
> x:test_shard1_replica_n2] o.a.s.s.HttpSolrCall
> null:org.apache.solr.common.SolrException: CoreContainer is either not
> initialized or shutting down
> at
> org.apache.solr.handler.admin.HealthCheckHandler.handleRequestBody(HealthCheckHandler.java:96)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2606)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:812)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:588)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
> at
> org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at org.eclipse.jetty.server.Server.handle(Server.java:500)
> at
> org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383)
> at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547)
> at org.e
