[jira] [Created] (SOLR-14265) Move to admin API to v2 completely
Anshum Gupta created SOLR-14265: --- Summary: Move to admin API to v2 completely Key: SOLR-14265 URL: https://issues.apache.org/jira/browse/SOLR-14265 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Anshum Gupta Assignee: Anshum Gupta V2 admin API has been available in Solr for a very long time, making it difficult for both users and developers to remember and understand which format to use when. We should move to v2 API completely for all Solr Admin calls for the following reasons: # converge code - there are multiple ways of doing the same thing, there's unwanted back-compat code, and we should get rid of that # POJO all the way - no more NamedList. I know this would have split opinions, but I strongly think we should move in this direction. I created Jira about this specific task in the past and went half way but I think we should just close this one out now. # Automatic documentation # Others This is just an umbrella Jira for the task. Let's create sub-tasks and split this up as it would require a bunch of rewriting of the code and it makes a lot of sense to get this out with 9.0 so we don't have to support v1 forever! There have been some conversations going on about this and it feels like most folks are happy to go this route. -- 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-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
[
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038881#comment-17038881
]
Jacek Kikiewicz commented on SOLR-13974:
Hi [~erickerickson] from what I was able to test -> I didn't encounter our
issues.
What is important to remember is the fact we see those issues only sometimes
and it might be the case that new version is the same and I was just lucky in
my testing time.
Nevertheless it's not any worse :)
Btw. Is there a rough idea when 8.5 will come out?
> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
> Issue Type: Bug
> Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505) at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.try
[jira] [Commented] (LUCENE-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038900#comment-17038900
]
Uwe Schindler commented on LUCENE-8987:
---
bq. So you suggest something like this?
This is somehow not really good, as the link shown to enduser is still
hardcoded, so we can stay with the simple {{<>}} syntax.
There is one way to make absolute links display (also formatted as code)
automatically, although the href is relative:
{code:javascript}
$('a.autolink').each(function() {
$(this).text( $(this).prop('href') ).addClass('code');
});
{code}
This will reformat every link on page load with jQuery to just contain the href
(which gets expanded by browser). All those links just need a special class:
{{}}. Not sure if this is an
idea, but I use it quite often for API documentation where you have relative
links to API endpoints , but you want to show the full URL as link description.
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
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-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038905#comment-17038905
]
Jan Høydahl commented on LUCENE-8987:
-
Ok, I would not really bother too much right now. The historic release
announcement news articles actually reflect what was in fact emailed out, so I
don't see the big win in making them relative. If you write a new draft news
and want it to link to some new page section in staged site, you can explicitly
make that link relative of course.
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv
updates by terms by applying
URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380377204
##
File path: lucene/core/src/java/org/apache/lucene/util/BytesRefArray.java
##
@@ -136,22 +138,28 @@ protected int compare(int i, int j) {
final int idx1 = orderedEntries[i], idx2 = orderedEntries[j];
setBytesRef(scratch1, scratchBytes1, idx1);
setBytesRef(scratch2, scratchBytes2, idx2);
-return comp.compare(scratchBytes1, scratchBytes2);
+return compare(idx1, scratchBytes1, idx2, scratchBytes2);
}
@Override
protected void setPivot(int i) {
-final int index = orderedEntries[i];
-setBytesRef(pivotBuilder, pivot, index);
+pivotIndex = orderedEntries[i];
+setBytesRef(pivotBuilder, pivot, pivotIndex);
}
@Override
protected int comparePivot(int j) {
final int index = orderedEntries[j];
setBytesRef(scratch2, scratchBytes2, index);
-return comp.compare(pivot, scratchBytes2);
+return compare(pivotIndex, pivot, index, scratchBytes2);
}
+ private int compare(int i1, BytesRef b1, int i2, BytesRef b2) {
+int res = comp.compare(b1, b2);
+return res == 0 ? tieComparator.applyAsInt(i1, i2): res;
Review comment:
nit
```suggestion
return res == 0 ? tieComparator.applyAsInt(i1, i2) : res;
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9223) Add Apache license headers
[ https://issues.apache.org/jira/browse/LUCENE-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038906#comment-17038906 ] Jan Høydahl commented on LUCENE-9223: - Thinking about this - what is the actual ASF policy wrt license headers for web site content? Is the requirement that every HTML page people download should contain ASF license info, or is the requirement that people who browse Git repo should see the license for every single MD file, every template file, every JS and CSS etc? > Add Apache license headers > -- > > Key: LUCENE-9223 > URL: https://issues.apache.org/jira/browse/LUCENE-9223 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > All source files should probably have the license header. Now some have and > others don't. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv
updates by terms by applying
URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380534145
##
File path:
lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java
##
@@ -808,10 +808,17 @@ private void setField(String field) throws IOException {
} else {
termsEnum = null;
}
+currentTermVisited = false;
}
}
-DocIdSetIterator nextTerm(String field, BytesRef term) throws IOException {
+/**
+ * Returns a {@link DocIdSetIterator} for the given field and term if
exists. If the parameter
+ * {@code skipIfTermVisited} is true, then this method will return null if
the given and field
+ * was visited already. This optimization is currently used in
+ * {@link #applyDocValuesUpdates(BufferedUpdatesStream.SegmentState, Map,
long, boolean)}
+ */
+DocIdSetIterator nextTerm(String field, BytesRef term, boolean
skipIfTermVisited) throws IOException {
Review comment:
I was expecting this `skipIfTermVisited` logic could go to
`BufferedUpdateIterator` instead? So `TermDocsIterator` would be left untouched
and `BufferedUpdateIterator` would silently skip duplicate terms when the
optimization kicks in? (It's very possible that I'm missing something and that
it's not doable)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv
updates by terms by applying
URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380524161
##
File path: lucene/core/src/java/org/apache/lucene/index/FieldUpdatesBuffer.java
##
@@ -195,10 +197,34 @@ private int append(Term term) {
return numUpdates++;
}
+ void finish() {
+assert termsIteratorProvider == null;
+if (isSortedTerms()) {
+ // sort by ascending by term, then sort descending by docsUpTo
+ termsIteratorProvider = termValues.iteratorProvider(BytesRef::compareTo,
+ (i1, i2) -> Integer.compare(
+ docsUpTo[getArrayIndex(docsUpTo.length, i2)],
+ docsUpTo[getArrayIndex(docsUpTo.length, i1)]));
+ bytesUsed.addAndGet(termValues.size() * Integer.BYTES); // sorted
indices of the iterators
+} else {
+ termsIteratorProvider = termValues.iteratorProvider(null, null);
+}
+ }
+
BufferedUpdateIterator iterator() {
+assert termsIteratorProvider != null : "finish is not called yet";
Review comment:
can we also assert that it is null in calls to `addUpdate`?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
jpountz commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380524771 ## File path: lucene/core/src/java/org/apache/lucene/index/FieldUpdatesBuffer.java ## @@ -51,6 +52,7 @@ // on CPU for those. We also save on not needing to sort in order to apply the terms in order // since by definition we store them in order. private final BytesRefArray termValues; + private Supplier termsIteratorProvider; Review comment: should we null it out in `clear()`? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038908#comment-17038908
]
Uwe Schindler commented on LUCENE-8987:
---
I removed the lib folder in master.
Do you want to merge everything to production soon? Your changes from yesterday
are not yet visible.
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
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-site] janhoy merged pull request #12: Namgyu comments
janhoy merged pull request #12: Namgyu comments URL: https://github.com/apache/lucene-site/pull/12 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038911#comment-17038911
]
Uwe Schindler commented on LUCENE-8987:
---
We can maybe change the {{base.html}} template to do some search/replace for
news articles automatically. So we can search/replace http://lucene.apache.org
and replace by https://lucene.apache.org. This would enforce HTTPS links for
everything that's local.
Something like:
{code}
{% block content_inner %}
{{ page.content | replace('http://lucene.apache.org/',
'https://lucene.apache.org/') }}
{% endblock content_inner %}
{code}
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
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-9227) Make page ready for pure HTTPS
[ https://issues.apache.org/jira/browse/LUCENE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038916#comment-17038916 ] Jan Høydahl commented on LUCENE-9227: - Many literal http links were moved to https in https://github.com/apache/lucene-site/pull/12/commits/9f10a556b2e424aefc66426076dcb20ab2344e25 > Make page ready for pure HTTPS > -- > > Key: LUCENE-9227 > URL: https://issues.apache.org/jira/browse/LUCENE-9227 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Blocker > > The web page can currently be visited using HTTPS but this brings warning: > - Both search providers create a form that passes USER ENTERED INPUT using no > encryption. This is not allowed due to GDPR. We have to fix this asap. It > looks like [~otis] search is working with HTTPS (if we change domain name), > but the Lucidworks does not > - There were some CSS files loaded with HTTP (fonts from Google - this was > fixed) > Once those 2 problems are fixed (I grepped for HTTP and still found many > links with HTTP, but looks like no images or scripts or css anymore), I'd > like to add a permanent redirect http://lucene.apache.org/ -> > https://lucene.apache.org to the htaccess template file. -- 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-9198) Remove news section from TLP website
[ https://issues.apache.org/jira/browse/LUCENE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038933#comment-17038933 ] Uwe Schindler commented on LUCENE-9198: --- bq. Merged to master - available on https://lucene.staged.apache.org/index.html for review (many need to force update a few times to cache new CSS). Shift-Reload helps (Hold shift key and then press reload button with mouse). Jan and I already discussed some ways on slack to make CSS/JS assets cache forever and still alow changes at same time. The trick is to add hashes to filenames, so whenever contents change the filename changes, too. Pelican has a plugin for this: https://pypi.org/project/pelican-webassets/ > Remove news section from TLP website > > > Key: LUCENE-9198 > URL: https://issues.apache.org/jira/browse/LUCENE-9198 > Project: Lucene - Core > Issue Type: Improvement > Components: general/website >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: new-tlp-conditional-news.png, > new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png > > Time Spent: 20m > Remaining Estimate: 0h > > On the front page [https://lucene.apache.org|https://lucene.apache.org/] we > today show a list of TLP news. > For every release we author one news article for Solr, one news article for > LuceneCore, and one news article for TLP site, combining the two. > In all these years we have never published a news item to TLP that is not a > release announcement, except in 2014 when we announced that OpenRelevance sub > project closed. > I thus propose to remove this news section, and replace it with two widgets > that automatically display the last 5 news headings from LuceneCore, Solr and > PyLucene sub projects. > If we have an important TLP announcement to make at some point, that can be > done right there on the front page, not? -- 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-site] janhoy opened a new pull request #13: Prevent caching surprises for CSS, JS
janhoy opened a new pull request #13: Prevent caching surprises for CSS, JS
URL: https://github.com/apache/lucene-site/pull/13
Add a {{ STATIC_RESOURCE_SUFFIX }} to all unversioned static css and js
resources to avoid caching issues.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9198) Remove news section from TLP website
[ https://issues.apache.org/jira/browse/LUCENE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038933#comment-17038933 ] Uwe Schindler edited comment on LUCENE-9198 at 2/18/20 9:29 AM: bq. Merged to master - available on https://lucene.staged.apache.org/index.html for review (many need to force update a few times to cache new CSS). Shift-Reload helps (Hold shift key and then press reload button with mouse). Jan and I already discussed some ways on slack to make CSS/JS assets cache forever and still alow changes at same time. The trick is to add hashes to filenames, so whenever contents change the filename changes, too. Pelican has a plugin for this: https://pypi.org/project/pelican-webassets/ It also allows us to mimize CSS and JS before it gets copied to output folder, increaing page load times even more :-) was (Author: thetaphi): bq. Merged to master - available on https://lucene.staged.apache.org/index.html for review (many need to force update a few times to cache new CSS). Shift-Reload helps (Hold shift key and then press reload button with mouse). Jan and I already discussed some ways on slack to make CSS/JS assets cache forever and still alow changes at same time. The trick is to add hashes to filenames, so whenever contents change the filename changes, too. Pelican has a plugin for this: https://pypi.org/project/pelican-webassets/ > Remove news section from TLP website > > > Key: LUCENE-9198 > URL: https://issues.apache.org/jira/browse/LUCENE-9198 > Project: Lucene - Core > Issue Type: Improvement > Components: general/website >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Attachments: new-tlp-conditional-news.png, > new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png > > Time Spent: 20m > Remaining Estimate: 0h > > On the front page [https://lucene.apache.org|https://lucene.apache.org/] we > today show a list of TLP news. > For every release we author one news article for Solr, one news article for > LuceneCore, and one news article for TLP site, combining the two. > In all these years we have never published a news item to TLP that is not a > release announcement, except in 2014 when we announced that OpenRelevance sub > project closed. > I thus propose to remove this news section, and replace it with two widgets > that automatically display the last 5 news headings from LuceneCore, Solr and > PyLucene sub projects. > If we have an important TLP announcement to make at some point, that can be > done right there on the front page, not? -- 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-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038936#comment-17038936
]
Jan Høydahl commented on LUCENE-8987:
-
Yes we can merge to production soon.
I attempted a fix to the CSS caching issue. It is just a simple Pelican
variable that gets injected for every unversioned CSS and JS in our HTML
templates. See https://github.com/apache/lucene-site/pull/13 - Adding this
should make the new front page load well for everyone after publishing :)
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
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-site] janhoy commented on issue #13: Prevent caching surprises for CSS, JS
janhoy commented on issue #13: Prevent caching surprises for CSS, JS URL: https://github.com/apache/lucene-site/pull/13#issuecomment-587364381 The alternative would be to investigate an automated solution like https://pypi.org/project/pelican-webassets/ but that would probably be much more 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9223) Add Apache license headers
[
https://issues.apache.org/jira/browse/LUCENE-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038943#comment-17038943
]
Jan Høydahl commented on LUCENE-9223:
-
Answering my own question:
https://www.apache.org/legal/src-headers.html#faq-webpages
{quote}
DOES THIS POLICY ALSO APPLY TO CONTENT DISPLAYED ON OUR WEB SITES?
No. Our web sites do not have an associated NOTICE file. Instead we may soon be
making the terms of such content explicit through a "Terms of Use" or "Legal
Information" link in the footer of web pages. At this point, no action is
required for Apache web sites.
{quote}
So I think we should NOT add all those headers.
Instead we can add a {{LICENSE}} file to the top of the git repo
> Add Apache license headers
> --
>
> Key: LUCENE-9223
> URL: https://issues.apache.org/jira/browse/LUCENE-9223
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Jan Høydahl
>Priority: Major
>
> All source files should probably have the license header. Now some have and
> others don't.
--
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-site] janhoy opened a new pull request #14: Add license.txt to clarify the license of the repo
janhoy opened a new pull request #14: Add license.txt to clarify the license of the repo URL: https://github.com/apache/lucene-site/pull/14 Refer to https://issues.apache.org/jira/browse/LUCENE-9223 for discussion This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] janhoy commented on issue #14: Add license.txt to clarify the license of the repo
janhoy commented on issue #14: Add license.txt to clarify the license of the repo URL: https://github.com/apache/lucene-site/pull/14#issuecomment-587377984 Removed some headers from MD and added two to .js This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9223) Add Apache license headers
[ https://issues.apache.org/jira/browse/LUCENE-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038955#comment-17038955 ] Jan Høydahl commented on LUCENE-9223: - See https://github.com/apache/lucene-site/pull/14 for proposed changes > Add Apache license headers > -- > > Key: LUCENE-9223 > URL: https://issues.apache.org/jira/browse/LUCENE-9223 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Jan Høydahl >Priority: Major > > All source files should probably have the license header. Now some have and > others don't. -- 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] (LUCENE-9223) Add Apache license headers
[ https://issues.apache.org/jira/browse/LUCENE-9223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned LUCENE-9223: --- Assignee: Jan Høydahl > Add Apache license headers > -- > > Key: LUCENE-9223 > URL: https://issues.apache.org/jira/browse/LUCENE-9223 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > > All source files should probably have the license header. Now some have and > others don't. -- 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-12550) ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
[ https://issues.apache.org/jira/browse/SOLR-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038966#comment-17038966 ] Bérénice MAUREL commented on SOLR-12550: Hi, I'm under Solr 8.3 and the problem is still there, it's very inconvenient. This patch seems to be a good solution, why it isn't integrate yet ? > ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize > > > Key: SOLR-12550 > URL: https://issues.apache.org/jira/browse/SOLR-12550 > Project: Solr > Issue Type: Bug >Reporter: Marc Morissette >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We're in a situation where we need to optimize some of our collections. These > optimizations are done with waitSearcher=true as a simple throttling > mechanism to prevent too many collections from being optimized at once. > We're seeing these optimize commands return without error after 10 minutes > but well before the end of the operation. Our Solr logs show errors with > socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value > has no effect. > See the links section for my patch. > It turns out that ConcurrentUpdateSolrClient delegates commit and optimize > commands to a private HttpSolrClient but fails to pass along its builder's > timeouts to that client. > A patch is attached in the links section. -- 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-12550) ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
[ https://issues.apache.org/jira/browse/SOLR-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039009#comment-17039009 ] Mikhail Khludnev commented on SOLR-12550: - I like #417. Are there any concerns with merging it? > ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize > > > Key: SOLR-12550 > URL: https://issues.apache.org/jira/browse/SOLR-12550 > Project: Solr > Issue Type: Bug >Reporter: Marc Morissette >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We're in a situation where we need to optimize some of our collections. These > optimizations are done with waitSearcher=true as a simple throttling > mechanism to prevent too many collections from being optimized at once. > We're seeing these optimize commands return without error after 10 minutes > but well before the end of the operation. Our Solr logs show errors with > socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value > has no effect. > See the links section for my patch. > It turns out that ConcurrentUpdateSolrClient delegates commit and optimize > commands to a private HttpSolrClient but fails to pass along its builder's > timeouts to that client. > A patch is attached in the links section. -- 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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039013#comment-17039013
]
Robert Muir commented on LUCENE-9232:
-
I didn't experiment with anything. I used all the defaults on a machine where
i'd never run gradle before, clean checkout!
It created 2 daemons that leaked and did not go away. My problem was the bad
defaults (daemon=on).
If it was disabled I wouldn't have had multiple JVMs with gigabyte+ heaps
leaked.
Sorry, I cannot just sit by and "not do anything" when we can disable such
waste so easily.
The daemon feature is not ready for prime-time: it must not be the default.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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] shalinmangar commented on a change in pull request #417: Fixes SOLR-12550: ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
shalinmangar commented on a change in pull request #417: Fixes SOLR-12550:
ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
URL: https://github.com/apache/lucene-solr/pull/417#discussion_r380624225
##
File path:
solr/solrj/src/test/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClientTest.java
##
@@ -346,4 +347,25 @@ public OutcomeCountingConcurrentUpdateSolrClient build() {
}
}
}
+
+ /**
+ * Test that connection timeout information is passed to the HttpSolrClient
that handle non add operations
+ */
+ @Test(timeout = 1000)
+ public void testConnectionTimeoutOnCommit() throws IOException,
SolrServerException {
+// 240.0.0.0/4 is reserved for future use by the IANA and is in effect a
black hole
+try (ConcurrentUpdateSolrClient client = new
ConcurrentUpdateSolrClient.Builder("http://240.0.0.1:8983/";)
Review comment:
Please use `SolrTestCaseJ4.DEAD_HOST` instead of a real networking address
so that it fails fast. After SOLR-14050, the security policy for tests allows
connections to loopback 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
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039016#comment-17039016
]
Dawid Weiss commented on LUCENE-9232:
-
Not trying to justify anything but Gradle tells you when it can't reuse the
same daemon (and for whatever reason). This isn't a feature anymore – it's the
default. Disabling the daemon will still fork a new one on each invocation.
I s4ill think having it on is a saner default (with a reasonably short timeout)
than launching a new daemon over and over again – if you don't like it you can
disable it locally but I'm not convinced this should be the default for
everyone around.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
> `Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-12550) ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
[ https://issues.apache.org/jira/browse/SOLR-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039017#comment-17039017 ] Shalin Shekhar Mangar commented on SOLR-12550: -- I added a review comment to #417. Other than that it looks good. > ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize > > > Key: SOLR-12550 > URL: https://issues.apache.org/jira/browse/SOLR-12550 > Project: Solr > Issue Type: Bug >Reporter: Marc Morissette >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > We're in a situation where we need to optimize some of our collections. These > optimizations are done with waitSearcher=true as a simple throttling > mechanism to prevent too many collections from being optimized at once. > We're seeing these optimize commands return without error after 10 minutes > but well before the end of the operation. Our Solr logs show errors with > socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value > has no effect. > See the links section for my patch. > It turns out that ConcurrentUpdateSolrClient delegates commit and optimize > commands to a private HttpSolrClient but fails to pass along its builder's > timeouts to that client. > A patch is attached in the links section. -- 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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039019#comment-17039019
]
Robert Muir commented on LUCENE-9232:
-
I think {{generate-defaults.gradle}} may have caused the leaked daemon here.
The first time you run the build, there's no gradle.properties, it forks a
daemon. it creates a new gradle.properties since that is what our build does.
The second time you run the build, there's now the gradle.properties so jvm
options have changed. daemon is "incompatible" so it forks another one.
now you have 2 daemons. and for me after many many hours they never go away
This isn't me doing anything at all: its simply the out of box experience.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039023#comment-17039023
]
Robert Muir commented on LUCENE-9232:
-
We can quantify daemon's value on a measly 2-core laptop:
without daemon:
{noformat}
BUILD SUCCESSFUL in 9s
1 actionable task: 1 executed
{noformat}
with daemon:
{noformat}
BUILD SUCCESSFUL in 4s
1 actionable task: 1 executed
{noformat}
This is why I open the issue. Keeping around multi-gigabyte process(es) in
memory doesn't seem like its worth the trouble?
> disable gradle daemon by`default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, sur0rised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039044#comment-17039044
]
Dawid Weiss commented on LUCENE-9232:
-
{quote}bq. The first time you run the build, there's no gradle.properties, it
forks a daemon. it creates a new gradle.properties since that is what our build
does.
{quote}
Ah, this is a valid point... It does it because we alter JVM properties (heap).
I don't know how we can avoid this though. When you run it the first time it'll
fork a daemon – even if you put no-daemon options to gradle.properties that
first one is going to stay dormant in the background.
The timings you gave are only for script evaluation. The gain is (and I'm not
completely confident here, just guessing) that when you run something larger
(say "gradlew compile") caches of inputs/ outputs are reused.
Regardless of the default for daemon or no-daemon the initial run is indeed a
problem (I don't know how to solve it off the top of my head).
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039064#comment-17039064
]
Robert Muir commented on LUCENE-9232:
-
As far as abnormally long time (default is supposed to be 3 hours), I think it
might be related to closing/opening laptops lid and their Timer class that
governs when daemon will exit.
I actually didn't kill daemons until around 15:00. I tried to make sense of how
it was implemented there at a glance, but I was unsuccessful and have to get
moving today.
>From my experiments with the gradle integration of Eclipse IDE (they are
>short-lived because it thinks lucene projects have recursive dependencies?
>Maybe I am holding it wrong?), Eclipse spins up its own gradle daemon anyway
>for IDE purposes, with its own timeout. I have not looked into other IDEs or
>even where we are at with IDE integration in general. But it is something to
>consider here.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-site] janhoy commented on a change in pull request #14: Add license.txt to clarify the license of the repo
janhoy commented on a change in pull request #14: Add license.txt to clarify the license of the repo URL: https://github.com/apache/lucene-site/pull/14#discussion_r380659946 ## File path: LICENSE.txt ## @@ -200,27 +200,3 @@ See the License for the specific language governing permissions and limitations under the License. -== Review comment: I have no idea why the JQuery license was attached to LICENSE.txt that I copied from Solr This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9233) Add LICENSE.txt to git root
Jan Høydahl created LUCENE-9233: --- Summary: Add LICENSE.txt to git root Key: LUCENE-9233 URL: https://issues.apache.org/jira/browse/LUCENE-9233 Project: Lucene - Core Issue Type: Task Reporter: Jan Høydahl GitHub does not know about Lucene's license since we don't have a top level LICENSE file in our git repo. When adding one through the GitHub UI we can select a template and our repo will show with the Apache-License icon in GitHub. I think we should add 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] [Created] (SOLR-14266) Fix or suppress 14 resource leak warnings in apache/solr/core
Andras Salamon created SOLR-14266:
-
Summary: Fix or suppress 14 resource leak warnings in
apache/solr/core
Key: SOLR-14266
URL: https://issues.apache.org/jira/browse/SOLR-14266
Project: Solr
Issue Type: Sub-task
Reporter: Andras Salamon
There are 14 resource leak warnings in {{apache/solr/common:}}
{noformat}
[ecj-lint] 10. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 745)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
--
[ecj-lint] 5. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
(at line 215)
[ecj-lint] SolrResourceLoader loader = new SolrResourceLoader();
[ecj-lint]^^
[ecj-lint] Resource leak: 'loader' is never closed
--
[ecj-lint] 6. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
(at line 244)
[ecj-lint] MetricsHandler handler = new
MetricsHandler(h.getCoreContainer());
[ecj-lint]^^^
[ecj-lint] Resource leak: 'handler' is never closed
--
[ecj-lint] 7. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
(at line 364)
[ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
[ecj-lint]^
[ecj-lint] Resource leak: 'admin' is never closed
--
[ecj-lint] 8. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
(at line 378)
[ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
[ecj-lint]^
[ecj-lint] Resource leak: 'admin' is never closed
--
[ecj-lint] 9. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
(at line 638)
[ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
[ecj-lint]^
[ecj-lint] Resource leak: 'admin' is never closed
--
[ecj-lint] 10. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 32)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 11. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 39)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 12. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 47)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 13. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 55)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 14. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 63)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 15. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 71)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-lint]
[ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
--
[ecj-lint] 16. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
(at line 79)
[ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
HdfsBackupRepository();
[ecj-l
[jira] [Updated] (SOLR-14266) Fix or suppress 14 resource leak warnings in apache/solr/core
[
https://issues.apache.org/jira/browse/SOLR-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated SOLR-14266:
--
Status: Patch Available (was: Open)
> Fix or suppress 14 resource leak warnings in apache/solr/core
> -
>
> Key: SOLR-14266
> URL: https://issues.apache.org/jira/browse/SOLR-14266
> Project: Solr
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14266-01.patch
>
>
> There are 14 resource leak warnings in {{apache/solr/common:}}
> {noformat}
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> (at line 745)
> [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
> --
> [ecj-lint] 5. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
> (at line 215)
> [ecj-lint] SolrResourceLoader loader = new SolrResourceLoader();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'loader' is never closed
> --
> [ecj-lint] 6. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 244)
> [ecj-lint] MetricsHandler handler = new
> MetricsHandler(h.getCoreContainer());
> [ecj-lint]^^^
> [ecj-lint] Resource leak: 'handler' is never closed
> --
> [ecj-lint] 7. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 364)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 8. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 378)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 9. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 638)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 32)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 11. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 39)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 12. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 47)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 13. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 55)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 14. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 63)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 71)
> [ecj-lint] Hdfs
[jira] [Updated] (SOLR-14266) Fix or suppress 14 resource leak warnings in apache/solr/core
[
https://issues.apache.org/jira/browse/SOLR-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated SOLR-14266:
--
Attachment: SOLR-14266-01.patch
> Fix or suppress 14 resource leak warnings in apache/solr/core
> -
>
> Key: SOLR-14266
> URL: https://issues.apache.org/jira/browse/SOLR-14266
> Project: Solr
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14266-01.patch
>
>
> There are 14 resource leak warnings in {{apache/solr/common:}}
> {noformat}
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> (at line 745)
> [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
> --
> [ecj-lint] 5. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
> (at line 215)
> [ecj-lint] SolrResourceLoader loader = new SolrResourceLoader();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'loader' is never closed
> --
> [ecj-lint] 6. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 244)
> [ecj-lint] MetricsHandler handler = new
> MetricsHandler(h.getCoreContainer());
> [ecj-lint]^^^
> [ecj-lint] Resource leak: 'handler' is never closed
> --
> [ecj-lint] 7. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 364)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 8. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 378)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 9. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 638)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 32)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 11. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 39)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 12. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 47)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 13. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 55)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 14. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 63)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 71)
> [ecj-lint] HdfsBacku
[jira] [Commented] (SOLR-14266) Fix or suppress 14 resource leak warnings in apache/solr/core
[
https://issues.apache.org/jira/browse/SOLR-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039086#comment-17039086
]
Andras Salamon commented on SOLR-14266:
---
Usually I use try-with-resources in the patch. In {{ResourceLoaderTest}} I
close the resource just to make it similar to the other test methods in the
class. In {{CoreContainer}} I suppress the warning. I don't think we should
close the resource there. Just to be sure I tried adding a close() there and
got lots of test failures.
> Fix or suppress 14 resource leak warnings in apache/solr/core
> -
>
> Key: SOLR-14266
> URL: https://issues.apache.org/jira/browse/SOLR-14266
> Project: Solr
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14266-01.patch
>
>
> There are 14 resource leak warnings in {{apache/solr/common:}}
> {noformat}
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> (at line 745)
> [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
> --
> [ecj-lint] 5. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
> (at line 215)
> [ecj-lint] SolrResourceLoader loader = new SolrResourceLoader();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'loader' is never closed
> --
> [ecj-lint] 6. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 244)
> [ecj-lint] MetricsHandler handler = new
> MetricsHandler(h.getCoreContainer());
> [ecj-lint]^^^
> [ecj-lint] Resource leak: 'handler' is never closed
> --
> [ecj-lint] 7. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 364)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 8. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 378)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 9. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 638)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 32)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 11. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 39)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 12. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 47)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 13. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 55)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBackupRepository();
> [ecj-lint]
> [ecj-lint] Resource leak: 'hdfsBackupRepository' is never closed
> --
> [ecj-lint] 14. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/backup/repository/HdfsBackupRepositoryTest.java
> (at line 63)
> [ecj-lint] HdfsBackupRepository hdfsBackupRepository = new
> HdfsBacku
[GitHub] [lucene-solr] markharwood merged pull request #1234: LUCENE-9211 Add compression for Binary doc value fields
markharwood merged pull request #1234: LUCENE-9211 Add compression for Binary doc value fields URL: https://github.com/apache/lucene-solr/pull/1234 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9211) Adding compression to BinaryDocValues storage
[ https://issues.apache.org/jira/browse/LUCENE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039104#comment-17039104 ] ASF subversion and git services commented on LUCENE-9211: - Commit ce2959fe4cb1d1e77df04464c46004bf7846f6b5 in lucene-solr's branch refs/heads/master from markharwood [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ce2959f ] LUCENE-9211 Add compression for Binary doc value fields (#1234) Stores groups of 32 binary doc values in LZ4-compressed blocks. > Adding compression to BinaryDocValues storage > - > > Key: LUCENE-9211 > URL: https://issues.apache.org/jira/browse/LUCENE-9211 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Reporter: Mark Harwood >Assignee: Mark Harwood >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > While SortedSetDocValues can be used today to store identical values in a > compact form this is not effective for data with many unique values. > The proposal is that BinaryDocValues should be stored in LZ4 compressed > blocks which can dramatically reduce disk storage costs in many cases. The > proposal is blocks of a number of documents are stored as a single compressed > blob along with metadata that records offsets where the original document > values can be found in the uncompressed content. > There's a trade-off here between efficient compression (more docs-per-block = > better compression) and fast retrieval times (fewer docs-per-block = faster > read access for single values). A fixed block size of 32 docs seems like it > would be a reasonable compromise for most scenarios. > A PR is up for review here [https://github.com/apache/lucene-solr/pull/1234] -- 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-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
[
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039113#comment-17039113
]
Erick Erickson commented on SOLR-13974:
---
I'll close this then, thanks for the feedback!
As for when 8.5 comes out, the release cadence for 8x has been eerh 2-3 months,
so maybe a month or so. That said, nobody has volunteered yet to release 8.5 so
it's a guess.
> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
> Issue Type: Bug
> Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505) at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:12
[jira] [Resolved] (SOLR-13974) Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
[
https://issues.apache.org/jira/browse/SOLR-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-13974.
---
Fix Version/s: 8.5
Resolution: Fixed
Fixed by SOLR-14026 as far as we can tell.
> Solr 8.3 http2 client errors: java.io.IOException: cancel_stream_error
> --
>
> Key: SOLR-13974
> URL: https://issues.apache.org/jira/browse/SOLR-13974
> Project: Solr
> Issue Type: Bug
> Components: http2
>Affects Versions: 8.3, 8.3.1
>Reporter: Jacek Kikiewicz
>Priority: Major
> Fix For: 8.5
>
>
> We are running a solrcloud clusters with Solr 8.3 , from time to time during
> data import we see following errors in solr log:
> {code:java}
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error
> java.io.IOException: cancel_stream_error at
> org.apache.solr.update.processor.DistributedZkUpdateProcessor.doDistribFinish(DistributedZkUpdateProcessor.java:1189)
> at
> org.apache.solr.update.processor.DistributedUpdateProcessor.finish(DistributedUpdateProcessor.java:1096)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:78)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:198)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2576) at
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:803) at
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:582) at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:424)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:311)
> at
> org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:265)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:505) at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
> at
> org.eclipse.jetty.util.thread.Queued
[GitHub] [lucene-solr] markharwood opened a new pull request #1264: LUCENE-9211 Add compression for Binary doc value fields (#1234)
markharwood opened a new pull request #1264: LUCENE-9211 Add compression for Binary doc value fields (#1234) URL: https://github.com/apache/lucene-solr/pull/1264 (cherry picked from commit ce2959fe4cb1d1e77df04464c46004bf7846f6b5) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9230) gradle moman fails on my machine, assumes python -> python2
[
https://issues.apache.org/jira/browse/LUCENE-9230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039120#comment-17039120
]
Erick Erickson commented on LUCENE-9230:
LGTM, thanks! But I'll totally defer to people who, like, use Python ;).
Yeah, I have to use like 24G to run regenerate under Ant.
Honest, I tried to install Python3 on my mac to try to work with this but it
turned into a rabbit-hole...
> gradle moman fails on my machine, assumes python -> python2
> ---
>
> Key: LUCENE-9230
> URL: https://issues.apache.org/jira/browse/LUCENE-9230
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9230.patch, LUCENE-9230.patch
>
>
> python2 is EOL and many distros are transitioning {{python}} to really invoke
> python3. So the scripts fail on wrong syntax in such cases. This happens for
> me if i try {{gradle moman}}.
> I think as a first step, we should explicitly call {{python2}} for any
> python2 scripts, and {{python3}} for python3 scripts?
> cc [~mikemccand]
--
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-12325) introduce uniqueBlockQuery(parent:true) aggregation for JSON Facet
[
https://issues.apache.org/jira/browse/SOLR-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12325:
Attachment: SOLR-12325_Random_test_for_uniqueBlockQuery (1).patch
> introduce uniqueBlockQuery(parent:true) aggregation for JSON Facet
> --
>
> Key: SOLR-12325
> URL: https://issues.apache.org/jira/browse/SOLR-12325
> Project: Solr
> Issue Type: New Feature
> Components: Facet Module
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-12325.patch, SOLR-12325.patch, SOLR-12325.patch,
> SOLR-12325.patch, SOLR-12325_Random_test_for_uniqueBlockQuery (1).patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It might be faster twin for {{uniqueBlock(\_root_)}}. Please utilise buildin
> query parsing method, don't invent your own.
--
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-8962) Can we merge small segments during refresh, for faster searching?
[
https://issues.apache.org/jira/browse/LUCENE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039126#comment-17039126
]
Michael McCandless commented on LUCENE-8962:
Thanks [~dsmiley] and [~msfroh]! I think this is ready? I'll work on merging
the PR soon ...
> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Attachments: LUCENE-8962_demo.png
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory
> segments to disk and open an {{IndexReader}} to search them, and this is
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}}
> will accumulate write many small segments during {{refresh}} and this then
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if
> given a little time ... so, could we somehow improve {{IndexWriter'}}s
> refresh to optionally kick off merge policy to merge segments below some
> threshold before opening the near-real-time reader? It'd be a bit tricky
> because while we are waiting for merges, indexing may continue, and new
> segments may be flushed, but those new segments shouldn't be included in the
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy,
> and some hackity logic to have the merge policy target small segments just
> written by refresh, but it's tricky to then open a near-real-time reader,
> excluding newly flushed but including newly merged segments since the refresh
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for
> discussion!
--
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-9211) Adding compression to BinaryDocValues storage
[ https://issues.apache.org/jira/browse/LUCENE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039132#comment-17039132 ] ASF subversion and git services commented on LUCENE-9211: - Commit bcdc21a0013709095abee1c588b3271a14949ea2 in lucene-solr's branch refs/heads/branch_8x from markharwood [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bcdc21a ] LUCENE-9211 Add compression for Binary doc value fields (#1234) Stores groups of 32 binary doc values in LZ4-compressed blocks. (cherry picked from commit f549ee353530fcd48390a314aff9ec1723b47346) > Adding compression to BinaryDocValues storage > - > > Key: LUCENE-9211 > URL: https://issues.apache.org/jira/browse/LUCENE-9211 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Reporter: Mark Harwood >Assignee: Mark Harwood >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > While SortedSetDocValues can be used today to store identical values in a > compact form this is not effective for data with many unique values. > The proposal is that BinaryDocValues should be stored in LZ4 compressed > blocks which can dramatically reduce disk storage costs in many cases. The > proposal is blocks of a number of documents are stored as a single compressed > blob along with metadata that records offsets where the original document > values can be found in the uncompressed content. > There's a trade-off here between efficient compression (more docs-per-block = > better compression) and fast retrieval times (fewer docs-per-block = faster > read access for single values). A fixed block size of 32 docs seems like it > would be a reasonable compromise for most scenarios. > A PR is up for review here [https://github.com/apache/lucene-solr/pull/1234] -- 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] markharwood merged pull request #1264: LUCENE-9211 Add compression for Binary doc value fields (#1234)
markharwood merged pull request #1264: LUCENE-9211 Add compression for Binary doc value fields (#1234) URL: https://github.com/apache/lucene-solr/pull/1264 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9211) Adding compression to BinaryDocValues storage
[ https://issues.apache.org/jira/browse/LUCENE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Harwood resolved LUCENE-9211. -- Fix Version/s: 8.5 Resolution: Fixed > Adding compression to BinaryDocValues storage > - > > Key: LUCENE-9211 > URL: https://issues.apache.org/jira/browse/LUCENE-9211 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs >Reporter: Mark Harwood >Assignee: Mark Harwood >Priority: Minor > Labels: pull-request-available > Fix For: 8.5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > While SortedSetDocValues can be used today to store identical values in a > compact form this is not effective for data with many unique values. > The proposal is that BinaryDocValues should be stored in LZ4 compressed > blocks which can dramatically reduce disk storage costs in many cases. The > proposal is blocks of a number of documents are stored as a single compressed > blob along with metadata that records offsets where the original document > values can be found in the uncompressed content. > There's a trade-off here between efficient compression (more docs-per-block = > better compression) and fast retrieval times (fewer docs-per-block = faster > read access for single values). A fixed block size of 32 docs seems like it > would be a reasonable compromise for most scenarios. > A PR is up for review here [https://github.com/apache/lucene-solr/pull/1234] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[
https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039137#comment-17039137
]
Tomoko Uchida commented on LUCENE-9201:
---
Yes, the patch works for me too, with this modification. It's not explicitly
documented, but {{sourceSet.getTaskName("ecjLint", null)}} generates
"ecjLintMain" for main sourceSet and "ecjLintTest" for test sourceSet (on
Gradle version 6.0).
{code:java}
//tasks.create("${sourceSet.name}EcjLint", JavaExec, {
tasks.create(sourceSet.getTaskName("ecjLint", null), JavaExec, {
{code}
Can I ask a few questions before creating a patch?
1. When I commented out those lines in gradle.build,
":solr:solr-ref-guide:ecjLint" finished without doing nothing (linting was
safely skipped by the changes in solr/solr-ref-guide/build.gradle, if my
understanding is correct). Is this configuration still needed?
{code:java}
// This excludes solr-ref-guide from the check (excludes are not taken into
account
// and linting of the ant-based task fails.
configure(project(":solr:solr-ref-guide")) {
afterEvaluate {
project.tasks.findByPath("mainEcjLint").enabled = false
}
}
{code}
2. Currently all other check tasks are grouped in "Verification", so would it
be better to change the task group name "validation" to "Verification"?
{code:java}
$ ./gradles tasks
...
Validation tasks
ecjLint - Lint Java sources using ECJ.
Verification tasks
--
check - Runs all checks.
checkUnusedConstraints - Ensures all versions in your versions.props correspond
to an actual gradle dependency
forbiddenApis - Runs forbidden-apis checks.
owasp - Check project dependencies against OWASP vulnerability database.
rat - Runs Apache Rat checks.
test - Runs the unit tests.
verifyLocks - Verifies that your versions.lock is up to date
{code}
> Port documentation-lint task to Gradle build
>
>
> Key: LUCENE-9201
> URL: https://issues.apache.org/jira/browse/LUCENE-9201
> Project: Lucene - Core
> Issue Type: Sub-task
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch,
> javadocGRADLE.png, javadocHTML4.png, javadocHTML5.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Ant build's "documentation-lint" target consists of those two sub targets.
> * "-ecj-javadoc-lint" (Javadoc linting by ECJ)
> * "-documentation-lint"(Missing javadocs / broken links check by python
> scripts)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] BiM31 commented on a change in pull request #417: Fixes SOLR-12550: ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
BiM31 commented on a change in pull request #417: Fixes SOLR-12550:
ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
URL: https://github.com/apache/lucene-solr/pull/417#discussion_r380719554
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClient.java
##
@@ -121,9 +121,11 @@ protected ConcurrentUpdateSolrClient(String solrServerUrl,
protected ConcurrentUpdateSolrClient(Builder builder) {
this.internalHttpClient = (builder.httpClient == null);
-this.client = new HttpSolrClient.Builder(builder.baseSolrUrl)
-.withHttpClient(builder.httpClient)
-.build();
+HttpSolrClient.Builder httpClientBuilder = new
HttpSolrClient.Builder(builder.baseSolrUrl)
+.withHttpClient(builder.httpClient);
+httpClientBuilder.connectionTimeoutMillis =
builder.connectionTimeoutMillis;
+httpClientBuilder.socketTimeoutMillis = builder.socketTimeoutMillis;
Review comment:
Maybe you should use with* methods and do the build as the previous version.
```
.withConnectionTimeout(builder.connectionTimeoutMillis)
.withSocketTimeout(builder.socketTimeoutMillis)
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8987) Move Lucene web site from svn to git
[
https://issues.apache.org/jira/browse/LUCENE-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039139#comment-17039139
]
Namgyu Kim commented on LUCENE-8987:
Thanks for checking my comment. [~janhoy] :)
I checked [https://github.com/apache/lucene-site/pull/12] and it looks good.
> Move Lucene web site from svn to git
>
>
> Key: LUCENE-8987
> URL: https://issues.apache.org/jira/browse/LUCENE-8987
> Project: Lucene - Core
> Issue Type: Task
> Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: lucene-site-repo.png
>
>
> INFRA just enabled [a new way of configuring website
> build|https://s.apache.org/asfyaml] from a git branch, [see dev list
> email|https://lists.apache.org/thread.html/b6f7e40bece5e83e27072ecc634a7815980c90240bc0a2ccb417f1fd@%3Cdev.lucene.apache.org%3E].
> It allows for automatic builds of both staging and production site, much
> like the old CMS. We can choose to auto publish the html content of an
> {{output/}} folder, or to have a bot build the site using
> [Pelican|https://github.com/getpelican/pelican] from a {{content/}} folder.
> The goal of this issue is to explore how this can be done for
> [http://lucene.apache.org|http://lucene.apache.org/] by, by creating a new
> git repo {{lucene-site}}, copy over the site from svn, see if it can be
> "Pelicanized" easily and then test staging. Benefits are that more people
> will be able to edit the web site and we can take PRs from the public (with
> GitHub preview of pages).
> Non-goals:
> * Create a new web site or a new graphic design
> * Change from Markdown to Asciidoc
--
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] (LUCENE-9201) Port documentation-lint task to Gradle build
[
https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039137#comment-17039137
]
Tomoko Uchida edited comment on LUCENE-9201 at 2/18/20 2:59 PM:
Yes, the patch works for me too, with this modification. It's not explicitly
documented, but {{sourceSet.getTaskName("ecjLint", null)}} generates
"ecjLintMain" for main sourceSet and "ecjLintTest" for test sourceSet (on
Gradle version 6.0).
{code:java}
//tasks.create("${sourceSet.name}EcjLint", JavaExec, {
tasks.create(sourceSet.getTaskName("ecjLint", null), JavaExec, {
{code}
Can I ask a few more questions before creating a patch?
1. Even when I commented out those lines in gradle.build,
":solr:solr-ref-guide:ecjLint" finished without doing nothing (linting was
safely skipped by the changes in solr/solr-ref-guide/build.gradle, if my
understanding is correct). Is this configuration still needed?
{code:java}
// This excludes solr-ref-guide from the check (excludes are not taken into
account
// and linting of the ant-based task fails.
configure(project(":solr:solr-ref-guide")) {
afterEvaluate {
project.tasks.findByPath("mainEcjLint").enabled = false
}
}
{code}
2. Currently all other check tasks are grouped in "Verification", so would it
be better to change the task group name "validation" to "Verification"?
{code:java}
$ ./gradles tasks
...
Validation tasks
ecjLint - Lint Java sources using ECJ.
Verification tasks
--
check - Runs all checks.
checkUnusedConstraints - Ensures all versions in your versions.props correspond
to an actual gradle dependency
forbiddenApis - Runs forbidden-apis checks.
owasp - Check project dependencies against OWASP vulnerability database.
rat - Runs Apache Rat checks.
test - Runs the unit tests.
verifyLocks - Verifies that your versions.lock is up to date
{code}
was (Author: tomoko uchida):
Yes, the patch works for me too, with this modification. It's not explicitly
documented, but {{sourceSet.getTaskName("ecjLint", null)}} generates
"ecjLintMain" for main sourceSet and "ecjLintTest" for test sourceSet (on
Gradle version 6.0).
{code:java}
//tasks.create("${sourceSet.name}EcjLint", JavaExec, {
tasks.create(sourceSet.getTaskName("ecjLint", null), JavaExec, {
{code}
Can I ask a few questions before creating a patch?
1. When I commented out those lines in gradle.build,
":solr:solr-ref-guide:ecjLint" finished without doing nothing (linting was
safely skipped by the changes in solr/solr-ref-guide/build.gradle, if my
understanding is correct). Is this configuration still needed?
{code:java}
// This excludes solr-ref-guide from the check (excludes are not taken into
account
// and linting of the ant-based task fails.
configure(project(":solr:solr-ref-guide")) {
afterEvaluate {
project.tasks.findByPath("mainEcjLint").enabled = false
}
}
{code}
2. Currently all other check tasks are grouped in "Verification", so would it
be better to change the task group name "validation" to "Verification"?
{code:java}
$ ./gradles tasks
...
Validation tasks
ecjLint - Lint Java sources using ECJ.
Verification tasks
--
check - Runs all checks.
checkUnusedConstraints - Ensures all versions in your versions.props correspond
to an actual gradle dependency
forbiddenApis - Runs forbidden-apis checks.
owasp - Check project dependencies against OWASP vulnerability database.
rat - Runs Apache Rat checks.
test - Runs the unit tests.
verifyLocks - Verifies that your versions.lock is up to date
{code}
> Port documentation-lint task to Gradle build
>
>
> Key: LUCENE-9201
> URL: https://issues.apache.org/jira/browse/LUCENE-9201
> Project: Lucene - Core
> Issue Type: Sub-task
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch,
> javadocGRADLE.png, javadocHTML4.png, javadocHTML5.png
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Ant build's "documentation-lint" target consists of those two sub targets.
> * "-ecj-javadoc-lint" (Javadoc linting by ECJ)
> * "-documentation-lint"(Missing javadocs / broken links check by python
> scripts)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9201) Port documentation-lint task to Gradle build
[ https://issues.apache.org/jira/browse/LUCENE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039152#comment-17039152 ] Dawid Weiss commented on LUCENE-9201: - # Feel free to switch to sourceSet.getTaskName. # The solr-ref-guide shouldfail on linting without this block because it'll have incomplete classpath and won't be able to compile one of the source files (we don't use that one in Gradle; ant build adds ant classpath so it compiles). I think the task has been skipped because it observed no changes on inputs. Try running with --rerun-tasks and I'm sure it'll fail. # Correct group name, good catch. > Port documentation-lint task to Gradle build > > > Key: LUCENE-9201 > URL: https://issues.apache.org/jira/browse/LUCENE-9201 > Project: Lucene - Core > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Attachments: LUCENE-9201-ecj-2.patch, LUCENE-9201-ecj.patch, > javadocGRADLE.png, javadocHTML4.png, javadocHTML5.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Ant build's "documentation-lint" target consists of those two sub targets. > * "-ecj-javadoc-lint" (Javadoc linting by ECJ) > * "-documentation-lint"(Missing javadocs / broken links check by python > scripts) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039154#comment-17039154
]
Christine Poerschke commented on SOLR-13240:
bq. ... very easy to trigger in the production environment, it makes
UTILIZENODE action not usable in Solr 7.x.x versions. Do you think this feature
should be removed or marked as beta in Solr 7.x ...
Understood. Unfortunately I'm not aware of any mechanisms to remove a feature
from an existing release or to mark it as beta. On this ticket here extending
the "Affected versions" tagging beyond the current 7.6 should be easily
possible though, let me go and do that.
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Assignee: Christine Poerschke
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.
[jira] [Updated] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-13240:
---
Affects Version/s: 7.7
7.7.1
7.7.2
8.0
8.1
8.2
8.1.1
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6, 7.7, 7.7.1, 7.7.2, 8.0, 8.1, 8.2, 8.1.1
>Reporter: Hendrik Haddorp
>Assignee: Christine Poerschke
>Priority: Major
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)\n\ta
[jira] [Commented] (SOLR-12550) ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
[ https://issues.apache.org/jira/browse/SOLR-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039158#comment-17039158 ] Bérénice MAUREL commented on SOLR-12550: I also added a comment to this PR. > ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize > > > Key: SOLR-12550 > URL: https://issues.apache.org/jira/browse/SOLR-12550 > Project: Solr > Issue Type: Bug >Reporter: Marc Morissette >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We're in a situation where we need to optimize some of our collections. These > optimizations are done with waitSearcher=true as a simple throttling > mechanism to prevent too many collections from being optimized at once. > We're seeing these optimize commands return without error after 10 minutes > but well before the end of the operation. Our Solr logs show errors with > socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value > has no effect. > See the links section for my patch. > It turns out that ConcurrentUpdateSolrClient delegates commit and optimize > commands to a private HttpSolrClient but fails to pass along its builder's > timeouts to that client. > A patch is attached in the links section. -- 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] dnhatn commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
dnhatn commented on a change in pull request #1263: LUCENE-9228: Sort dv
updates by terms by applying
URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380734250
##
File path:
lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java
##
@@ -808,10 +808,17 @@ private void setField(String field) throws IOException {
} else {
termsEnum = null;
}
+currentTermVisited = false;
}
}
-DocIdSetIterator nextTerm(String field, BytesRef term) throws IOException {
+/**
+ * Returns a {@link DocIdSetIterator} for the given field and term if
exists. If the parameter
+ * {@code skipIfTermVisited} is true, then this method will return null if
the given and field
+ * was visited already. This optimization is currently used in
+ * {@link #applyDocValuesUpdates(BufferedUpdatesStream.SegmentState, Map,
long, boolean)}
+ */
+DocIdSetIterator nextTerm(String field, BytesRef term, boolean
skipIfTermVisited) throws IOException {
Review comment:
It's doable and more contained than the current approach, but there are two
downsides with it. We need to compare the current term and the last term. Here,
we don't have to as we re-use the comparison between the reader term and the
current term. We also need to maintain an extra iterator for the last term as
we set BytesRef when iterating terms. I am happy to make this change if you
think the comparison cost is not significant.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9219) Port ECJ-based linter to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-9219: -- Attachment: LUCENE-9219.patch > Port ECJ-based linter to gradle > --- > > Key: LUCENE-9219 > URL: https://issues.apache.org/jira/browse/LUCENE-9219 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: LUCENE-9219.patch > > -- 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 issue #417: Fixes SOLR-12550: ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
HoustonPutman commented on issue #417: Fixes SOLR-12550: ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize URL: https://github.com/apache/lucene-solr/pull/417#issuecomment-587519481 So I think this is built off of a really old master. We should probably make sure these timeouts are also respected by `ConcurrentUpdateHttp2SolrClient` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13669) [CVE-2019-0193] Remote Code Execution via DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-13669: -- Fix Version/s: 7.7 > [CVE-2019-0193] Remote Code Execution via DataImportHandler > --- > > Key: SOLR-13669 > URL: https://issues.apache.org/jira/browse/SOLR-13669 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Michael Stepankin >Assignee: David Smiley >Priority: Major > Fix For: 7.7, 8.1.2, 8.2.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The DataImportHandler, an optional but popular module to pull in data from > databases and other sources, has a feature in which the whole DIH > configuration can come from a request's "dataConfig" parameter. The debug > mode of the DIH admin screen uses this to allow convenient debugging / > development of a DIH config. Since a DIH config can contain scripts, this > parameter is a security risk. Starting with version 8.2.0 of Solr, use of > this parameter requires setting the Java System property > "enable.dih.dataConfigParam" to true. > Mitigations: > * Upgrade to 8.2.0 or later, which is secure by default. > * or, edit solrconfig.xml to configure all DataImportHandler usages with an > "invariants" section listing the "dataConfig" parameter set to am empty > string. > * Ensure your network settings are configured so that only trusted traffic > communicates with Solr, especially to the DIH request handler. This is a > best practice to all of Solr. > Credits: > * Michael Stepankin > References: > * https://issues.apache.org/jira/browse/SOLR-13669 > * https://cwiki.apache.org/confluence/display/solr/SolrSecurity -- 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-9219) Port ECJ-based linter to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated LUCENE-9219: -- Attachment: LUCENE-9219.patch > Port ECJ-based linter to gradle > --- > > Key: LUCENE-9219 > URL: https://issues.apache.org/jira/browse/LUCENE-9219 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: LUCENE-9219.patch, LUCENE-9219.patch > > -- 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-14266) Fix or suppress 14 resource leak warnings in apache/solr/core
[
https://issues.apache.org/jira/browse/SOLR-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039177#comment-17039177
]
Lucene/Solr QA commented on SOLR-14266:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
45s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 23s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 82m
58s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 91m 0s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14266 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12993763/SOLR-14266-01.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-170-generic #199-Ubuntu SMP
Thu Nov 14 01:45:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / ce2959f |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/683/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/683/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Fix or suppress 14 resource leak warnings in apache/solr/core
> -
>
> Key: SOLR-14266
> URL: https://issues.apache.org/jira/browse/SOLR-14266
> Project: Solr
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14266-01.patch
>
>
> There are 14 resource leak warnings in {{apache/solr/common:}}
> {noformat}
> [ecj-lint] 10. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/java/org/apache/solr/core/CoreContainer.java
> (at line 745)
> [ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'fieldCacheBean' is never closed
> --
> [ecj-lint] 5. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/ResourceLoaderTest.java
> (at line 215)
> [ecj-lint] SolrResourceLoader loader = new SolrResourceLoader();
> [ecj-lint]^^
> [ecj-lint] Resource leak: 'loader' is never closed
> --
> [ecj-lint] 6. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 244)
> [ecj-lint] MetricsHandler handler = new
> MetricsHandler(h.getCoreContainer());
> [ecj-lint]^^^
> [ecj-lint] Resource leak: 'handler' is never closed
> --
> [ecj-lint] 7. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 364)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is never closed
> --
> [ecj-lint] 8. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/solr/core/src/test/org/apache/solr/core/TestLazyCores.java
> (at line 378)
> [ecj-lint] final CoreAdminHandler admin = new CoreAdminHandler(cc);
> [ecj-lint]^
> [ecj-lint] Resource leak: 'admin' is
[jira] [Updated] (LUCENE-9191) Fix linefiledocs compression or replace in tests
[
https://issues.apache.org/jira/browse/LUCENE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-9191:
---
Attachment: LUCENE-9191.patch
Status: Open (was: Open)
Another iteration of the patch, improving the previous hackity word boundary
detection to use Python's regex {{\W}} with {{re.UNICODE}} flag (thanks
[~rcmuir]!). I then regenerated all three line files + seek files, and
confirmed Lucene tests pass with the 20 MB file.
> Fix linefiledocs compression or replace in tests
>
>
> Key: LUCENE-9191
> URL: https://issues.apache.org/jira/browse/LUCENE-9191
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Robert Muir
>Assignee: Michael McCandless
>Priority: Major
> Attachments: LUCENE-9191.patch, LUCENE-9191.patch
>
>
> LineFileDocs(random) is very slow, even to open. It does a very slow "random
> skip" through a gzip compressed file.
> For the analyzers tests, in LUCENE-9186 I simply removed its usage, since
> TestUtil.randomAnalysisString is superior, and fast. But we should address
> other tests using it, since LineFileDocs(random) is slow!
> I think it is also the case that every lucene test has probably tested every
> LineFileDocs line many times now, whereas randomAnalysisString will invent
> new ones.
> Alternatively, we could "fix" LineFileDocs(random), e.g. special compression
> options (in blocks)... deflate supports such stuff. But it would make it even
> hairier than it is now.
--
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] andywebb1975 opened a new pull request #1265: SOLR-14252: avoid NPE in metric aggregation
andywebb1975 opened a new pull request #1265: SOLR-14252: avoid NPE in metric aggregation URL: https://github.com/apache/lucene-solr/pull/1265 # Description The getMax and getMin methods in AggregateMetric can throw an NPE if _only_ non-Number values are present when it tries to cast a null Double to a double. # Solution This PR switches to using primitive doubles, defaulting to zero, and logs when non-Number values are provided (we've seen `false` and `LocalStatsCache`). # Tests TBC # 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 With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13910) Create security news feed on website with RSS/Atom feed
[ https://issues.apache.org/jira/browse/SOLR-13910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-13910: -- Assignee: Jan Høydahl > Create security news feed on website with RSS/Atom feed > --- > > Key: SOLR-13910 > URL: https://issues.apache.org/jira/browse/SOLR-13910 > Project: Solr > Issue Type: Task > Components: website >Reporter: Adam Walz >Assignee: Jan Høydahl >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > From [~janhoy] > We're in the process of migrating our web site to Git and in that same > process we also change CMS from an ASF one to Pelican. The new site has > built-in support for news posts as individual files and also RSS feeds of > those. So I propose to add [https://lucene.apache.org/solr/security.html] > to the site, including a list of newest CVEs and an RSS/Atom feed to go > along with it. This way users have ONE place to visit to check security > announcements and they can monitor RSS to be alerted once we post a new > announcement. > We could also add RSS feeds for Lucene-core news and Solr-news sections > of course. > At the same time I propose that the news on the front-page > [lucene.apache.org|http://lucene.apache.org/] > is replaced with widgets that show the title only of the last 3 announcements > from Lucene, Solr and PyLucene sub projects. That front page is waaay > too long :) -- 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-13910) Create security news feed on website with RSS/Atom feed
[
https://issues.apache.org/jira/browse/SOLR-13910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039185#comment-17039185
]
Jan Høydahl commented on SOLR-13910:
I'm continuing with this in PR#4. Here are my plans
* Separate security/ folder to place CVE news into
* New "Security" page only for Solr, linked into top menu, that will display
only {{category solr/security}}
* The Solr main "News" page will display both normal news and security news
(selecting both categories)
* The front-page last 3 news items will also consider security news, and those
will have light-red background color instead of light-green
* Add an RSS/ATOM feed for the Solr security news
> Create security news feed on website with RSS/Atom feed
> ---
>
> Key: SOLR-13910
> URL: https://issues.apache.org/jira/browse/SOLR-13910
> Project: Solr
> Issue Type: Task
> Components: website
>Reporter: Adam Walz
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> From [~janhoy]
> We're in the process of migrating our web site to Git and in that same
> process we also change CMS from an ASF one to Pelican. The new site has
> built-in support for news posts as individual files and also RSS feeds of
> those. So I propose to add [https://lucene.apache.org/solr/security.html]
> to the site, including a list of newest CVEs and an RSS/Atom feed to go
> along with it. This way users have ONE place to visit to check security
> announcements and they can monitor RSS to be alerted once we post a new
> announcement.
> We could also add RSS feeds for Lucene-core news and Solr-news sections
> of course.
> At the same time I propose that the news on the front-page
> [lucene.apache.org|http://lucene.apache.org/]
> is replaced with widgets that show the title only of the last 3 announcements
> from Lucene, Solr and PyLucene sub projects. That front page is waaay
> too long :)
--
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] andywebb1975 commented on issue #1247: SOLR-14252 use double rather than Double to avoid NPE
andywebb1975 commented on issue #1247: SOLR-14252 use double rather than Double to avoid NPE URL: https://github.com/apache/lucene-solr/pull/1247#issuecomment-587533065 I've opened a new clean PR: https://github.com/apache/lucene-solr/pull/1265 to replace this one, taking a different approach to avoiding the NPE. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] andywebb1975 closed pull request #1247: SOLR-14252 use double rather than Double to avoid NPE
andywebb1975 closed pull request #1247: SOLR-14252 use double rather than Double to avoid NPE URL: https://github.com/apache/lucene-solr/pull/1247 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14252) NullPointerException in AggregateMetric
[
https://issues.apache.org/jira/browse/SOLR-14252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Webb updated SOLR-14252:
-
Description:
The {{getMax}} and {{getMin}} methods in
[AggregateMetric|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/metrics/AggregateMetric.java]
can throw an NPE if non-{{Number}} values are present in {{values}}, when it
tries to cast a {{null}} {{Double}} to a {{double}}.
This PR prevents the NPE occurring:
[https://github.com/apache/lucene-solr/pull/1265]
(We've also noticed an error in the documentation - see
https://github.com/apache/lucene-solr/commit/109d3411cd3866d83273187170dbc5b8b3211d20
- this could be pulled out into a separate ticket if necessary?)
was:
The {{getMax}} and {{getMin}} methods in
[AggregateMetric|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/metrics/AggregateMetric.java]
can throw an NPE if non-{{Number}} values are present in {{values}}, when it
tries to cast a {{null}} {{Double}} to a {{double}}.
This PR prevents the NPE occurring:
[https://github.com/apache/lucene-solr/pull/1247]
(We've also noticed an error in the documentation - see
https://github.com/apache/lucene-solr/commit/109d3411cd3866d83273187170dbc5b8b3211d20
- this could be pulled out into a separate ticket if necessary?)
> NullPointerException in AggregateMetric
> ---
>
> Key: SOLR-14252
> URL: https://issues.apache.org/jira/browse/SOLR-14252
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Andy Webb
>Assignee: Andrzej Bialecki
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> The {{getMax}} and {{getMin}} methods in
> [AggregateMetric|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/metrics/AggregateMetric.java]
> can throw an NPE if non-{{Number}} values are present in {{values}}, when it
> tries to cast a {{null}} {{Double}} to a {{double}}.
> This PR prevents the NPE occurring:
> [https://github.com/apache/lucene-solr/pull/1265]
> (We've also noticed an error in the documentation - see
> https://github.com/apache/lucene-solr/commit/109d3411cd3866d83273187170dbc5b8b3211d20
> - this could be pulled out into a separate ticket if necessary?)
--
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-9219) Port ECJ-based linter to gradle
[
https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039190#comment-17039190
]
Tomoko Uchida commented on LUCENE-9219:
---
Hi [~dweiss],
I attached [^LUCENE-9219.patch], a modified version of the patch in
LUCENE-9201. Could you take a look at this?
(diffs from LUCENE-9201-ecj-2.patch)
- use sourceSet.getTaskName()
- task group was changed to "Verification"
- the artifact version of "org.eclipse.jdt:ecj" was moved to "build.gradle"
from "ecj-lint.gradle"
Also I excluded the changes for "lucene/common-build.xml", because I thought
this was added to the patch accidentally. Please let me know if this should be
included again.
{code:java}
diff --git a/lucene/common-build.xml b/lucene/common-build.xml
index 1e3da88250b..ca5887df550 100644
--- a/lucene/common-build.xml
+++ b/lucene/common-build.xml
@@ -2034,6 +2034,7 @@
${ant.project.name}.test.dependencies=${test.classpath.list}
+
{code}
> Port ECJ-based linter to gradle
> ---
>
> Key: LUCENE-9219
> URL: https://issues.apache.org/jira/browse/LUCENE-9219
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Priority: Major
> Attachments: LUCENE-9219.patch, LUCENE-9219.patch
>
>
--
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-13965) Adding new functions to GraphHandler should be same as Streamhandler
[ https://issues.apache.org/jira/browse/SOLR-13965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039192#comment-17039192 ] ASF subversion and git services commented on SOLR-13965: Commit 5d32c04096dfdbf0a0e9c3c5fd6f4a787ca153ea in lucene-solr's branch refs/heads/master from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5d32c04 ] SOLR-13965: StreamHandler class-level javadoc edits (Eric Pugh via Christine Poerschke) > Adding new functions to GraphHandler should be same as Streamhandler > > > Key: SOLR-13965 > URL: https://issues.apache.org/jira/browse/SOLR-13965 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Affects Versions: 8.3 >Reporter: David Eric Pugh >Priority: Minor > Attachments: SOLR-13965.01.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently you add new functions to GraphHandler differently than you do in > StreamHandler. We should have one way of extending the handlers that support > streaming expressions. -- 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-13965) Adding new functions to GraphHandler should be same as Streamhandler
[ https://issues.apache.org/jira/browse/SOLR-13965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039193#comment-17039193 ] ASF subversion and git services commented on SOLR-13965: Commit f23def6b721192f6cf6ebec037fbf0a1a4b0d33c in lucene-solr's branch refs/heads/master from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f23def6 ] SOLR-13965: s/StreamHandler/GraphHandler fix GraphHandler.getDescription() (Eric Pugh via Christine Poerschke) > Adding new functions to GraphHandler should be same as Streamhandler > > > Key: SOLR-13965 > URL: https://issues.apache.org/jira/browse/SOLR-13965 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Affects Versions: 8.3 >Reporter: David Eric Pugh >Priority: Minor > Attachments: SOLR-13965.01.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently you add new functions to GraphHandler differently than you do in > StreamHandler. We should have one way of extending the handlers that support > streaming expressions. -- 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-13041) SolrJ autoscaling Condition class has equals but no hashCode
[ https://issues.apache.org/jira/browse/SOLR-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039195#comment-17039195 ] ASF subversion and git services commented on SOLR-13041: Commit 003303a9cc8e1d5471448b538b611984b5e669a7 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=003303a ] SOLR-13041: Add hashCode for autoscaling.Condition to accompany the already present equals. (Zsolt Gyulavari via Christine Poerschke) > SolrJ autoscaling Condition class has equals but no hashCode > > > Key: SOLR-13041 > URL: https://issues.apache.org/jira/browse/SOLR-13041 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 7.5 >Reporter: Zsolt Gyulavari >Assignee: Noble Paul >Priority: Major > Labels: patch-available > Attachments: SOLR-13041.patch, SOLR-13041.patch > > > SolrJ autoscaling Condition class has equals but no hashCode implementation. > Instances are being used in a HashSet in Clause.testGroupNodes method, so > this could lead to unreliable behavior or increased memory consumption. -- 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] zsgyulavari commented on issue #1144: SOLR-13756 updated restlet mvn repository url.
zsgyulavari commented on issue #1144: SOLR-13756 updated restlet mvn repository url. URL: https://github.com/apache/lucene-solr/pull/1144#issuecomment-587541091 rebased on top of master and went on to remove the unused cloudera repos. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13041) SolrJ autoscaling Condition class has equals but no hashCode
[ https://issues.apache.org/jira/browse/SOLR-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039196#comment-17039196 ] Christine Poerschke commented on SOLR-13041: Thanks [~gyzsolt] for the issue find, fix and associated tests! [~noble.paul], I hope you don't mind me proceeding to commit on this issue here? It looked good-to-go and I happened to stumble across it in the backlog ... > SolrJ autoscaling Condition class has equals but no hashCode > > > Key: SOLR-13041 > URL: https://issues.apache.org/jira/browse/SOLR-13041 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 7.5 >Reporter: Zsolt Gyulavari >Assignee: Noble Paul >Priority: Major > Labels: patch-available > Attachments: SOLR-13041.patch, SOLR-13041.patch > > > SolrJ autoscaling Condition class has equals but no hashCode implementation. > Instances are being used in a HashSet in Clause.testGroupNodes method, so > this could lead to unreliable behavior or increased memory consumption. -- 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-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039201#comment-17039201 ] Zsolt Gyulavari commented on SOLR-13756: I've rebased on top of master and went on to remove the unused Cloudera repos. Please review. > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug >Reporter: Chongchen Chen >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- 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-13965) Adding new functions to GraphHandler should be same as Streamhandler
[ https://issues.apache.org/jira/browse/SOLR-13965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039220#comment-17039220 ] ASF subversion and git services commented on SOLR-13965: Commit d52e70a731d15c493087bc060766a52d33305647 in lucene-solr's branch refs/heads/branch_8x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d52e70a ] SOLR-13965: StreamHandler class-level javadoc edits (Eric Pugh via Christine Poerschke) > Adding new functions to GraphHandler should be same as Streamhandler > > > Key: SOLR-13965 > URL: https://issues.apache.org/jira/browse/SOLR-13965 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Affects Versions: 8.3 >Reporter: David Eric Pugh >Priority: Minor > Attachments: SOLR-13965.01.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently you add new functions to GraphHandler differently than you do in > StreamHandler. We should have one way of extending the handlers that support > streaming expressions. -- 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-13965) Adding new functions to GraphHandler should be same as Streamhandler
[ https://issues.apache.org/jira/browse/SOLR-13965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039221#comment-17039221 ] ASF subversion and git services commented on SOLR-13965: Commit f8e50a8fc21f4fa614e73d7c7a1d99cea1625379 in lucene-solr's branch refs/heads/branch_8x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f8e50a8 ] SOLR-13965: s/StreamHandler/GraphHandler fix GraphHandler.getDescription() (Eric Pugh via Christine Poerschke) > Adding new functions to GraphHandler should be same as Streamhandler > > > Key: SOLR-13965 > URL: https://issues.apache.org/jira/browse/SOLR-13965 > Project: Solr > Issue Type: Improvement > Components: streaming expressions >Affects Versions: 8.3 >Reporter: David Eric Pugh >Priority: Minor > Attachments: SOLR-13965.01.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently you add new functions to GraphHandler differently than you do in > StreamHandler. We should have one way of extending the handlers that support > streaming expressions. -- 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-13041) SolrJ autoscaling Condition class has equals but no hashCode
[ https://issues.apache.org/jira/browse/SOLR-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039222#comment-17039222 ] ASF subversion and git services commented on SOLR-13041: Commit 01c9c68cc8dffe496f9a15de253c6f81cd2d2c16 in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=01c9c68 ] SOLR-13041: Add hashCode for autoscaling.Condition to accompany the already present equals. (Zsolt Gyulavari via Christine Poerschke) > SolrJ autoscaling Condition class has equals but no hashCode > > > Key: SOLR-13041 > URL: https://issues.apache.org/jira/browse/SOLR-13041 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 7.5 >Reporter: Zsolt Gyulavari >Assignee: Noble Paul >Priority: Major > Labels: patch-available > Attachments: SOLR-13041.patch, SOLR-13041.patch > > > SolrJ autoscaling Condition class has equals but no hashCode implementation. > Instances are being used in a HashSet in Clause.testGroupNodes method, so > this could lead to unreliable behavior or increased memory consumption. -- 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-13041) SolrJ autoscaling Condition class has equals but no hashCode
[ https://issues.apache.org/jira/browse/SOLR-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-13041: --- Fix Version/s: 8.5 master (9.0) > SolrJ autoscaling Condition class has equals but no hashCode > > > Key: SOLR-13041 > URL: https://issues.apache.org/jira/browse/SOLR-13041 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 7.5 >Reporter: Zsolt Gyulavari >Assignee: Noble Paul >Priority: Major > Labels: patch-available > Fix For: master (9.0), 8.5 > > Attachments: SOLR-13041.patch, SOLR-13041.patch > > > SolrJ autoscaling Condition class has equals but no hashCode implementation. > Instances are being used in a HashSet in Clause.testGroupNodes method, so > this could lead to unreliable behavior or increased memory consumption. -- 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] dnhatn commented on a change in pull request #1263: LUCENE-9228: Sort dv updates by terms by applying
dnhatn commented on a change in pull request #1263: LUCENE-9228: Sort dv
updates by terms by applying
URL: https://github.com/apache/lucene-solr/pull/1263#discussion_r380797423
##
File path:
lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java
##
@@ -808,10 +808,17 @@ private void setField(String field) throws IOException {
} else {
termsEnum = null;
}
+currentTermVisited = false;
}
}
-DocIdSetIterator nextTerm(String field, BytesRef term) throws IOException {
+/**
+ * Returns a {@link DocIdSetIterator} for the given field and term if
exists. If the parameter
+ * {@code skipIfTermVisited} is true, then this method will return null if
the given and field
+ * was visited already. This optimization is currently used in
+ * {@link #applyDocValuesUpdates(BufferedUpdatesStream.SegmentState, Map,
long, boolean)}
+ */
+DocIdSetIterator nextTerm(String field, BytesRef term, boolean
skipIfTermVisited) throws IOException {
Review comment:
FYI, I am benchmarking the new change.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on issue #1260: SOLR-13669: DIH: Add System property toggle for use of dataConfig param
HoustonPutman commented on issue #1260: SOLR-13669: DIH: Add System property toggle for use of dataConfig param URL: https://github.com/apache/lucene-solr/pull/1260#issuecomment-587567685 Full test suite looks fine as well. Will merge this unless there are any objections. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9219) Port ECJ-based linter to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039250#comment-17039250 ] Dawid Weiss commented on LUCENE-9219: - Looks good to me, thanks [~tomoko]! > Port ECJ-based linter to gradle > --- > > Key: LUCENE-9219 > URL: https://issues.apache.org/jira/browse/LUCENE-9219 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: LUCENE-9219.patch, LUCENE-9219.patch > > -- 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 merged pull request #1260: SOLR-13669: DIH: Add System property toggle for use of dataConfig param
HoustonPutman merged pull request #1260: SOLR-13669: DIH: Add System property toggle for use of dataConfig param URL: https://github.com/apache/lucene-solr/pull/1260 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13669) [CVE-2019-0193] Remote Code Execution via DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039262#comment-17039262 ] ASF subversion and git services commented on SOLR-13669: Commit 224c038f9b9a40517ff5378971d3c8aac7c4aafa in lucene-solr's branch refs/heads/branch_7_7 from Houston Putman [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=224c038 ] SOLR-13669: DIH: Add System property toggle for use of dataConfig param (#1260) (cherry picked from commit 325824cd391c8e71f36f17d687f52344e50e9715) Addresses CVE-2019-0193, backported from Solr 8.1.2 > [CVE-2019-0193] Remote Code Execution via DataImportHandler > --- > > Key: SOLR-13669 > URL: https://issues.apache.org/jira/browse/SOLR-13669 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Michael Stepankin >Assignee: David Smiley >Priority: Major > Fix For: 7.7.3, 8.1.2, 8.2.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The DataImportHandler, an optional but popular module to pull in data from > databases and other sources, has a feature in which the whole DIH > configuration can come from a request's "dataConfig" parameter. The debug > mode of the DIH admin screen uses this to allow convenient debugging / > development of a DIH config. Since a DIH config can contain scripts, this > parameter is a security risk. Starting with version 8.2.0 of Solr, use of > this parameter requires setting the Java System property > "enable.dih.dataConfigParam" to true. > Mitigations: > * Upgrade to 8.2.0 or later, which is secure by default. > * or, edit solrconfig.xml to configure all DataImportHandler usages with an > "invariants" section listing the "dataConfig" parameter set to am empty > string. > * Ensure your network settings are configured so that only trusted traffic > communicates with Solr, especially to the DIH request handler. This is a > best practice to all of Solr. > Credits: > * Michael Stepankin > References: > * https://issues.apache.org/jira/browse/SOLR-13669 > * https://cwiki.apache.org/confluence/display/solr/SolrSecurity -- 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-13669) [CVE-2019-0193] Remote Code Execution via DataImportHandler
[ https://issues.apache.org/jira/browse/SOLR-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-13669: -- Fix Version/s: (was: 7.7) 7.7.3 > [CVE-2019-0193] Remote Code Execution via DataImportHandler > --- > > Key: SOLR-13669 > URL: https://issues.apache.org/jira/browse/SOLR-13669 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Reporter: Michael Stepankin >Assignee: David Smiley >Priority: Major > Fix For: 7.7.3, 8.1.2, 8.2.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The DataImportHandler, an optional but popular module to pull in data from > databases and other sources, has a feature in which the whole DIH > configuration can come from a request's "dataConfig" parameter. The debug > mode of the DIH admin screen uses this to allow convenient debugging / > development of a DIH config. Since a DIH config can contain scripts, this > parameter is a security risk. Starting with version 8.2.0 of Solr, use of > this parameter requires setting the Java System property > "enable.dih.dataConfigParam" to true. > Mitigations: > * Upgrade to 8.2.0 or later, which is secure by default. > * or, edit solrconfig.xml to configure all DataImportHandler usages with an > "invariants" section listing the "dataConfig" parameter set to am empty > string. > * Ensure your network settings are configured so that only trusted traffic > communicates with Solr, especially to the DIH request handler. This is a > best practice to all of Solr. > Credits: > * Michael Stepankin > References: > * https://issues.apache.org/jira/browse/SOLR-13669 > * https://cwiki.apache.org/confluence/display/solr/SolrSecurity -- 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-12325) introduce uniqueBlockQuery(parent:true) aggregation for JSON Facet
[
https://issues.apache.org/jira/browse/SOLR-12325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039266#comment-17039266
]
Lucene/Solr QA commented on SOLR-12325:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
52s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
20s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 11s{color}
| {color:red} solr_core generated 1 new + 102 unchanged - 0 fixed = 103 total
(was 102) {color} |
| {color:green}+1{color} | {color:green} Release`audit (RAT) {color} |
{color:green} 2m 16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 11s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 79m 45s{color}
| {color:red} core in the patch failed. {#olor} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
52s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 88m 10s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.search.facet.TestJsonFacetsWithRandomIndex |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12325 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12993769/SOLR-12325_Random_test_for_uniqueBlockQuery%20%281%29.patch
|
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-170-generic #199-Ubuntu SMP
Thu Nov 14 01:45:04 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / ce2959f |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| javac |
https://builds.apache.org/job/PreCommit-SOLR-Build/684/artifact/out/diff-compile-javac-solr_core.txt
|
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/684/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/684/testReport/ |
| modules | C: solr/core solr/test-framework U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/684/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> introduce uniqueBlockQuery(parent:true) aggregation for JSON Facet
> --
>
> Key: SOLR-12325
> URL: https://issues.apache.org/jira/browse/SOLR-12325
> Project: Solr
> Issue Type: New Feature
> Components: Facet Module
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.5
>
> Attachments: SOLR-12325.patch, SOLR-12325.patch, SOLR-12325.patch,
> SOLR-12325.patch, SOLR-12325_Random_test_for_uniqueBlockQuery (1).patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> It might be faster twin for {{uniqueBlock(\_root_)}}. Please utilise buildin
> query parsing method, don't invent your own.
--
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-9219) Port ECJ-based linter to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039286#comment-17039286 ] ASF subversion and git services commented on LUCENE-9219: - Commit 2a88aa9d0f77044d9a69cadf97683cc478b49063 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2a88aa9 ] LUCENE-9219: Port ECJ-based linter to gradle Co-authored-by: Tomoko Uchida > Port ECJ-based linter to gradle > --- > > Key: LUCENE-9219 > URL: https://issues.apache.org/jira/browse/LUCENE-9219 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Priority: Major > Attachments: LUCENE-9219.patch, LUCENE-9219.patch > > -- 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-14267) complete solrconfig.xml removal
Christine Poerschke created SOLR-14267: -- Summary: complete solrconfig.xml removal Key: SOLR-14267 URL: https://issues.apache.org/jira/browse/SOLR-14267 Project: Solr Issue Type: Task Reporter: Christine Poerschke Assignee: Christine Poerschke * The code already warns about it being deprecated: ** [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.4.1/solr/core/src/java/org/apache/solr/core/SolrConfig.java#L217-L218] – and the element attributes are read but not used. * There are no apparent documentation references. * A number of test solrconfig.xml files still configure the value. -- 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-14267) complete solrconfig.xml removal
[ https://issues.apache.org/jira/browse/SOLR-14267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-14267: --- Attachment: SOLR-14267.patch > complete solrconfig.xml removal > --- > > Key: SOLR-14267 > URL: https://issues.apache.org/jira/browse/SOLR-14267 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-14267.patch > > > * The code already warns about it being deprecated: > ** > [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.4.1/solr/core/src/java/org/apache/solr/core/SolrConfig.java#L217-L218] > – and the element attributes are read but not used. > * There are no apparent documentation references. > * A number of test solrconfig.xml files still configure the value. -- 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-14267) complete solrconfig.xml removal
[ https://issues.apache.org/jira/browse/SOLR-14267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039299#comment-17039299 ] Christine Poerschke commented on SOLR-14267: Attached patch proposes to outright remove given that the element is unused and undocumented, and the warning has been there since 3.6.0 version: * [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/3.6.0/solr/core/src/java/org/apache/solr/core/SolrConfig.java#L168-L169] An alternative to outright removal would be to annotate as deprecated first and then remove from 9.0 release onwards. > complete solrconfig.xml removal > --- > > Key: SOLR-14267 > URL: https://issues.apache.org/jira/browse/SOLR-14267 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-14267.patch > > > * The code already warns about it being deprecated: > ** > [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.4.1/solr/core/src/java/org/apache/solr/core/SolrConfig.java#L217-L218] > – and the element attributes are read but not used. > * There are no apparent documentation references. > * A number of test solrconfig.xml files still configure the value. -- 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-14256) Remove HashDocSet
[
https://issues.apache.org/jira/browse/SOLR-14256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039303#comment-17039303
]
Christine Poerschke commented on SOLR-14256:
Curiosity led me to find unused {{}} remnants in {{solrconfig.xml}}
-- SOLR-14267 created for proposed removal.
> Remove HashDocSet
> -
>
> Key: SOLR-14256
> URL: https://issues.apache.org/jira/browse/SOLR-14256
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: David Smiley
>Priority: Major
>
> This particular DocSet is only used in places where we need to convert
> SortedIntDocSet in particular to a DocSet that is fast for random access.
> Once such a conversion happens, it's only used to test some docs for presence
> and it could be another interface. DocSet has kind of a large-ish API
> surface area to implement. Since we only need to test docs, we could use
> Bits interface (having only 2 methods) backed by an off-the-shelf primitive
> long hash set on our classpath. Perhaps a new method on DocSet: getBits() or
> DocSetUtil.getBits(DocSet).
> In addition to removing complexity unto itself, this improvement is required
> by SOLR-14185 because it wants to be able to produce a DocIdSetIterator slice
> directly from the DocSet but HashDocSet can't do that without sorting first.
--
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-9219) Port ECJ-based linter to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida resolved LUCENE-9219. --- Fix Version/s: master (9.0) Assignee: Tomoko Uchida Resolution: Fixed It was merged. [~dweiss] Many thanks for your kind help. > Port ECJ-based linter to gradle > --- > > Key: LUCENE-9219 > URL: https://issues.apache.org/jira/browse/LUCENE-9219 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: LUCENE-9219.patch, LUCENE-9219.patch > > -- 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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-9232:
Attachment: LUCENE-9232.patch
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9232.patch
>
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9234) Keep write support for old codecs?
Adrien Grand created LUCENE-9234:
Summary: Keep write support for old codecs?
Key: LUCENE-9234
URL: https://issues.apache.org/jira/browse/LUCENE-9234
Project: Lucene - Core
Issue Type: Wish
Reporter: Adrien Grand
Currenty we maintain read/write support for the latest codec in lucene/core,
and read-only support for codecs of previous versions (up to \{N-1\}.0}) in
lucene/backward-codecs. We often keep write support in test-framework for
testing purposes only.
This raises challenges for Elasticsearch with regard to rolling upgrades: we
have some users who index very large amounts of data on clusters that are quite
large, so that rolling upgrades take significant time. Meanwhile, several
indices may be created.
Allocating indices when the cluster has nodes of different versions requires
care as Lucene indices created on nodes with a newer version cannot be read by
the nodes running the older version. It is possible to force primary replicas
to be allocated on the older nodes, but this brings other problems like
availability, uneven disk usage across nodes, or moving a lot of data around.
If Lucene could write data using the minimum version that exists in the
cluster, this would avoid this problem as the written data could be read by any
node of the cluster. I understand this change would not come for free,
especially when it comes to testing as we'd need to make sure that older Lucene
versions can read indices created by this "compatibility mode".
I'd be curious to understand whether this is a problem for Solr too, if not how
this problem is being handled, and maybe whether there are other problems that
you have encountered that would also benefit from the ability to write data
with an older format.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039316#comment-17039316
]
Dawid Weiss commented on LUCENE-9232:
-
I didn't find a way to tell gradle to shut down the "current" daemon gracefully
(even if there seems to be internal API to do so there is no way to access it).
I attach a dumb patch that just passes "--no-daemon" if local gradle.properties
isn't available. Not too elegant but works for me.
I can't say what Eclipse does but IntelliJ uses Gradle's tooling APIs (so yes,
it forks its own internal daemon too). Memory consumption doesn't seem to be an
issue for folks behind gradle (there are discussions on the forum about it).
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9232.patch
>
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039319#comment-17039319
]
Robert Muir commented on LUCENE-9232:
-
+1 to the patch. this is a solid improvement. defaults will be generated
without leaking a daemon. user can disable daemon in the properties file if
they choose. all without running kill or wasting gigs of ram.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9232.patch
>
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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-9232) disable gradle daemon by default
[
https://issues.apache.org/jira/browse/LUCENE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039325#comment-17039325
]
Dawid Weiss commented on LUCENE-9232:
-
I'll tone down the idle shutdown timeout too; 3 hours is way too long. I'd say
if you don't do anything within 15 minutes then there is no harm in the daemon
closing and forking a new copy on subsequent invocation.
> disable gradle daemon by default
>
>
> Key: LUCENE-9232
> URL: https://issues.apache.org/jira/browse/LUCENE-9232
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-9232.patch
>
>
> We should disable the gradle daemon by default: the user can opt-in by
> changing the properties file.
> If you forget to do this, you end out with leaked JVMs everywhere. It won't
> just leak one daemon, it will leak multiple ones.
> I ran {{ps}} on my laptop, surprised at 13:00 to find 2 leaked gradle jvms
> when I hadn't used the thing since 07:00.
--
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
