[jira] [Commented] (SOLR-10359) User Interactions Logging Module
[ https://issues.apache.org/jira/browse/SOLR-10359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865107#comment-17865107 ] Eric Pugh commented on SOLR-10359: -- I wanted to share some work that I've been doing in this space. As part of another project, I've been able to contribute to a standard we are calling "User Behavior Interactions" for tracking what users are doing. This standard, which is NOT tied to any specific search engine, like Solr, is documented at [https://github.com/o19s/ubi.] There is a draft PR for implementing UBI for Solr here: [https://github.com/apache/solr/pull/2452] I have hopes that in the latter half of 2024, we'll be publishing some jupyter notebook style demonstration code for taking UBI based data and producing implicit judgements from that data ;). > User Interactions Logging Module > > > Key: SOLR-10359 > URL: https://issues.apache.org/jira/browse/SOLR-10359 > Project: Solr > Issue Type: New Feature >Reporter: Alessandro Benedetti >Priority: Major > Labels: CTR, evaluation > > *Introduction* > Being able to evaluate the quality of your search engine is becoming more and > more important day by day. > This issue is to put a milestone to integrate online evaluation metrics with > Solr. > *Scope* > Scope of this issue is to provide a set of components able to : > 1) Collect Search Results impressions ( results shown per query) > 2) Collect Users interactions ( user interactions on the search results per > query e.g. clicks, bookmarking,ect ) > 3) Calculate evaluation metrics on demand, such as Click Through Rate, DCG ... > *Technical Design* > A SearchComponent can be designed : > *UsersEventsLoggerComponent* > A property (such as storeDir) will define where the data collected will be > stored. > Different data structures can be explored, to keep it simple, a first > implementation can be a Lucene Index. > *Data Model* > The user event can be modelled in the following way : > - the user query the event is related to > - the ID of the search result involved in the interaction > - the position in the ranking of the search result involved > in the interaction > - time when the interaction happened > - 0 for impressions, a value between 1-5 to identify the > type of user event, the semantic will depend on the domain and use cases > - this can identify a variant, in A/B testing > *Impressions Logging* > When the SearchComponent is assigned to a request handler, everytime it > processes a request and return to the user a result set for a query, the > component will collect the impressions ( results returned) and index them in > the auxiliary lucene index. > This will happen in parallel as soon as you return the results to avoid > affecting the query time. > Of course an impact on CPU load and memory is expected, will be interesting > to minimise it. > *User Events Logging* > An UpdateHandler will be exposed to accept POST requests and collect user > events. > Everytime a request is sent, the user event will be indexed in the underline > auxiliary Lucene Index. > *Stats Calculation* > A RequestHandler will be exposed to be able to calculate stats and > aggregations for the metrics : > /evaluation?metric=ctr=query=testA,testB > This request could calculate the CTR for our testA and testB to compare. > Showing stats in total and per query ( to highlight the queries with > lower/higher CTR). > The calculations will happen separating the for an easy > comparison. > Will be important to keep it as simple as possible for a first version, to > then extend it as much as we like -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17359) Make SolrCLI handle arg parsing of zk sub commands
[
https://issues.apache.org/jira/browse/SOLR-17359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17863206#comment-17863206
]
Eric Pugh commented on SOLR-17359:
--
One thought, do we like the sub command pattern? Is that how modern "good"
CLI's are built? If so, then do we think this is an opportunity to improve
commons-cli instead of rolling our own code? (and if so what would that look
like??)
> Make SolrCLI handle arg parsing of zk sub commands
> --
>
> Key: SOLR-17359
> URL: https://issues.apache.org/jira/browse/SOLR-17359
> Project: Solr
> Issue Type: Sub-task
> Components: scripts and tools
>Reporter: Jan Høydahl
>Priority: Major
>
> Both bin/solr and bin/solr.cmd have lots of shell code to parse the zk sub
> commands, and to print the usage text. We have both a short zk uage text and
> the full one.
> {code:java}
> Usage: solr zk upconfig|downconfig -d -n [-z zkHost]
> [-s solrUrl]"
>solr zk cp [-r] [-z zkHost] [-s solrUrl]"
>solr zk rm [-r] [-z zkHost] [-s solrUrl]"
>solr zk mv [-z zkHost] [-s solrUrl]"
>solr zk ls [-r] [-z zkHost] [-s solrUrl]"
>solr zk mkroot [-z zkHost] [-s solrUrl]"
>solr zk linkconfig --conf-name -c [-z zkHost]
> [-s solrUrl]"
>solr zk updateacls [-z zkHost] [-s solrUrl]" {code}
> Extend SolrCLI and tools API to handle sub commands more natively so that
> doing {{solr zk -h}} shows a list of sub commands, while `solr zk cp -h`
> shows usage for that sub command.
> I think commons-cli does not have native subcommand support like e.g.
> picocli, but it should be possible to implement..
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17174) commit to mixedCase cli options or dashed-case cli options
[ https://issues.apache.org/jira/browse/SOLR-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17862821#comment-17862821 ] Eric Pugh commented on SOLR-17174: -- Correct... > commit to mixedCase cli options or dashed-case cli options > -- > > Key: SOLR-17174 > URL: https://issues.apache.org/jira/browse/SOLR-17174 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17327) Update bats test to remove /solr from solr Urls.
[ https://issues.apache.org/jira/browse/SOLR-17327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860943#comment-17860943 ] Eric Pugh commented on SOLR-17327: -- Thanks for figuring this out! No breach of etiquette ;) > Update bats test to remove /solr from solr Urls. > - > > Key: SOLR-17327 > URL: https://issues.apache.org/jira/browse/SOLR-17327 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > Fix For: 9.7 > > Time Spent: 20m > Remaining Estimate: 0h > > For all the bats tests Except where it matters, remove the /solr context path > from the various --solr-url's. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17351) Cosmetic changes to v2 filestore "get file" API
[
https://issues.apache.org/jira/browse/SOLR-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860649#comment-17860649
]
Eric Pugh commented on SOLR-17351:
--
Fair point. I've never done the cluster upgrade in the rolling pattern..
I've only ever done blue/green, so I keep forgetting about that aspect!
> Cosmetic changes to v2 filestore "get file" API
> ---
>
> Key: SOLR-17351
> URL: https://issues.apache.org/jira/browse/SOLR-17351
> Project: Solr
> Issue Type: Sub-task
> Components: Package Manager, v2 API
>Affects Versions: 9.6.1
>Reporter: Jason Gerlowski
>Priority: Minor
>
> Solr's filestore APIs fit well with the REST-ful design we're targeting with
> our v2 APIs, with one large exception: the "get file" API current available
> at {{GET /api/node/files/somePath.txt}}. This API stands out for a few
> reasons:
> 1. It uses a different path-prefix than all other filestore APIs. (i.e.
> {{/api/node/files}} instead of {{/api/cluster/files}})
> 2. It exposes 4 or 5 conceptually distinct operations. Obviously in the
> "default" case it allows callers to retrieve filestore contents, but based on
> query params it can instead:
> - return filestore entry metadata (when {{meta=true}} is specified)
> - instruct the receiving Solr node to pull a file from another node's
> filestore and cache it locally (when {{getFrom=someOtherNode}} is specified)
> - instruct the receiving Solr node to push its cached copy of a file out to
> all other Solr nodes (when {{sync=true}} is specified)
> 3. Even in the default case of returning "raw" filestore contents, the API
> can provide two different styles of response:
> - if {{wt=json}} is specified Solr will take the filestore entry bytes,
> attempt to stringify them, and then return a JSON object that uses this
> string as the value for a "response" key. It's unclear how this would work
> for binary content
> - for all other values of "wt", the API will return the raw file content.
> We should reconsider this endpoint and see if it can't be massaged into being
> more in line with our other v2 APIs. Some cosmetic tweaks will go a long
> way, but the biggest benefit is likely to come from breaking the endpoint up
> into multiple distinct APIs. In its current form, the API returns such a
> variety of responses that it's hard to write client code for. (I suspect
> this is the main reason these "filestore" APIs were never made available in
> SolrJ.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17352) Remove deprecated commands from CLI, such as -zkHost.
Eric Pugh created SOLR-17352: Summary: Remove deprecated commands from CLI, such as -zkHost. Key: SOLR-17352 URL: https://issues.apache.org/jira/browse/SOLR-17352 Project: Solr Issue Type: Sub-task Components: cli Affects Versions: main (10.0) Reporter: Eric Pugh We will remove the deprecated CLI commands like -zkHost and -solrUrl etc from 10.x -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17351) Cosmetic changes to v2 filestore "get file" API
[
https://issues.apache.org/jira/browse/SOLR-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17860598#comment-17860598
]
Eric Pugh commented on SOLR-17351:
--
I like your plan, however I'd prefer to see the internal usage of these APIs to
happen in 9.x as well. My theory is that this is the best way to confirm that
the new API meets our needs, otherwise we are building it in a vacuum. Plus,
this ensures the new API works as well as the old one since Solr is a key user
of these APIs!
> Cosmetic changes to v2 filestore "get file" API
> ---
>
> Key: SOLR-17351
> URL: https://issues.apache.org/jira/browse/SOLR-17351
> Project: Solr
> Issue Type: Sub-task
> Components: Package Manager, v2 API
>Affects Versions: 9.6.1
>Reporter: Jason Gerlowski
>Priority: Minor
>
> Solr's filestore APIs fit well with the REST-ful design we're targeting with
> our v2 APIs, with one large exception: the "get file" API current available
> at {{GET /api/node/files/somePath.txt}}. This API stands out for a few
> reasons:
> 1. It uses a different path-prefix than all other filestore APIs. (i.e.
> {{/api/node/files}} instead of {{/api/cluster/files}})
> 2. It exposes 4 or 5 conceptually distinct operations. Obviously in the
> "default" case it allows callers to retrieve filestore contents, but based on
> query params it can instead:
> - return filestore entry metadata (when {{meta=true}} is specified)
> - instruct the receiving Solr node to pull a file from another node's
> filestore and cache it locally (when {{getFrom=someOtherNode}} is specified)
> - instruct the receiving Solr node to push its cached copy of a file out to
> all other Solr nodes (when {{sync=true}} is specified)
> 3. Even in the default case of returning "raw" filestore contents, the API
> can provide two different styles of response:
> - if {{wt=json}} is specified Solr will take the filestore entry bytes,
> attempt to stringify them, and then return a JSON object that uses this
> string as the value for a "response" key. It's unclear how this would work
> for binary content
> - for all other values of "wt", the API will return the raw file content.
> We should reconsider this endpoint and see if it can't be massaged into being
> more in line with our other v2 APIs. Some cosmetic tweaks will go a long
> way, but the biggest benefit is likely to come from breaking the endpoint up
> into multiple distinct APIs. In its current form, the API returns such a
> variety of responses that it's hard to write client code for. (I suspect
> this is the main reason these "filestore" APIs were never made available in
> SolrJ.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15582) remove deprecated APIs in solrj Tuple class
[
https://issues.apache.org/jira/browse/SOLR-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-15582:
-
Fix Version/s: 9.7
Assignee: Eric Pugh (was: Christine Poerschke)
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks Christine!
> remove deprecated APIs in solrj Tuple class
> ---
>
> Key: SOLR-15582
> URL: https://issues.apache.org/jira/browse/SOLR-15582
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> * remove use of deprecated APIs on both {{lucene-solr/branch_8x}} and
> {{solr/main}} branches
> * remove deprecated APIs itself on {{solr/main}} branch only
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17330) Default value for 'loadOnStartup' is fuzzy
[
https://issues.apache.org/jira/browse/SOLR-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856940#comment-17856940
]
Eric Pugh commented on SOLR-17330:
--
I went ahead and merged this one, and I added it to Changes only to make sure
to track the change that Pierre did. I like another ticket to get the
EnvUtils, maybe one that does that everywhere in Solr?
> Default value for 'loadOnStartup' is fuzzy
> --
>
> Key: SOLR-17330
> URL: https://issues.apache.org/jira/browse/SOLR-17330
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.6
>Reporter: Pierre Salagnac
>Assignee: Eric Pugh
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Each core has property {{loadOnStartup}} to decide if the core is opened at
> start-up or delayed until first access.
> When creating a new core and *not* specifying the property in the request, we
> take the default value from {{CoreDescriptor.defaultProperties}} which is
> {{true}}.
> {code:java|title= defaultProperties}
> private static final Map defaultProperties = Map.of(,
> CORE_LOADONSTARTUP, "true");
> {code}
> Then, when we retrieve the value of the property in
> {{CoreDescriptor.isLoadOnStartup()}}, if the property is not the core stored
> properties, default value is {{false}}.
> {code:java|title=isLoadOnStartup()}
> String tmp = coreProperties.getProperty(CORE_LOADONSTARTUP, "false");
> {code}
> Impact is low since all cores are created with value {{"true"}} when not
> explicitly created, using value from the default properties. This just makes
> the code confusing to read.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17330) Default value for 'loadOnStartup' is fuzzy
[
https://issues.apache.org/jira/browse/SOLR-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17330.
--
Fix Version/s: 9.7
Resolution: Fixed
> Default value for 'loadOnStartup' is fuzzy
> --
>
> Key: SOLR-17330
> URL: https://issues.apache.org/jira/browse/SOLR-17330
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.6
>Reporter: Pierre Salagnac
>Assignee: Eric Pugh
>Priority: Trivial
> Fix For: 9.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Each core has property {{loadOnStartup}} to decide if the core is opened at
> start-up or delayed until first access.
> When creating a new core and *not* specifying the property in the request, we
> take the default value from {{CoreDescriptor.defaultProperties}} which is
> {{true}}.
> {code:java|title= defaultProperties}
> private static final Map defaultProperties = Map.of(,
> CORE_LOADONSTARTUP, "true");
> {code}
> Then, when we retrieve the value of the property in
> {{CoreDescriptor.isLoadOnStartup()}}, if the property is not the core stored
> properties, default value is {{false}}.
> {code:java|title=isLoadOnStartup()}
> String tmp = coreProperties.getProperty(CORE_LOADONSTARTUP, "false");
> {code}
> Impact is low since all cores are created with value {{"true"}} when not
> explicitly created, using value from the default properties. This just makes
> the code confusing to read.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17330) Default value for 'loadOnStartup' is fuzzy
[
https://issues.apache.org/jira/browse/SOLR-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17330:
Assignee: Eric Pugh
> Default value for 'loadOnStartup' is fuzzy
> --
>
> Key: SOLR-17330
> URL: https://issues.apache.org/jira/browse/SOLR-17330
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.6
>Reporter: Pierre Salagnac
>Assignee: Eric Pugh
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Each core has property {{loadOnStartup}} to decide if the core is opened at
> start-up or delayed until first access.
> When creating a new core and *not* specifying the property in the request, we
> take the default value from {{CoreDescriptor.defaultProperties}} which is
> {{true}}.
> {code:java|title= defaultProperties}
> private static final Map defaultProperties = Map.of(,
> CORE_LOADONSTARTUP, "true");
> {code}
> Then, when we retrieve the value of the property in
> {{CoreDescriptor.isLoadOnStartup()}}, if the property is not the core stored
> properties, default value is {{false}}.
> {code:java|title=isLoadOnStartup()}
> String tmp = coreProperties.getProperty(CORE_LOADONSTARTUP, "false");
> {code}
> Impact is low since all cores are created with value {{"true"}} when not
> explicitly created, using value from the default properties. This just makes
> the code confusing to read.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-15591) NullPointerException in ExternalPaths.determineSourceHome makes debugging cumbersome
[
https://issues.apache.org/jira/browse/SOLR-15591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-15591.
--
Fix Version/s: 9.7
Resolution: Fixed
> NullPointerException in ExternalPaths.determineSourceHome makes debugging
> cumbersome
>
>
> Key: SOLR-15591
> URL: https://issues.apache.org/jira/browse/SOLR-15591
> Project: Solr
> Issue Type: Improvement
> Components: Tests
>Reporter: Mike Drob
>Assignee: Eric Pugh
>Priority: Major
> Labels: newdev
> Fix For: 9.7
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When running a debugger set to break on exceptions, some tests will throw NPE
> in {{determineSourceHome()}}, which we dutifully catch and easily recover
> from. We should instead check for the null condition instead of forcing the
> debugger to stop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-15591) NullPointerException in ExternalPaths.determineSourceHome makes debugging cumbersome
[
https://issues.apache.org/jira/browse/SOLR-15591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-15591:
Assignee: Eric Pugh
> NullPointerException in ExternalPaths.determineSourceHome makes debugging
> cumbersome
>
>
> Key: SOLR-15591
> URL: https://issues.apache.org/jira/browse/SOLR-15591
> Project: Solr
> Issue Type: Improvement
> Components: Tests
>Reporter: Mike Drob
>Assignee: Eric Pugh
>Priority: Major
> Labels: newdev
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When running a debugger set to break on exceptions, some tests will throw NPE
> in {{determineSourceHome()}}, which we dutifully catch and easily recover
> from. We should instead check for the null condition instead of forcing the
> debugger to stop.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16576) Improve StrField field type documentation for large string storage
[
https://issues.apache.org/jira/browse/SOLR-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856933#comment-17856933
]
Eric Pugh commented on SOLR-16576:
--
Thank you [~nosvalds]
> Improve StrField field type documentation for large string storage
> --
>
> Key: SOLR-16576
> URL: https://issues.apache.org/jira/browse/SOLR-16576
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 9.1
>Reporter: Nikolas Osvalds
>Assignee: Eric Pugh
>Priority: Trivial
> Labels: documentation-update
> Fix For: 9.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The existing documentation for the `StrField` field type makes some
> assumptions about the configuration and steers users toward not using it for
> large strings. Apparently it's the {{indexed=true}} aspect that effectively
> limits the size of StrField, not the type of the field itself.
>
> It can be fine to use StrField for large strings as long as `indexed=false`
> and `docValues=false`.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16576) Improve StrField field type documentation for large string storage
[
https://issues.apache.org/jira/browse/SOLR-16576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-16576.
--
Fix Version/s: 9.7
Assignee: Eric Pugh (was: Michael Gibney)
Resolution: Fixed
> Improve StrField field type documentation for large string storage
> --
>
> Key: SOLR-16576
> URL: https://issues.apache.org/jira/browse/SOLR-16576
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 9.1
>Reporter: Nikolas Osvalds
>Assignee: Eric Pugh
>Priority: Trivial
> Labels: documentation-update
> Fix For: 9.7
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The existing documentation for the `StrField` field type makes some
> assumptions about the configuration and steers users toward not using it for
> large strings. Apparently it's the {{indexed=true}} aspect that effectively
> limits the size of StrField, not the type of the field itself.
>
> It can be fine to use StrField for large strings as long as `indexed=false`
> and `docValues=false`.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15960) Unified use of system properties and environment variables
[
https://issues.apache.org/jira/browse/SOLR-15960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856932#comment-17856932
]
Eric Pugh commented on SOLR-15960:
--
Makes sense to me. I want us to get away from using environment variables all
over the place, each a bit differently treated. Would you then use
forbiddenapi to make sure we don't backslide?
> Unified use of system properties and environment variables
> --
>
> Key: SOLR-15960
> URL: https://issues.apache.org/jira/browse/SOLR-15960
> Project: Solr
> Issue Type: Improvement
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 9.5
>
> Time Spent: 10h 20m
> Remaining Estimate: 0h
>
> We have a lot of boiler-plate code in Solr related to resolving configuration
> from config-files, system properties and environment variables.
> The main pattern so far has been to load a config from an xml file, which
> uses system property variables like {{{}$\{myVar{. All the environment
> variables that we expose in {{solr.in.sh}} are converted to system.properties
> in {{bin/solr}} and inside of Solr we only care about sys.props. This has
> served us quite well, but is also has certain disadvantages:
> * Naming mismatches. You have one config name in the xml file, one as system
> property and yet another for environment variable.
> * Duplicate code to deal with type conversion, and converting comma
> separated lists from env.var into Java lists
> * Every new config option needs to touch {{{}bin/solr{}}}, {{bin/solr.cmd}}
> and often more.
> In the world of containers and k8s, we want to configure almost every aspect
> of an app using environment variables. It is sometimes also more secure than
> passing sys.props on the cmdline since they won't show up in a "ps".
> So this is a proposal to unify all Solr's configs in a more structured way
> * Make naming a convention. All env.variable should be uppercase with format
> {{SOLR_X_Y}} and all sys.propos should be lowercase with the format
> {{solr.x.y}}. Perhaps {{solr.camelCase}} should map to {{SOLR_CAMEL_CASE}},
> or we discourage camel case in favour of dots.
> * Add a central {{ConfigResolver}} class to Solr that can answer e.g.
> {{getInt("solr.my.number")}} and it would return either prop
> {{solr.my.number}} or {{SOLR_MY_NUMBER}}. Similar for String, bool etc, and
> with fallback-values
> * List support, e.g. {{getListOfStrings("solr.modules")}} and it would
> return a {{List}} from either {{solr.modules}} or {{SOLR_MODULES}},
> supporting comma-separated, custom separator and why not also json list
> format ["foo","bar"]?
> A pitfall of using environment variables directly is testing, since env.vars
> are immutable. I suggest we solve this by reading all {{SOLR_*}}
> env.variables on startup and inserting them into a static, mutable map
> somewhere which is the single source of truth for env.vars. Then we can ban
> the use of {{System.getenv()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17338) Change missing zkHost/solrUrl to system.err
Eric Pugh created SOLR-17338: Summary: Change missing zkHost/solrUrl to system.err Key: SOLR-17338 URL: https://issues.apache.org/jira/browse/SOLR-17338 Project: Solr Issue Type: Sub-task Components: cli Affects Versions: 9.6.1 Reporter: Eric Pugh We log the warnign to standard out, which means if you pipe things, you have to filter it out! -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856492#comment-17856492
]
Eric Pugh commented on SOLR-14673:
--
Not sure why it hasn't linked, but [https://github.com/apache/solr/pull/2479]
is the PR
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Eric Pugh
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17336) Merge windows and linux examples in ref guide for post tool
Eric Pugh created SOLR-17336: Summary: Merge windows and linux examples in ref guide for post tool Key: SOLR-17336 URL: https://issues.apache.org/jira/browse/SOLR-17336 Project: Solr Issue Type: Sub-task Components: documentation Reporter: Eric Pugh Per email thread, we'll just use a single example because java deals with windows and linux filesystem slashes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17327) Update bats test to remove /solr from solr Urls.
[ https://issues.apache.org/jira/browse/SOLR-17327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17327. -- Fix Version/s: 9.7 Resolution: Fixed refactoring so no CHANGEs.txt > Update bats test to remove /solr from solr Urls. > - > > Key: SOLR-17327 > URL: https://issues.apache.org/jira/browse/SOLR-17327 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > Fix For: 9.7 > > Time Spent: 20m > Remaining Estimate: 0h > > For all the bats tests Except where it matters, remove the /solr context path > from the various --solr-url's. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17332) Remove last vestiges of post.jar from main
[ https://issues.apache.org/jira/browse/SOLR-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17332. -- Fix Version/s: main (10.0) Assignee: Eric Pugh Resolution: Fixed > Remove last vestiges of post.jar from main > -- > > Key: SOLR-17332 > URL: https://issues.apache.org/jira/browse/SOLR-17332 > Project: Solr > Issue Type: Sub-task > Components: cli, documentation >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0) > > Time Spent: 40m > Remaining Estimate: 0h > > Still mentions of post.jar through the docs and build files in main. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17332) Remove last vestiges of post.jar from main
[ https://issues.apache.org/jira/browse/SOLR-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17855079#comment-17855079 ] Eric Pugh commented on SOLR-17332: -- Documentation changes on both main and branch_9x. Removing the post.jar build tooling JUST on main. > Remove last vestiges of post.jar from main > -- > > Key: SOLR-17332 > URL: https://issues.apache.org/jira/browse/SOLR-17332 > Project: Solr > Issue Type: Sub-task > Components: cli, documentation >Reporter: Eric Pugh >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > Still mentions of post.jar through the docs and build files in main. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17332) Remove last vestiges of post.jar from main
[ https://issues.apache.org/jira/browse/SOLR-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854779#comment-17854779 ] Eric Pugh commented on SOLR-17332: -- * SOLR-17159: Remove deprecated bin/post and bin/postlogs scripts in favour of bin/solr equivalents. (Eric Pugh) I don't use the post.jar directly, so didn't mention it in the changelog.. Do you want me to amend the CHANGES.txt for SOLR-17159 to mention explicitly "post.jar"? > Remove last vestiges of post.jar from main > -- > > Key: SOLR-17332 > URL: https://issues.apache.org/jira/browse/SOLR-17332 > Project: Solr > Issue Type: Sub-task > Components: cli, documentation >Reporter: Eric Pugh >Priority: Minor > > Still mentions of post.jar through the docs and build files in main. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17332) Remove last vestiges of post.jar from main
Eric Pugh created SOLR-17332: Summary: Remove last vestiges of post.jar from main Key: SOLR-17332 URL: https://issues.apache.org/jira/browse/SOLR-17332 Project: Solr Issue Type: Sub-task Components: cli, documentation Reporter: Eric Pugh Still mentions of post.jar through the docs and build files in main. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17315) Bug in messaging when creating a collection, and then you can't actually call the config method to set-user-property
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17315.
--
Fix Version/s: 9.7
Resolution: Fixed
> Bug in messaging when creating a collection, and then you can't actually call
> the config method to set-user-property
>
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17109) solr.sharedLib should be explicitly added to the security policy with read access
[ https://issues.apache.org/jira/browse/SOLR-17109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17109. -- Fix Version/s: 9.7 Resolution: Fixed thanks! > solr.sharedLib should be explicitly added to the security policy with read > access > - > > Key: SOLR-17109 > URL: https://issues.apache.org/jira/browse/SOLR-17109 > Project: Solr > Issue Type: Improvement > Components: security >Reporter: Tomas Eduardo Fernandez Lobbe >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.7 > > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17327) Update bats test to remove /solr from solr Urls.
Eric Pugh created SOLR-17327: Summary: Update bats test to remove /solr from solr Urls. Key: SOLR-17327 URL: https://issues.apache.org/jira/browse/SOLR-17327 Project: Solr Issue Type: Sub-task Components: cli Reporter: Eric Pugh For all the bats tests Except where it matters, remove the /solr context path from the various --solr-url's. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16875) Resolve Fate of bin/post and the SimplePostTool code base.
[ https://issues.apache.org/jira/browse/SOLR-16875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-16875: Assignee: Eric Pugh > Resolve Fate of bin/post and the SimplePostTool code base. > -- > > Key: SOLR-16875 > URL: https://issues.apache.org/jira/browse/SOLR-16875 > Project: Solr > Issue Type: Sub-task > Components: cli >Affects Versions: main (10.0) >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > > Following up from SOLR-6994, we still generate a post.jar as a separate > artifact, and we now have competing PostTool.java and SimplePostTool.java. > Get consensus on the future of the post.jar in 10x? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17109) solr.sharedLib should be explicitly added to the security policy with read access
[ https://issues.apache.org/jira/browse/SOLR-17109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17109: Assignee: Eric Pugh > solr.sharedLib should be explicitly added to the security policy with read > access > - > > Key: SOLR-17109 > URL: https://issues.apache.org/jira/browse/SOLR-17109 > Project: Solr > Issue Type: Improvement > Components: security >Reporter: Tomas Eduardo Fernandez Lobbe >Assignee: Eric Pugh >Priority: Minor > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17322) Make RankQuery.getTopDocsCollector use covariant generic types
[
https://issues.apache.org/jira/browse/SOLR-17322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853188#comment-17853188
]
Eric Pugh commented on SOLR-17322:
--
I am hoping someone besides me with stronger opinions can review this PR. It
looks "fine" to me, but I probably dont' understand this area very well...
> Make RankQuery.getTopDocsCollector use covariant generic types
> --
>
> Key: SOLR-17322
> URL: https://issues.apache.org/jira/browse/SOLR-17322
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 9.0, 9.1, 9.2, 9.1.1, 9.3, 9.2.1, 9.4, 9.5, 9.4.1, 9.6,
> 9.6.1
>Reporter: Stephen Woods
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, rank queries can only use TopDocsCollectors that operate on
> ScoreDocs.
> TopDocsCollector has a class signature of:
> {code:java}
> public abstract class TopDocsCollector implements
> Collector {code}
> It contains a single covariant generic type T, which allows the collection of
> not only ScoreDocs, but subclasses of ScoreDocs as well (in the event
> additional information needs to be collected per document during the
> collection process).
> SOLR-15385 involved a large commit that removed raw types from much of the
> Solr code base. As part of that work, RankQuery was modified so that the
> getTopDocsCollector method no longer returns a raw TopDocsCollector but
> instead returns a TopDocsCollector of invariant ScoreDocs. Unfortunately, by
> doing so, it is no longer possible to use custom TopDocsCollectors that
> operate on types that extend ScoreDoc in rank queries; they _only_ work with
> ScoreDocs. Any attempt to use a class other than ScoreDoc will result in a
> compilation error.
> The fix for this issue is very simple: Modify the method signature from:
> {code:java}
> public abstract TopDocsCollector getTopDocsCollector(
> int len, QueryCommand cmd, IndexSearcher searcher) throws IOException;
> {code}
> to
> {code:java}
> public abstract TopDocsCollector getTopDocsCollector(
> int len, QueryCommand cmd, IndexSearcher searcher) throws IOException;
> {code}
> The call site for this method, within
> SolrIndexSearcher.buildTopDocsCollector, already uses this type signature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17313) Remove Deprecated SolrLogPostTool
[ https://issues.apache.org/jira/browse/SOLR-17313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17313. -- Fix Version/s: main (10.0) Resolution: Fixed > Remove Deprecated SolrLogPostTool > - > > Key: SOLR-17313 > URL: https://issues.apache.org/jira/browse/SOLR-17313 > Project: Solr > Issue Type: Task > Components: cli >Affects Versions: main (10.0) >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0) > > Time Spent: 20m > Remaining Estimate: 0h > > A follow up to SOLR-16883 is to finish removing from 10x the deprecated code. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17315) Bug in messaging when creating a collection, and then you can't actually call the config method to set-user-property
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17315:
Assignee: Eric Pugh
> Bug in messaging when creating a collection, and then you can't actually call
> the config method to set-user-property
>
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17304) PKG_VERSIONS not honored when loading the schema plugins
[ https://issues.apache.org/jira/browse/SOLR-17304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17304: Assignee: Eric Pugh > PKG_VERSIONS not honored when loading the schema plugins > > > Key: SOLR-17304 > URL: https://issues.apache.org/jira/browse/SOLR-17304 > Project: Solr > Issue Type: Bug > Components: Package Manager >Affects Versions: 9.6 >Reporter: Andrey Bozhko >Assignee: Eric Pugh >Priority: Minor > Time Spent: 2h 50m > Remaining Estimate: 0h > > If the schema references plugin classes from the package uploaded to the > package store, Solr always uses the latest version of the package when > loading the schema even if the constraint is specified in params.json. > Steps to reproduce > 1. Upload multiple versions of the same package to Solr (the versions don't > have to be compatible with each other) > 2. Upload a configset which requests a specific package version via > PKG_VERSIONS in params.json > 3. Create a collection using the uploaded configset > Expected behavior > - If the configsets references custom classes from the package, then Solr > uses the package version constraint from params.json to initialize all the > plugins mentioned in `solrconfig.xml` and `schema.xml` > Actual behavior > - Solr uses the package version specified in params.json only for loading > the `solrconfig.xml` plugins > - For `schema.xml` plugins (field types, token filters, similarities, etc.) > Solr always goes for the latest available package version, regardless of what > was specified in params.json > Test that reproduces the issue: [https://github.com/apache/solr/pull/2471]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17304) PKG_VERSIONS not honored when loading the schema plugins
[ https://issues.apache.org/jira/browse/SOLR-17304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17304. -- Fix Version/s: 9.7 Resolution: Fixed Thank you! > PKG_VERSIONS not honored when loading the schema plugins > > > Key: SOLR-17304 > URL: https://issues.apache.org/jira/browse/SOLR-17304 > Project: Solr > Issue Type: Bug > Components: Package Manager >Affects Versions: 9.6 >Reporter: Andrey Bozhko >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.7 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > If the schema references plugin classes from the package uploaded to the > package store, Solr always uses the latest version of the package when > loading the schema even if the constraint is specified in params.json. > Steps to reproduce > 1. Upload multiple versions of the same package to Solr (the versions don't > have to be compatible with each other) > 2. Upload a configset which requests a specific package version via > PKG_VERSIONS in params.json > 3. Create a collection using the uploaded configset > Expected behavior > - If the configsets references custom classes from the package, then Solr > uses the package version constraint from params.json to initialize all the > plugins mentioned in `solrconfig.xml` and `schema.xml` > Actual behavior > - Solr uses the package version specified in params.json only for loading > the `solrconfig.xml` plugins > - For `schema.xml` plugins (field types, token filters, similarities, etc.) > Solr always goes for the latest available package version, regardless of what > was specified in params.json > Test that reproduces the issue: [https://github.com/apache/solr/pull/2471]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17137) Prometheus-exporter support SSL on Solr standalone
[ https://issues.apache.org/jira/browse/SOLR-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17137. -- Fix Version/s: 9.7 Assignee: Eric Pugh Resolution: Fixed > Prometheus-exporter support SSL on Solr standalone > -- > > Key: SOLR-17137 > URL: https://issues.apache.org/jira/browse/SOLR-17137 > Project: Solr > Issue Type: Improvement > Components: contrib - prometheus-exporter >Affects Versions: 9.4.1 >Reporter: Eivind Bergtøl >Assignee: Eric Pugh >Priority: Major > Fix For: 9.7 > > Time Spent: 3.5h > Remaining Estimate: 0h > > If you enable TLS on Solr, the promethes-exporter cannot fetch metrics. It > should be configured with SSLContext in Http2SolrClient builder -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17318) bin/solr version should take a -z or -s and return actual version.
Eric Pugh created SOLR-17318:
Summary: bin/solr version should take a -z or -s and return actual
version.
Key: SOLR-17318
URL: https://issues.apache.org/jira/browse/SOLR-17318
Project: Solr
Issue Type: Sub-task
Components: cli
Reporter: Eric Pugh
Sourced from [https://github.com/apache/solr/pull/1768#issuecomment-2142193420]
Now that {{bin/solr}} supports a remote Solr cluster with {{{}--solr-url{}}}.
We currently support {{solr version}} which prints the version from
{{{}SolrVersion.java{}}}, i.e. the client version. However, if you run the tool
towards a remote solr with a different version, you won't see that.
So I wonder if {{solr --version}} should be the tool version, but {{solr
version --solr-url http://foo.bar/solr/}} should call the backend to ask for
its version.
Maybe have solr/version ALSO report the version of Solr the CLI was built with.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17316) SolrResponseBase getters should work with all ResponseParsers
[ https://issues.apache.org/jira/browse/SOLR-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850726#comment-17850726 ] Eric Pugh commented on SOLR-17316: -- I wonder if we would do better to either fix the issues (and introduce the testing to verify it across all the wt's) or remove the methods from the base? As a user, I would assume that I could swap from binary to json and my Java code would continue to work! It would be quite a surprise to get a ClassCastExeception. Thinking aloud, but what if we throw a Exception that signals more clearly the issue? "ResponseFormatDoesntSupportThisMethod" ? > SolrResponseBase getters should work with all ResponseParsers > -- > > Key: SOLR-17316 > URL: https://issues.apache.org/jira/browse/SOLR-17316 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: main (10.0), 9.6.1 >Reporter: Jason Gerlowski >Priority: Minor > > SolrJ's SolrResponseBase has several "getter" methods that give users a > syntactic sugar for accessing common response properties (such as the > response header's "status" field). These methods are useful, but make > certain Java class/type assumptions that only hold for some of Solr's > ResponseParsers. > For example, "SolrResponseBase.getResponseHeader" returns a NamedList - which > is correct when the default "BinaryResponseParser" is used, but will cause a > ClassCastException when used with other parsers (e.g. JsonMapResponseParser) > We have a few options for how to remedy this: > 1. Make these SolrResponseBase methods a little more flexible in the types > they return and the variety of types they can handle as they walk the > response NamedList > 2. Try to align all ResponseParser implementations around using types > similarly. > 3. If (1) and (2) are infeasible, we could at least add Javadocs to these > SolrResponseBase methods to indicate that they may throw CCE, and that > they're only guaranteed to work with the BinaryResponseParser. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17315) Bug in messaging when creating a collection, and then you can't actually call the config method to set-user-property
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-17315:
-
Summary: Bug in messaging when creating a collection, and then you can't
actually call the config method to set-user-property (was: Bug in messaging
when creating a collection)
> Bug in messaging when creating a collection, and then you can't actually call
> the config method to set-user-property
>
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17315) Bug in messaging when creating a collection
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-17315:
-
Affects Version/s: 9.6
(was: main (10.0))
> Bug in messaging when creating a collection
> ---
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.6
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17315) Bug in messaging when creating a collection
[
https://issues.apache.org/jira/browse/SOLR-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850450#comment-17850450
]
Eric Pugh commented on SOLR-17315:
--
With the default docker-compose for solr cloud from
[https://solr.apache.org/guide/solr/latest/deployment-guide/solr-in-docker.html#docker-compose]
run docker exec dev-solr-1 solr create -c stuff and then docker exec dev-solr-1
solr config -c stuff -action set-user-property -property
update.autoCreateFields -value false
> Bug in messaging when creating a collection
> ---
>
> Key: SOLR-17315
> URL: https://issues.apache.org/jira/browse/SOLR-17315
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0)
>Reporter: Eric Pugh
>Priority: Minor
>
> I made a collection, and noticed the default message doesn't format properly:
>
> {{{
> bin/solr create -c stuff
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
> http://localhost:8983.
> WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
> creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
> Zookeeper nodes
> WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
> Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
> 'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
> WARNING: Using _default configset. Data driven schema functionality is
> enabled by default, which is
> NOT RECOMMENDED for production use.
> To turn it off:
> curl http://localhost:8983/null/config -d '\{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> Or:
> bin/solr config -c null -p 8983 -action set-user-property
> -property update.autoCreateFields -value false
> }}}
>
> -c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17315) Bug in messaging when creating a collection
Eric Pugh created SOLR-17315:
Summary: Bug in messaging when creating a collection
Key: SOLR-17315
URL: https://issues.apache.org/jira/browse/SOLR-17315
Project: Solr
Issue Type: Sub-task
Components: cli
Affects Versions: main (10.0)
Reporter: Eric Pugh
I made a collection, and noticed the default message doesn't format properly:
{{{
bin/solr create -c stuff
Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
http://localhost:8983.
Neither -zkHost or -solrUrl parameters provided so assuming solrUrl is
http://localhost:8983.
WARN - 2024-05-29 13:48:32.981; org.apache.solr.common.cloud.SolrZkClient;
Using default ZkCredentialsInjector. ZkCredentialsInjector is not secure, it
creates an empty list of credentials which leads to 'OPEN_ACL_UNSAFE' ACLs to
Zookeeper nodes
WARN - 2024-05-29 13:48:33.049; org.apache.solr.common.cloud.SolrZkClient;
Using default ZkACLProvider. DefaultZkACLProvider is not secure, it creates
'OPEN_ACL_UNSAFE' ACLs to Zookeeper nodes
WARNING: Using _default configset. Data driven schema functionality is enabled
by default, which is
NOT RECOMMENDED for production use.
To turn it off:
curl http://localhost:8983/null/config -d '\{"set-user-property":
{"update.autoCreateFields":"false"}}'
Or:
bin/solr config -c null -p 8983 -action set-user-property -property
update.autoCreateFields -value false
}}}
-c null is wrong. Also, on main, the -p didn't work!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17313) Remove Deprecated SolrLogPostTool
Eric Pugh created SOLR-17313: Summary: Remove Deprecated SolrLogPostTool Key: SOLR-17313 URL: https://issues.apache.org/jira/browse/SOLR-17313 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: cli Affects Versions: main (10.0) Reporter: Eric Pugh Assignee: Eric Pugh A follow up to SOLR-16883 is to finish removing from 10x the deprecated code. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17247.
--
Fix Version/s: 9.7
Resolution: Fixed
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17247) 'WWW-Authenticate' headers missing in MultiAuthPlugin
[
https://issues.apache.org/jira/browse/SOLR-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17247:
Assignee: Eric Pugh
> 'WWW-Authenticate' headers missing in MultiAuthPlugin
> -
>
> Key: SOLR-17247
> URL: https://issues.apache.org/jira/browse/SOLR-17247
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Lamine
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> MultiAuthPlugin does not return WWW-Authenticate' headers
> When returning a 401 response a Web application needs to indicate to the
> client what authentication challenges it supports, otherwise an exception
> like "{_}HTTP protocol violation: Authentication challenge without
> WWW-Authenticate header{_}“ is raised.
> Solr’s MultiAuthPlugin does not supports this. Solr should return the list
> of supported schemes (challenges).
>
> According to HTTP [RFC
> 7235|https://datatracker.ietf.org/doc/html/rfc7235#section-3.1]:
> _The 401 (Unauthorized) status code indicates that the request has not_
> _been applied because it lacks valid authentication credentials for_
> _the target resource. The server generating a 401 response *MUST* send_
> _a WWW-Authenticate header field ([Section
> 4.1|https://datatracker.ietf.org/doc/html/rfc7235#section-4.1]) containing at
> least one_
> _challenge applicable to the target resource._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849458#comment-17849458
]
Eric Pugh commented on SOLR-14673:
--
I've opened up a draft PR to bring the patch file up to date and use SolrCLI.
In my mind, I was thinking a command might look like:
bin/solr stream echo(hello)
and you would run that streaming expression. How ever, maybe what the patch
expects is a
bin/solr stream myexpression.expr
and the myexpression.expr would contain the text "echo(hello)" ??
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Eric Pugh
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-14673:
Assignee: Eric Pugh (was: Joel Bernstein)
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Eric Pugh
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17284) Remove deprecated Blobapi and runtime lib
[ https://issues.apache.org/jira/browse/SOLR-17284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17284. -- Fix Version/s: main (10.0) Assignee: Eric Pugh Resolution: Fixed Removed BlobRepository. FYI SchemaDesigner uses BlobHandler, which is backed by magic .system collection. > Remove deprecated Blobapi and runtime lib > - > > Key: SOLR-17284 > URL: https://issues.apache.org/jira/browse/SOLR-17284 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Fix For: main (10.0) > > Time Spent: 3h 10m > Remaining Estimate: 0h > > In SOLR-14072 we decided to deprecate the blob repository and remove in 9. > This is to investigate this removal. One thing to keep in mind is the > Schema Designer assumes a .system collection. Does this intersect? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16659) DistribPackageStore.distribute may alter node name
[
https://issues.apache.org/jira/browse/SOLR-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849086#comment-17849086
]
Eric Pugh commented on SOLR-16659:
--
Thanks for reporting this ticket and now we have a more general cleanup!
> DistribPackageStore.distribute may alter node name
> --
>
> Key: SOLR-16659
> URL: https://issues.apache.org/jira/browse/SOLR-16659
> Project: Solr
> Issue Type: Bug
> Components: Package Manager
>Affects Versions: 9.1.1
>Reporter: def onion
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This bug occurs when using the package manager in solr cloud mode with solr
> nodes that have a node name starting with "solr".
> The [distribute
> |https://github.com/apache/solr/blob/08e4591fd7f6f92c3dc42b4b1f334a960358fa4e/solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java#L365]method
> in the DistribPackageStore alters the URL of the solr nodes by replacing the
> string "/solr" with "/api". This can lead to wrong host names of solr nodes,
> e.g. "http://solr-2.solrcluster:8983; is changed to
> "http://api-2.solrcluster:8983":
> {code:java}
> 2023-02-15 09:34:29.049 ERROR (qtp35984028-19) [] o.a.s.c.u.Utils Error in
> request to url :
> http://api-2.solrcluster:8983/api/node/files/_trusted_/keys/store-key?getFrom=solr-0.solrcluster:8983_solr
> => java.net.UnknownHostException: api-2.solrcluster
> at java.base/java.net.InetAddress$CachedAddresses.get(Unknown Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16659) DistribPackageStore.distribute may alter node name
[
https://issues.apache.org/jira/browse/SOLR-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-16659.
--
Fix Version/s: main (10.0)
9.7
Resolution: Fixed
> DistribPackageStore.distribute may alter node name
> --
>
> Key: SOLR-16659
> URL: https://issues.apache.org/jira/browse/SOLR-16659
> Project: Solr
> Issue Type: Bug
> Components: Package Manager
>Affects Versions: 9.1.1
>Reporter: def onion
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: main (10.0), 9.7
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This bug occurs when using the package manager in solr cloud mode with solr
> nodes that have a node name starting with "solr".
> The [distribute
> |https://github.com/apache/solr/blob/08e4591fd7f6f92c3dc42b4b1f334a960358fa4e/solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java#L365]method
> in the DistribPackageStore alters the URL of the solr nodes by replacing the
> string "/solr" with "/api". This can lead to wrong host names of solr nodes,
> e.g. "http://solr-2.solrcluster:8983; is changed to
> "http://api-2.solrcluster:8983":
> {code:java}
> 2023-02-15 09:34:29.049 ERROR (qtp35984028-19) [] o.a.s.c.u.Utils Error in
> request to url :
> http://api-2.solrcluster:8983/api/node/files/_trusted_/keys/store-key?getFrom=solr-0.solrcluster:8983_solr
> => java.net.UnknownHostException: api-2.solrcluster
> at java.base/java.net.InetAddress$CachedAddresses.get(Unknown Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16659) DistribPackageStore.distribute may alter node name
[
https://issues.apache.org/jira/browse/SOLR-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-16659:
Assignee: Eric Pugh (was: Ishan Chattopadhyaya)
> DistribPackageStore.distribute may alter node name
> --
>
> Key: SOLR-16659
> URL: https://issues.apache.org/jira/browse/SOLR-16659
> Project: Solr
> Issue Type: Bug
> Components: Package Manager
>Affects Versions: 9.1.1
>Reporter: def onion
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> This bug occurs when using the package manager in solr cloud mode with solr
> nodes that have a node name starting with "solr".
> The [distribute
> |https://github.com/apache/solr/blob/08e4591fd7f6f92c3dc42b4b1f334a960358fa4e/solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java#L365]method
> in the DistribPackageStore alters the URL of the solr nodes by replacing the
> string "/solr" with "/api". This can lead to wrong host names of solr nodes,
> e.g. "http://solr-2.solrcluster:8983; is changed to
> "http://api-2.solrcluster:8983":
> {code:java}
> 2023-02-15 09:34:29.049 ERROR (qtp35984028-19) [] o.a.s.c.u.Utils Error in
> request to url :
> http://api-2.solrcluster:8983/api/node/files/_trusted_/keys/store-key?getFrom=solr-0.solrcluster:8983_solr
> => java.net.UnknownHostException: api-2.solrcluster
> at java.base/java.net.InetAddress$CachedAddresses.get(Unknown Source)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17279) consolidate security.json constants in test code
[ https://issues.apache.org/jira/browse/SOLR-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848743#comment-17848743 ] Eric Pugh commented on SOLR-17279: -- [~sanjaydutt] so I looked and I was only going to make this change on main, and not back port it. Mostly because many of the places it touched are around security for the SolrCLI commands, and supporting basic auth is a 10x feature that we never backported that feature to 9x. There are days I regret that decision. > consolidate security.json constants in test code > > > Key: SOLR-17279 > URL: https://issues.apache.org/jira/browse/SOLR-17279 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Rudi Seitz >Assignee: Eric Pugh >Priority: Trivial > Fix For: main (10.0) > > Time Spent: 50m > Remaining Estimate: 0h > > Various unit tests declare a SECURITY_JSON constant. Maybe of these constants > are identical (likely introduced via copy/paste from other tests, resulting > in code duplication). This ticket is to consolidate the various SECURITY_JSON > constants across the tests in a central place. > This point was raised during discussion of the fix for SOLR-12813. See > https://github.com/apache/solr/pull/2404#discussion_r1568012056 > In that discussion, it was agreed to address SECURITY_JSON consolidation in a > separate ticket -- this is that ticket. > Tagging [~epugh] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17279) consolidate security.json constants in test code
[ https://issues.apache.org/jira/browse/SOLR-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848643#comment-17848643 ] Eric Pugh commented on SOLR-17279: -- Thanks for flagging this... Let me look again at why i didn't backport immediately.. it may have been some conflicts... > consolidate security.json constants in test code > > > Key: SOLR-17279 > URL: https://issues.apache.org/jira/browse/SOLR-17279 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Rudi Seitz >Assignee: Eric Pugh >Priority: Trivial > Fix For: main (10.0) > > Time Spent: 50m > Remaining Estimate: 0h > > Various unit tests declare a SECURITY_JSON constant. Maybe of these constants > are identical (likely introduced via copy/paste from other tests, resulting > in code duplication). This ticket is to consolidate the various SECURITY_JSON > constants across the tests in a central place. > This point was raised during discussion of the fix for SOLR-12813. See > https://github.com/apache/solr/pull/2404#discussion_r1568012056 > In that discussion, it was agreed to address SECURITY_JSON consolidation in a > separate ticket -- this is that ticket. > Tagging [~epugh] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17306) Solr Repeater or Slave loses data after restart when replication is not enabled on leader
[
https://issues.apache.org/jira/browse/SOLR-17306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848580#comment-17848580
]
Eric Pugh commented on SOLR-17306:
--
Could you put together a reproducible bats style test that demonstrates this
behavior? For inspiration, look at [https://github.com/apache/solr/pull/1875]
as an example.
> Solr Repeater or Slave loses data after restart when replication is not
> enabled on leader
> -
>
> Key: SOLR-17306
> URL: https://issues.apache.org/jira/browse/SOLR-17306
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.2, 9.3, 9.4, 9.6, 9.5.0
>Reporter: Peter Kroiss
>Priority: Major
>
> We are testing Solr 9.6.2 in a leader - repeater - follower configuration. We
> have times where we write the leader heavily, in that time replication is
> disabled to save bandwidth.
> In the time, when replication is disabled on leader, the repeater restarts
> for some reason, the repeater loses all documents and doesn't recover when
> the leader is opened for replication.
> The documents are deleted but indexVersion and generation properties are set
> to the value of the leader, so the repeater or follower doesn't recover when
> the leader is opened for replication again.
> It recovers only when there are commits on the leader after opening the
> replication.
> Log:
> 2024-05-22 06:18:42.186 INFO (qtp16373883-27-null-23) [c: s: r: x:mycore
> t:null-23] o.a.s.c.S.Request webapp=/solr path=/replication
> params=\{wt=json=details} status=0 QTime=10
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's generation: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Leader's version: 0
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's generation: 2913
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher Follower's version: 1716300697144
> 2024-05-22 06:18:46.195 INFO (indexFetcher-43-thread-1) [c: s: r: x:mycore
> t:] o.a.s.h.IndexFetcher New index in Leader. Deleting mine...
>
> --> there is no new Index in Leader it is only closed for replication
>
>
> We think the problem is in IndexFetcher
> old: if (IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
> forceReplication - will probably fix the problem
> new : if (forceReplication &&
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) != 0L) {
>
>
>
>
> When investigation the problem we also found some inconsistencies in the
> details request. There are two fragments leader. When the leader is closed
> for replication the property leader. replicationEnabled is set to true, the
> property follower. leaderDetails. Leader. replicationEnabled is correct.
>
> Example
> curl -s
> "https://solr9-repeater:8983/solr/mycore/replication?wt=json=details;
> | jq '.details |
> { indexSize: .indexSize, indexVersion: .indexVersion, generation:
> .generation, indexPath: .indexPath, leader: \\{ replicableVersion:
> .leader.replicableVersion, replicableGeneration:
> .leader.replicableGeneration, replicationEnabled: .leader.replicationEnabled }
> ,
> follower: { leaderDetails: { indexSize: .follower.leaderDetails.indexSize,
> generation: .follower.leaderDetails.generation,
> indexVersion: .follower.leaderDetails.indexVersion, indexPath:
> .follower.leaderDetails.indexPath,
> leader:
> { replicableVersion: .follower.leaderDetails.leader.replicableVersion ,
> replicableGeneration: .follower.leaderDetails.leader.replicableGeneration,
> replicationEnabled: .follower.leaderDetails.leader.replicationEnabled }
> }}
> }'
>
> {
> "indexSize": "10.34 GB",
> "indexVersion": 1716358708159,
> "generation": 2913,
> "indexPath": "/var/solr/data/mycore/data/index.20240522061946262",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration": 2913,
> "replicationEnabled": "true" }
> ,
> "follower": {
> "leaderDetails": {
> "indexSize": "10.34 GB",
> "generation": 2913,
> "indexVersion": 1716358708159,
> "indexPath": "/var/solr/data/mycore/data/restore.20240508131046932",
> "leader":
> { "replicableVersion": 1716358708159, "replicableGeneration":
> 2913, "replicationEnabled": "false" }
> }
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail:
[jira] [Commented] (SOLR-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846679#comment-17846679
]
Eric Pugh commented on SOLR-14673:
--
I am poking around at the patch file to see if I can understand it ;)
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846047#comment-17846047
]
Eric Pugh commented on SOLR-17263:
--
I *think* that if we know we are doing a 9.6.1, then you could just do it there
under them all? Otherwise, what James said!
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17279) consolidate security.json constants in test code
[ https://issues.apache.org/jira/browse/SOLR-17279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17279. -- Fix Version/s: main (10.0) Assignee: Eric Pugh Resolution: Fixed > consolidate security.json constants in test code > > > Key: SOLR-17279 > URL: https://issues.apache.org/jira/browse/SOLR-17279 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Tests >Reporter: Rudi Seitz >Assignee: Eric Pugh >Priority: Trivial > Fix For: main (10.0) > > Time Spent: 50m > Remaining Estimate: 0h > > Various unit tests declare a SECURITY_JSON constant. Maybe of these constants > are identical (likely introduced via copy/paste from other tests, resulting > in code duplication). This ticket is to consolidate the various SECURITY_JSON > constants across the tests in a central place. > This point was raised during discussion of the fix for SOLR-12813. See > https://github.com/apache/solr/pull/2404#discussion_r1568012056 > In that discussion, it was agreed to address SECURITY_JSON consolidation in a > separate ticket -- this is that ticket. > Tagging [~epugh] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17284) Remove deprecated Blobapi and runtime lib
Eric Pugh created SOLR-17284: Summary: Remove deprecated Blobapi and runtime lib Key: SOLR-17284 URL: https://issues.apache.org/jira/browse/SOLR-17284 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Eric Pugh In SOLR-14072 we decided to deprecate the blob repository and remove in 9. This is to investigate this removal. One thing to keep in mind is the Schema Designer assumes a .system collection. Does this intersect? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17282. -- Fix Version/s: 9.7 Resolution: Fixed thank you for your attention to detail! > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Assignee: Eric Pugh >Priority: Major > Fix For: 9.7 > > Time Spent: 20m > Remaining Estimate: 0h > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17282) Update basic-authentication-plugin.adoc
[ https://issues.apache.org/jira/browse/SOLR-17282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17282: Assignee: Eric Pugh > Update basic-authentication-plugin.adoc > --- > > Key: SOLR-17282 > URL: https://issues.apache.org/jira/browse/SOLR-17282 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: guoshipneg >Assignee: Eric Pugh >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > As I was reading through this documentation, I noticed a problem with the > encryption section, as follows: > (Format: base64(sha256(sha256(salt+password)) base64(salt)), so I started to > think that I have to use base64 to encrypt the whole content of the back of > the encryption, but in fact it's not true, there is a ')' missing, it should > be like this base64(sha256(sha256( salt+password))) base64(salt), so that the > result of the separate encryption can be used. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17278) Timezone with DST=true and DST=0 fails test
[
https://issues.apache.org/jira/browse/SOLR-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844277#comment-17844277
]
Eric Pugh commented on SOLR-17278:
--
I think this commit broke errorprone? I am seeing:
Task :solr:core:compileTestJava FAILED
/home/runner/work/solr/solr/solr/core/src/test/org/apache/solr/util/TimeZoneUtilsTest.java:65:
warning: [OperatorPrecedence] Use grouping parenthesis to make the operator
precedence explicit
if (expected.useDaylightTime() && expected.getDSTSavings() == 0
^
(see [https://errorprone.info/bugpattern/OperatorPrecedence)]
Did you mean 'if ((expected.useDaylightTime() && expected.getDSTSavings() ==
0)'?
/home/runner/work/solr/solr/solr/core/src/test/org/apache/solr/util/TimeZoneUtilsTest.java:66:
warning: [OperatorPrecedence] Use grouping parenthesis to make the operator
precedence explicit
|| actual.useDaylightTime() && actual.getDSTSavings() == 0) {
^
(see [https://errorprone.info/bugpattern/OperatorPrecedence)]
Did you mean '|| (actual.useDaylightTime() && actual.getDSTSavings() == 0))
{'?
error: warnings found and -Werror specified
> Timezone with DST=true and DST=0 fails test
> ---
>
> Key: SOLR-17278
> URL: https://issues.apache.org/jira/browse/SOLR-17278
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.7
>
> Attachments: SOLR-17278-1.patch, SOLR-17278.patch
>
>
> The TimeZoneUtilsTest#testValidIds() fails with some timezones that have
> useDaylightTime() as true but getDSTSavings() returns 0. Such timezones can't
> be converted to String using String.valueOf().
> Here's my JVM:
> {code}
> [ishan@deskmini solr] $ java -version
> openjdk version "11.0.22" 2024-01-16
> OpenJDK Runtime Environment (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7)
> OpenJDK 64-Bit Server VM (Red_Hat-11.0.22.0.7-1) (build 11.0.22+7, mixed
> mode, sharing)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-14115) Deprecate zkcli.sh
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-14115: - Fix Version/s: main (10.0) > Deprecate zkcli.sh > -- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Assignee: Eric Pugh >Priority: Major > Fix For: main (10.0), 9.7 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-14115) Deprecate zkcli.sh
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-14115. -- Fix Version/s: 9.7 Resolution: Fixed > Deprecate zkcli.sh > -- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Assignee: Eric Pugh >Priority: Major > Fix For: 9.7 > > Time Spent: 50m > Remaining Estimate: 0h > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-16921) Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
[
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-16921.
--
Fix Version/s: 9.7
Resolution: Fixed
> Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
> -
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.7
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a message like:
> if (zkHost == null) {
> throw new IllegalStateException(
> "Solr at "
> + cli.getOptionValue("solrUrl")
> + " is running in standalone server mode, upconfig can only be
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..
> Although, why not???
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16921) Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
[
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh updated SOLR-16921:
-
Summary: Use -solrUrl to derive the zk host connection for bin/solr zk
subcommands (was: bin/solr upconfig and downconfig reference solrUrl but don't
list it as option!)
> Use -solrUrl to derive the zk host connection for bin/solr zk subcommands
> -
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have a message like:
> if (zkHost == null) {
> throw new IllegalStateException(
> "Solr at "
> + cli.getOptionValue("solrUrl")
> + " is running in standalone server mode, upconfig can only be
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..
> Although, why not???
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-12813) SolrCloud + 2 shards + subquery + auth = 401 Exception
[
https://issues.apache.org/jira/browse/SOLR-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-12813.
--
Fix Version/s: 9.7
Assignee: Eric Pugh
Resolution: Fixed
> SolrCloud + 2 shards + subquery + auth = 401 Exception
> --
>
> Key: SOLR-12813
> URL: https://issues.apache.org/jira/browse/SOLR-12813
> Project: Solr
> Issue Type: Bug
> Components: security, SolrCloud
>Affects Versions: 6.4.1, 7.5, 8.11
>Reporter: Igor Fedoryn
>Assignee: Eric Pugh
>Priority: Major
> Fix For: 9.7
>
> Attachments: screen1.png, screen2.png
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Environment: * Solr 6.4.1
> * Zookeeper 3.4.6
> * Java 1.8
> Run Zookeeper
> Upload simple configuration wherein the Solr schema has fields for a
> relationship between parent/child
> Run two Solr instance (2 nodes)
> Create the collection with 1 shard on each Solr nodes
>
> Add parent document to one shard and child document to another shard.
> The response for: *
> /select?q=ChildIdField:VALUE=*,parents:[subqery]=\{!term f=id
> v=$row.ParentIdsField}
> correct.
>
> After that add Basic Authentication with some user for collection.
> Restart Solr or reload Solr collection.
> If the simple request /select?q=*:* with authorization on Solr server is a
> success then run previously request
> with authorization on Solr server and you get the exception: "Solr HTTP
> error: Unauthorized (401) "
>
> Screens in the attachment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17248) Refactor ZK related SolrCli tools to separate SolrZkClient and CloudSolrClient instantiation/usage
[ https://issues.apache.org/jira/browse/SOLR-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17248: Assignee: Eric Pugh > Refactor ZK related SolrCli tools to separate SolrZkClient and > CloudSolrClient instantiation/usage > -- > > Key: SOLR-17248 > URL: https://issues.apache.org/jira/browse/SOLR-17248 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Lamine >Assignee: Eric Pugh >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Many CLI tool-related classes currently duplicate SolrZkClient & > _CloudSolrClient_ instantiation, with the same code appearing 12 times across > 8 different classes. It would be beneficial to extract this instantiation and > reuse the code for easy maintainability > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17233) The parameters of q.op are recommended to be trim()
[ https://issues.apache.org/jira/browse/SOLR-17233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837700#comment-17837700 ] Eric Pugh commented on SOLR-17233: -- I'd be happy to review a PR for fixing this I wonder if we need to have better handling of all parameter parsing... Curious how the space got in in the very first place? > The parameters of q.op are recommended to be trim() > --- > > Key: SOLR-17233 > URL: https://issues.apache.org/jira/browse/SOLR-17233 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: ichar >Priority: Minor > Attachments: image-2024-04-16-14-46-12-603.png > > > !image-2024-04-16-14-46-12-603.png|width=301,height=265! > The expected result should be empty, but this was found out. The reason is > that the parameter "and" of q.op (with an extra space) is taken out and the > judgment of "and" is different. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17213) Don't warn users about the /solr in the url when we look it up direct from zk
[
https://issues.apache.org/jira/browse/SOLR-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17213.
--
Fix Version/s: 9.6.0
Resolution: Fixed
> Don't warn users about the /solr in the url when we look it up direct from zk
> -
>
> Key: SOLR-17213
> URL: https://issues.apache.org/jira/browse/SOLR-17213
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.5
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Fix For: 9.6.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> when you derive a solrUrl from Zookeeper -z, we warn about the trailing /solr
> in the
> SolrCLI.normalizeSolrUrl(cli){color:#cc7832}; method, we should only warn if
> it's user input, not code input.
> {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-17153) CloudSolrClient should not throw "Collection not found" with an out-dated ClusterState
[ https://issues.apache.org/jira/browse/SOLR-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834416#comment-17834416 ] Eric Pugh edited comment on SOLR-17153 at 4/5/24 7:06 PM: -- I am seeing errors in main that I think are from this commit. bin/solr start -c and then pull up the Solr Admin UI and you get an exception. ``` java.lang.IndexOutOfBoundsException: Index: 0\n\tat java.base/java.util.Collections$EmptyList.get(Collections.java:4481)\n\tat org.apache.solr.servlet.HttpSolrCall.resolveDocCollection(HttpSolrCall.java:363)\n\tat org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:286) ``` Removing this commit restores the Admin UI to loading. was (Author: epugh): I am seeing errors in main that I think are from this commit. bin/solr start -c and then pull up the Solr Admin UI and you get an exception. ``` java.lang.IndexOutOfBoundsException: Index: 0\n\tat java.base/java.util.Collections$EmptyList.get(Collections.java:4481)\n\tat org.apache.solr.servlet.HttpSolrCall.resolveDocCollection(HttpSolrCall.java:363)\n\tat org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:286) ``` > CloudSolrClient should not throw "Collection not found" with an out-dated > ClusterState > -- > > Key: SOLR-17153 > URL: https://issues.apache.org/jira/browse/SOLR-17153 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Today, CloudSolrClient will locally fail if it's asked to send a request to a > collection that it thinks does not exist due to its local ClusterState view > being out-of-date. We shouldn't fail! And most SolrCloud tests should then > remove their waitForState calls that follow collection creation! Other stale > state matters are out-of-scope. > Proposal: CloudSolrClient shouldn't try and be too smart. Always route a > request to Solr (any node); don't presume its state is up-to-date. Maybe, > after a response is received, it can check if its state has been updated and > if not then explicitly get a new state. Or not if that's too complicated. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17153) CloudSolrClient should not throw "Collection not found" with an out-dated ClusterState
[ https://issues.apache.org/jira/browse/SOLR-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834416#comment-17834416 ] Eric Pugh commented on SOLR-17153: -- I am seeing errors in main that I think are from this commit. bin/solr start -c and then pull up the Solr Admin UI and you get an exception. ``` java.lang.IndexOutOfBoundsException: Index: 0\n\tat java.base/java.util.Collections$EmptyList.get(Collections.java:4481)\n\tat org.apache.solr.servlet.HttpSolrCall.resolveDocCollection(HttpSolrCall.java:363)\n\tat org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:286) ``` > CloudSolrClient should not throw "Collection not found" with an out-dated > ClusterState > -- > > Key: SOLR-17153 > URL: https://issues.apache.org/jira/browse/SOLR-17153 > Project: Solr > Issue Type: Improvement > Components: SolrJ >Reporter: David Smiley >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > Today, CloudSolrClient will locally fail if it's asked to send a request to a > collection that it thinks does not exist due to its local ClusterState view > being out-of-date. We shouldn't fail! And most SolrCloud tests should then > remove their waitForState calls that follow collection creation! Other stale > state matters are out-of-scope. > Proposal: CloudSolrClient shouldn't try and be too smart. Always route a > request to Solr (any node); don't presume its state is up-to-date. Maybe, > after a response is received, it can check if its state has been updated and > if not then explicitly get a new state. Or not if that's too complicated. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17194) CloudHttp2SolrClient doesn't properly use httpClient Builder on certain paths
[ https://issues.apache.org/jira/browse/SOLR-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-17194: - Priority: Major (was: Minor) Summary: CloudHttp2SolrClient doesn't properly use httpClient Builder on certain paths (was: Export doesn't support basic auth) > CloudHttp2SolrClient doesn't properly use httpClient Builder on certain paths > - > > Key: SOLR-17194 > URL: https://issues.apache.org/jira/browse/SOLR-17194 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17194) Export doesn't support basic auth
[ https://issues.apache.org/jira/browse/SOLR-17194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17194: Assignee: Eric Pugh > Export doesn't support basic auth > - > > Key: SOLR-17194 > URL: https://issues.apache.org/jira/browse/SOLR-17194 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17213) Don't warn users about the /solr in the url when we look it up direct from zk
[
https://issues.apache.org/jira/browse/SOLR-17213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17213:
Assignee: Eric Pugh
> Don't warn users about the /solr in the url when we look it up direct from zk
> -
>
> Key: SOLR-17213
> URL: https://issues.apache.org/jira/browse/SOLR-17213
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: 9.5
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> when you derive a solrUrl from Zookeeper -z, we warn about the trailing /solr
> in the
> SolrCLI.normalizeSolrUrl(cli){color:#cc7832}; method, we should only warn if
> it's user input, not code input.
> {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17110) unquoted uuid values in json query response
[
https://issues.apache.org/jira/browse/SOLR-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-17110:
Assignee: Eric Pugh
> unquoted uuid values in json query response
> ---
>
> Key: SOLR-17110
> URL: https://issues.apache.org/jira/browse/SOLR-17110
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.3, 9.4
> Environment: linux, jdk 17
>Reporter: Märt
>Assignee: Eric Pugh
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Json query responses that contain UUID field values are malformed: the values
> are not properly quoted. Example:
>
> {code:java}
> "docs":[{
> "id":"1",
> "eventId":d8fa5301-4f7b-4c14-aa0e-b891e20f16f5,
> "_version_":1787085364586872832
> }] {code}
> Steps to repro:
> Unpack solr 9.4.0 and start with `{color:#00}bin/solr -f{color}`.
> Run the shell script:
>
> {code:java}
> baseurl="http://localhost:8983;
> curl -X POST
> "$baseurl/solr/admin/cores?action=CREATE&=sample=_default"
> curl -H 'Content-Type: application/json' --data-binary '{"add-field-type":
> {"name":"uuid", "class":"solr.UUIDField"}}' "$baseurl/solr/sample/schema"
> curl -H 'Content-Type: application/json' --data-binary '{"add-field":
> {"name": "eventId", "type":"uuid"}}' "$baseurl/solr/sample/schema"
> curl -H 'Content-Type: application/json' --data-binary '{"id": "1",
> "eventId": "d8fa5301-4f7b-4c14-aa0e-b891e20f16f5"}'
> "$baseurl/solr/sample/update/json/docs?commit=true"
> curl "$baseurl/solr/sample/query?q=*:*"
> {code}
> This is likely a regression from SOLR-16691.
> This was first reported in
> [https://lists.apache.org/thread/b717gcmjj92vxgq48g4ho8wct3zm4rct] and
> something was done in SOLR-10653 but it seems the issue persists. The latest
> CI build solr-9.5.0-jenkins725.tgz still reproduces.
> I reported the issue again in
> [https://lists.apache.org/thread/zfgz4oh23b3njklgjs4cqjn6p7ctz3ow] but no
> response yet.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17110) unquoted uuid values in json query response
[
https://issues.apache.org/jira/browse/SOLR-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17110.
--
Fix Version/s: 9.6.0
Resolution: Fixed
> unquoted uuid values in json query response
> ---
>
> Key: SOLR-17110
> URL: https://issues.apache.org/jira/browse/SOLR-17110
> Project: Solr
> Issue Type: Bug
>Affects Versions: 9.3, 9.4
> Environment: linux, jdk 17
>Reporter: Märt
>Assignee: Eric Pugh
>Priority: Major
> Fix For: 9.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Json query responses that contain UUID field values are malformed: the values
> are not properly quoted. Example:
>
> {code:java}
> "docs":[{
> "id":"1",
> "eventId":d8fa5301-4f7b-4c14-aa0e-b891e20f16f5,
> "_version_":1787085364586872832
> }] {code}
> Steps to repro:
> Unpack solr 9.4.0 and start with `{color:#00}bin/solr -f{color}`.
> Run the shell script:
>
> {code:java}
> baseurl="http://localhost:8983;
> curl -X POST
> "$baseurl/solr/admin/cores?action=CREATE&=sample=_default"
> curl -H 'Content-Type: application/json' --data-binary '{"add-field-type":
> {"name":"uuid", "class":"solr.UUIDField"}}' "$baseurl/solr/sample/schema"
> curl -H 'Content-Type: application/json' --data-binary '{"add-field":
> {"name": "eventId", "type":"uuid"}}' "$baseurl/solr/sample/schema"
> curl -H 'Content-Type: application/json' --data-binary '{"id": "1",
> "eventId": "d8fa5301-4f7b-4c14-aa0e-b891e20f16f5"}'
> "$baseurl/solr/sample/update/json/docs?commit=true"
> curl "$baseurl/solr/sample/query?q=*:*"
> {code}
> This is likely a regression from SOLR-16691.
> This was first reported in
> [https://lists.apache.org/thread/b717gcmjj92vxgq48g4ho8wct3zm4rct] and
> something was done in SOLR-10653 but it seems the issue persists. The latest
> CI build solr-9.5.0-jenkins725.tgz still reproduces.
> I reported the issue again in
> [https://lists.apache.org/thread/zfgz4oh23b3njklgjs4cqjn6p7ctz3ow] but no
> response yet.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17213) Don't warn users about the /solr in the url when we look it up direct from zk
Eric Pugh created SOLR-17213:
Summary: Don't warn users about the /solr in the url when we look
it up direct from zk
Key: SOLR-17213
URL: https://issues.apache.org/jira/browse/SOLR-17213
Project: Solr
Issue Type: Sub-task
Components: cli
Affects Versions: 9.5
Reporter: Eric Pugh
when you derive a solrUrl from Zookeeper -z, we warn about the trailing /solr
in the
SolrCLI.normalizeSolrUrl(cli){color:#cc7832}; method, we should only warn if
it's user input, not code input.
{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17212) Establish "Standalone" as the term for non Solr Cloud, non Embedded Solr
Eric Pugh created SOLR-17212: Summary: Establish "Standalone" as the term for non Solr Cloud, non Embedded Solr Key: SOLR-17212 URL: https://issues.apache.org/jira/browse/SOLR-17212 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Eric Pugh Assignee: Eric Pugh During a long thread discussion, it veered into "What is the right term for non embedded, non solr cloud" and the community uses the term Standalone, even though "User Managed" was the quasi official term used in Ref Guide. This ticket is to accept the will of the people, and use Standalone ;) [https://lists.apache.org/thread/shh62tkx9zwd2t76qwtksz2lgyqjw0cr] Update the ref guide, and add Standalone to the glossary. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17174) commit to mixedCase cli options or dashed-case cli options
[ https://issues.apache.org/jira/browse/SOLR-17174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830712#comment-17830712 ] Eric Pugh commented on SOLR-17174: -- Community agreed that "kebab case" was the way to go. So --zkHost becomes --zk-host. > commit to mixedCase cli options or dashed-case cli options > -- > > Key: SOLR-17174 > URL: https://issues.apache.org/jira/browse/SOLR-17174 > Project: Solr > Issue Type: Sub-task > Components: cli >Reporter: Eric Pugh >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16921) bin/solr upconfig and downconfig reference solrUrl but don't list it as option!
[
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh reassigned SOLR-16921:
Assignee: Eric Pugh
> bin/solr upconfig and downconfig reference solrUrl but don't list it as
> option!
> ---
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Assignee: Eric Pugh
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a message like:
> if (zkHost == null) {
> throw new IllegalStateException(
> "Solr at "
> + cli.getOptionValue("solrUrl")
> + " is running in standalone server mode, upconfig can only be
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..
> Although, why not???
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16921) bin/solr upconfig and downconfig reference solrUrl but don't list it as option!
[
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830492#comment-17830492
]
Eric Pugh commented on SOLR-16921:
--
It works! Always nice when a bug turns into an opportunity for an improved
user experience! I would very much appreciate it if anyone on windows could
validate the changes to bin/solr.cmd.
> bin/solr upconfig and downconfig reference solrUrl but don't list it as
> option!
> ---
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a message like:
> if (zkHost == null) {
> throw new IllegalStateException(
> "Solr at "
> + cli.getOptionValue("solrUrl")
> + " is running in standalone server mode, upconfig can only be
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..
> Although, why not???
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-12089) FileBasedSpellChecker docs have some missing params
[ https://issues.apache.org/jira/browse/SOLR-12089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830467#comment-17830467 ] Eric Pugh commented on SOLR-12089: -- We also fixed the misspelled parameter breakSugestionTieBreaker in 9x with deprecation warnings, and removed it from 10x. > FileBasedSpellChecker docs have some missing params > --- > > Key: SOLR-12089 > URL: https://issues.apache.org/jira/browse/SOLR-12089 > Project: Solr > Issue Type: Improvement > Components: documentation, spellchecker >Reporter: Varun Thacker >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.6.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > FileBasedSpellChecker has params like "fieldType" that is not documented. > I'm creating a Jira to audit the params on all the spellcheckers and make > sure they are documented in the ref guide > http://lucene.apache.org/solr/guide/spell-checking.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17209) NullPointerException in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-17209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Pugh resolved SOLR-17209.
--
Fix Version/s: 9.6.0
Assignee: Eric Pugh
Resolution: Fixed
Thank you for the fix!
> NullPointerException in QueryComponent
> --
>
> Key: SOLR-17209
> URL: https://issues.apache.org/jira/browse/SOLR-17209
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 8.6
>Reporter: Vincent Primault
>Assignee: Eric Pugh
>Priority: Major
> Fix For: 9.6.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In our production deployment of Solr, running 8.6, we see the following
> stacktrace (truncated):
> {{java.lang.NullPointerException at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:873)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:628)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:607)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16921) bin/solr upconfig and downconfig reference solrUrl but don't list it as option!
[
https://issues.apache.org/jira/browse/SOLR-16921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830129#comment-17830129
]
Eric Pugh commented on SOLR-16921:
--
I think that it may be very easy to support -solrUrl and get the zk host...
Any reason NOT to support both a -z and -s options?
> bin/solr upconfig and downconfig reference solrUrl but don't list it as
> option!
> ---
>
> Key: SOLR-16921
> URL: https://issues.apache.org/jira/browse/SOLR-16921
> Project: Solr
> Issue Type: Sub-task
> Components: cli
>Affects Versions: main (10.0), 9.3
>Reporter: Eric Pugh
>Priority: Minor
>
> We have a message like:
> if (zkHost == null) {
> throw new IllegalStateException(
> "Solr at "
> + cli.getOptionValue("solrUrl")
> + " is running in standalone server mode, upconfig can only be
> used when running in SolrCloud mode.\n");
> }
> but we don't declare the option value of solrUrl..
> Although, why not???
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-7637) Improve error logging in the zkcli CLUSTERPROP command
[ https://issues.apache.org/jira/browse/SOLR-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-7637. - Resolution: Won't Fix Closing this as we won't be fixing zkcli.sh. However, if you think this is still an issue in the bin/solr zk command in SOLR-14115 , please do speak up! > Improve error logging in the zkcli CLUSTERPROP command > -- > > Key: SOLR-7637 > URL: https://issues.apache.org/jira/browse/SOLR-7637 > Project: Solr > Issue Type: Improvement >Reporter: Hrishikesh Gadre >Assignee: Gregory Chanan >Priority: Trivial > Attachments: SOLR-7637.patch > > > SOLR-7176 introduced capability to update Solr cluster properties via ZK CLI. > The error logging implemented as part of that fix was not proper (i.e. the > actual error was getting masked). We should improve the error logging to > explicitly state the root cause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-7637) Improve error logging in the zkcli CLUSTERPROP command
[ https://issues.apache.org/jira/browse/SOLR-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830065#comment-17830065 ] Eric Pugh commented on SOLR-7637: - We are getting rid of zkcli in favour of bin/solr zk subcommands in SOLR-14115 > Improve error logging in the zkcli CLUSTERPROP command > -- > > Key: SOLR-7637 > URL: https://issues.apache.org/jira/browse/SOLR-7637 > Project: Solr > Issue Type: Improvement >Reporter: Hrishikesh Gadre >Assignee: Gregory Chanan >Priority: Trivial > Attachments: SOLR-7637.patch > > > SOLR-7176 introduced capability to update Solr cluster properties via ZK CLI. > The error logging implemented as part of that fix was not proper (i.e. the > actual error was getting masked). We should improve the error logging to > explicitly state the root cause. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-12089) FileBasedSpellChecker docs have some missing params
[ https://issues.apache.org/jira/browse/SOLR-12089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-12089: - Component/s: spellchecker > FileBasedSpellChecker docs have some missing params > --- > > Key: SOLR-12089 > URL: https://issues.apache.org/jira/browse/SOLR-12089 > Project: Solr > Issue Type: Improvement > Components: documentation, spellchecker >Reporter: Varun Thacker >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.6.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > FileBasedSpellChecker has params like "fieldType" that is not documented. > I'm creating a Jira to audit the params on all the spellcheckers and make > sure they are documented in the ref guide > http://lucene.apache.org/solr/guide/spell-checking.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-12089) FileBasedSpellChecker docs have some missing params
[ https://issues.apache.org/jira/browse/SOLR-12089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-12089. -- Fix Version/s: 9.6.0 Resolution: Fixed Great improvement! > FileBasedSpellChecker docs have some missing params > --- > > Key: SOLR-12089 > URL: https://issues.apache.org/jira/browse/SOLR-12089 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Varun Thacker >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.6.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > FileBasedSpellChecker has params like "fieldType" that is not documented. > I'm creating a Jira to audit the params on all the spellcheckers and make > sure they are documented in the ref guide > http://lucene.apache.org/solr/guide/spell-checking.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-12089) FileBasedSpellChecker docs have some missing params
[ https://issues.apache.org/jira/browse/SOLR-12089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-12089: Assignee: Eric Pugh > FileBasedSpellChecker docs have some missing params > --- > > Key: SOLR-12089 > URL: https://issues.apache.org/jira/browse/SOLR-12089 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Varun Thacker >Assignee: Eric Pugh >Priority: Minor > Time Spent: 3h > Remaining Estimate: 0h > > FileBasedSpellChecker has params like "fieldType" that is not documented. > I'm creating a Jira to audit the params on all the spellcheckers and make > sure they are documented in the ref guide > http://lucene.apache.org/solr/guide/spell-checking.html -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16824) Adopt Linux Command line tool pattern of -- for multi character commands.
[ https://issues.apache.org/jira/browse/SOLR-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-16824: - Summary: Adopt Linux Command line tool pattern of -- for multi character commands. (was: Adopt Linux Command line tool pattern of -- for multi charater commands.) > Adopt Linux Command line tool pattern of -- for multi character commands. > - > > Key: SOLR-16824 > URL: https://issues.apache.org/jira/browse/SOLR-16824 > Project: Solr > Issue Type: Sub-task > Components: cli > Environment: sweep through and have --get instead of -get etc through > all our command options. >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16824) Adopt Linux Command line tool pattern of -- for multi charater commands.
[ https://issues.apache.org/jira/browse/SOLR-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823594#comment-17823594 ] Eric Pugh commented on SOLR-16824: -- This is ready for review and merge! I would love some additional testing in Windows if someone could help on that. > Adopt Linux Command line tool pattern of -- for multi charater commands. > > > Key: SOLR-16824 > URL: https://issues.apache.org/jira/browse/SOLR-16824 > Project: Solr > Issue Type: Sub-task > Components: cli > Environment: sweep through and have --get instead of -get etc through > all our command options. >Reporter: Eric Pugh >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16824) Adopt Linux Command line tool pattern of -- for multi charater commands.
[ https://issues.apache.org/jira/browse/SOLR-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-16824: Assignee: Eric Pugh > Adopt Linux Command line tool pattern of -- for multi charater commands. > > > Key: SOLR-16824 > URL: https://issues.apache.org/jira/browse/SOLR-16824 > Project: Solr > Issue Type: Sub-task > Components: cli > Environment: sweep through and have --get instead of -get etc through > all our command options. >Reporter: Eric Pugh >Assignee: Eric Pugh >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-17197) Fix getting fieldType by its name in FileBasedSpellChecker
[ https://issues.apache.org/jira/browse/SOLR-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-17197. -- Fix Version/s: 9.6.0 Resolution: Fixed Thank you [~andreybozhko] > Fix getting fieldType by its name in FileBasedSpellChecker > -- > > Key: SOLR-17197 > URL: https://issues.apache.org/jira/browse/SOLR-17197 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: spellchecker >Affects Versions: main (10.0), 9.5.0 >Reporter: Andrey Bozhko >Assignee: Eric Pugh >Priority: Minor > Fix For: 9.6.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The logic in FileBasedSpellChecker uses wrong method to retrieve fieldType by > its name -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-17197) Fix getting fieldType by its name in FileBasedSpellChecker
[ https://issues.apache.org/jira/browse/SOLR-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh reassigned SOLR-17197: Assignee: Eric Pugh > Fix getting fieldType by its name in FileBasedSpellChecker > -- > > Key: SOLR-17197 > URL: https://issues.apache.org/jira/browse/SOLR-17197 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: spellchecker >Affects Versions: main (10.0), 9.5.0 >Reporter: Andrey Bozhko >Assignee: Eric Pugh >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > The logic in FileBasedSpellChecker uses wrong method to retrieve fieldType by > its name -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-17194) Export doesn't support basic auth
Eric Pugh created SOLR-17194: Summary: Export doesn't support basic auth Key: SOLR-17194 URL: https://issues.apache.org/jira/browse/SOLR-17194 Project: Solr Issue Type: Sub-task Components: cli Reporter: Eric Pugh -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16824) Adopt Linux Command line tool pattern of -- for multi charater commands.
[
https://issues.apache.org/jira/browse/SOLR-16824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823185#comment-17823185
]
Eric Pugh commented on SOLR-16824:
--
{color:#00}Now instead of “solrUrl” sometimes meaning
{color}[http://localhost:8983/solr]{color:#00} and sometimes being
{color}[http://localhost:8983/solr/mycollection]{color:#00} and even
{color}[http://localhost:8983/solr/mycollection/extract]{color:#00},{color}
we have -url as the short, and then --solr-url,--solr-update-url and
--solr-collection-url
> Adopt Linux Command line tool pattern of -- for multi charater commands.
>
>
> Key: SOLR-16824
> URL: https://issues.apache.org/jira/browse/SOLR-16824
> Project: Solr
> Issue Type: Sub-task
> Components: cli
> Environment: sweep through and have --get instead of -get etc through
> all our command options.
>Reporter: Eric Pugh
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-7074) Simple script to start external Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh resolved SOLR-7074. - Resolution: Workaround > Simple script to start external Zookeeper > - > > Key: SOLR-7074 > URL: https://issues.apache.org/jira/browse/SOLR-7074 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Upayavira >Priority: Major > > When starting Zookeeper for SolrCloud, we have two choices, bin/solr -c > (without -z) and run Zookeeper embedded. Whilst this works, it is suggestive > of bad practice, something you will have to unlearn later. > The second option is to download Zookeeper, and install it manually. This > isn't hugely hard, but it is quite manual. However, try it on Windows, and > you'll find the Windows start script for Zookeeper is extremely thin (no > start/stop options, etc). > Solr contains everything needed to start Zookeeper. Why not have a bin/zk > script that can start it for us. Thus, first time user instructions for > ZolrCloud could be: > bin/zk start > bin/zk uploadconf examples/techproducts/conf > bin/solr start -c -Z > -Z here hypothetically says "look in the standard place, localhost:2181, for > Zookeeper". > or even: > bin/zk start -config=examples/techproducts/conf > bin/ssolr start -Z > This should support both Windows and Unix. > bin/zk would support all the functionality of the current zkCli scripts as > well as being able to start/stop zookeeper. > This would make initial experience of using Solr a lot simpler, in my view, > which would be a good thing. > Not only that, deploying Zookeeper in production, for Solr, need only be push > a Solr app dir to the server, then run bin/zk start, reducing the complexity > of installation. > Thoughts? If this seems like a good idea, and don't share valid objections, > I'm prepared to make it happen. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-7074) Simple script to start external Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822966#comment-17822966 ] Eric Pugh commented on SOLR-7074: - Need to start up zookeeper? do this. docker run --name my-zookeeper -p 2181:2181 -d zookeeper Going to close this as won't do. > Simple script to start external Zookeeper > - > > Key: SOLR-7074 > URL: https://issues.apache.org/jira/browse/SOLR-7074 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Reporter: Upayavira >Priority: Major > > When starting Zookeeper for SolrCloud, we have two choices, bin/solr -c > (without -z) and run Zookeeper embedded. Whilst this works, it is suggestive > of bad practice, something you will have to unlearn later. > The second option is to download Zookeeper, and install it manually. This > isn't hugely hard, but it is quite manual. However, try it on Windows, and > you'll find the Windows start script for Zookeeper is extremely thin (no > start/stop options, etc). > Solr contains everything needed to start Zookeeper. Why not have a bin/zk > script that can start it for us. Thus, first time user instructions for > ZolrCloud could be: > bin/zk start > bin/zk uploadconf examples/techproducts/conf > bin/solr start -c -Z > -Z here hypothetically says "look in the standard place, localhost:2181, for > Zookeeper". > or even: > bin/zk start -config=examples/techproducts/conf > bin/ssolr start -Z > This should support both Windows and Unix. > bin/zk would support all the functionality of the current zkCli scripts as > well as being able to start/stop zookeeper. > This would make initial experience of using Solr a lot simpler, in my view, > which would be a good thing. > Not only that, deploying Zookeeper in production, for Solr, need only be push > a Solr app dir to the server, then run bin/zk start, reducing the complexity > of installation. > Thoughts? If this seems like a good idea, and don't share valid objections, > I'm prepared to make it happen. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-14115) Deprecate zkcli.sh
[ https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822964#comment-17822964 ] Eric Pugh commented on SOLR-14115: -- I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > Deprecate zkcli.sh > -- > > Key: SOLR-14115 > URL: https://issues.apache.org/jira/browse/SOLR-14115 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Erick Erickson >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > I think it's a valid argument that these have outlived their usefulness and > we should remove them and have APIs to do what Solr requires. Especially if > we can find and point to a third-party visual ZK tool for _changing_ > arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI > (although I don't see how to change data in ZK with it. Haven't looked very > much). > While we're ripping stuff out of Solr, are these candidates? It would break > my heart to rip ZK support out from bin/solr, but all good things must come > to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of > doing the same thing? > Mark put the zkcli stuff in before we had APIs to do what Solr needs to do > with ZK, mainly uploading configsets at the time. I put the zk support in > bin/solr also before the APIs existed because I thought having to learn our > custom wrapper for ZK was yet another orphan bit of code laying around. All > before we had things like the configsets API. > Personally, I'd prefer removing zkcli rather than bin/solr, but that's > because I originated the bin/solr code ;) > This occurred when reading SOLR-14109, I'm not entirely sure what I _really_ > think about it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] (SOLR-7233) rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when both are in $PATH
[ https://issues.apache.org/jira/browse/SOLR-7233 ] Eric Pugh deleted comment on SOLR-7233: - was (Author: epugh): I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when > both are in $PATH > > > Key: SOLR-7233 > URL: https://issues.apache.org/jira/browse/SOLR-7233 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 4.10 >Reporter: Hari Sekhon >Priority: Trivial > > Mac is case insensitive on CLI search so zkcli.sh clashes with zkCli.sh from > ZooKeeper when both are in the $PATH, ruining commands for one or the other > unless the script path is qualified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-7233) rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when both are in $PATH
[ https://issues.apache.org/jira/browse/SOLR-7233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822957#comment-17822957 ] Eric Pugh commented on SOLR-7233: - I noticed in [https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot] a reference to the "bootstrap" capablity. I feel like that is an older artifact that isn't used, and we never listed it as something to port to bin/solr zk subcommands. I'm not going to preserve it unless someone speaks up that it's actually a "good thing". It feels very opaque to use... and I suspect isn't actually used! > rename zkcli.sh script it clashes with zkCli.sh from ZooKeeper on Mac when > both are in $PATH > > > Key: SOLR-7233 > URL: https://issues.apache.org/jira/browse/SOLR-7233 > Project: Solr > Issue Type: Task > Components: scripts and tools >Affects Versions: 4.10 >Reporter: Hari Sekhon >Priority: Trivial > > Mac is case insensitive on CLI search so zkcli.sh clashes with zkCli.sh from > ZooKeeper when both are in the $PATH, ruining commands for one or the other > unless the script path is qualified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
