[jira] [Updated] (SOLR-14102) FacetModule use number of responses from shards as number of shards
[ https://issues.apache.org/jira/browse/SOLR-14102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomohiro Manabe updated SOLR-14102: --- Attachment: SOLR-14102.patch Status: Open (was: Open) I have attached a tiny patch. > FacetModule use number of responses from shards as number of shards > --- > > Key: SOLR-14102 > URL: https://issues.apache.org/jira/browse/SOLR-14102 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomohiro Manabe >Priority: Major > Attachments: SOLR-14102.patch > > > Hi, I am developing a SearchComponent which sends some requests to only a > part of shards. > Basically it works well, but using it with facetting triggers an error. > I found that FacetModule use the number of responses from shards > (sreq.responses.size()) as the number of shards. > Of course this assumption is incorrect in case that only a part of shards > respond. > Instead of the number of responses, using rb.shards.length may be better. -- 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-14152) Upgrade Derby dependency in DIH
Jan Høydahl created SOLR-14152: -- Summary: Upgrade Derby dependency in DIH Key: SOLR-14152 URL: https://issues.apache.org/jira/browse/SOLR-14152 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: contrib - DataImportHandler Reporter: Jan Høydahl Upgrade Derby to 10.15.1.3 (used in DIH example) -- 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-14151) Make schema components load from packages
Noble Paul created SOLR-14151: - Summary: Make schema components load from packages Key: SOLR-14151 URL: https://issues.apache.org/jira/browse/SOLR-14151 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1121: SOLR-11207: Add OWASP dependency checker to gradle build
janhoy opened a new pull request #1121: SOLR-11207: Add OWASP dependency checker to gradle build URL: https://github.com/apache/lucene-solr/pull/1121 PR against gradle-master branch to add owasp dependency checker plugin. See https://issues.apache.org/jira/browse/SOLR-11207 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] noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo
noblepaul commented on a change in pull request #1109: More pervasive use of
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361234358
##
File path: solr/core/src/java/org/apache/solr/core/PluginBag.java
##
@@ -140,11 +139,10 @@ public static void initInstance(Object inst, PluginInfo
info) {
log.debug("{} : '{}' created with startup=lazy ", meta.getCleanTag(),
info.name);
return new LazyPluginHolder(meta, info, core,
core.getResourceLoader(), false);
} else {
- if (info.pkgName != null) {
-PackagePluginHolder holder = new PackagePluginHolder<>(info, core,
meta);
-return holder;
+ if (core.getResourceLoader().getPackage(info.pkgName) != null) {
Review comment:
The idea of `SRL` trying to resolve the correct package is wrong. Let's not
do this. SRL has no idea what version of a package should be used to load a
plugin. Only a `SolrCore` does
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] noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo
noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361234213 ## File path: solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java ## @@ -954,4 +987,46 @@ public static void persistConfLocally(SolrResourceLoader loader, String resource } } + // TODO document these methods... Review comment: SRL has nothing to do with packages. It's an anti pattern. SRL is used by PackageLaoder and SRL is totally agnostic of the package system. We should just limit exposure of Packages to 2 places - `CoreContainer` : This is where the package loader is stored - `SolrCore` : This is where the correct version of a package for a plugin can be identified and listeners for package updates are registered Without the correct version, we leave the system inconsistent 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] noblepaul commented on issue #1109: More pervasive use of PackageLoader / PluginInfo
noblepaul commented on issue #1109: More pervasive use of PackageLoader / PluginInfo URL: https://github.com/apache/lucene-solr/pull/1109#issuecomment-568812967 Technically, Hot-reloading means reloading an object without restarting the JVM. So, it's OK to reload an object by reloading a core. The problem with this PR is that it leaves the system in an inconsistent state. Consider the following scenario - `ComponentX` uses `PackageA` `1.0` - User updates `PackageA` to `2.0` - A core that got started after the package update uses `2.0` & all other cores use `1.0` We really cannot leave the system in an inconsistent state and say we will deal with the inconsistencies in another ticket. What is the solution? There are 2 ways to use packages. 1. Ensure that the plugin has true hot reloading. As it is done for the plugins we support today 2. Or, we identify a list of plugins that do not need to be `hot-reloaded`. If a package is updated and such a plugin is using that package, we just reload the core Wherever possible we strive to implement option#1 because reloading cores can cause instability in the system & we try to minimize it as much as possible. If option#1 is not possible we MUST implement option#2. 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-14137) Boosting by date (and perhaps others) shows a steady decline 6.6->8.3
[
https://issues.apache.org/jira/browse/SOLR-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003019#comment-17003019
]
Erick Erickson commented on SOLR-14137:
---
Don't ask me why I missed pdate on 6x, but the results are consistent with the
other versions: the difference between pdate and tdate is minimal for all
versions and constantly degrades the more recent the version.
> Boosting by date (and perhaps others) shows a steady decline 6.6->8.3
> -
>
> Key: SOLR-14137
> URL: https://issues.apache.org/jira/browse/SOLR-14137
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Priority: Major
> Attachments: Screen Shot 2019-12-19 at 2.35.41 PM.png, Screen Shot
> 2019-12-19 at 3.09.37 PM.png, Screen Shot 2019-12-19 at 3.31.16 PM.png
>
>
> Moving a user's list discussion over here.
> {color:#00}The very short form is that from Solr 6.6.1 to Solr 8.3.1, the
> throughput for date boosting in my tests dropped by 40+%{color}
> {color:#00}I’ve been hearing about slowdowns in successive Solr releases
> with boost functions, so I dug into it a bit. The test setup is just a
> boost-by-date with an additional big OR clause of 100 random words so I’d be
> sure to hit a bunch of docs. I figured that if there were few hits, the
> signal would be lost in the noise, but I didn’t look at the actual hit
> counts.{color}
> {color:#00}I saw several Solr JIRAs about this subject, but they were
> slightly different, although quite possibly the same underlying issue. So I
> tried to get this down to a very specific form of a query.{color}
> {color:#00}I’ve also seen some cases in the wild where the response was
> proportional to the number of segments, thus my optimize experiments.{color}
> {color:#00}Here are the results, explanation below. O stands for
> optimized to one segment. I spot checked pdate against 6.6, 7.1 and 8.3 and
> they weren’t significantly different performance wise from tdate. All have
> docValues enabled. I ran these against a multiValued=“false” field. All the
> tests pegged all my CPUs. Jmeter is being run on a different machine than
> Solr. Only one Solr was running for any test.{color}
> {color:#00}Solr version queries/min {color}
> {color:#00}6.6.1 3,400 {color}
> {color:#00}6.6.1 O 4,800 {color}
> {color:#00}7.1 2,800 {color}
> {color:#00}7.1 O 4,200 {color}
> {color:#00}7.7.1 2,400 {color}
> {color:#00}7.7.1 O 3,500 {color}
> {color:#00}8.3.1 2,000 {color}
> {color:#00}8.3.1 O 2,600 {color}
> {color:#00}The tests I’ve been running just index 20M docs into a single
> core, then run the exact same 10,000 queries against them from jmeter with 24
> threads. Spot checks showed no hits on the queryResultCache.{color}
> {color:#00}A query looks like this: {color}
> {color:#00}rows=0&\{!boost b=recip(ms(NOW,
> INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR
> anyplace…97 more random words){color}
> {color:#00}There is no faceting. No grouping. No sorting.{color}
> {color:#00}I fill in INSERT_FIELD_HERE through jmeter magic. I’m running
> the exact same queries for every test.{color}
> {color:#00}One wildcard is that I did regenerate the index for each major
> revision, and the chose random words from the same list of words, as well as
> random times (bounded in the same range though) so the docs are not
> completely identical. The index was in the native format for that major
> version even if slightly different between versions. I ran the test once,
> then ran it again after optimizing the index.{color}
> {color:#00}I haven’t dug any farther, if anyone’s interested I can throw
> a profiler at, say, 8.3 and see what I can see, although I’m not going to
> have time to dive into this any time soon. I’d be glad to run some tests
> though. I saved the queries and the indexes so running a test would only
> take a few minutes.{color}
> {color:#00}While I concentrated on date fields, the docs have date, int,
> and long fields, both docValues=true and docValues=false, each variant with
> multiValued=true and multiValued=false and both Trie and Point (where
> possible) variants as well as a pretty simple text field.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14137) Boosting by date (and perhaps others) shows a steady decline 6.6->8.3
[
https://issues.apache.org/jira/browse/SOLR-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-14137:
--
Description:
Moving a user's list discussion over here.
{color:#00}The very short form is that from Solr 6.6.1 to Solr 8.3.1, the
throughput for date boosting in my tests dropped by 40+%{color}
{color:#00}I’ve been hearing about slowdowns in successive Solr releases
with boost functions, so I dug into it a bit. The test setup is just a
boost-by-date with an additional big OR clause of 100 random words so I’d be
sure to hit a bunch of docs. I figured that if there were few hits, the signal
would be lost in the noise, but I didn’t look at the actual hit counts.{color}
{color:#00}I saw several Solr JIRAs about this subject, but they were
slightly different, although quite possibly the same underlying issue. So I
tried to get this down to a very specific form of a query.{color}
{color:#00}I’ve also seen some cases in the wild where the response was
proportional to the number of segments, thus my optimize experiments.{color}
{color:#00}Here are the results, explanation below. O stands for optimized
to one segment. I spot checked pdate against 6.6, 7.1 and 8.3 and they weren’t
significantly different performance wise from tdate. All have docValues
enabled. I ran these against a multiValued=“false” field. All the tests pegged
all my CPUs. Jmeter is being run on a different machine than Solr. Only one
Solr was running for any test.{color}
{color:#00}Solr version queries/min {color}
{color:#00}6.6.1 3,400 {color}
{color:#00}6.6.1 O 4,800 {color}
{color:#00}7.1 2,800 {color}
{color:#00}7.1 O 4,200 {color}
{color:#00}7.7.1 2,400 {color}
{color:#00}7.7.1 O 3,500 {color}
{color:#00}8.3.1 2,000 {color}
{color:#00}8.3.1 O 2,600 {color}
{color:#00}The tests I’ve been running just index 20M docs into a single
core, then run the exact same 10,000 queries against them from jmeter with 24
threads. Spot checks showed no hits on the queryResultCache.{color}
{color:#00}A query looks like this: {color}
{color:#00}rows=0&\{!boost b=recip(ms(NOW,
INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR
anyplace…97 more random words){color}
{color:#00}There is no faceting. No grouping. No sorting.{color}
{color:#00}I fill in INSERT_FIELD_HERE through jmeter magic. I’m running
the exact same queries for every test.{color}
{color:#00}One wildcard is that I did regenerate the index for each major
revision, and the chose random words from the same list of words, as well as
random times (bounded in the same range though) so the docs are not completely
identical. The index was in the native format for that major version even if
slightly different between versions. I ran the test once, then ran it again
after optimizing the index.{color}
{color:#00}I haven’t dug any farther, if anyone’s interested I can throw a
profiler at, say, 8.3 and see what I can see, although I’m not going to have
time to dive into this any time soon. I’d be glad to run some tests though. I
saved the queries and the indexes so running a test would only take a few
minutes.{color}
{color:#00}While I concentrated on date fields, the docs have date, int,
and long fields, both docValues=true and docValues=false, each variant with
multiValued=true and multiValued=false and both Trie and Point (where possible)
variants as well as a pretty simple text field.{color}
was:
Moving a user's list discussion over here.
{color:#00}The very short form is that from Solr 6.6.1 to Solr 8.3.1, the
throughput for date boosting in my tests dropped by 40+%{color}
{color:#00}I’ve been hearing about slowdowns in successive Solr releases
with boost functions, so I dug into it a bit. The test setup is just a
boost-by-date with an additional big OR clause of 100 random words so I’d be
sure to hit a bunch of docs. I figured that if there were few hits, the signal
would be lost in the noise, but I didn’t look at the actual hit counts.{color}
{color:#00}I saw several Solr JIRAs about this subject, but they were
slightly different, although quite possibly the same underlying issue. So I
tried to get this down to a very specific form of a query.{color}
{color:#00}I’ve also seen some cases in the wild where the response was
proportional to the number of segments, thus my optimize experiments.{color}
{color:#00}Here are the results, explanation below. O stands for optimized
to one segment. I spot checked pdate against 7x and 8x and they weren’t
significantly different performance wise from tdate. All have docValues
enabled. I ran these
[jira] [Commented] (SOLR-11207) Add OWASP dependency checker to detect security vulnerabilities in third party libraries
[ https://issues.apache.org/jira/browse/SOLR-11207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003017#comment-17003017 ] Jan Høydahl commented on SOLR-11207: I just tested the gradle owasp dependencycheck plugin and I propose we add it to the maven build and forget about ant for now. Also, we can just leave it as a manual run for now, and then once we've excluded false positives we could add it to some check task and Jenkins. > Add OWASP dependency checker to detect security vulnerabilities in third > party libraries > > > Key: SOLR-11207 > URL: https://issues.apache.org/jira/browse/SOLR-11207 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 6.0 >Reporter: Hrishikesh Gadre >Assignee: Jan Høydahl >Priority: Major > > Lucene/Solr project depends on number of third party libraries. Some of those > libraries contain security vulnerabilities. Upgrading to versions of those > libraries that have fixes for those vulnerabilities is a simple, critical > step we can take to improve the security of the system. But for that we need > a tool which can scan the Lucene/Solr dependencies and look up the security > database for known vulnerabilities. > I found that [OWASP > dependency-checker|https://jeremylong.github.io/DependencyCheck/dependency-check-ant/] > can be used for this purpose. It provides a ant task which we can include in > the Lucene/Solr build. We also need to figure out how (and when) to invoke > this dependency-checker. But this can be figured out once we complete the > first step of integrating this tool with the Lucene/Solr build system. -- 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] noblepaul commented on a change in pull request #1109: More pervasive use of PackageLoader / PluginInfo
noblepaul commented on a change in pull request #1109: More pervasive use of
PackageLoader / PluginInfo
URL: https://github.com/apache/lucene-solr/pull/1109#discussion_r361233110
##
File path: solr/core/src/java/org/apache/solr/core/DirectoryFactory.java
##
@@ -420,7 +420,7 @@ static DirectoryFactory loadDirectoryFactory(SolrConfig
config, CoreContainer cc
final DirectoryFactory dirFactory;
if (info != null) {
log.debug(info.className);
- dirFactory = config.getResourceLoader().newInstance(info.className,
DirectoryFactory.class);
+ dirFactory = config.getResourceLoader().newInstance(info,
DirectoryFactory.class);
Review comment:
It's possible that we can share instances of SolrConfig between cores. We
should always use SRL from core
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-11207) Add OWASP dependency checker to detect security vulnerabilities in third party libraries
[ https://issues.apache.org/jira/browse/SOLR-11207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-11207: -- Assignee: Jan Høydahl > Add OWASP dependency checker to detect security vulnerabilities in third > party libraries > > > Key: SOLR-11207 > URL: https://issues.apache.org/jira/browse/SOLR-11207 > Project: Solr > Issue Type: Improvement > Components: Build >Affects Versions: 6.0 >Reporter: Hrishikesh Gadre >Assignee: Jan Høydahl >Priority: Major > > Lucene/Solr project depends on number of third party libraries. Some of those > libraries contain security vulnerabilities. Upgrading to versions of those > libraries that have fixes for those vulnerabilities is a simple, critical > step we can take to improve the security of the system. But for that we need > a tool which can scan the Lucene/Solr dependencies and look up the security > database for known vulnerabilities. > I found that [OWASP > dependency-checker|https://jeremylong.github.io/DependencyCheck/dependency-check-ant/] > can be used for this purpose. It provides a ant task which we can include in > the Lucene/Solr build. We also need to figure out how (and when) to invoke > this dependency-checker. But this can be figured out once we complete the > first step of integrating this tool with the Lucene/Solr build system. -- 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-14150) admin/luke doesn't show indexed fields correctly
Erick Erickson created SOLR-14150: - Summary: admin/luke doesn't show indexed fields correctly Key: SOLR-14150 URL: https://issues.apache.org/jira/browse/SOLR-14150 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI, Schema and Analysis Reporter: Erick Erickson Attachments: Screen Shot 2019-12-24 at 5.37.30 PM.png See screenshot. I'm absolutely sure that the schema used had docValues defined when the index was created. Additionally, the "tokenized" flag in the "index" part of the display shows numeric fields as tokenized. This is understandable for points-based fields, we don't support them at all (see: SOLR-12884), but Trie-based fields show this as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-14146. Resolution: Fixed > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1118: Change 72h voting rules for release wizard
janhoy merged pull request #1118: Change 72h voting rules for release wizard URL: https://github.com/apache/lucene-solr/pull/1118 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003003#comment-17003003 ] Jan Høydahl commented on SOLR-14146: [~ctargett] This is merged to 8_4 for ref-guide. [~jpountz] the only change here is ref-guide. [~dsmiley] let's improve the solr-system-requirements page in separate issues / commits > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003002#comment-17003002 ] ASF subversion and git services commented on SOLR-14146: Commit 4d495960575e65d922cdd30d14dd9c2b2bcec148 in lucene-solr's branch refs/heads/branch_8_4 from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4d49596 ] SOLR-14146: Zookeeper version not resolved in RefGuide (#1119) (cherry picked from commit aa43f352d9103b51c0cf33fd41bf16192810627f) > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003001#comment-17003001 ] ASF subversion and git services commented on SOLR-14146: Commit 6722b94d52efeba4dbc1285a89fb7d373e712f58 in lucene-solr's branch refs/heads/branch_8x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6722b94 ] SOLR-14146: Zookeeper version not resolved in RefGuide (#1119) (cherry picked from commit aa43f352d9103b51c0cf33fd41bf16192810627f) > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003000#comment-17003000 ] ASF subversion and git services commented on SOLR-14146: Commit aa43f352d9103b51c0cf33fd41bf16192810627f in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aa43f35 ] SOLR-14146: Zookeeper version not resolved in RefGuide (#1119) > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14146: --- Fix Version/s: (was: 8.5) 8.4 > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1119: SOLR-14146: Zookeeper version not resolved in RefGuide
janhoy merged pull request #1119: SOLR-14146: Zookeeper version not resolved in RefGuide URL: https://github.com/apache/lucene-solr/pull/1119 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] dweiss commented on issue #1114: LUCENE-9109: Use stack walker to implement TestSecurityManager's detection of test JVM exit
dweiss commented on issue #1114: LUCENE-9109: Use stack walker to implement TestSecurityManager's detection of test JVM exit URL: https://github.com/apache/lucene-solr/pull/1114#issuecomment-568802441 LGTM! 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-14120) Solr Admin UI breaks when using IE 11
[ https://issues.apache.org/jira/browse/SOLR-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14120: --- Fix Version/s: 8.5 Resolution: Fixed Status: Resolved (was: Patch Available) Thanks [~jafurrer]. I tested inside my VM, It is really completely broken without this patch if you use this browser. > Solr Admin UI breaks when using IE 11 > - > > Key: SOLR-14120 > URL: https://issues.apache.org/jira/browse/SOLR-14120 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: master (9.0), 8.3.1 > Environment: Operation System: Microsoft Windows 10 Enterprise > (German) > Version: 10.0.17763 Build 17763 > Browser: Internet Explorer 11 > Version: 11.864.17763 > Update: 11.0.160 >Reporter: Jakob Furrer >Assignee: Robert Muir >Priority: Minor > Fix For: 8.5 > > Attachments: SOLR-14120.patch, SOLR-14120.patch, SOLR-14120.patch, > Solr-8.3.1_ IE11_AdminUI_Error.png > > > A customer of mine is restricted to use no other browser than Internet > Explorer to access the Solr Administration User Interface. > He reported that the website does not display any content in the main area > when any button of the menu on the left hand side is clicked. > I can replicate that behavior on my machine. > Symptoms > - > When the Admin UI is loaded, the menu on the left hand side is visible but no > content is ever displayed in the main area. > Any menu item (e.g. "Dashboard", "logging", "Java Properties" etc.) can be > clicked but no content appears. > An error with a stacktrace is shown in the JavaScript console. > History > - > I can confirm, that some month ago the Admin UI worked well under IE. > However, I have not researched with what update of IE the problems exactly > started. > Analysis > - > The displayed stacktrace indicates that Internet Explorer does not support > the method "startsWith" (and subsequently, the same is true for the method > "includes"). > This behavior is documented: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#Browser_compatibility -- 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-14120) Solr Admin UI breaks when using IE 11
[ https://issues.apache.org/jira/browse/SOLR-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002972#comment-17002972 ] ASF subversion and git services commented on SOLR-14120: Commit 359d82348e84348fa5fe4305b0f56c4ca387837e in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=359d823 ] SOLR-14120: Solr Admin UI breaks when using IE11 > Solr Admin UI breaks when using IE 11 > - > > Key: SOLR-14120 > URL: https://issues.apache.org/jira/browse/SOLR-14120 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: master (9.0), 8.3.1 > Environment: Operation System: Microsoft Windows 10 Enterprise > (German) > Version: 10.0.17763 Build 17763 > Browser: Internet Explorer 11 > Version: 11.864.17763 > Update: 11.0.160 >Reporter: Jakob Furrer >Assignee: Robert Muir >Priority: Minor > Attachments: SOLR-14120.patch, SOLR-14120.patch, SOLR-14120.patch, > Solr-8.3.1_ IE11_AdminUI_Error.png > > > A customer of mine is restricted to use no other browser than Internet > Explorer to access the Solr Administration User Interface. > He reported that the website does not display any content in the main area > when any button of the menu on the left hand side is clicked. > I can replicate that behavior on my machine. > Symptoms > - > When the Admin UI is loaded, the menu on the left hand side is visible but no > content is ever displayed in the main area. > Any menu item (e.g. "Dashboard", "logging", "Java Properties" etc.) can be > clicked but no content appears. > An error with a stacktrace is shown in the JavaScript console. > History > - > I can confirm, that some month ago the Admin UI worked well under IE. > However, I have not researched with what update of IE the problems exactly > started. > Analysis > - > The displayed stacktrace indicates that Internet Explorer does not support > the method "startsWith" (and subsequently, the same is true for the method > "includes"). > This behavior is documented: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#Browser_compatibility -- 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-14120) Solr Admin UI breaks when using IE 11
[ https://issues.apache.org/jira/browse/SOLR-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002971#comment-17002971 ] ASF subversion and git services commented on SOLR-14120: Commit 3ab59aa1c910d71239d3fbfed05dcb30aca616b5 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3ab59aa ] SOLR-14120: Solr Admin UI breaks when using IE11 > Solr Admin UI breaks when using IE 11 > - > > Key: SOLR-14120 > URL: https://issues.apache.org/jira/browse/SOLR-14120 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: master (9.0), 8.3.1 > Environment: Operation System: Microsoft Windows 10 Enterprise > (German) > Version: 10.0.17763 Build 17763 > Browser: Internet Explorer 11 > Version: 11.864.17763 > Update: 11.0.160 >Reporter: Jakob Furrer >Assignee: Robert Muir >Priority: Minor > Attachments: SOLR-14120.patch, SOLR-14120.patch, SOLR-14120.patch, > Solr-8.3.1_ IE11_AdminUI_Error.png > > > A customer of mine is restricted to use no other browser than Internet > Explorer to access the Solr Administration User Interface. > He reported that the website does not display any content in the main area > when any button of the menu on the left hand side is clicked. > I can replicate that behavior on my machine. > Symptoms > - > When the Admin UI is loaded, the menu on the left hand side is visible but no > content is ever displayed in the main area. > Any menu item (e.g. "Dashboard", "logging", "Java Properties" etc.) can be > clicked but no content appears. > An error with a stacktrace is shown in the JavaScript console. > History > - > I can confirm, that some month ago the Admin UI worked well under IE. > However, I have not researched with what update of IE the problems exactly > started. > Analysis > - > The displayed stacktrace indicates that Internet Explorer does not support > the method "startsWith" (and subsequently, the same is true for the method > "includes"). > This behavior is documented: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#Browser_compatibility -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14120) Solr Admin UI breaks when using IE 11
[ https://issues.apache.org/jira/browse/SOLR-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned SOLR-14120: -- Assignee: Robert Muir > Solr Admin UI breaks when using IE 11 > - > > Key: SOLR-14120 > URL: https://issues.apache.org/jira/browse/SOLR-14120 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: master (9.0), 8.3.1 > Environment: Operation System: Microsoft Windows 10 Enterprise > (German) > Version: 10.0.17763 Build 17763 > Browser: Internet Explorer 11 > Version: 11.864.17763 > Update: 11.0.160 >Reporter: Jakob Furrer >Assignee: Robert Muir >Priority: Minor > Attachments: SOLR-14120.patch, SOLR-14120.patch, SOLR-14120.patch, > Solr-8.3.1_ IE11_AdminUI_Error.png > > > A customer of mine is restricted to use no other browser than Internet > Explorer to access the Solr Administration User Interface. > He reported that the website does not display any content in the main area > when any button of the menu on the left hand side is clicked. > I can replicate that behavior on my machine. > Symptoms > - > When the Admin UI is loaded, the menu on the left hand side is visible but no > content is ever displayed in the main area. > Any menu item (e.g. "Dashboard", "logging", "Java Properties" etc.) can be > clicked but no content appears. > An error with a stacktrace is shown in the JavaScript console. > History > - > I can confirm, that some month ago the Admin UI worked well under IE. > However, I have not researched with what update of IE the problems exactly > started. > Analysis > - > The displayed stacktrace indicates that Internet Explorer does not support > the method "startsWith" (and subsequently, the same is true for the method > "includes"). > This behavior is documented: > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes#Browser_compatibility > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#Browser_compatibility -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002965#comment-17002965 ] David Smiley commented on SOLR-14146: - Dunno if you want to increase the scope a little bit but you could add the version to solr-system-requirements.adoc page as well. > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14149) Remove non-changes from CHANGES.txt
[ https://issues.apache.org/jira/browse/SOLR-14149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002964#comment-17002964 ] David Smiley commented on SOLR-14149: - bq. Maybe give a hint where to look for the "important" jar files The layout of the distribution is documented in solr/README.txt – feel free to make minor changes as you propose directly. > Remove non-changes from CHANGES.txt > --- > > Key: SOLR-14149 > URL: https://issues.apache.org/jira/browse/SOLR-14149 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > Our CHANGES.txt should just list our changes / release notes. Nothing else. > * no Introduction > * no "Getting Started" > * no "Versions of Major Components" with each release. > We have a website, a reference guide, and a README.md that are all more > suitable places. Lets not maintain it here as well; lets keep this file > focused on it's namesake. We can/should *link* to that information from > CHANGES.txt. For example linking to > https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html is highly > appropriate as it's a more user friendly editorialized version of CHANGES.txt. -- 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-13890) Add postfilter support to {!terms} queries
[
https://issues.apache.org/jira/browse/SOLR-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002960#comment-17002960
]
David Smiley commented on SOLR-13890:
-
bq. The TPI "approximation" for DocValuesTermsQuery is the unfiltered
doc-values structure for the field. As a result TPI matches() is going to be
called on all documents that have any value at all for the field in question.
Under a post-filter implementation, the bitset lookup is (potentially) called
much less frequently, as we only lookup values for docs that have matched all
the other (non-postfilter) query clauses. Does that make sense, or am I
off-base David Smiley?
I don't think this characterization is accurate. If other lower cost queries
are in play then TPI matches() won't be called if the document can be excluded
by them.
bq. So, the postfilters behavior (not cached in filter cache) provides the best
solution for certain situations where the filter cache is problematic.
We can make an estimation that it's best to not cache; the Query could
implement ExtendedQuery to return a default getCache() of false sometimes.
Perhaps always default to false... maybe all O(docs) queries should default
this way. Perhaps a better heuristic, is how long the IndexSearcher has been
open for. Regardless the user can & should retain the ability to be explicit
if he/she chooses.
> Add postfilter support to {!terms} queries
> --
>
> Key: SOLR-13890
> URL: https://issues.apache.org/jira/browse/SOLR-13890
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: master (9.0)
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-13890.patch, SOLR-13890.patch, SOLR-13890.patch
>
>
> There are some use-cases where it'd be nice if the "terms" qparser created a
> query that could be run as a postfilter. Particularly, when users are
> checking for hundreds or thousands of terms, a postfilter implementation can
> be more performant than the standard processing.
> WIth this issue, I'd like to propose a post-filter implementation for the
> {{docValuesTermsFilter}} "method". Postfilter creation can use a
> SortedSetDocValues object to populate a DV bitset with the "terms" being
> checked for. Each document run through the post-filter can look at their
> doc-values for the field in question and check them efficiently against the
> constructed bitset.
--
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-14149) Remove non-changes from CHANGES.txt
[ https://issues.apache.org/jira/browse/SOLR-14149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002959#comment-17002959 ] Erick Erickson commented on SOLR-14149: --- Suggest a few of things: 1> link to the generic ref guide, people can chose the right version: [https://lucene.apache.org/solr/guide/.|https://lucene.apache.org/solr/guide/] It's one less thing that could get out of sync. 2> take out the JVM requirement too. 3> Put the JVM and Zookeeper requirements in solr-system-requirements.adoc. Zookeeper only because we expect users to download/install separately. 4> Maybe give a hint where to look for the "important" jar files, although that's somewhat confusing. Perhaps that belongs in some developer's guide: dist dist/solrj-libs server/solr-webapp/webapp/WEB-INF/lib server/lib > Remove non-changes from CHANGES.txt > --- > > Key: SOLR-14149 > URL: https://issues.apache.org/jira/browse/SOLR-14149 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > Our CHANGES.txt should just list our changes / release notes. Nothing else. > * no Introduction > * no "Getting Started" > * no "Versions of Major Components" with each release. > We have a website, a reference guide, and a README.md that are all more > suitable places. Lets not maintain it here as well; lets keep this file > focused on it's namesake. We can/should *link* to that information from > CHANGES.txt. For example linking to > https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html is highly > appropriate as it's a more user friendly editorialized version of CHANGES.txt. -- 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-14149) Remove non-changes from CHANGES.txt
David Smiley created SOLR-14149: --- Summary: Remove non-changes from CHANGES.txt Key: SOLR-14149 URL: https://issues.apache.org/jira/browse/SOLR-14149 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: David Smiley Assignee: David Smiley Our CHANGES.txt should just list our changes / release notes. Nothing else. * no Introduction * no "Getting Started" * no "Versions of Major Components" with each release. We have a website, a reference guide, and a README.md that are all more suitable places. Lets not maintain it here as well; lets keep this file focused on it's namesake. We can/should *link* to that information from CHANGES.txt. For example linking to https://lucene.apache.org/solr/guide/8_4/solr-upgrade-notes.html is highly appropriate as it's a more user friendly editorialized version of CHANGES.txt. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002942#comment-17002942 ] David Smiley commented on SOLR-14146: - +1 > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > Time Spent: 20m > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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] ctargett commented on issue #1119: SOLR-14146: Zookeeper version not resolved in RefGuide
ctargett commented on issue #1119: SOLR-14146: Zookeeper version not resolved in RefGuide URL: https://github.com/apache/lucene-solr/pull/1119#issuecomment-568779495 +1 - I didn't test it, but looked up how it broke (SOLR-8346) and your change makes sense. If you backport to `branch_8_4` also, it will be fixed in the final release of the 8.4 Ref Guide too. 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] uschindler edited a comment on issue #1120: LUCENE-9110: Switch tests to use StackWalker
uschindler edited a comment on issue #1120: LUCENE-9110: Switch tests to use StackWalker URL: https://github.com/apache/lucene-solr/pull/1120#issuecomment-568774365 @rmuir: I was thinking about the same. Maybe at a later stage. The risk is that this old legacy code breaks in future (with Graal), as the stack trace of Exceptions or Thread may be corrumpted if optimizer jumps in. To get the "real" stack trace, you should use StackWalker. 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] uschindler commented on issue #1120: LUCENE-9110: Switch tests to use StackWalker
uschindler commented on issue #1120: LUCENE-9110: Switch tests to use StackWalker URL: https://github.com/apache/lucene-solr/pull/1120#issuecomment-568774365 @rmuir: I was thinking about the same. Maybe at a later stage. The risk is that this code breaks in future (with Graal), as the stack trace of Exceptions or Thread may be corrumpted if optimizer jumps in. To get the "real" stack trace, you should use StackWalker. 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] rmuir commented on issue #1120: LUCENE-9110: Switch tests to use StackWalker
rmuir commented on issue #1120: LUCENE-9110: Switch tests to use StackWalker URL: https://github.com/apache/lucene-solr/pull/1120#issuecomment-568774024 Should we introduce some forbidden APIs here? At least for test code? I am thinking something like Thread#getStackTrace / Throwable#getStackTrace? If i do `git grep getStackTrace` it seems nearly all usages are tests doing this kind of thing. 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-9110) Use StackWalker in tests instead of iterating through StackTraceElement arrays
[ https://issues.apache.org/jira/browse/LUCENE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9110: -- Description: Followup of LUCENE-9109: There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack). There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception. For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. One important thing is: Using StackWalker makes sure that the stack is "correct". Stacks from Thread or Exception may miss some frames, as it does not deoptimize the code. So depending on JVMs and optimizations (e.g. Graal), call stacks may change if we still use old code for analysis. This is no longer an issue for Java 8, but may be in future. was: Followup of LUCENE-9109: There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack). There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception. For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. > Use StackWalker in tests instead of iterating through StackTraceElement arrays > -- > > Key: LUCENE-9110 > URL: https://issues.apache.org/jira/browse/LUCENE-9110 > Project: Lucene - Core > Issue Type: Improvement > Components: general/test >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0), 8.5 > > Time Spent: 10m > Remaining Estimate: 0h > > Followup of LUCENE-9109: > There are a lot of tests (especially around IndexWriter) that look into stack > traces to inject failures or check that some methods were called in their > call stack. > This issue will refactor all those tests by adding a few methods to > LuceneTestCase that make it easy to verify if some method call/class is in > stack trace. On master (Java 11) we can use StackWalker to do this checks, > which has a speedup of sometimes >>2 times (depending on how deep you dive > into call stack). > There are a few tests (only 3) that do more complex stack trace analysis. > Those should be refactored at some point. For now I added a deprecated method > to get the whole StackTrace in Java 11, which is still 2 times faster than > using an Exception. > For branch 8.x i will apply the same patch, just the LuceneTestCase methods > use the old "Java 8" way to inspect stack trace using the thread's stack > trace (which is very expensive). > So this issue is mainly about refactoring the tests to use a common method > pattern to check the existence of stack frames. > One important thing is: Using StackWalker makes sure that the stack is > "correct". Stacks from Thread or Exception may miss some frames, as it does > not deoptimize the code. So depending on JVMs and optimizations (e.g. Graal), > call stacks may change if we still use old code for analysis. This is no > longer an issue for Java 8, but may be in future. -- 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:
[GitHub] [lucene-solr] uschindler opened a new pull request #1120: LUCENE-9110: Switch tests to use StackWalker
uschindler opened a new pull request #1120: LUCENE-9110: Switch tests to use StackWalker URL: https://github.com/apache/lucene-solr/pull/1120 There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack). There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception. For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. 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-9110) Use StackWalker in tests instead of iterating through StackTraceElement arrays
[ https://issues.apache.org/jira/browse/LUCENE-9110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-9110: -- Description: Followup of LUCENE-9109: There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in their call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of sometimes >>2 times (depending on how deep you dive into call stack). There are a few tests (only 3) that do more complex stack trace analysis. Those should be refactored at some point. For now I added a deprecated method to get the whole StackTrace in Java 11, which is still 2 times faster than using an Exception. For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. was: Followup of LUCENE-9109: There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in ther call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of >2 times (depending on how you test it). For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. > Use StackWalker in tests instead of iterating through StackTraceElement arrays > -- > > Key: LUCENE-9110 > URL: https://issues.apache.org/jira/browse/LUCENE-9110 > Project: Lucene - Core > Issue Type: Improvement > Components: general/test >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0), 8.5 > > > Followup of LUCENE-9109: > There are a lot of tests (especially around IndexWriter) that look into stack > traces to inject failures or check that some methods were called in their > call stack. > This issue will refactor all those tests by adding a few methods to > LuceneTestCase that make it easy to verify if some method call/class is in > stack trace. On master (Java 11) we can use StackWalker to do this checks, > which has a speedup of sometimes >>2 times (depending on how deep you dive > into call stack). > There are a few tests (only 3) that do more complex stack trace analysis. > Those should be refactored at some point. For now I added a deprecated method > to get the whole StackTrace in Java 11, which is still 2 times faster than > using an Exception. > For branch 8.x i will apply the same patch, just the LuceneTestCase methods > use the old "Java 8" way to inspect stack trace using the thread's stack > trace (which is very expensive). > So this issue is mainly about refactoring the tests to use a common method > pattern to check the existence of stack frames. -- 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-14148) enable IP access control by default
Robert Muir created SOLR-14148:
--
Summary: enable IP access control by default
Key: SOLR-14148
URL: https://issues.apache.org/jira/browse/SOLR-14148
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Robert Muir
Currently network access is wide-open to the world and the user has to "secure"
it through steps on the securing solr page. Instead the user is asked to
explicitly "tune a firewall"... these are not good defaults.
It would be much better if access was restricted by default via ACL (e.g. to
{{127.0.0.0/8, [::1]}}), and the user instead explicitly grants access to
hosts/networks that should have it. Similar to PostgreSQL's {{pg_hba.conf}}.
Just like {{pg_hba.conf}}, this is separate from what interfaces are bound to
by default.
We could remove the IP-based ACL step from securing solr page, and even change
or remove the "firewall" wording at the top.
--
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-14144) add IP-based access control to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002907#comment-17002907 ] ASF subversion and git services commented on SOLR-14144: Commit 7feba46a6f2e8aefc1c513771128a07aa2624d8e in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7feba46 ] SOLR-14144: add IP-based access control to securing solr page > add IP-based access control to securing solr page > - > > Key: SOLR-14144 > URL: https://issues.apache.org/jira/browse/SOLR-14144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14144.patch > > > This is an easy way to improve security. See SOLR-14136 > By default, access is allowed to all addresses, but if someone specifies a > simple configuration to only allow local access and their own servers, such > as: > SOLR_IP_WHITELIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64" > , then with a simple one-liner, things are a lot better than being open to > everyone. Let's add something short and sweet to the ref guide security page. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14144) add IP-based access control to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-14144. Fix Version/s: 8.5 Assignee: Robert Muir Resolution: Fixed > add IP-based access control to securing solr page > - > > Key: SOLR-14144 > URL: https://issues.apache.org/jira/browse/SOLR-14144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14144.patch > > > This is an easy way to improve security. See SOLR-14136 > By default, access is allowed to all addresses, but if someone specifies a > simple configuration to only allow local access and their own servers, such > as: > SOLR_IP_WHITELIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64" > , then with a simple one-liner, things are a lot better than being open to > everyone. Let's add something short and sweet to the ref guide security page. -- 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-14144) add IP-based access control to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002906#comment-17002906 ] ASF subversion and git services commented on SOLR-14144: Commit b73e27d1ca20eebc2c5a2acd2d58bce0f64e8cb0 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b73e27d ] SOLR-14144: add IP-based access control to securing solr page > add IP-based access control to securing solr page > - > > Key: SOLR-14144 > URL: https://issues.apache.org/jira/browse/SOLR-14144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14144.patch > > > This is an easy way to improve security. See SOLR-14136 > By default, access is allowed to all addresses, but if someone specifies a > simple configuration to only allow local access and their own servers, such > as: > SOLR_IP_WHITELIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64" > , then with a simple one-liner, things are a lot better than being open to > everyone. Let's add something short and sweet to the ref guide security page. -- 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-9110) Use StackWalker in tests instead of iterating through StackTraceElement arrays
Uwe Schindler created LUCENE-9110: - Summary: Use StackWalker in tests instead of iterating through StackTraceElement arrays Key: LUCENE-9110 URL: https://issues.apache.org/jira/browse/LUCENE-9110 Project: Lucene - Core Issue Type: Improvement Components: general/test Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: master (9.0), 8.5 Followup of LUCENE-9109: There are a lot of tests (especially around IndexWriter) that look into stack traces to inject failures or check that some methods were called in ther call stack. This issue will refactor all those tests by adding a few methods to LuceneTestCase that make it easy to verify if some method call/class is in stack trace. On master (Java 11) we can use StackWalker to do this checks, which has a speedup of >2 times (depending on how you test it). For branch 8.x i will apply the same patch, just the LuceneTestCase methods use the old "Java 8" way to inspect stack trace using the thread's stack trace (which is very expensive). So this issue is mainly about refactoring the tests to use a common method pattern to check the existence of stack frames. -- 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-14144) add IP-based access control to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14144: --- Attachment: SOLR-14144.patch > add IP-based access control to securing solr page > - > > Key: SOLR-14144 > URL: https://issues.apache.org/jira/browse/SOLR-14144 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14144.patch > > > This is an easy way to improve security. See SOLR-14136 > By default, access is allowed to all addresses, but if someone specifies a > simple configuration to only allow local access and their own servers, such > as: > SOLR_IP_WHITELIST="127.0.0.1, [::1], 192.168.0.0/24, [2000:123:4:5::]/64" > , then with a simple one-liner, things are a lot better than being open to > everyone. Let's add something short and sweet to the ref guide security page. -- 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-14147) enable security manager by default
Robert Muir created SOLR-14147: -- Summary: enable security manager by default Key: SOLR-14147 URL: https://issues.apache.org/jira/browse/SOLR-14147 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Robert Muir Fix For: master (9.0) For 9.0, set SOLR_SECURITY_MANAGER_ENABLED=true by default. Remove the step from securing solr page as it will be done by default (defaults become safe). Users can disable if they are running hadoop or doing other crazy stuff. -- 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-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-14142: --- Attachment: SOLR-14142.patch > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14143) Add request-logging to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002879#comment-17002879 ] ASF subversion and git services commented on SOLR-14143: Commit 4cde252a8474eacaa294ca04518527a80da8f97b in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4cde252 ] SOLR-14143: add request logging to securing solr page > Add request-logging to securing solr page > - > > Key: SOLR-14143 > URL: https://issues.apache.org/jira/browse/SOLR-14143 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14143.patch > > > This functionality was cleaned up in SOLR-14138 and for a major release I've > proposed to turn it on by default in SOLR-14142. > But for now, I think the "securing solr" page should instruct how to turn > this on. Hopefully if we fix the default in SOLR-14142, this paragraph can > simply go away (I think it is expert to not want to log such a basic thing). > There is some overlap with "audit logging", but for sure the request log is > always more complete, since it logs things that never even make it to solr > (as well as 4xx denied by solr itself, of course). You can see the differenes > by running a simple nmap script scan of your solr instance or similar. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14143) Add request-logging to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-14143. Fix Version/s: 8.5 Assignee: Robert Muir Resolution: Fixed > Add request-logging to securing solr page > - > > Key: SOLR-14143 > URL: https://issues.apache.org/jira/browse/SOLR-14143 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Assignee: Robert Muir >Priority: Major > Fix For: 8.5 > > Attachments: SOLR-14143.patch > > > This functionality was cleaned up in SOLR-14138 and for a major release I've > proposed to turn it on by default in SOLR-14142. > But for now, I think the "securing solr" page should instruct how to turn > this on. Hopefully if we fix the default in SOLR-14142, this paragraph can > simply go away (I think it is expert to not want to log such a basic thing). > There is some overlap with "audit logging", but for sure the request log is > always more complete, since it logs things that never even make it to solr > (as well as 4xx denied by solr itself, of course). You can see the differenes > by running a simple nmap script scan of your solr instance or similar. -- 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-14143) Add request-logging to securing solr page
[ https://issues.apache.org/jira/browse/SOLR-14143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002877#comment-17002877 ] ASF subversion and git services commented on SOLR-14143: Commit b87e1f5843f163ab5d8a90c6b0dc0f95f6e932fc in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b87e1f5 ] SOLR-14143: add request logging to securing solr page > Add request-logging to securing solr page > - > > Key: SOLR-14143 > URL: https://issues.apache.org/jira/browse/SOLR-14143 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Robert Muir >Priority: Major > Attachments: SOLR-14143.patch > > > This functionality was cleaned up in SOLR-14138 and for a major release I've > proposed to turn it on by default in SOLR-14142. > But for now, I think the "securing solr" page should instruct how to turn > this on. Hopefully if we fix the default in SOLR-14142, this paragraph can > simply go away (I think it is expert to not want to log such a basic thing). > There is some overlap with "audit logging", but for sure the request log is > always more complete, since it logs things that never even make it to solr > (as well as 4xx denied by solr itself, of course). You can see the differenes > by running a simple nmap script scan of your solr instance or similar. -- 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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002871#comment-17002871
]
ASF subversion and git services commented on SOLR-13984:
Commit 30069e13f56b5f7836eb86cf8a69d2ff963a489e in lucene-solr's branch
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=30069e1 ]
SOLR-13984: docs, changes.txt
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002869#comment-17002869
]
ASF subversion and git services commented on SOLR-13984:
Commit efd13f2884d55d67d73dca771fa9a2a20ae3d6ee in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=efd13f2 ]
SOLR-13984: docs, changes.txt
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved SOLR-13984.
Fix Version/s: 8.5
Assignee: Robert Muir
Resolution: Fixed
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Robert Muir
>Priority: Major
> Fix For: 8.5
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002865#comment-17002865
]
ASF subversion and git services commented on SOLR-13984:
Commit 89d88de5c2998b3c1bb393113931cc686cfabc2b in lucene-solr's branch
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=89d88de ]
SOLR-13984: add (experimental, disabled by default) security manager support
(#1082)
* SOLR-13984: add (experimental, disabled by default) security manager support.
User can set SOLR_SECURITY_MANAGER_ENABLED=true to enable security manager at
runtime.
The current policy file used by tests is moved to solr/server
Additional permissions are granted for the filesystem locations set by
bin/solr, and networking everywhere is enabled.
This takes advantage of the fact that permission entries are ignored if
properties are not defined:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#PropertyExp
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002866#comment-17002866
]
ASF subversion and git services commented on SOLR-13984:
Commit 89d88de5c2998b3c1bb393113931cc686cfabc2b in lucene-solr's branch
refs/heads/branch_8x from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=89d88de ]
SOLR-13984: add (experimental, disabled by default) security manager support
(#1082)
* SOLR-13984: add (experimental, disabled by default) security manager support.
User can set SOLR_SECURITY_MANAGER_ENABLED=true to enable security manager at
runtime.
The current policy file used by tests is moved to solr/server
Additional permissions are granted for the filesystem locations set by
bin/solr, and networking everywhere is enabled.
This takes advantage of the fact that permission entries are ignored if
properties are not defined:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#PropertyExp
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002862#comment-17002862
]
ASF subversion and git services commented on SOLR-13984:
Commit 126d6b77679102db775a0b241501fe8ce0d8eb9d in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=126d6b7 ]
SOLR-13984: add (experimental, disabled by default) security manager support
(#1082)
* SOLR-13984: add (experimental, disabled by default) security manager support.
User can set SOLR_SECURITY_MANAGER_ENABLED=true to enable security manager at
runtime.
The current policy file used by tests is moved to solr/server
Additional permissions are granted for the filesystem locations set by
bin/solr, and networking everywhere is enabled.
This takes advantage of the fact that permission entries are ignored if
properties are not defined:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#PropertyExp
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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-13984) Solr should run inside a SecurityManager
[
https://issues.apache.org/jira/browse/SOLR-13984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002861#comment-17002861
]
ASF subversion and git services commented on SOLR-13984:
Commit 126d6b77679102db775a0b241501fe8ce0d8eb9d in lucene-solr's branch
refs/heads/master from Robert Muir
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=126d6b7 ]
SOLR-13984: add (experimental, disabled by default) security manager support
(#1082)
* SOLR-13984: add (experimental, disabled by default) security manager support.
User can set SOLR_SECURITY_MANAGER_ENABLED=true to enable security manager at
runtime.
The current policy file used by tests is moved to solr/server
Additional permissions are granted for the filesystem locations set by
bin/solr, and networking everywhere is enabled.
This takes advantage of the fact that permission entries are ignored if
properties are not defined:
https://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#PropertyExp
> Solr should run inside a SecurityManager
>
>
> Key: SOLR-13984
> URL: https://issues.apache.org/jira/browse/SOLR-13984
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> To reduce the effect of attacks, esp. RCE, Solr should run inside a
> SecurityManager.
> Quoting Uwe here:
> {quote}
> The correct way to fix all issues we have seen the last time is very simple:
> LET'S RUN SOLR INSIDE A SECURITY MANAGER IN PRODUCTION (like in tests).
> Elasticsearch is doing this, so please please let's do this instead. But this
> requires to finally get rid of the webapplication and start.jar and add our
> own bootstrapping (like in tests) that configure Jetty and Security Manager
> from our own org.apache.solr.bootstrap.Main.java (or similar).
> {quote}
> https://jira.apache.org/jira/browse/SOLR-12316?focusedCommentId=16465038=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16465038
--
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] rmuir merged pull request #1082: SOLR-13984: add (experimental, disabled by default) security manager support
rmuir merged pull request #1082: SOLR-13984: add (experimental, disabled by default) security manager support URL: https://github.com/apache/lucene-solr/pull/1082 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-14131) Add maxQueryLength option to DirectSolrSpellchecker
[ https://issues.apache.org/jira/browse/SOLR-14131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002852#comment-17002852 ] ASF subversion and git services commented on SOLR-14131: Commit 27840562a6f4419a1e8953789ada0f0d19551aa7 in lucene-solr's branch refs/heads/master from Bruno Roustant [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2784056 ] SOLR-14131: Add maxQueryLength option to DirectSolrSpellchecker. Closes #1113 > Add maxQueryLength option to DirectSolrSpellchecker > --- > > Key: SOLR-14131 > URL: https://issues.apache.org/jira/browse/SOLR-14131 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Reporter: Andy Webb >Assignee: Bruno Roustant >Priority: Minor > Time Spent: 3h 20m > Remaining Estimate: 0h > > Attempting to spellcheck some long query terms can trigger > org.apache.lucene.util.automaton.TooComplexToDeterminizeException. This > change (previously discussed in SOLR-13190, and dependent on LUCENE-9102) > adds a maxQueryLength option to DirectSolrSpellChecker so that Lucene/Solr > can be configured to not attempt to spellcheck terms over a specified length. > Here's a PR: https://github.com/apache/lucene-solr/pull/1113 -- 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] asfgit closed pull request #1113: SOLR-14131: adds maxQueryLength option
asfgit closed pull request #1113: SOLR-14131: adds maxQueryLength option URL: https://github.com/apache/lucene-solr/pull/1113 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-9107) CommonsTermsQuery with huge no. of terms slower with top-k scoring
[
https://issues.apache.org/jira/browse/LUCENE-9107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002848#comment-17002848
]
Adrien Grand commented on LUCENE-9107:
--
CommonTermsQuery probably makes the issue worse by having clauses on multiple
levels of boolean queries (see e.g. how the nested boolean queries perform
worse than single-level boolean queries in the nightly benchmarks
http://people.apache.org/~mikemccand/lucenebench/AndMedOrHighHigh.html), but
this is an issue with BooleanQuery too. We have complex logic that tries to
skip as many hits as possible, but when this logic is defeated, which is
typically the case when
- there are lots of clauses,
- or clauses have about the same max scores,
- or maximum score upper bounds are highly overestimated (ClassicSimilarity
might contribute a bit here too),
then we need to pay the price for this overhead without getting any benefits.
What latency do you get if you run a pure disjunction with these clauses
instead of a CommonTermsQuery?
> CommonsTermsQuery with huge no. of terms slower with top-k scoring
> --
>
> Key: LUCENE-9107
> URL: https://issues.apache.org/jira/browse/LUCENE-9107
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/search
>Affects Versions: 8.3
>Reporter: Tommaso Teofili
>Priority: Major
>
> In [1] a {{CommonTermsQuery}} is used in order to perform a query with lots
> of (duplicate) terms. Using a max term frequency cutoff of 0.999 for low
> frequency terms, the query, although big, finishes in around 2-300ms with
> Lucene 7.6.0.
> However, when upgrading the code to Lucene 8.x, the query runs in 2-3s
> instead [2].
> After digging a bit into it it seems that the regression in speed comes from
> the fact that top-k scoring introduced by default in version 8 is causing
> that, not sure "where" exactly in the code though.
> When switching back to complete hit scoring [3], the speed goes back to the
> initial 2-300ms also in Lucene 8.3.x.
> It'd be nice to understand the reason why this is happening and if it is only
> concerning {{CommonTermsQuery}} or affecting {{BooleanQuery}} as well.
> If this is a case that depends on the data and application involved (Anserini
> in this case), the application should handle it, otherwise if it is a
> regression/bug in Lucene it'd be nice to fix it.
> [1] :
> https://github.com/tteofili/Anserini-embeddings/blob/nnsearch/src/main/java/io/anserini/embeddings/nn/fw/FakeWordsRunner.java
> [2] :
> https://github.com/castorini/anserini/blob/master/src/main/java/io/anserini/analysis/vectors/ApproximateNearestNeighborEval.java
> [3] :
> https://github.com/tteofili/anserini/blob/ann-paper-reproduce/src/main/java/io/anserini/analysis/vectors/ApproximateNearestNeighborEval.java#L174
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1105: LUCENE-9105: UniformSplit postings format detects corrupted index
dsmiley commented on a change in pull request #1105: LUCENE-9105: UniformSplit
postings format detects corrupted index
URL: https://github.com/apache/lucene-solr/pull/1105#discussion_r361166565
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/IndexDictionary.java
##
@@ -97,31 +100,47 @@
* Otherwise {@code -1} if there is no floor block key because the searched
* term precedes alphabetically the first block key of the dictionary.
*/
-long seekBlock(BytesRef term);
+long seekBlock(BytesRef term) throws IOException;
/**
* Returns the next block key and positions the browser at this key.
* A key is a prefix of a term in the dictionary.
* If seekBlock was just called then this is the current block key.
*/
-BytesRef nextKey();
+BytesRef nextKey() throws IOException;
/**
* Returns the next key without advancing.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-BytesRef peekKey();
+BytesRef peekKey() throws IOException;
/**
* Returns the number of characters of this block's key that is in common
with all terms in this block.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-int getBlockPrefixLen();
+int getBlockPrefixLen() throws IOException;
/**
* Returns the block file pointer associated with the key returned.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-long getBlockFilePointer();
+long getBlockFilePointer() throws IOException;
+ }
+
+ /**
+ * Supplier for a new stateful {@link Browser} created on the immutable
{@link IndexDictionary}.
+ *
+ * The immutable {@link IndexDictionary} is lazy loaded thread safely. This
lazy loading allows
+ * us to load it only when {@link
org.apache.lucene.index.TermsEnum#seekCeil} or
+ * {@link org.apache.lucene.index.TermsEnum#seekExact} are called (it is not
loaded for a direct
+ * all-terms enumeration).
+ */
+ interface BrowserSupplier extends Accountable {
Review comment:
> What about keeping BrowserSupplier to join IOSupplier and Accountable
(without additional interface contract)?
+1
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-9093) Unified highlighter with word separator never gives context to the left
[ https://issues.apache.org/jira/browse/LUCENE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002839#comment-17002839 ] David Smiley commented on LUCENE-9093: -- In this situation, do it in two phases. Phase 1 is what you have already and would be merged to both branches. Phase 2 changes the default and only merges to master branch. This can all happen under this issue ID. > Unified highlighter with word separator never gives context to the left > --- > > Key: LUCENE-9093 > URL: https://issues.apache.org/jira/browse/LUCENE-9093 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: Tim Retout >Priority: Major > Attachments: LUCENE-9093.patch > > > When using the unified highlighter with hl.bs.type=WORD, I am not able to get > context to the left of the matches returned; only words to the right of each > match are shown. I see this behaviour on both Solr 6.4 and Solr 7.1. > Without context to the left of a match, the highlighted snippets are much > less useful for understanding where the match appears in a document. > As an example, using the techproducts data with Solr 7.1, given a search for > "apple", highlighting the "features" field: > http://localhost:8983/solr/techproducts/select?hl.fl=features=on=apple=WORD=30=unified > I see this snippet: > "Apple Lossless, H.264 video" > Note that "Apple" is anchored to the left. Compare with the original > highlighter: > http://localhost:8983/solr/techproducts/select?hl.fl=features=on=apple=30 > And the match has context either side: > ", Audible, Apple Lossless, H.264 video" > (To complicate this, in general I am not sure that the unified highlighter is > respecting the hl.fragsize parameter, although [SOLR-9935] suggests support > was added. I included the hl.fragsize param in the unified URL too, but it's > making no difference unless set to 0.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002822#comment-17002822 ] Jan Høydahl commented on SOLR-14146: Uploaded a PR that fixes it, please review :) > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > Time Spent: 10m > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002821#comment-17002821 ] ASF subversion and git services commented on SOLR-14146: Commit f7ca8faa4118f8b06e587c9a6cb70cbbe17fb0e1 in lucene-solr's branch refs/heads/SOLR-14146-refguide-zk-version from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f7ca8fa ] SOLR-14146: Zookeeper version not resolved in RefGuide > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > Time Spent: 10m > Remaining Estimate: 0h > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1119: SOLR-14146: Zookeeper version not resolved in RefGuide
janhoy opened a new pull request #1119: SOLR-14146: Zookeeper version not resolved in RefGuide URL: https://github.com/apache/lucene-solr/pull/1119 See https://issues.apache.org/jira/browse/SOLR-14146 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] janhoy opened a new pull request #1118: Change 72h voting rules for release wizard
janhoy opened a new pull request #1118: Change 72h voting rules for release wizard URL: https://github.com/apache/lucene-solr/pull/1118 Instead of a hard 3 working day requiremet, we use the ASF standard of 72 clock hours. But use the holiday logic to warn the RM about upcoming holidays and that she may want to extend the deadline. 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-9093) Unified highlighter with word separator never gives context to the left
[
https://issues.apache.org/jira/browse/LUCENE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002807#comment-17002807
]
Lucene/Solr QA commented on LUCENE-9093:
| (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
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red}
0m 23s{color} | {color:red} Check forbidden APIs check-forbidden-apis failed
{color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} |
{color:red} 0m 23s{color} | {color:red} Check forbidden APIs
check-forbidden-apis failed {color} |
| {color:red}-1{color} | {color:red} Validate ref guide {color} | {color:red}
0m 23s{color} | {color:red} Check forbidden APIs check-forbidden-apis failed
{color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
40s{color} | {color:green} highlighter in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 45m
59s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m
37s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 56m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9093 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12989051/LUCENE-9093.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns validaterefguide |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 72c99e921c4 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Check forbidden APIs |
https://builds.apache.org/job/PreCommit-LUCENE-Build/245/artifact/out/patch-check-forbidden-apis-root.txt
|
| Validate source patterns |
https://builds.apache.org/job/PreCommit-LUCENE-Build/245/artifact/out/patch-check-forbidden-apis-root.txt
|
| Validate ref guide |
https://builds.apache.org/job/PreCommit-LUCENE-Build/245/artifact/out/patch-check-forbidden-apis-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/245/testReport/ |
| modules | C: lucene lucene/highlighter solr/core solr/solrj
solr/solr-ref-guide U: . |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/245/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Unified highlighter with word separator never gives context to the left
> ---
>
> Key: LUCENE-9093
> URL: https://issues.apache.org/jira/browse/LUCENE-9093
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/highlighter
>Reporter: Tim Retout
>Priority: Major
> Attachments: LUCENE-9093.patch
>
>
> When using the unified highlighter with hl.bs.type=WORD, I am not able to get
> context to the left of the matches returned; only words to the right of each
> match are shown. I see this behaviour on both Solr 6.4 and Solr 7.1.
> Without context to the left of a match, the highlighted snippets are much
> less useful for understanding where the match appears in a document.
> As an example, using the techproducts data with Solr 7.1, given a search for
> "apple", highlighting the "features" field:
> http://localhost:8983/solr/techproducts/select?hl.fl=features=on=apple=WORD=30=unified
> I see this snippet:
> "Apple Lossless, H.264 video"
> Note that "Apple" is anchored to the left. Compare with the original
[jira] [Assigned] (SOLR-14146) Zookeeper version not resolved in RefGuide
[ https://issues.apache.org/jira/browse/SOLR-14146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl reassigned SOLR-14146: -- Assignee: Jan Høydahl > Zookeeper version not resolved in RefGuide > -- > > Key: SOLR-14146 > URL: https://issues.apache.org/jira/browse/SOLR-14146 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.3.1 >Reporter: Jan Høydahl >Assignee: Jan Høydahl >Priority: Major > Fix For: 8.5 > > > Check the page > [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] > It prints literal version string instead of the actual zookeeper version > number. -- 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-14146) Zookeeper version not resolved in RefGuide
Jan Høydahl created SOLR-14146: -- Summary: Zookeeper version not resolved in RefGuide Key: SOLR-14146 URL: https://issues.apache.org/jira/browse/SOLR-14146 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 8.3.1 Reporter: Jan Høydahl Fix For: 8.5 Check the page [https://lucene.apache.org/solr/guide/8_3/setting-up-an-external-zookeeper-ensemble.html#download-apache-zookeeper] It prints literal version string instead of the actual zookeeper version number. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6613) TextField.analyzeMultiTerm should not throw exception when analyzer returns no term
[
https://issues.apache.org/jira/browse/SOLR-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Roustant reassigned SOLR-6613:
Assignee: Bruno Roustant
> TextField.analyzeMultiTerm should not throw exception when analyzer returns
> no term
> ---
>
> Key: SOLR-6613
> URL: https://issues.apache.org/jira/browse/SOLR-6613
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 4.3.1, 4.10.2, 6.0
>Reporter: Bruno Roustant
>Assignee: Bruno Roustant
>Priority: Major
> Attachments: TestTextField.java
>
>
> In TextField.analyzeMultiTerm()
> at line
> try {
> if (!source.incrementToken())
> throw new SolrException();
> The method should not throw an exception if there is no token because having
> no token is legitimate because all tokens may be filtered out (e.g. with a
> blocking Filter such as StopFilter).
> In this case it should simply return null (as it already returns null in some
> cases, see first line of method). However, SolrQueryParserBase needs also to
> be fixed to correctly handle null returned by TextField.analyzeMultiTerm().
> See attached TestTextField for the corresponding new test class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14131) Add maxQueryLength option to DirectSolrSpellchecker
[ https://issues.apache.org/jira/browse/SOLR-14131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno Roustant reassigned SOLR-14131: - Assignee: Bruno Roustant > Add maxQueryLength option to DirectSolrSpellchecker > --- > > Key: SOLR-14131 > URL: https://issues.apache.org/jira/browse/SOLR-14131 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Reporter: Andy Webb >Assignee: Bruno Roustant >Priority: Minor > Time Spent: 3h 20m > Remaining Estimate: 0h > > Attempting to spellcheck some long query terms can trigger > org.apache.lucene.util.automaton.TooComplexToDeterminizeException. This > change (previously discussed in SOLR-13190, and dependent on LUCENE-9102) > adds a maxQueryLength option to DirectSolrSpellChecker so that Lucene/Solr > can be configured to not attempt to spellcheck terms over a specified length. > Here's a PR: https://github.com/apache/lucene-solr/pull/1113 -- 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] bruno-roustant commented on a change in pull request #1106: LUCENE-9106: UniformSplit postings format allows extension of block/line serializers.
bruno-roustant commented on a change in pull request #1106: LUCENE-9106:
UniformSplit postings format allows extension of block/line serializers.
URL: https://github.com/apache/lucene-solr/pull/1106#discussion_r361124327
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/UniformSplitTermsReader.java
##
@@ -68,16 +68,18 @@
* It can be used for decompression or decryption.
*/
public UniformSplitTermsReader(PostingsReaderBase postingsReader,
SegmentReadState state, BlockDecoder blockDecoder) throws IOException {
-this(postingsReader, state, blockDecoder, NAME, VERSION_START,
VERSION_CURRENT,
+this(postingsReader, state, blockDecoder, new FieldMetadata.Serializer(),
NAME, VERSION_START, VERSION_CURRENT,
Review comment:
Good point.
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] bruno-roustant commented on a change in pull request #1105: LUCENE-9105: UniformSplit postings format detects corrupted index
bruno-roustant commented on a change in pull request #1105: LUCENE-9105:
UniformSplit postings format detects corrupted index
URL: https://github.com/apache/lucene-solr/pull/1105#discussion_r361119723
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/IndexDictionary.java
##
@@ -97,31 +100,47 @@
* Otherwise {@code -1} if there is no floor block key because the searched
* term precedes alphabetically the first block key of the dictionary.
*/
-long seekBlock(BytesRef term);
+long seekBlock(BytesRef term) throws IOException;
/**
* Returns the next block key and positions the browser at this key.
* A key is a prefix of a term in the dictionary.
* If seekBlock was just called then this is the current block key.
*/
-BytesRef nextKey();
+BytesRef nextKey() throws IOException;
/**
* Returns the next key without advancing.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-BytesRef peekKey();
+BytesRef peekKey() throws IOException;
/**
* Returns the number of characters of this block's key that is in common
with all terms in this block.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-int getBlockPrefixLen();
+int getBlockPrefixLen() throws IOException;
/**
* Returns the block file pointer associated with the key returned.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-long getBlockFilePointer();
+long getBlockFilePointer() throws IOException;
+ }
+
+ /**
+ * Supplier for a new stateful {@link Browser} created on the immutable
{@link IndexDictionary}.
+ *
+ * The immutable {@link IndexDictionary} is lazy loaded thread safely. This
lazy loading allows
+ * us to load it only when {@link
org.apache.lucene.index.TermsEnum#seekCeil} or
+ * {@link org.apache.lucene.index.TermsEnum#seekExact} are called (it is not
loaded for a direct
+ * all-terms enumeration).
+ */
+ interface BrowserSupplier extends Accountable {
Review comment:
Thanks. I looked externally for such supplier but I didn't think to look in
Lucene util...
Accountable is leveraged in UniformSplitTerms.getDictionaryRamBytesUsed()
when computing the heap space. We could indeed put there an instanceof check
and optionally cast to Accountable. But I'd prefer to mandate Accountable so
that any implementation doesn't forget to provide it.
What about keeping BrowserSupplier to join IOSupplier and Accountable
(without additional interface contract)?
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] bruno-roustant commented on a change in pull request #1105: LUCENE-9105: UniformSplit postings format detects corrupted index
bruno-roustant commented on a change in pull request #1105: LUCENE-9105:
UniformSplit postings format detects corrupted index
URL: https://github.com/apache/lucene-solr/pull/1105#discussion_r361119723
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/IndexDictionary.java
##
@@ -97,31 +100,47 @@
* Otherwise {@code -1} if there is no floor block key because the searched
* term precedes alphabetically the first block key of the dictionary.
*/
-long seekBlock(BytesRef term);
+long seekBlock(BytesRef term) throws IOException;
/**
* Returns the next block key and positions the browser at this key.
* A key is a prefix of a term in the dictionary.
* If seekBlock was just called then this is the current block key.
*/
-BytesRef nextKey();
+BytesRef nextKey() throws IOException;
/**
* Returns the next key without advancing.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-BytesRef peekKey();
+BytesRef peekKey() throws IOException;
/**
* Returns the number of characters of this block's key that is in common
with all terms in this block.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-int getBlockPrefixLen();
+int getBlockPrefixLen() throws IOException;
/**
* Returns the block file pointer associated with the key returned.
* Only call this after {@link #nextKey()} returns a non-null result.
*/
-long getBlockFilePointer();
+long getBlockFilePointer() throws IOException;
+ }
+
+ /**
+ * Supplier for a new stateful {@link Browser} created on the immutable
{@link IndexDictionary}.
+ *
+ * The immutable {@link IndexDictionary} is lazy loaded thread safely. This
lazy loading allows
+ * us to load it only when {@link
org.apache.lucene.index.TermsEnum#seekCeil} or
+ * {@link org.apache.lucene.index.TermsEnum#seekExact} are called (it is not
loaded for a direct
+ * all-terms enumeration).
+ */
+ interface BrowserSupplier extends Accountable {
Review comment:
Thanks. I looked externally for such supplier but I didn't think of looking
in Lucene util...
Accountable is leveraged in UniformSplitTerms.getDictionaryRamBytesUsed()
when computing the heap space. We could indeed put there an instanceof check
and optionally cast to Accountable. But I'd prefer to mandate Accountable so
that any implementation doesn't forget to provide it.
What about keeping BrowserSupplier to join IOSupplier and Accountable
(without additional interface contract)?
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-9093) Unified highlighter with word separator never gives context to the left
[ https://issues.apache.org/jira/browse/LUCENE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002740#comment-17002740 ] Nándor Mátravölgyi commented on LUCENE-9093: How should I make pull requests with the different default fragalign [~dsmiley] ? My guess is that the PR to master should have the default fragalign of 0.5 (and modified docs), while I also make a PR to the 8x and 7x branch with the original patch. This way after the master is accepted and merged to the others, their PR can be accepted and cherry picked on the differences. I'll wait for your input on this. > Unified highlighter with word separator never gives context to the left > --- > > Key: LUCENE-9093 > URL: https://issues.apache.org/jira/browse/LUCENE-9093 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: Tim Retout >Priority: Major > Attachments: LUCENE-9093.patch > > > When using the unified highlighter with hl.bs.type=WORD, I am not able to get > context to the left of the matches returned; only words to the right of each > match are shown. I see this behaviour on both Solr 6.4 and Solr 7.1. > Without context to the left of a match, the highlighted snippets are much > less useful for understanding where the match appears in a document. > As an example, using the techproducts data with Solr 7.1, given a search for > "apple", highlighting the "features" field: > http://localhost:8983/solr/techproducts/select?hl.fl=features=on=apple=WORD=30=unified > I see this snippet: > "Apple Lossless, H.264 video" > Note that "Apple" is anchored to the left. Compare with the original > highlighter: > http://localhost:8983/solr/techproducts/select?hl.fl=features=on=apple=30 > And the match has context either side: > ", Audible, Apple Lossless, H.264 video" > (To complicate this, in general I am not sure that the unified highlighter is > respecting the hl.fragsize parameter, although [SOLR-9935] suggests support > was added. I included the hl.fragsize param in the unified URL too, but it's > making no difference unless set to 0.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14145) Failed to restore collection when cluster autoscaling policy is applied
yuan zhao created SOLR-14145:
Summary: Failed to restore collection when cluster autoscaling
policy is applied
Key: SOLR-14145
URL: https://issues.apache.org/jira/browse/SOLR-14145
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.4
Environment: [^collection_state.json]
Reporter: yuan zhao
Attachments: collection_state.json
My solr cluster respect the autoscaling policy as:
{
"set-cluster-policy" : [{
"replica" : "<2",
"shard" : "#EACH",
"node" : "#ANY"
}]
}
Steps to reproduce:
# create a collection named "demo".
# back up the collection.
# we can find the collecion_state.json file from the backup path. And there is
one line records "maxShardsPerNode":"1"
# drop this collection "demo".
# restore collection "demo", I will got the error message:
`"'maxShardsPerNode>0' is not supported when autoScaling policies are used",`
# if I change "maxShardsPerNode" to "0" or "-1", I will got error:`"Solr cloud
with available number of nodes:2 is insufficient for restoring a collection
with 1 shards, total replicas per shard 1 and maxShardsPerNode 2147483647.
Consider increasing maxShardsPerNode value OR number of available nodes."`
# if I delete "maxShardsPerNode" from collection_state.json, I will got
error:`maxShardsPerNode is not in the cluster state.`
I have attach the collection state 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
