[jira] [Commented] (SOLR-14993) Unable to download zookeeper files of 1byte in size
[ https://issues.apache.org/jira/browse/SOLR-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236951#comment-17236951 ] ASF subversion and git services commented on SOLR-14993: Commit 77a205387f697ed8bf86af2623b111ec11c8ac95 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=77a2053 ] SOLR-14993: Unable to download zookeeper files of 1byte in size > Unable to download zookeeper files of 1byte in size > --- > > Key: SOLR-14993 > URL: https://issues.apache.org/jira/browse/SOLR-14993 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.5.1 >Reporter: Allen Sooredoo >Assignee: Erick Erickson >Priority: Minor > > When downloading a file from Zookeeper using the Solrj client, files of size > 1 byte are ignored. -- 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-14993) Unable to download zookeeper files of 1byte in size
[ https://issues.apache.org/jira/browse/SOLR-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236952#comment-17236952 ] ASF subversion and git services commented on SOLR-14993: Commit 12900a1078751ff593175a1034bb2371b3bf4cd1 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=12900a1 ] SOLR-14993: Unable to download zookeeper files of 1byte in size > Unable to download zookeeper files of 1byte in size > --- > > Key: SOLR-14993 > URL: https://issues.apache.org/jira/browse/SOLR-14993 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.5.1 >Reporter: Allen Sooredoo >Assignee: Erick Erickson >Priority: Minor > > When downloading a file from Zookeeper using the Solrj client, files of size > 1 byte are ignored. -- 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-14993) Unable to download zookeeper files of 1byte in size
[ https://issues.apache.org/jira/browse/SOLR-14993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14993. --- Fix Version/s: 8.8 Resolution: Fixed > Unable to download zookeeper files of 1byte in size > --- > > Key: SOLR-14993 > URL: https://issues.apache.org/jira/browse/SOLR-14993 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud, SolrJ >Affects Versions: 8.5.1 >Reporter: Allen Sooredoo >Assignee: Erick Erickson >Priority: Minor > Fix For: 8.8 > > > When downloading a file from Zookeeper using the Solrj client, files of size > 1 byte are ignored. -- 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-15011) /admin/logging handler should be able to configure logs on all nodes
David Smiley created SOLR-15011: --- Summary: /admin/logging handler should be able to configure logs on all nodes Key: SOLR-15011 URL: https://issues.apache.org/jira/browse/SOLR-15011 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: logging Reporter: David Smiley The LoggingHandler registered at /admin/logging can configure log levels for the current node. This is nice but in SolrCloud, what's needed is an ability to change the level for _all_ nodes in the cluster. I propose that this be a parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI could have a checkbox for it. I don't propose that the read operations be changed -- they can continue to just look at the node you are hitting. -- 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-9619) Move Points from a visitor API to a custor-style API?
Adrien Grand created LUCENE-9619: Summary: Move Points from a visitor API to a custor-style API? Key: LUCENE-9619 URL: https://issues.apache.org/jira/browse/LUCENE-9619 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Points' visitor API work well but there are a couple things we could make better if we moved to a cursor API, e.g. - Term queries could return a DocIdSetIterator without having to materialize a BitSet. - Nearest-neighbor search could work on top of the regular API instead of casting to BKDReader https://github.com/apache/lucene-solr/blob/6a7131ee246d700c2436a85ddc537575de2aeacf/lucene/sandbox/src/java/org/apache/lucene/sandbox/document/FloatPointNearestNeighbor.java#L296 - We could optimize counting the number of matches of a query by adding the number of points in a leaf without visiting documents where there are no deleted documents and a leaf fully matches the query. -- 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-14837) prometheus-exporter: different metrics ports publishes mixed metrics
[ https://issues.apache.org/jira/browse/SOLR-14837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14837: --- Status: Patch Available (was: Open) > prometheus-exporter: different metrics ports publishes mixed metrics > > > Key: SOLR-14837 > URL: https://issues.apache.org/jira/browse/SOLR-14837 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 8.6.2 >Reporter: Fadi Mohsen >Priority: Minor > Attachments: SOLR-14837.patch > > > when calling SolrExporter.main "pro-grammatically"/"same JVM" with two > different solr masters asking to publish the metrics on two different ports, > the metrics are being mixed on both metric endpoints from the two solr > masters. > This was tracked down to a static variable called *defaultRegistry*: > https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java#L86 > removing the static keyword fixes the issue. -- 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-14837) prometheus-exporter: different metrics ports publishes mixed metrics
[ https://issues.apache.org/jira/browse/SOLR-14837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14837: --- Status: Open (was: Patch Available) > prometheus-exporter: different metrics ports publishes mixed metrics > > > Key: SOLR-14837 > URL: https://issues.apache.org/jira/browse/SOLR-14837 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 8.6.2 >Reporter: Fadi Mohsen >Priority: Minor > Attachments: SOLR-14837.patch > > > when calling SolrExporter.main "pro-grammatically"/"same JVM" with two > different solr masters asking to publish the metrics on two different ports, > the metrics are being mixed on both metric endpoints from the two solr > masters. > This was tracked down to a static variable called *defaultRegistry*: > https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java#L86 > removing the static keyword fixes the issue. -- 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-14837) prometheus-exporter: different metrics ports publishes mixed metrics
[ https://issues.apache.org/jira/browse/SOLR-14837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237028#comment-17237028 ] Jan Høydahl commented on SOLR-14837: Thanks for following up. A patch is ok but easier to review and give feedback on a or. I won’t have a chance to look at this right now, hope that someone else will take a look. > prometheus-exporter: different metrics ports publishes mixed metrics > > > Key: SOLR-14837 > URL: https://issues.apache.org/jira/browse/SOLR-14837 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 8.6.2 >Reporter: Fadi Mohsen >Priority: Minor > Attachments: SOLR-14837.patch > > > when calling SolrExporter.main "pro-grammatically"/"same JVM" with two > different solr masters asking to publish the metrics on two different ports, > the metrics are being mixed on both metric endpoints from the two solr > masters. > This was tracked down to a static variable called *defaultRegistry*: > https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java#L86 > removing the static keyword fixes the issue. -- 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-6733) Umbrella issue - Solr as a standalone application
[ https://issues.apache.org/jira/browse/SOLR-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237030#comment-17237030 ] Jan Høydahl commented on SOLR-6733: --- Related to SIP-6 https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process There is a pr with an initial POC for a bootstrap jar that simply delegates to Jetty’s start class. That could be the first step, while still keeping jetty’s config. Next step would be to build the context in Java. > Umbrella issue - Solr as a standalone application > - > > Key: SOLR-6733 > URL: https://issues.apache.org/jira/browse/SOLR-6733 > Project: Solr > Issue Type: New Feature >Reporter: Shawn Heisey >Priority: Major > > Umbrella issue. > Solr should be a standalone application, where the main method is provided by > Solr source code. > Here are the major tasks I envision, if we choose to embed Jetty: > * Create org.apache.solr.start.Main (and possibly other classes in the same > package), to be placed in solr-start.jar. The Main class will contain the > main method that starts the embedded Jetty and Solr. I do not know how to > adjust the build system to do this successfully. > * Handle central configurations in code -- TCP port, SSL, and things like > web.xml. > * For each of these steps, clean up any test fallout. > * Handle cloud-related configurations in code -- port, hostname, protocol, > etc. Use the same information as the central configurations. > * Consider whether things like authentication need changes. > * Handle any remaining container configurations. > I am currently imagining this work happening in a new branch and ultimately > being applied only to master, not the stable branch. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] HoustonPutman commented on pull request #1972: SOLR-14915: Prometheus-exporter does not depend on Solr-core any longer
HoustonPutman commented on pull request #1972: URL: https://github.com/apache/lucene-solr/pull/1972#issuecomment-731896579 I didn't know there was a stigma around `File`, but made the change to use `Path` and `Files` instead. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1972: SOLR-14915: Prometheus-exporter does not depend on Solr-core any longer
dsmiley commented on a change in pull request #1972:
URL: https://github.com/apache/lucene-solr/pull/1972#discussion_r528452221
##
File path:
solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/MetricsConfiguration.java
##
@@ -66,13 +81,36 @@ public PrometheusExporterSettings getSettings() {
return searchConfiguration;
}
- public static MetricsConfiguration from(XmlConfigFile config) throws
Exception {
-Node settings = config.getNode("/config/settings", false);
+ public static MetricsConfiguration from(String path) throws Exception {
+// See solr-core XmlConfigFile
+final DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
+try {
+ dbf.setXIncludeAware(true);
+ dbf.setNamespaceAware(true);
+} catch (UnsupportedOperationException e) {
+ log.warn("{} XML parser doesn't support XInclude option", path);
+}
+
+Document document;
+File file = new File(path);
Review comment:
Not a problem as the config can only be specified by an admin on the
local machine.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul edited a comment on pull request #2010: SOLR-12182: Don't persist base_url in ZK as the scheme is variable, compute from node_name instead
noblepaul edited a comment on pull request #2010: URL: https://github.com/apache/lucene-solr/pull/2010#issuecomment-731661638 > we don't want to promise the community a zero-downtime upgrade to enable TLS, because it is a hard thing to promise I don't have a problem if there is a downtime when you upgrade from one scheme to another. I only worry if the scheme remains same and a rolling restart is not possible. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1972: SOLR-14915: Prometheus-exporter does not depend on Solr-core any longer
dsmiley commented on a change in pull request #1972:
URL: https://github.com/apache/lucene-solr/pull/1972#discussion_r528453632
##
File path:
solr/contrib/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/MetricsConfiguration.java
##
@@ -77,22 +79,22 @@ public PrometheusExporterSettings getSettings() {
return searchConfiguration;
}
- public static MetricsConfiguration from(String path) throws Exception {
+ public static MetricsConfiguration from(String resource) throws Exception {
// See solr-core XmlConfigFile
final DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
dbf.setXIncludeAware(true);
dbf.setNamespaceAware(true);
} catch (UnsupportedOperationException e) {
- log.warn("{} XML parser doesn't support XInclude option", path);
+ log.warn("{} XML parser doesn't support XInclude option", resource);
}
Document document;
-File file = new File(path);
-if (file.isFile()) {
- document = dbf.newDocumentBuilder().parse(file);
+Path path = Path.of(resource);
+if (Files.exists(path)) {
+ document =
dbf.newDocumentBuilder().parse(path.toAbsolutePath().toString());
Review comment:
This `parse(String)` is documented to take a URI. I don't think a file
path is a URI? If you look at the implementation of the variant that takes a
File, it converts it to a URI then and then an ASCII string. This could be
done via `path.toUri().toASCIIString()`. FWIW I'd also be okay with just
doing path.toFile() here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9581) Clarify discardCompoundToken behavior in the JapaneseTokenizer
[ https://issues.apache.org/jira/browse/LUCENE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237176#comment-17237176 ] ASF subversion and git services commented on LUCENE-9581: - Commit a5d0654a2469c92bf02497e8fd18587058cb1a96 in lucene-solr's branch refs/heads/master from jimczi [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a5d0654 ] LUCENE-9581: Japanese tokenizer should discard the compound token instead of disabling the decomposition of long tokens when discardCompoundToken is activated. > Clarify discardCompoundToken behavior in the JapaneseTokenizer > -- > > Key: LUCENE-9581 > URL: https://issues.apache.org/jira/browse/LUCENE-9581 > Project: Lucene - Core > Issue Type: Bug >Reporter: Jim Ferenczi >Priority: Minor > Attachments: LUCENE-9581.patch, LUCENE-9581.patch, LUCENE-9581.patch > > > At first sight, the discardCompoundToken option added in LUCENE-9123 seems > redundant with the NORMAL mode of the Japanese tokenizer. When set to true, > the current behavior is to disable the decomposition for compounds, that's > exactly what the NORMAL mode does. > So I wonder if the right semantic of the option would be to keep only the > decomposition of the compound or if it's really needed. If the goal is to > make the output compatible with a graph token filter, the current workaround > to set the mode to NORMAL should be enough. > That's consistent with the mode that should be used to preserve positions in > the index since we don't handle position length on the indexing side. > Am I missing something regarding the new option ? Is there a compelling case > where it differs from the NORMAL mode ? -- 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
