[GitHub] [lucene-solr] noblepaul merged pull request #1635: SOLR-14610: ReflectMapWriter to use VarHandle instead of old legacy reflection
noblepaul merged pull request #1635: URL: https://github.com/apache/lucene-solr/pull/1635 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14610) ReflectMapWriter to use VarHandle instead of old legacy reflection
[ https://issues.apache.org/jira/browse/SOLR-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150742#comment-17150742 ] ASF subversion and git services commented on SOLR-14610: Commit 05324e7b1813c43084fbce7f3e6305db0ac94c32 in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=05324e7 ] SOLR-14610: ReflectMapWriter to use VarHandle instead of old legacy reflection (#1635) > ReflectMapWriter to use VarHandle instead of old legacy reflection > -- > > Key: SOLR-14610 > URL: https://issues.apache.org/jira/browse/SOLR-14610 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The same reason why we changed to MethodHandles in SOLR-14404 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150723#comment-17150723 ] ASF subversion and git services commented on SOLR-10742: Commit e39c2f624a71e6f9eec242e91b3545fd5b64d8f8 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e39c2f6 ] SOLR-10742: SolrCores.getNamesForCore is quite inefficient and blocks other core operations > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-10742. --- Fix Version/s: 8.7 Resolution: Fixed > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150722#comment-17150722 ] ASF subversion and git services commented on SOLR-10742: Commit e9568c347316552c38137c5bef8fafcb14defd6b in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e9568c3 ] SOLR-10742: SolrCores.getNamesForCore is quite inefficient and blocks other core operations > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr
[
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150613#comment-17150613
]
Lucene/Solr QA commented on SOLR-14569:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
58s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 43m
14s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 47m 0s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-14569 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13006971/SOLR-14569.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 2005c43667b |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/774/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/774/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Configuring a shardHandlerFactory on the /select requestHandler results in
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch,
> curl_requests-responses.txt, security.json, security.json, solr.log,
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr
> with security.json.
> Searching on a single collection returns the expected results, but searching
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created
> using the _default configuration.*
> Update: Fast-forward to this comment for the reason why:
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> The attached patch includes a unit test to query on an alias. *Fixed and
> updated as per [~gerlowskija]' comments*
> *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the
> patch to fix SOLR-13510.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler
> in configset cloud-minimal
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with atta
[GitHub] [lucene-solr] zhaih edited a comment on pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih edited a comment on pull request #1613: URL: https://github.com/apache/lucene-solr/pull/1613#issuecomment-653223245 Erick: Thanks for clarifying it! However I think it's an existing code lies in current mainline that cause this warning(but not code change in this PR): https://github.com/apache/lucene-solr/blob/1b8fb70216030c19e0f1139065c56e0c273eb206/solr/core/src/java/org/apache/solr/handler/export/ExportWriterStream.java#L69 So I believe we should open another PR to fix it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on pull request #1613: URL: https://github.com/apache/lucene-solr/pull/1613#issuecomment-653223245 Eric: Thanks for clarifying it! However I think it's an existing code lies in current mainline that cause this warning(but not code change in this PR): https://github.com/apache/lucene-solr/blob/1b8fb70216030c19e0f1139065c56e0c273eb206/solr/core/src/java/org/apache/solr/handler/export/ExportWriterStream.java#L69 So I believe we should open another PR to fix it? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150582#comment-17150582 ] Dawid Weiss commented on SOLR-13308: A rule is pretty simple, really. Look at the interface: [https://junit.org/junit4/javadoc/4.12/org/junit/rules/TestRule.html] There is essentially a Statement you wrap with your code (typically before-after). As for restoring *all* properties - this works in most cases but the rule's code would have to have a permission to enumerate (and set) all properties. In Lucene code the security manager prevents that so only a subset of properties can be set/ reset (and you need to know these by name). > Move SystemPropertiesRestoreRule to SolrTestCase > > > Key: SOLR-13308 > URL: https://issues.apache.org/jira/browse/SOLR-13308 > Project: Solr > Issue Type: Improvement >Affects Versions: 8.1, master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the > discussion at SOLR-13297. > Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase. > Once that's pushed, does it make sense to put that rule in SolrTestCase so it > gets performed automagically so this kind of error doesn't creep back in? > I don't know the details of how that rule is implemented or whether this > makes sense at that level but wanted to discuss. > I've assigned it to myself, but that's just so I don't lose track of it, but > anyone else who wants to pick it up please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14618) Using Solrj Refguide Page doesn't link to ConcurrentUpdateHttp2SolrClient properly
[ https://issues.apache.org/jira/browse/SOLR-14618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh resolved SOLR-14618. Fix Version/s: 8.6 Resolution: Fixed Fixed with commit d24bdd9cfb306a79d579485f3e2a274a1c92293e > Using Solrj Refguide Page doesn't link to ConcurrentUpdateHttp2SolrClient > properly > -- > > Key: SOLR-14618 > URL: https://issues.apache.org/jira/browse/SOLR-14618 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.5 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Time Spent: 20m > Remaining Estimate: 0h > > https://lucene.apache.org/solr/guide/8_5/using-solrj.html#types-of-solrclients > the link to the ConcurrentUpdateHttp2SolrClient javadoc is listed as > ConcurrentUpdateHttpSolrClient. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh merged pull request #1642: SOLR-14618 fix link and wordsmith a bit
epugh merged pull request #1642: URL: https://github.com/apache/lucene-solr/pull/1642 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
dsmiley commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r449248769
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -500,6 +508,31 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ private void tagRequestWithRequestId(ResponseBuilder rb) {
+final boolean ridTaggingDisabled =
rb.req.getParams().getBool(CommonParams.DISABLE_REQUEST_ID, false);
+if (! ridTaggingDisabled) {
+ String rid = getRequestId(rb.req);
+ if
(StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
+ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
Review comment:
Parameter / cognitive overload / excessive.
If a user passes `rid=whatever` then Solr will pass this along (thanks to
you); right? Then in a sense it's self-disableable by a user with a blank rid
and putting it in solrconfig.xml init param for `/*`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] s1monw commented on pull request #1623: LUCENE-8962: Merge segments on getReader
s1monw commented on pull request #1623: URL: https://github.com/apache/lucene-solr/pull/1623#issuecomment-653203756 this assertion checks that we don't hold the full flush lock. I am trying to remember why I added this assertion. I understand the assertion above which also has a comment but I am unsure about the full flush lock it should not cause any deadlocks or any issues. I will keep thinking about it This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr
[ https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-14569: Status: Patch Available (was: Open) > Configuring a shardHandlerFactory on the /select requestHandler results in > HTTP 401 when searching on alias in secured Solr > --- > > Key: SOLR-14569 > URL: https://issues.apache.org/jira/browse/SOLR-14569 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: master (9.0), 8.5 > Environment: Unit test on master branch (9x) built on Windows 10 with > Java 11 > Solr 8.5.0 instance running on CentOS 7.7 with Java 11 >Reporter: Isabelle Giguere >Priority: Major > Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch, > curl_requests-responses.txt, security.json, security.json, solr.log, > solr_conf.zip, updated_solr_conf.zip > > > The issue was first noticed on an instance of Solr 8.5.0, after securing Solr > with security.json. > Searching on a single collection returns the expected results, but searching > on an alias returns HTTP 401. > *Note that this issue is not reproduced when the collections are created > using the _default configuration.* > Update: Fast-forward to this comment for the reason why: > https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195 > The attached patch includes a unit test to query on an alias. *Fixed and > updated as per [~gerlowskija]' comments* > *Patch applies on master branch (9x)*. > The unit test is added to the test class that was originally part of the > patch to fix SOLR-13510. > Update: Unit tests fail if sharHandlerFactory is added to the requestHandler > in configset cloud-minimal > I also attach: > - our product-specific Solr configuration, modified to remove irrelevant > plugins and fields > - security.json with user 'admin' (pwd 'admin') > -- Note that forwardCredentials true or false does not modify the behavior > To test with attached configuration solr_conf.zip or updated_solr_conf.zip: > - Download and unzip Solr 8.5.0 > - Modify ./bin/solr.in.sh : > -- ZK_HOST (optional) > -- SOLR_AUTH_TYPE="basic" > -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin" > - Upload security.json into Zookeeper > -- ./bin/solr zk cp > [file:/path/to/security.json|file:///path/to/security.json] > zk:/path/to/solr/security.json [-z :[/]] > - Start Solr in cloud mode > -- ./bin/solr -c > - Upload the provided configuration > - ./bin/solr zk upconfig -z :[/] -n conf_en -d > /path/to/folder/conf/ > - Create 2 collections using the uploaded configuration > -- test1, test2 > - Create an alias grouping the 2 collections > -- test = test1, test2 > - Query (/select?q=*:*) one collection > -- results in successful Solr response > - Query the alias (/select?q=*:*) > -- results in HTTP 401 > There is no need to add documents to observe the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr
[
https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150553#comment-17150553
]
Isabelle Giguere commented on SOLR-14569:
-
Attached a patch with a fix.
This patch fixes the SearchHandler only, I have not looked at other request
handlers, and it may not be the most elegant fix.
Analysis:
When a shard handler factory is configured directly on a request handler (a
search handler), in solconfig.xml, method SearchHandler.inform(SolrCore)
creates a new instance of ShardHandlerFactory. But in this case, the security
builder of the shard handler factory remains null.
Fix:
Add a boolean marker in ShardHandlerFactory, to indicate if security was
initialized, and method to get the marker.
In SearchHandler.inform(SolrCore), after the new instance of
ShardHandlerFactory is created, verify if security was enabled. In this patch,
call the CoreContainer method getAuthenticationPlugin() and check that it's not
null. We may want to use another marker somewhere, if it can be cleaner.
Also verify if security was enabled in the new shard handler factory, using the
new marker in ShardHandlerFactory.
If security is enabled but the new shard handler factory is not initialized for
it, then set the security builder, by providing the core container's PKI
authentication plugin, following what is done in
CoreContainer.setupHttpClientForAuthPlugin(...)
Adding unit test class TestAuthWithShardHandlerFactoryOverride, and configset.
Note that if you comment-out the lines that set the security builder in
SearchHandler.inform(SolrCore), and try to run these unit tests, they fail with:
{noformat}
org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation:
Authentication challenge without WWW-Authenticate header
{noformat}
So it's not exactly the same error as seen from a query run in Solr Admin UI or
a REST client. But it at least shows there's something wrong with
authentication. I suppose the HTTP protocol violation error is translated into
HTTP 401 in a part of code that the unit test doesn't reach.
Is there some other way to ensure that the search handler's specific shard
handler factory is made aware of security settings ?
> Configuring a shardHandlerFactory on the /select requestHandler results in
> HTTP 401 when searching on alias in secured Solr
> ---
>
> Key: SOLR-14569
> URL: https://issues.apache.org/jira/browse/SOLR-14569
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Affects Versions: master (9.0), 8.5
> Environment: Unit test on master branch (9x) built on Windows 10 with
> Java 11
> Solr 8.5.0 instance running on CentOS 7.7 with Java 11
>Reporter: Isabelle Giguere
>Priority: Major
> Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch,
> curl_requests-responses.txt, security.json, security.json, solr.log,
> solr_conf.zip, updated_solr_conf.zip
>
>
> The issue was first noticed on an instance of Solr 8.5.0, after securing Solr
> with security.json.
> Searching on a single collection returns the expected results, but searching
> on an alias returns HTTP 401.
> *Note that this issue is not reproduced when the collections are created
> using the _default configuration.*
> Update: Fast-forward to this comment for the reason why:
> https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195
> The attached patch includes a unit test to query on an alias. *Fixed and
> updated as per [~gerlowskija]' comments*
> *Patch applies on master branch (9x)*.
> The unit test is added to the test class that was originally part of the
> patch to fix SOLR-13510.
> Update: Unit tests fail if sharHandlerFactory is added to the requestHandler
> in configset cloud-minimal
> I also attach:
> - our product-specific Solr configuration, modified to remove irrelevant
> plugins and fields
> - security.json with user 'admin' (pwd 'admin')
> -- Note that forwardCredentials true or false does not modify the behavior
> To test with attached configuration solr_conf.zip or updated_solr_conf.zip:
> - Download and unzip Solr 8.5.0
> - Modify ./bin/solr.in.sh :
> -- ZK_HOST (optional)
> -- SOLR_AUTH_TYPE="basic"
> -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin"
> - Upload security.json into Zookeeper
> -- ./bin/solr zk cp
> [file:/path/to/security.json|file:///path/to/security.json]
> zk:/path/to/solr/security.json [-z :[/]]
> - Start Solr in cloud mode
> -- ./bin/solr -c
> - Upload the provided configuration
> - ./bin/solr zk u
[jira] [Created] (SOLR-14619) Avoid needless calls to SolrIndexSearcher.getDocSet(query)
David Smiley created SOLR-14619: --- Summary: Avoid needless calls to SolrIndexSearcher.getDocSet(query) Key: SOLR-14619 URL: https://issues.apache.org/jira/browse/SOLR-14619 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: search Reporter: David Smiley Assignee: David Smiley There are places where we get a DocSet from a query (potentially cached) when we don't need to. This is a minor optimization but could simply also be viewed as a simplification. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley opened a new pull request #1643: SOLR-14619 avoid SolrIndexSearcher.getDocSet(q)
dsmiley opened a new pull request #1643: URL: https://github.com/apache/lucene-solr/pull/1643 There are places where we get a DocSet from a query when we don't need to. Also, improved DocSet.getTopFilter to implement DocSetProducer so as to avoid possible re-construction of the DocSet. Deprecated SolrPluginUtils.numDocs. Nobody calls it. Maybe @yonik or @mkhludnev might be interested in code reviewing? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh opened a new pull request #1642: SOLR-14618 fix link and wordsmith a bit
epugh opened a new pull request #1642: URL: https://github.com/apache/lucene-solr/pull/1642 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14569) Configuring a shardHandlerFactory on the /select requestHandler results in HTTP 401 when searching on alias in secured Solr
[ https://issues.apache.org/jira/browse/SOLR-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Isabelle Giguere updated SOLR-14569: Attachment: SOLR-14569.patch > Configuring a shardHandlerFactory on the /select requestHandler results in > HTTP 401 when searching on alias in secured Solr > --- > > Key: SOLR-14569 > URL: https://issues.apache.org/jira/browse/SOLR-14569 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication >Affects Versions: master (9.0), 8.5 > Environment: Unit test on master branch (9x) built on Windows 10 with > Java 11 > Solr 8.5.0 instance running on CentOS 7.7 with Java 11 >Reporter: Isabelle Giguere >Priority: Major > Attachments: SOLR-14569.patch, SOLR-14569.patch, SOLR-14569.patch, > curl_requests-responses.txt, security.json, security.json, solr.log, > solr_conf.zip, updated_solr_conf.zip > > > The issue was first noticed on an instance of Solr 8.5.0, after securing Solr > with security.json. > Searching on a single collection returns the expected results, but searching > on an alias returns HTTP 401. > *Note that this issue is not reproduced when the collections are created > using the _default configuration.* > Update: Fast-forward to this comment for the reason why: > https://issues.apache.org/jira/browse/SOLR-14569?focusedCommentId=17136195&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17136195 > The attached patch includes a unit test to query on an alias. *Fixed and > updated as per [~gerlowskija]' comments* > *Patch applies on master branch (9x)*. > The unit test is added to the test class that was originally part of the > patch to fix SOLR-13510. > Update: Unit tests fail if sharHandlerFactory is added to the requestHandler > in configset cloud-minimal > I also attach: > - our product-specific Solr configuration, modified to remove irrelevant > plugins and fields > - security.json with user 'admin' (pwd 'admin') > -- Note that forwardCredentials true or false does not modify the behavior > To test with attached configuration solr_conf.zip or updated_solr_conf.zip: > - Download and unzip Solr 8.5.0 > - Modify ./bin/solr.in.sh : > -- ZK_HOST (optional) > -- SOLR_AUTH_TYPE="basic" > -- SOLR_AUTHENTICATION_OPTS="-Dbasicauth=admin:admin" > - Upload security.json into Zookeeper > -- ./bin/solr zk cp > [file:/path/to/security.json|file:///path/to/security.json] > zk:/path/to/solr/security.json [-z :[/]] > - Start Solr in cloud mode > -- ./bin/solr -c > - Upload the provided configuration > - ./bin/solr zk upconfig -z :[/] -n conf_en -d > /path/to/folder/conf/ > - Create 2 collections using the uploaded configuration > -- test1, test2 > - Create an alias grouping the 2 collections > -- test = test1, test2 > - Query (/select?q=*:*) one collection > -- results in successful Solr response > - Query the alias (/select?q=*:*) > -- results in HTTP 401 > There is no need to add documents to observe the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14618) Using Solrj Refguide Page doesn't link to ConcurrentUpdateHttp2SolrClient properly
David Eric Pugh created SOLR-14618: -- Summary: Using Solrj Refguide Page doesn't link to ConcurrentUpdateHttp2SolrClient properly Key: SOLR-14618 URL: https://issues.apache.org/jira/browse/SOLR-14618 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: documentation Affects Versions: 8.5 Reporter: David Eric Pugh Assignee: David Eric Pugh https://lucene.apache.org/solr/guide/8_5/using-solrj.html#types-of-solrclients the link to the ConcurrentUpdateHttp2SolrClient javadoc is listed as ConcurrentUpdateHttpSolrClient. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14358) Comment to explain how to use URLClassifyProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh resolved SOLR-14358. Fix Version/s: 8.6 Assignee: David Eric Pugh Resolution: Fixed > Comment to explain how to use URLClassifyProcessorFactory > - > > Key: SOLR-14358 > URL: https://issues.apache.org/jira/browse/SOLR-14358 > Project: Solr > Issue Type: Improvement > Components: UpdateRequestProcessors >Affects Versions: 8.4.1 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Time Spent: 1h > Remaining Estimate: 0h > > There is an existing Pull Request out there that documents how to use this, > however needs some formatting love before it can be committed. > https://github.com/apache/lucene-solr/pull/404 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh reopened SOLR-14422: Wrong JIRA. > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14422) Solr 8.5 Admin UI shows Angular placeholders on first load / refresh
[ https://issues.apache.org/jira/browse/SOLR-14422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh updated SOLR-14422: --- Fix Version/s: 8.6 Assignee: David Eric Pugh Resolution: Resolved Status: Resolved (was: Patch Available) > Solr 8.5 Admin UI shows Angular placeholders on first load / refresh > > > Key: SOLR-14422 > URL: https://issues.apache.org/jira/browse/SOLR-14422 > Project: Solr > Issue Type: Bug > Components: Admin UI >Affects Versions: 8.5, 8.5.1, 8.5.2 >Reporter: Colvin Cowie >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.6 > > Attachments: SOLR-14422.patch, image-2020-04-21-14-51-18-923.png > > > When loading / refreshing the Admin UI in 8.5.1, it briefly but _visibly_ > shows a placeholder for the "SolrCore Initialization Failures" error message, > with a lot of redness. It looks like there is a real problem. Obviously the > message then disappears, and it can be ignored. > However, if I was a first time user, it would not give me confidence that > everything is okay. In a way, an error message that appears briefly then > disappears before I can finish reading it is worse than one which just stays > there. > > Here's a screenshot of what I mean !image-2020-04-21-14-51-18-923.png! > > I suspect that SOLR-14132 will have caused this > > From a (very) brief googling it seems like using the ng-cloak attribute is > the right way to fix this, and it certainly seems to work for me. > https://docs.angularjs.org/api/ng/directive/ngCloak > I will attach a patch with it, but if someone who actually knows Angular etc > has a better approach then please go for it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
ErickErickson commented on pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#issuecomment-653180860
Patrick:
This is a relatively recent change (failing on unsuppressed warnings).
The preferred solution is to to type the list, e.g.
List lst = new ArrayList<>();
If that’s too difficult, you can add
@SupppressWarnings({“rawtypes”})
in this case you can probably add it right above the declaration. But please
try to solve it
correctly first by adding a type to the List.
Yeah, I know there are a zillion SuppressWarnings in the code; we’ve been
accruing
this kind of cruft for years. I recently went through and added lots of
SuppressWarnings so
we could get to the point of having a chance of not adding any new warnings
because
things fail. BTW, compilation should have failed well in advance of
precommit.
Second BTW, “the gradle way” is “gradlew check -x test”...
Oh, and if you are working on code anyway with SuppressWarnings and can fix
a few
of those too on the way by that would be great!
Best,
Erick
> On Jul 2, 2020, at 2:55 PM, Patrick Zhai wrote:
>
> List lst = new ArrayList();
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14358) Comment to explain how to use URLClassifyProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150540#comment-17150540 ] ASF subversion and git services commented on SOLR-14358: Commit 149005399d4eef109d402428afd6fd166a7bc64c in lucene-solr's branch refs/heads/branch_8_6 from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1490053 ] SOLR-14358 respond to feedback on URLClassifyProcessorFactory (#1632) * Add an example explaining how to use * fix up JavaDoc formatting * Respond to feedback from @janhoy Co-authored-by: ohtwadi > Comment to explain how to use URLClassifyProcessorFactory > - > > Key: SOLR-14358 > URL: https://issues.apache.org/jira/browse/SOLR-14358 > Project: Solr > Issue Type: Improvement > Components: UpdateRequestProcessors >Affects Versions: 8.4.1 >Reporter: David Eric Pugh >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > There is an existing Pull Request out there that documents how to use this, > however needs some formatting love before it can be committed. > https://github.com/apache/lucene-solr/pull/404 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14358) Comment to explain how to use URLClassifyProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150538#comment-17150538 ] ASF subversion and git services commented on SOLR-14358: Commit 6457ef30078aa1e81b5c1fd6b8c2d578ed58d464 in lucene-solr's branch refs/heads/branch_8x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6457ef3 ] SOLR-14358 respond to feedback on URLClassifyProcessorFactory (#1632) * Add an example explaining how to use * fix up JavaDoc formatting * Respond to feedback from @janhoy Co-authored-by: ohtwadi > Comment to explain how to use URLClassifyProcessorFactory > - > > Key: SOLR-14358 > URL: https://issues.apache.org/jira/browse/SOLR-14358 > Project: Solr > Issue Type: Improvement > Components: UpdateRequestProcessors >Affects Versions: 8.4.1 >Reporter: David Eric Pugh >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > There is an existing Pull Request out there that documents how to use this, > however needs some formatting love before it can be committed. > https://github.com/apache/lucene-solr/pull/404 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14358) Comment to explain how to use URLClassifyProcessorFactory
[ https://issues.apache.org/jira/browse/SOLR-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150537#comment-17150537 ] ASF subversion and git services commented on SOLR-14358: Commit b50dd0c9c78f5973fe9a3d604390472cc0d66593 in lucene-solr's branch refs/heads/master from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b50dd0c ] SOLR-14358 respond to feedback on URLClassifyProcessorFactory (#1632) * Add an example explaining how to use * fix up JavaDoc formatting * Respond to feedback from @janhoy Co-authored-by: ohtwadi > Comment to explain how to use URLClassifyProcessorFactory > - > > Key: SOLR-14358 > URL: https://issues.apache.org/jira/browse/SOLR-14358 > Project: Solr > Issue Type: Improvement > Components: UpdateRequestProcessors >Affects Versions: 8.4.1 >Reporter: David Eric Pugh >Priority: Minor > Time Spent: 1h > Remaining Estimate: 0h > > There is an existing Pull Request out there that documents how to use this, > however needs some formatting love before it can be committed. > https://github.com/apache/lucene-solr/pull/404 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] epugh merged pull request #1632: SOLR-14358 respond to feedback on URLClassifyProcessorFactory
epugh merged pull request #1632: URL: https://github.com/apache/lucene-solr/pull/1632 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on pull request #1613: URL: https://github.com/apache/lucene-solr/pull/1613#issuecomment-653170259 Rebased to master and gradle precommit failed because of following warning (which becomes error since `-Werror specified`): > /home/runner/work/lucene-solr/lucene-solr/solr/core/src/java/org/apache/solr/handler/export/ExportWriterStream.java:69: warning: [rawtypes] found raw type: List List lst = new ArrayList(); This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zhaih commented on a change in pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
zhaih commented on a change in pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#discussion_r449200188
##
File path:
lucene/expressions/src/java/org/apache/lucene/expressions/CachingExpressionValueSource.java
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.expressions;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DoubleValues;
+import org.apache.lucene.search.DoubleValuesSource;
+
+final class CachingExpressionValueSource extends ExpressionValueSource {
+
+ CachingExpressionValueSource(Bindings bindings, Expression expression) {
+super(bindings, expression);
+ }
+
+ CachingExpressionValueSource(DoubleValuesSource[] variables, Expression
expression, boolean needsScores) {
+super(variables, expression, needsScores);
+ }
+
+ public CachingExpressionValueSource(ExpressionValueSource
expressionValueSource) {
+super(expressionValueSource.variables, expressionValueSource.expression,
expressionValueSource.needsScores);
+ }
+
+ @Override
+ public DoubleValues getValues(LeafReaderContext readerContext, DoubleValues
scores) throws IOException {
+return getValuesWithCache(readerContext, scores, new HashMap<>());
+ }
+
+ public DoubleValues getValuesWithCache(LeafReaderContext readerContext,
DoubleValues scores,
+ Map
valuesCache) throws IOException {
+DoubleValues[] externalValues = new
DoubleValues[expression.variables.length];
+
+for (int i = 0; i < variables.length; ++i) {
+ String externalName = expression.variables[i];
+ DoubleValues values = valuesCache.get(externalName);
+ if (values == null) {
+if (variables[i] instanceof CachingExpressionValueSource) {
+ values =
((CachingExpressionValueSource)variables[i]).getValuesWithCache(readerContext,
scores, valuesCache);
+} else {
+ values = variables[i].getValues(readerContext, scores);
+}
+if (values == null) {
+ throw new RuntimeException("Internal error. External (" +
externalName + ") does not exist.");
Review comment:
Changed!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
dsmiley commented on pull request #1608: URL: https://github.com/apache/lucene-solr/pull/1608#issuecomment-653150307 Lets use JIRA ( LUCENE-9379 ) to discuss higher level concerns and GitHub code reviews for code details. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150465#comment-17150465 ] ASF subversion and git services commented on SOLR-14022: Commit e4f71f50fb80f3c37e4489eece5414272f58a8e4 in lucene-solr's branch refs/heads/branch_8_6 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e4f71f5 ] SOLR-14066, SOLR-14022: Fix compilation issues with JDK8, which doesn't support since with @Deprecated > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150467#comment-17150467 ] ASF subversion and git services commented on SOLR-14022: Commit 7326be6406014a15de8325629c9eb326f59ea366 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7326be6 ] SOLR-14066, SOLR-14022: Fix compilation issues with JDK8, which doesn't support since with @Deprecated > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150466#comment-17150466 ] ASF subversion and git services commented on SOLR-14066: Commit 7326be6406014a15de8325629c9eb326f59ea366 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7326be6 ] SOLR-14066, SOLR-14022: Fix compilation issues with JDK8, which doesn't support since with @Deprecated > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150464#comment-17150464 ] ASF subversion and git services commented on SOLR-14066: Commit e4f71f50fb80f3c37e4489eece5414272f58a8e4 in lucene-solr's branch refs/heads/branch_8_6 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e4f71f5 ] SOLR-14066, SOLR-14022: Fix compilation issues with JDK8, which doesn't support since with @Deprecated > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
gerlowskija commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r449163848
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -500,6 +508,31 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
}
+ private void tagRequestWithRequestId(ResponseBuilder rb) {
+final boolean ridTaggingDisabled =
rb.req.getParams().getBool(CommonParams.DISABLE_REQUEST_ID, false);
+if (! ridTaggingDisabled) {
+ String rid = getRequestId(rb.req);
+ if
(StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
+ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
Review comment:
I like the simplicity of having the flag be its own separate parameter
over packing in multiple different "flag" values to the existing param.
Simplicity and intuitiveness are admittedly subjective though, I'm open to
your opinion if you can convince me why you see having only a single param is
easier for users to digest.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-13308. --- Resolution: Fixed Chris: You nailed it, I didn't understand how "around" works I wasn't clear about Before/AfterClass I was thinking of adding a check in SolrTestCase to verify that the system vars were the same before as after as an alternative to a rule. I vastly prefer the rule, but was just thinking of possibilities if the Rule wasn't viable for some reason. So I'll just resolve this as done. I suppose theoretically we could now go through all the tests that have SolrTestCase in their ancestry and remove all the clearing/resetting for sysvars, but frankly I don't see enough tangible benefit to bother. [~dweiss] Thanks, what Chris put in allows us to not have to remember either one ;) > Move SystemPropertiesRestoreRule to SolrTestCase > > > Key: SOLR-13308 > URL: https://issues.apache.org/jira/browse/SOLR-13308 > Project: Solr > Issue Type: Improvement >Affects Versions: 8.1, master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the > discussion at SOLR-13297. > Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase. > Once that's pushed, does it make sense to put that rule in SolrTestCase so it > gets performed automagically so this kind of error doesn't creep back in? > I don't know the details of how that rule is implemented or whether this > makes sense at that level but wanted to discuss. > I've assigned it to myself, but that's just so I don't lose track of it, but > anyone else who wants to pick it up please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150443#comment-17150443 ] David Smiley commented on SOLR-14597: - Can you post a comment on class names you propose to be added to Lucene and likewise Solr? Like do an inventory and list them. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150438#comment-17150438 ] Gus Heck commented on SOLR-14597: - This thought has occurred to me, but the coordination of several parts across both Lucene and Solr layers seems awkward for a packge/plugin (Solr parser, a couple new Lucene filters, etc), and I do hope that it is a generally useful parser as you mention. When we sort out the legalities and get a patch up this will become more clear, but generally it adds another javacc based parser, that was based on and is able to reuse some bits of the standard parser (a few of which needed to be extracted/or made accessible). There are also a few small tweaks to core classes, (which seem justified to me, but of course review and commentary is welcome). So even if a package/plugin is part of the final result we will likely have some changes to Solr & Lucene directly as well. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 8.6 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1626: SOLR-14588: Implement Circuit Breakers
dsmiley commented on a change in pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626#discussion_r449135773 ## File path: solr/solr-ref-guide/src/index.adoc ## @@ -10,6 +10,7 @@ streaming-expressions, \ solrcloud, \ legacy-scaling-and-distribution, \ +circuit-breakers, \ Review comment: FYI @ctargett I'm not sure if this page deserves its own page or should be a part of another... and if it is its own page as Atris did then where the logical placement is. Any way; I just want to bring this to your attention. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150428#comment-17150428 ] Dawid Weiss commented on SOLR-13308: For what it's worth, the overhead of a rule vs. before/after class is pretty much the same. > Move SystemPropertiesRestoreRule to SolrTestCase > > > Key: SOLR-13308 > URL: https://issues.apache.org/jira/browse/SOLR-13308 > Project: Solr > Issue Type: Improvement >Affects Versions: 8.1, master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the > discussion at SOLR-13297. > Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase. > Once that's pushed, does it make sense to put that rule in SolrTestCase so it > gets performed automagically so this kind of error doesn't creep back in? > I don't know the details of how that rule is implemented or whether this > makes sense at that level but wanted to discuss. > I've assigned it to myself, but that's just so I don't lose track of it, but > anyone else who wants to pick it up please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[
https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150421#comment-17150421
]
Chris M. Hostetter commented on SOLR-13308:
---
bq. It looks like you already did something like this, but it's specific to
RevertDefaultThreadHandlerRule. WDYT about taking that restriction away?
I don't understand the question ... what restriction are you talking about?
(are you perhaps missunderstanding the use of RuleChain? ... that doesn't
"restrict" when SystemPropertiesRestoreRule or RevertDefaultThreadHandlerRule
are used relative to eachother -- it just dictates that they will be evaluated
in a predictable order, which would be undefined if they were declared as
independent {{\@ClassRule public static TestRule ...}} variables in the same
(base) class)
Why would new BeforeClass/AfterClass methods work better then using
SystemPropertiesRestoreRule? what sitaution?
I think in general this jira can just be resolved as DONE? do you have any
examples/evidence of system properties leaking from one test _class_ run to
another since this change was made in f549ee353530fcd48390a314aff9ec1723b47346 ?
> Move SystemPropertiesRestoreRule to SolrTestCase
>
>
> Key: SOLR-13308
> URL: https://issues.apache.org/jira/browse/SOLR-13308
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.1, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the
> discussion at SOLR-13297.
> Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase.
> Once that's pushed, does it make sense to put that rule in SolrTestCase so it
> gets performed automagically so this kind of error doesn't creep back in?
> I don't know the details of how that rule is implemented or whether this
> makes sense at that level but wanted to discuss.
> I've assigned it to myself, but that's just so I don't lose track of it, but
> anyone else who wants to pick it up please feel free.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mikemccand commented on a change in pull request #1613: LUCENE-8574 Cache ExpressionFunctionValues
mikemccand commented on a change in pull request #1613:
URL: https://github.com/apache/lucene-solr/pull/1613#discussion_r449117471
##
File path:
lucene/expressions/src/java/org/apache/lucene/expressions/CachingExpressionValueSource.java
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.expressions;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.Map;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.search.DoubleValues;
+import org.apache.lucene.search.DoubleValuesSource;
+
+final class CachingExpressionValueSource extends ExpressionValueSource {
+
+ CachingExpressionValueSource(Bindings bindings, Expression expression) {
+super(bindings, expression);
+ }
+
+ CachingExpressionValueSource(DoubleValuesSource[] variables, Expression
expression, boolean needsScores) {
+super(variables, expression, needsScores);
+ }
+
+ public CachingExpressionValueSource(ExpressionValueSource
expressionValueSource) {
+super(expressionValueSource.variables, expressionValueSource.expression,
expressionValueSource.needsScores);
+ }
+
+ @Override
+ public DoubleValues getValues(LeafReaderContext readerContext, DoubleValues
scores) throws IOException {
+return getValuesWithCache(readerContext, scores, new HashMap<>());
+ }
+
+ public DoubleValues getValuesWithCache(LeafReaderContext readerContext,
DoubleValues scores,
+ Map
valuesCache) throws IOException {
+DoubleValues[] externalValues = new
DoubleValues[expression.variables.length];
+
+for (int i = 0; i < variables.length; ++i) {
+ String externalName = expression.variables[i];
+ DoubleValues values = valuesCache.get(externalName);
+ if (values == null) {
+if (variables[i] instanceof CachingExpressionValueSource) {
+ values =
((CachingExpressionValueSource)variables[i]).getValuesWithCache(readerContext,
scores, valuesCache);
+} else {
+ values = variables[i].getValues(readerContext, scores);
+}
+if (values == null) {
+ throw new RuntimeException("Internal error. External (" +
externalName + ") does not exist.");
Review comment:
Oh yeah can we please change both?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-14588: Fix Version/s: master (9.0) Affects Version/s: (was: master (9.0)) Don't use "Affects Version" unless it's a bug; "Fix Version" needs to be populated when we resolve issues. > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Fix For: master (9.0) > > Time Spent: 13.5h > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150394#comment-17150394 ] David Smiley commented on SOLR-10742: - > I'm going to remove getNamesForCores and all associated code in the next > couple of days. Glad to here we can just remove it :-). Less code to maintain (and this issue, slowness / optimization is maintenance). > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14537) Improve performance of ExportWriter
[
https://issues.apache.org/jira/browse/SOLR-14537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150389#comment-17150389
]
ASF subversion and git services commented on SOLR-14537:
Commit 1b8fb70216030c19e0f1139065c56e0c273eb206 in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1b8fb70 ]
SOLR-14537: Improve performance of ExportWriter.
> Improve performance of ExportWriter
> ---
>
> Key: SOLR-14537
> URL: https://issues.apache.org/jira/browse/SOLR-14537
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Export Writer
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Retrieving, sorting and writing out documents in {{ExportWriter}} are three
> aspects of the /export handler that can be further optimized.
> SOLR-14470 introduced some level of caching in {{StringValue}}. Further
> options for caching and speedups should be explored.
> Currently the sort/retrieve and write operations are done sequentially, but
> they could be parallelized, considering that they block on different channels
> - the first is index reading & CPU bound, the other is bound by the receiving
> end because it uses blocking IO. The sorting and retrieving of values could
> be done in parallel with the operation of writing out the current batch of
> results.
> One possible approach here would be to use "double buffering" where one
> buffered batch that is ready (already sorted and retrieved) is being written
> out, while the other batch is being prepared in a background thread, and when
> both are done the buffers are swapped. This wouldn't complicate the current
> code too much but it should instantly give up to 2x higher throughput.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-10742) SolrCores.getNamesForCore is quite inefficient and blocks other core operations
[ https://issues.apache.org/jira/browse/SOLR-10742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150385#comment-17150385 ] Erick Erickson commented on SOLR-10742: --- I chatted with [~ab] and he doesn't object to removing this call, with the caveat that third-parties may rely on it. I propose removing this call from the metrics initialization code and all the associated calls as they're trappy. If someone really needs to implement this, they can iterate the lists themselves. The problem with maintaining a parallel inverted list is that then every operation that changed the cores list has to traverse all the values of the inverted list to potentially remove an old entry, which is the same problem in reverse. Alternatively we could make a copy of the cores list in getNamesForCore, then release the lock and return the results from the copy. I don't _know_ that's bad, on a brief experiment I think it took < 10ms to clone a 10K list. It would be relatively simple to keep a timestamp that's the last time the cores list was modified and only do the copy when that timestamp changed. But that feels like the tail wagging the dog for code noboby has spoken up for and is marked experimental anyway. Plus, that list would be changing all the time on startup with loading lots of cores and I have no evidence it's being used any other time. So absent objections, I'm going to remove getNamesForCores and all associated code in the next couple of days. > SolrCores.getNamesForCore is quite inefficient and blocks other core > operations > --- > > Key: SOLR-10742 > URL: https://issues.apache.org/jira/browse/SOLR-10742 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > SolrCores.getNamesForCore iterates through all the cores to find all the > aliases to this core. It does this in a synchronized block which blocks other > core operations. > For installations with many cores this can be a performance issue. I'm not > sure it makes sense to do it this way anyway, perhaps SolrCore should have a > list of its current aliases and we can be more efficient about this? Or > otherwise get this information in a less heavy-weight fashion? > I'm assigning this to myself to keep track of it, but anyone who wants to > grab it please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14561) Validate parameters to CoreAdminAPI
[
https://issues.apache.org/jira/browse/SOLR-14561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150353#comment-17150353
]
ASF subversion and git services commented on SOLR-14561:
Commit 257a1851073a9ed589d03abe082af215cb090c97 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=257a185 ]
SOLR-14561: Fix silly mistake in refguide link
> Validate parameters to CoreAdminAPI
> ---
>
> Key: SOLR-14561
> URL: https://issues.apache.org/jira/browse/SOLR-14561
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> CoreAdminAPI does not validate parameter input. We should limit what users
> can specify for at least {{instanceDir and dataDir}} params, perhaps restrict
> them to be relative to SOLR_HOME or SOLR_DATA_HOME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150271#comment-17150271 ] Erick Erickson edited comment on SOLR-13308 at 7/2/20, 2:52 PM: [~hoss...@fucit.org] It looks like you already did something like this, but it's specific to RevertDefaultThreadHandlerRule. WDYT about taking that restriction away? Mostly I'm curious about why you made it so specific, do you see problems with making it more general or is this simply being cautious? I'm a little nervous about RestoreRule affecting all tests. Would it make more sense to add a @BeforeClass that made a list of all the sysvars and then an @AfterClass that failed if the lists weren't identical? I don't particularly like adding that overhead, but it does seem safer. [~hossman] think I used the wrong link to ping you before. was (Author: erickerickson): [~hoss...@fucit.org] It looks like you already did something like this, but it's specific to RevertDefaultThreadHandlerRule. WDYT about taking that restriction away? Mostly I'm curious about why you made it so specific, do you see problems with making it more general or is this simply being cautious? I'm a little nervous about RestoreRule affecting all tests. Would it make more sense to add a @BeforeClass that made a list of all the sysvars and then an @AfterClass that failed if the lists weren't identical? I don't particularly like adding that overhead, but it does seem safer. > Move SystemPropertiesRestoreRule to SolrTestCase > > > Key: SOLR-13308 > URL: https://issues.apache.org/jira/browse/SOLR-13308 > Project: Solr > Issue Type: Improvement >Affects Versions: 8.1, master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the > discussion at SOLR-13297. > Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase. > Once that's pushed, does it make sense to put that rule in SolrTestCase so it > gets performed automagically so this kind of error doesn't creep back in? > I don't know the details of how that rule is implemented or whether this > makes sense at that level but wanted to discuss. > I've assigned it to myself, but that's just so I don't lose track of it, but > anyone else who wants to pick it up please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150337#comment-17150337 ] Ishan Chattopadhyaya commented on SOLR-14066: - bq. That text is outdated I guess, since you already found a maintainer? Feel free to author a similar message and send out. That makes sense. Rohit is still working on a release structure and formal release. Let [~rohitcse] announce the release first, and we can send this message out referring to Rohit's release. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14575) Solr restore is failing when basic authentication is enabled
[
https://issues.apache.org/jira/browse/SOLR-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150324#comment-17150324
]
Yaswanth commented on SOLR-14575:
-
Can I get an update or atleast a work around for this issue?
> Solr restore is failing when basic authentication is enabled
>
>
> Key: SOLR-14575
> URL: https://issues.apache.org/jira/browse/SOLR-14575
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Backup/Restore
>Affects Versions: 8.2
>Reporter: Yaswanth
>Priority: Blocker
>
> Hi Team,
> I was testing backup / restore for solrcloud and its failing exactly when I
> am trying to restore a successfully backed up collection.
> I am using solr 8.2 with basic authentication enabled and then creating a 2
> replica collection. When I run the backup like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> it worked fine and I do see a folder was created with the collection name
> under /solrdatabackup
> But now when I deleted the existing collection and then try running restore
> api like
> curl -u xxx:xxx -k
> '[https://x.x.x.x:8080/solr/admin/collections?action=RESTORE&name=test&collection=test&location=/solrdatabkup'|https://x.x.x.x:8080/solr/admin/collections?action=BACKUP&name=test&collection=test&location=/solrdatabkup%27]
> its throwing an error like
> {
> "responseHeader":{
> "status":500,
> "QTime":457},
> "Operation restore caused
> *exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
> ADDREPLICA failed to create replica",*
> "exception":{
> "msg":"ADDREPLICA failed to create replica",
> "rspCode":500},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"ADDREPLICA failed to create replica",
> "trace":"org.apache.solr.common.SolrException: ADDREPLICA failed to create
> replica\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:280)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:252)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:820)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:786)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:546)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
[jira] [Commented] (SOLR-14561) Validate parameters to CoreAdminAPI
[
https://issues.apache.org/jira/browse/SOLR-14561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150288#comment-17150288
]
ASF subversion and git services commented on SOLR-14561:
Commit b1bd8bd38cb128d40db329344b3b0684003fadf2 in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b1bd8bd ]
SOLR-14561: Adding upgrade notes for allowPaths (#1641)
(cherry picked from commit cc9df5af05f08396d6708c5d0644db342ff18c6d)
> Validate parameters to CoreAdminAPI
> ---
>
> Key: SOLR-14561
> URL: https://issues.apache.org/jira/browse/SOLR-14561
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> CoreAdminAPI does not validate parameter input. We should limit what users
> can specify for at least {{instanceDir and dataDir}} params, perhaps restrict
> them to be relative to SOLR_HOME or SOLR_DATA_HOME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14561) Validate parameters to CoreAdminAPI
[
https://issues.apache.org/jira/browse/SOLR-14561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150291#comment-17150291
]
ASF subversion and git services commented on SOLR-14561:
Commit ac36f7293abad768e26d7cb469f2233d2e3f9c1b in lucene-solr's branch
refs/heads/branch_8_6 from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ac36f72 ]
SOLR-14561: Adding upgrade notes for allowPaths (#1641)
(cherry picked from commit cc9df5af05f08396d6708c5d0644db342ff18c6d)
> Validate parameters to CoreAdminAPI
> ---
>
> Key: SOLR-14561
> URL: https://issues.apache.org/jira/browse/SOLR-14561
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> CoreAdminAPI does not validate parameter input. We should limit what users
> can specify for at least {{instanceDir and dataDir}} params, perhaps restrict
> them to be relative to SOLR_HOME or SOLR_DATA_HOME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14561) Validate parameters to CoreAdminAPI
[
https://issues.apache.org/jira/browse/SOLR-14561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150285#comment-17150285
]
ASF subversion and git services commented on SOLR-14561:
Commit cc9df5af05f08396d6708c5d0644db342ff18c6d in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc9df5a ]
SOLR-14561: Adding upgrade notes for allowPaths (#1641)
> Validate parameters to CoreAdminAPI
> ---
>
> Key: SOLR-14561
> URL: https://issues.apache.org/jira/browse/SOLR-14561
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> CoreAdminAPI does not validate parameter input. We should limit what users
> can specify for at least {{instanceDir and dataDir}} params, perhaps restrict
> them to be relative to SOLR_HOME or SOLR_DATA_HOME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy merged pull request #1641: SOLR-14561: Adding upgrade notes for allowPaths
janhoy merged pull request #1641: URL: https://github.com/apache/lucene-solr/pull/1641 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150281#comment-17150281 ] Jan Høydahl commented on SOLR-14066: That text is outdated I guess, since you already found a maintainer? Feel free to author a similar message and send out. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
janhoy commented on a change in pull request #1574:
URL: https://github.com/apache/lucene-solr/pull/1574#discussion_r449000598
##
File path:
solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java
##
@@ -510,14 +510,18 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
}
private void tagRequestWithRequestId(ResponseBuilder rb) {
-String rid = getRequestId(rb.req);
-if (StringUtils.isBlank(rb.req.getParams().get(CommonParams.REQUEST_ID))) {
- ModifiableSolrParams params = new
ModifiableSolrParams(rb.req.getParams());
- params.add(CommonParams.REQUEST_ID, rid);//add rid to the request so
that shards see it
- rb.req.setParams(params);
-}
-if (rb.isDistrib) {
- rb.rsp.addToLog(CommonParams.REQUEST_ID, rid); //to see it in the logs
of the landing core
+final String disableFlag =
rb.req.getParams().get(CommonParams.DISABLE_REQUEST_ID);
Review comment:
> I like a SolrParam better than a cluster property. Users might well
have reasons to enable/disable it differently based on the source or type of
query.
If users want full per-query control, they don't need a Solr feature at all,
they can just start including `whatever=1234` in their requests and track it in
their logs. :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13308) Move SystemPropertiesRestoreRule to SolrTestCase
[ https://issues.apache.org/jira/browse/SOLR-13308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150271#comment-17150271 ] Erick Erickson commented on SOLR-13308: --- [~hoss...@fucit.org] It looks like you already did something like this, but it's specific to RevertDefaultThreadHandlerRule. WDYT about taking that restriction away? Mostly I'm curious about why you made it so specific, do you see problems with making it more general or is this simply being cautious? I'm a little nervous about RestoreRule affecting all tests. Would it make more sense to add a @BeforeClass that made a list of all the sysvars and then an @AfterClass that failed if the lists weren't identical? I don't particularly like adding that overhead, but it does seem safer. > Move SystemPropertiesRestoreRule to SolrTestCase > > > Key: SOLR-13308 > URL: https://issues.apache.org/jira/browse/SOLR-13308 > Project: Solr > Issue Type: Improvement >Affects Versions: 8.1, master (9.0) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > [~krisden] just traced flaky HDFS tests to not clearing sysprops, see the > discussion at SOLR-13297. > Part of SOLR-13268 is to derive all Solr test classes from SolrTestCase. > Once that's pushed, does it make sense to put that rule in SolrTestCase so it > gets performed automagically so this kind of error doesn't creep back in? > I don't know the details of how that rule is implemented or whether this > makes sense at that level but wanted to discuss. > I've assigned it to myself, but that's just so I don't lose track of it, but > anyone else who wants to pick it up please feel free. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1641: SOLR-14561: Adding upgrade notes for allowPaths
janhoy commented on a change in pull request #1641: URL: https://github.com/apache/lucene-solr/pull/1641#discussion_r448984282 ## File path: solr/solr-ref-guide/src/solr-upgrade-notes.adoc ## @@ -85,11 +85,18 @@ For more information about how to use this, see the section <>. When using the `solr.xml` file shipping with 8.6, you can configure the list of paths to allow through the system property `solr.allowPaths`. Please see `bin/solr.in.sh` or `bin\solr.in.cmd` for example usage. Using the value `*` will allow any path as in erlier versions. + +Windows SMB shares on the UNC format, such as `\\myhost\myshare\mypath` are now always disallowed. Please use drive letter mounts instead, i.e. `S:\mypath`. -* Cross Data Center Replication (CDCR), in its current form, is deprecated and is scheduled to be removed in 9.0. Please refer to SOLR-14022. Review comment: See https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc and you'll understand (I'm removing the boldface *Deprecations* word from the end of the CDCR bullet This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1641: SOLR-14561: Adding upgrade notes for allowPaths
janhoy commented on a change in pull request #1641: URL: https://github.com/apache/lucene-solr/pull/1641#discussion_r448982135 ## File path: solr/solr-ref-guide/src/solr-upgrade-notes.adoc ## @@ -85,11 +85,18 @@ For more information about how to use this, see the section <>. When using the `solr.xml` file shipping with 8.6, you can configure the list of paths to allow through the system property `solr.allowPaths`. Please see `bin/solr.in.sh` or `bin\solr.in.cmd` for example usage. Using the value `*` will allow any path as in erlier versions. + +Windows SMB shares on the UNC format, such as `\\myhost\myshare\mypath` are now always disallowed. Please use drive letter mounts instead, i.e. `S:\mypath`. -* Cross Data Center Replication (CDCR), in its current form, is deprecated and is scheduled to be removed in 9.0. Please refer to SOLR-14022. Review comment: @chatman You had two *Deprecations* headlines in your upgrade note, and I remove the extra one in this commit This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy opened a new pull request #1641: SOLR-14561: Adding upgrade notes for allowPaths
janhoy opened a new pull request #1641: URL: https://github.com/apache/lucene-solr/pull/1641 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9286) FST arc.copyOf clones BitTables and this can lead to excessive memory use
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150210#comment-17150210 ] Michael Sokolov commented on LUCENE-9286: - > I noticed JapaneseAnalyzer perf test has been added (maybe yesterday?) Yay! And thank you for your work on this too, [~tomoko]. Now we can inovate with confidence :) > FST arc.copyOf clones BitTables and this can lead to excessive memory use > - > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Assignee: Bruno Roustant >Priority: Major > Fix For: 8.6 > > Attachments: screen-[1].png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9286) FST arc.copyOf clones BitTables and this can lead to excessive memory use
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150197#comment-17150197 ] Tomoko Uchida commented on LUCENE-9286: --- For status update: I noticed JapaneseAnalyzer perf test has been added (maybe yesterday?) to [https://home.apache.org/~mikemccand/lucenebench/analyzers.html], by the effort of the PR to luceneutil (thank you [~johtani] and [~mikemccand]!) I hope this will be a great help for FST hackers as well as devs who are interested in JapaneseTokenizer. > FST arc.copyOf clones BitTables and this can lead to excessive memory use > - > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Assignee: Bruno Roustant >Priority: Major > Fix For: 8.6 > > Attachments: screen-[1].png > > Time Spent: 1h 50m > Remaining Estimate: 0h > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14617) Remove DIH from 9.0
Ishan Chattopadhyaya created SOLR-14617: --- Summary: Remove DIH from 9.0 Key: SOLR-14617 URL: https://issues.apache.org/jira/browse/SOLR-14617 Project: Solr Issue Type: Sub-task Affects Versions: master (9.0) Reporter: Ishan Chattopadhyaya Remove DIH from 9.0. This was deprecated in SOLR-14066. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14617) Remove DIH from 9.0
[ https://issues.apache.org/jira/browse/SOLR-14617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya reassigned SOLR-14617: --- Assignee: Ishan Chattopadhyaya > Remove DIH from 9.0 > --- > > Key: SOLR-14617 > URL: https://issues.apache.org/jira/browse/SOLR-14617 > Project: Solr > Issue Type: Sub-task >Affects Versions: master (9.0) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > > Remove DIH from 9.0. This was deprecated in SOLR-14066. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14616) Remove CDCR from 9.0
Ishan Chattopadhyaya created SOLR-14616: --- Summary: Remove CDCR from 9.0 Key: SOLR-14616 URL: https://issues.apache.org/jira/browse/SOLR-14616 Project: Solr Issue Type: Sub-task Affects Versions: master (9.0) Reporter: Ishan Chattopadhyaya Assignee: Ishan Chattopadhyaya This was deprecated in SOLR-14022 and should be removed in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150191#comment-17150191 ] Ishan Chattopadhyaya edited comment on SOLR-14066 at 7/2/20, 11:14 AM: --- [~janhoy], would you like to send this out now? https://issues.apache.org/jira/browse/SOLR-14066?focusedCommentId=16996530&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16996530 was (Author: ichattopadhyaya): [~janhoy], would you like to send this out now? https://issues.apache.org/jira/browse/SOLR-14066?focusedCommentId=16995133&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16995133 > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150191#comment-17150191 ] Ishan Chattopadhyaya commented on SOLR-14066: - [~janhoy], would you like to send this out now? https://issues.apache.org/jira/browse/SOLR-14066?focusedCommentId=16995133&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16995133 > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-14066. - Resolution: Fixed Thanks everyone. I'll proceed to create a subtask of SOLR-13138 to remove this from master. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150188#comment-17150188 ] ASF subversion and git services commented on SOLR-14066: Commit 755d31c4933a5b9bb8e39e5e9fb50b17934ff336 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=755d31c ] SOLR-14066: Deprecate DIH > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150187#comment-17150187 ] ASF subversion and git services commented on SOLR-14066: Commit 7b677ca6130543b8210b45607ee0f56bceaa0426 in lucene-solr's branch refs/heads/branch_8_6 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7b677ca ] SOLR-14066: Deprecate DIH > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150189#comment-17150189 ] ASF subversion and git services commented on SOLR-14066: Commit dd6d1c90c8faabd49823ee3d1ed4070e4ed08e5c in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=dd6d1c9 ] SOLR-14066: Deprecate DIH > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya resolved SOLR-14022. - Resolution: Fixed Thanks to everyone. I'll proceed to remove it from master in a separate issue. > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150185#comment-17150185 ] ASF subversion and git services commented on SOLR-14022: Commit d79fbb6bca53277cbf1fb2d840ea120b22a33a91 in lucene-solr's branch refs/heads/branch_8_6 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d79fbb6 ] SOLR-14022: Deprecate CDCR > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150184#comment-17150184 ] ASF subversion and git services commented on SOLR-14022: Commit b135d3fc825633ba383edce2b619aa5226f042e4 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b135d3f ] SOLR-14022: Deprecate CDCR > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14022) Deprecate CDCR from Solr in 8.x
[ https://issues.apache.org/jira/browse/SOLR-14022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150183#comment-17150183 ] ASF subversion and git services commented on SOLR-14022: Commit 7c593b1940fd5026275313db6631e8367aecb2e4 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7c593b1 ] SOLR-14022: Deprecate CDCR > Deprecate CDCR from Solr in 8.x > --- > > Key: SOLR-14022 > URL: https://issues.apache.org/jira/browse/SOLR-14022 > Project: Solr > Issue Type: Improvement > Components: CDCR >Reporter: Joel Bernstein >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket will deprecate CDCR in Solr 8x. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija commented on pull request #1574: SOLR-14566: Add request-ID to all distrib-search requests
gerlowskija commented on pull request #1574: URL: https://github.com/apache/lucene-solr/pull/1574#issuecomment-652934406 > All I would request is for users to be able to provide their own request-id which should disable the auto-generation of request id inside solr if present This is actually how it works currently- if there's already an 'rid' param present, SearchHandler will use that value and propagate it, in lieu of generating its own. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] rmuir commented on pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
rmuir commented on pull request #1608: URL: https://github.com/apache/lucene-solr/pull/1608#issuecomment-652931712 I'm -1 to this approach because it breaks the use of the OS cache (I stated this on the JIRA issue, it was ignored, I don't want anyone to forget). Because we use the os filesystem cache, any encryption must also be done by os (filesystem, block level, etc) so that page caching works correctly. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150121#comment-17150121 ] Jan Høydahl commented on SOLR-6152: --- This is great. My comments: * Can you add to the patch a line for solr/CHANGES.txt ? Add it to the 8.7 section. * The terms "Request-Handler (REST result)" and "Query-Handler (debug form)" does not instantly make sense for me. * Do we need to add another text box for the AdminUI link? It will be exactly the same as the URL in browser address bar? * So my suggestion is to keep the "Request-Handler (REST result)" text with "Copy to clipboard" button, but then add another button next to it "Copy link to this Admin page" or similar. > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Priority: Major > Attachments: SOLR-6152.patch, copy_url_to_clipboard.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9416) Fix CheckIndex to print norms as unsigned integers
[
https://issues.apache.org/jira/browse/LUCENE-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150086#comment-17150086
]
Mohammad Sadiq commented on LUCENE-9416:
Thank you [~mikemccand] ! I'll work on first setting up a test case where such
a value is generated and then fix {{CheckIndex}} to address it.
> Fix CheckIndex to print norms as unsigned integers
> --
>
> Key: LUCENE-9416
> URL: https://issues.apache.org/jira/browse/LUCENE-9416
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
>Reporter: Mohammad Sadiq
>Priority: Minor
>
> In the [discussion on "CheckIndex complaining about -1 for norms value" in
> the java-user list|http://markmail.org/message/gcwdhasblsyovwc2], it was
> identified that we should "fix CheckIndex to print norms as unsigned
> integers".
> I'd like to take a stab at this.
> I'm trying to understand the problem and from what I gather, while norms are
> `byte`s, the API exposes them as `long` values. While printing the error
> message, we want it to print a zero instead of -1?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
juanka588 commented on a change in pull request #1608:
URL: https://github.com/apache/lucene-solr/pull/1608#discussion_r448853099
##
File path:
lucene/core/src/java/org/apache/lucene/util/crypto/AesCtrEncrypter.java
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.util.crypto;
+
+import java.nio.ByteBuffer;
+
+/**
+ * Stateful Encrypter specialized for AES algorithm in CTR (counter) mode with
no padding.
+ * In CTR mode, encryption and decryption are actually the same operation,
so this API does not require to specify
+ * whether it is used to encrypt or decrypt.
+ * An {@link AesCtrEncrypter} must be first {@link #init(long) initialized}
before it can be used to
+ * {@link #process(ByteBuffer, ByteBuffer) encrypt/decrypt}.
+ * Not thread safe.
+ *
+ * @lucene.experimental
+ */
+public interface AesCtrEncrypter extends Cloneable {
+
+ /**
+ * Initializes this encrypter at the provided CTR block counter (counter of
blocks of size {@link EncryptionUtil#AES_BLOCK_SIZE}).
+ * For example, the data byte at index i is inside the block at counter =
i / {@link EncryptionUtil#AES_BLOCK_SIZE}.
+ * CTR mode computes an IV for this block based on the initial IV (at
counter 0) and the provided counter. This allows
+ * efficient random access to encrypted data. Only the target block needs to
be decrypted.
+ * This method must be called first. Then the next call to {@link
#process(ByteBuffer, ByteBuffer)} will start at the
+ * beginning of the block: the first byte of data at input buffer {@link
ByteBuffer#position()} must be the first byte
+ * of the block.
+ */
+ void init(long counter);
Review comment:
setPosition(), setBlockPosoition(), moveToBlock()?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1608: LUCENE-9379: Encrypting Directory - functional but to optimize
juanka588 commented on a change in pull request #1608:
URL: https://github.com/apache/lucene-solr/pull/1608#discussion_r448853099
##
File path:
lucene/core/src/java/org/apache/lucene/util/crypto/AesCtrEncrypter.java
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.util.crypto;
+
+import java.nio.ByteBuffer;
+
+/**
+ * Stateful Encrypter specialized for AES algorithm in CTR (counter) mode with
no padding.
+ * In CTR mode, encryption and decryption are actually the same operation,
so this API does not require to specify
+ * whether it is used to encrypt or decrypt.
+ * An {@link AesCtrEncrypter} must be first {@link #init(long) initialized}
before it can be used to
+ * {@link #process(ByteBuffer, ByteBuffer) encrypt/decrypt}.
+ * Not thread safe.
+ *
+ * @lucene.experimental
+ */
+public interface AesCtrEncrypter extends Cloneable {
+
+ /**
+ * Initializes this encrypter at the provided CTR block counter (counter of
blocks of size {@link EncryptionUtil#AES_BLOCK_SIZE}).
+ * For example, the data byte at index i is inside the block at counter =
i / {@link EncryptionUtil#AES_BLOCK_SIZE}.
+ * CTR mode computes an IV for this block based on the initial IV (at
counter 0) and the provided counter. This allows
+ * efficient random access to encrypted data. Only the target block needs to
be decrypted.
+ * This method must be called first. Then the next call to {@link
#process(ByteBuffer, ByteBuffer)} will start at the
+ * beginning of the block: the first byte of data at input buffer {@link
ByteBuffer#position()} must be the first byte
+ * of the block.
+ */
+ void init(long counter);
Review comment:
setPosition(), setBlockPosition(), moveToBlock()?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14615) CPU Based Circuit Breaker
Atri Sharma created SOLR-14615: -- Summary: CPU Based Circuit Breaker Key: SOLR-14615 URL: https://issues.apache.org/jira/browse/SOLR-14615 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Atri Sharma We should have a circuit breaker that can monitor and trigger on CPU utilization -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma resolved SOLR-14588. Resolution: Fixed > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 13.5h > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149998#comment-17149998 ] ASF subversion and git services commented on SOLR-14588: Commit 3f9cc227f159f1e0583dd5aad2ec7a8bd102415f in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3f9cc22 ] SOLR-14588: Implement Circuit Breakers (#1626) * SOLR-14588: Implement Circuit Breakers This commit consists of two parts: add circuit breakers infrastructure and a "real" JVM heap memory based circuit breaker which monitors incoming search requests and rejects them with SERVICE_TOO_BUSY error if the defined threshold is breached, thus giving headroom to existing indexing and search requests to complete. > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 13.5h > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1714#comment-1714 ] ASF subversion and git services commented on SOLR-14588: Commit 3f9cc227f159f1e0583dd5aad2ec7a8bd102415f in lucene-solr's branch refs/heads/master from Atri Sharma [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3f9cc22 ] SOLR-14588: Implement Circuit Breakers (#1626) * SOLR-14588: Implement Circuit Breakers This commit consists of two parts: add circuit breakers infrastructure and a "real" JVM heap memory based circuit breaker which monitors incoming search requests and rejects them with SERVICE_TOO_BUSY error if the defined threshold is breached, thus giving headroom to existing indexing and search requests to complete. > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 13.5h > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris merged pull request #1626: SOLR-14588: Implement Circuit Breakers
atris merged pull request #1626: URL: https://github.com/apache/lucene-solr/pull/1626 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
