[jira] [Commented] (SOLR-14871) Use Annotations for v2 APIs in/cluster path
[ https://issues.apache.org/jira/browse/SOLR-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380438#comment-17380438 ] Noble Paul commented on SOLR-14871: --- Let's close this > Use Annotations for v2 APIs in/cluster path > --- > > Key: SOLR-14871 > URL: https://issues.apache.org/jira/browse/SOLR-14871 > Project: Solr > Issue Type: Sub-task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We have custom json specs for each of these APIs. With the annotation > framework , it can be made simple and readable and we can eliminate a lot of > code -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] cpoerschke commented on a change in pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
cpoerschke commented on a change in pull request #219: URL: https://github.com/apache/solr/pull/219#discussion_r669515038 ## File path: solr/solrj/src/java/org/apache/solr/common/cloud/VMParamsAllAndReadonlyDigestZkACLProvider.java ## @@ -30,6 +30,12 @@ public static final String DEFAULT_DIGEST_READONLY_USERNAME_VM_PARAM_NAME = "zkDigestReadonlyUsername"; public static final String DEFAULT_DIGEST_READONLY_PASSWORD_VM_PARAM_NAME = "zkDigestReadonlyPassword"; + + // fallback env vars if system props not set + public static final String ZK_ALL_ACL_USERNAME = "ZK_ALL_ACL_USERNAME"; + public static final String ZK_ALL_ACL_PASSWORD = "ZK_ALL_ACL_PASSWORD"; + public static final String ZK_READ_ACL_USERNAME = "ZK_READ_ACL_USERNAME"; + public static final String ZK_READ_ACL_PASSWORD = "ZK_READ_ACL_PASSWORD"; Review comment: `zkDigestReadonly*` is mentioned in `zookeeper-access-control.adoc` - maybe also mention these alternatives there? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15537) split 10-args LTRRescorer.scoreSingleHit method
Christine Poerschke created SOLR-15537: -- Summary: split 10-args LTRRescorer.scoreSingleHit method Key: SOLR-15537 URL: https://issues.apache.org/jira/browse/SOLR-15537 Project: Solr Issue Type: Task Components: contrib - LTR Reporter: Christine Poerschke Assignee: Christine Poerschke As part of the SOLR-14920 automatic code formatting effort it was noticed that the method has 10 arguments which is rather a lot. Since the method actually does "score and log" logic one way to split it would be into "score" and "log" logic methods. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] cpoerschke commented on pull request #192: SOLR-15537: split 10-args LTRRescorer.scoreSingleHit method
cpoerschke commented on pull request #192: URL: https://github.com/apache/solr/pull/192#issuecomment-879812736 @alessandrobenedetti and/or @madrob - perhaps you would be interested in reviewing this change? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-14871) Use Annotations for v2 APIs in/cluster path
[ https://issues.apache.org/jira/browse/SOLR-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-14871: --- Fix Version/s: main (9.0) > Use Annotations for v2 APIs in/cluster path > --- > > Key: SOLR-14871 > URL: https://issues.apache.org/jira/browse/SOLR-14871 > Project: Solr > Issue Type: Sub-task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: main (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > We have custom json specs for each of these APIs. With the annotation > framework , it can be made simple and readable and we can eliminate a lot of > code -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Resolved] (SOLR-14871) Use Annotations for v2 APIs in/cluster path
[ https://issues.apache.org/jira/browse/SOLR-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski resolved SOLR-14871. Resolution: Fixed > Use Annotations for v2 APIs in/cluster path > --- > > Key: SOLR-14871 > URL: https://issues.apache.org/jira/browse/SOLR-14871 > Project: Solr > Issue Type: Sub-task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > We have custom json specs for each of these APIs. With the annotation > framework , it can be made simple and readable and we can eliminate a lot of > code -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-14871) Use Annotations for v2 APIs in/cluster path
[ https://issues.apache.org/jira/browse/SOLR-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gerlowski updated SOLR-14871: --- Fix Version/s: 8.7 > Use Annotations for v2 APIs in/cluster path > --- > > Key: SOLR-14871 > URL: https://issues.apache.org/jira/browse/SOLR-14871 > Project: Solr > Issue Type: Sub-task >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 8.7, main (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > We have custom json specs for each of these APIs. With the annotation > framework , it can be made simple and readable and we can eliminate a lot of > code -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
epugh commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-879886897 Just reading this, are we adding "YAWTCS": _Yet Another Way To Configure Solr?I wonder if it's worth taking a pass through Solr and figuring out how to use this same pattern across all our various system properties? For example, today we support `-Dsolr.auth.jwt.allowOutboundHttp=true`.Could we extend this pattern to allow `-Dsolr.auth.jwt.allowOutboundHttp=env:SOME_ENV_VAR`?Or is this a situation that ONLY would every apply to Zookeeper ACL and wouldn't make sense elsewhere. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15428) Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and performance comparisons and investigation.
[ https://issues.apache.org/jira/browse/SOLR-15428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380602#comment-17380602 ] Mark Robert Miller commented on SOLR-15428: --- I've moved this to a pull request and straightened out the issues I mentioned above (with a couple things left to do on the refactored DocMaker). I'll have to double check, but I recall seeing an issue around no longer distributing a test-framework jar, in which case, not much else should be needed for the core integration. Otherwise, the jmh jar will need to be excluded from an dist builds. > Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and > performance comparisons and investigation. > --- > > Key: SOLR-15428 > URL: https://issues.apache.org/jira/browse/SOLR-15428 > Project: Solr > Issue Type: New Feature >Reporter: Mark Robert Miller >Priority: Major > Attachments: bench.patch > > Time Spent: 20m > Remaining Estimate: 0h > > I’ve spent a fair amount of time over the years on work around integrating > Lucene’s benchmark framework into Solr and while I’ve used this with > additional local work off and on, JMH has become somewhat of a standard for > micro benchmarks on the JVM. I have some work that provides an initial > integration, allowing for more targeted micro benchmarks as well as more > integration type benchmarking using JettySolrRunner. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15538) Update Lucene Preview Release dependency
Mark Robert Miller created SOLR-15538: - Summary: Update Lucene Preview Release dependency Key: SOLR-15538 URL: https://issues.apache.org/jira/browse/SOLR-15538 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Robert Miller -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-13933) Cluster mode Stress test suite
[
https://issues.apache.org/jira/browse/SOLR-13933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380606#comment-17380606
]
Ishan Chattopadhyaya commented on SOLR-13933:
-
{quote}Thanks Erick! It is about time that we bring in tight policing to defend
against attacks like SOLR-14665.
{quote}
I apologize for using the word "attack" here, as it may imply this slowdown was
deliberate and it wasn't. However, my goal remains for us to be committed to
performance benchmarks based policing of our commits.
> Cluster mode Stress test suite
> ---
>
> Key: SOLR-13933
> URL: https://issues.apache.org/jira/browse/SOLR-13933
> Project: Solr
> Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
>
> We need a stress test harness based on 10s or 100s of nodes, 1000s of
> collection API operations, overseer operations etc. This suite should run
> nightly, publish results publicly, so as to help with:
> # Uncover stability problems
> # Benchmarking (timings, resource metrics etc.) on collection operations
> # Indexing/querying performance
> # Validate the accuracy of potential improvements
> References:
> SOLR-10317
> https://github.com/lucidworks/solr-scale-tk
> https://github.com/shalinmangar/solr-perf-tools
> Lucene benchmarks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15539) Setup publicly repeated automated benchmarks
Ishan Chattopadhyaya created SOLR-15539: --- Summary: Setup publicly repeated automated benchmarks Key: SOLR-15539 URL: https://issues.apache.org/jira/browse/SOLR-15539 Project: Solr Issue Type: Sub-task Components: benchmarks Reporter: Ishan Chattopadhyaya Exploring an e-commerce events timeseries dataset that can be used for periodic benchmarks. The dataset is here: [https://www.kaggle.com/mkechinov/ecommerce-behavior-data-from-multi-category-store]. Since this is non-commercial use of this dataset, only for performance benchmarks, I think it is fair use. My goal is to use this dataset to benchmark indexing, faceting, join performance. Will use the benchmarking suite developed as part of SOLR-10317 and SOLR-13933. Details here: https://searchscale.com/blog/solr-bench/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on a change in pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on a change in pull request #219: URL: https://github.com/apache/solr/pull/219#discussion_r669644632 ## File path: solr/solrj/src/java/org/apache/solr/common/cloud/VMParamsAllAndReadonlyDigestZkACLProvider.java ## @@ -30,6 +30,12 @@ public static final String DEFAULT_DIGEST_READONLY_USERNAME_VM_PARAM_NAME = "zkDigestReadonlyUsername"; public static final String DEFAULT_DIGEST_READONLY_PASSWORD_VM_PARAM_NAME = "zkDigestReadonlyPassword"; + + // fallback env vars if system props not set + public static final String ZK_ALL_ACL_USERNAME = "ZK_ALL_ACL_USERNAME"; + public static final String ZK_ALL_ACL_PASSWORD = "ZK_ALL_ACL_PASSWORD"; + public static final String ZK_READ_ACL_USERNAME = "ZK_READ_ACL_USERNAME"; + public static final String ZK_READ_ACL_PASSWORD = "ZK_READ_ACL_PASSWORD"; Review comment: will do! -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-879921695 > Just reading this, are we adding "YAWTCS": _Yet Another Way To Configure Solr? I wonder if it's worth taking a pass through Solr and figuring out how to use this same pattern across all our various system properties? For example, today we support `-Dsolr.auth.jwt.allowOutboundHttp=true`. Could we extend this pattern to allow `-Dsolr.auth.jwt.allowOutboundHttp=env:SOME_ENV_VAR`? Or is this a situation that ONLY would every apply to Zookeeper ACL and wouldn't make sense elsewhere. I think only sensitive properties like credentials need this pattern as the main problem here is exposing credentials in Java sys props -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
epugh commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-879933198 > > Just reading this, are we adding "YAWTCS": _Yet Another Way To Configure Solr? I wonder if it's worth taking a pass through Solr and figuring out how to use this same pattern across all our various system properties? For example, today we support `-Dsolr.auth.jwt.allowOutboundHttp=true`. Could we extend this pattern to allow `-Dsolr.auth.jwt.allowOutboundHttp=env:SOME_ENV_VAR`? Or is this a situation that ONLY would every apply to Zookeeper ACL and wouldn't make sense elsewhere. > > I think only sensitive properties like credentials need this pattern as the main problem here is exposing credentials in Java sys props So if this works well, maybe apply this to other places like `-Djavax.net.ssl.keyStorePassword=secret`? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-879940832 You can use `EnvSSLCredentialProvider` for setting the keystore / truststore passwords from env vars. We could emulate that approach for ZK ACL creds by introducing new provider impls but then felt the `env:` was more expedient. I'm open to the alternative approach though (emulating EnvSSLCredentialProvider) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15540) Duplicated add document when Solr7 upgrade to Solr8
samuel ma created SOLR-15540:
Summary: Duplicated add document when Solr7 upgrade to Solr8
Key: SOLR-15540
URL: https://issues.apache.org/jira/browse/SOLR-15540
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: update, UpdateRequestProcessors
Affects Versions: 8.8.2
Environment: SolrCloud Solr 8.8.2
Reporter: samuel ma
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested in Solr8
{code:java}
{code}
Also I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated add document when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested in Solr8
{code:java}
{code}
Also I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated add document when Solr7 upgrade to Solr8
> ---
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
>
>
> Below is the schema.xml configuration:
>
> {code:java}
> multiValued="false" />
>
> id
> {code}
>
> Also add nested field in Solr8
> {code:java}
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Summary: Duplicated adding document for update when Solr7 upgrade to Solr8
(was: Duplicated adding document when Solr7 upgrade to Solr8)
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
>
>
> Below is the schema.xml configuration:
>
> {code:java}
> multiValued="false" />
>
> id
> {code}
>
> Also add nested field in Solr8
> {code:java}
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Summary: Duplicated adding document when Solr7 upgrade to Solr8 (was:
Duplicated add document when Solr7 upgrade to Solr8)
> Duplicated adding document when Solr7 upgrade to Solr8
> ---
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
>
>
> Below is the schema.xml configuration:
>
> {code:java}
> multiValued="false" />
>
> id
> {code}
>
> Also add nested field in Solr8
> {code:java}
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15428) Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and performance comparisons and investigation.
[ https://issues.apache.org/jira/browse/SOLR-15428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380657#comment-17380657 ] Mark Robert Miller commented on SOLR-15428: --- Jmh integration Why? Micro-benchmarks are hard. jmh comes from OpenJDK and is widely used. What about the work building on the Lucene Benchmark module? That was a fruitful path, but came with some downsides: * You had to learn the algorithm syntax. * You had to map solrj functionality to algorithm syntax. * The solrj bias is limiting. * Overall, less suited for low level micro-benchmarks, steeper learning curve, historical perspective says there won’t be a lot of developer activity. With jmh, low level micro-benchmarking is simple and testing single actions against a MiniCluster is viable and I have later found out, not treading new ground. The benchmarks are not solrj biased, graphing and sharing results is simple, treating benchmarks like unit tests is relatively straightforward, jmh is widely used and developer adoption is much simpler overall. Why not use the jmh Gradle plugin? The jmh build plugins generally work by creating a large single jar with shading. This is both costly and not always simple with our Gradle build setup. With a more direct jmh Gradle integration, we can avoid the ‘fat’ jar and shadowing and directly pass the correct information from the build to jmh. This was a bit tricky with our build to work out, but its straightforward and a small amount of Gradle. > Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and > performance comparisons and investigation. > --- > > Key: SOLR-15428 > URL: https://issues.apache.org/jira/browse/SOLR-15428 > Project: Solr > Issue Type: New Feature >Reporter: Mark Robert Miller >Priority: Major > Attachments: bench.patch > > Time Spent: 20m > Remaining Estimate: 0h > > I’ve spent a fair amount of time over the years on work around integrating > Lucene’s benchmark framework into Solr and while I’ve used this with > additional local work off and on, JMH has become somewhat of a standard for > micro benchmarks on the JVM. I have some work that provides an initial > integration, allowing for more targeted micro benchmarks as well as more > integration type benchmarking using JettySolrRunner. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
>
>
> Below is the schema.xml configuration:
>
> {code:java}
> multiValued="false" />
>
> id
> {code}
>
> Also add nested field in Solr8
> {code:java}
>
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
>
>
> Below is the schema.xml configuration:
>
> {code:java}
> multiValued="false" />
> id
> {code}
>
> Also add nested field in Solr8
> {code:java}
>
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration:
{code:java}
id
{code}
Also add nested field in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
> {code}
>
> Add some fields in Solr8
> {code:java}
>
>
> {code}
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
{code:java}
{code}
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
>
> {code}
>
> Add some fields in Solr8
>
>
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
>
> {code}
>
> Add some fields in Solr8
>
>
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior? how do we handle this?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #282: Allow changing the livenessPrope settings for prometheus exporter
HoustonPutman commented on issue #282: URL: https://github.com/apache/solr-operator/issues/282#issuecomment-879994152 Thanks for suggesting this @benediktarnold , and especially backing it up with such clear results. I think that adding support for changing all the probes for the PrometheusExporter is a no-brainer, and should be very simple to do. But if the performance using the default probes is this bad, we should probably look at options for changing the default behavior as well. Maybe one solution is to add an actual health-check handler to the PrometheusExporter itself (in Solr), that just checks that the metrics cache is healthy, and the jetty server responds. A second question, what version of the prometheus exporter are you using? It seems weird to me that additional calls to `/metrics` would be that expensive, given that all the metrics _should_ be cached in the first place. Maybe it's very expensive to generate the long response? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-880001765 Latest commit here drops the `env:` approach and introduces new providers that read from env vars ... seems a bit heavy handed to me but is more inline with the `EnvSSLCredentialProvider` approach already in the code base. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #264: Specifiy/Create a service account used by the created SolrCloud
HoustonPutman commented on issue #264: URL: https://github.com/apache/solr-operator/issues/264#issuecomment-880013205 @thomaswoeckinger I'm working on the custom `serviceAccountName` now, and that is very straightforward. > This makes it impossible to run on OKD, because default security constraints deny the usage of fsGroup 8983. This might be harder to fix. The reason we use fsGroup 8983 is because the Solr docker image uses the [8983 user](https://github.com/docker-solr/docker-solr/blob/master/8.9/Dockerfile#L26) to [own `/var/solr`](https://github.com/docker-solr/docker-solr/blob/master/8.9/Dockerfile#L112) (the data directory) I might be wrong here, but I believe that's why it was `fsGroup` has always been set to 8983. We can definitely look at changing that in the future, I want the solr-operator to be fully OKD compatible, but it will be more work than making the serviceAccountName configurable. Are you able to get OKD to work with the 8983 `fsGroup` with a custom service account? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15541) opt-in support to INFO log all parameters on error
Christine Poerschke created SOLR-15541:
--
Summary: opt-in support to INFO log all parameters on error
Key: SOLR-15541
URL: https://issues.apache.org/jira/browse/SOLR-15541
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
* The
[logParamsList|https://solr.apache.org/guide/8_9/common-query-parameters.html#logparamslist-parameter]
parameter (available from Solr 4.7 onwards via SOLR-5672) is useful if full
request logging on each of multiple shards is just 'too much' and/or if the
content being logged is to be redacted e.g. to only log opaque request
identifiers but not request details.
** A downside of reduced logging is that less detail is available when
investigating issues.
* The
[echoParams|https://solr.apache.org/guide/8_9/common-query-parameters.html#echoparams-parameter]
parameter controls what information about request parameters is included in
the response header.
** With respect to investating of issues it's worth noting here that
{{echoParams=explicit}} is the default value and that routine use of
{{echoParams=all}} would return more details to the client but that details of
within-Solr requests e.g. requests using the {{group.distributed.first}} and
{{group.distributed.second}} [group
parameters|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.9.0/solr/solrj/src/java/org/apache/solr/common/params/GroupParams.java#L60-L66]
would _not_ be captured.
This ticket proposes to add a new parameter, called (say)
{{logAllParamsOnError}} whose use will result in all parameters being logged on
error, irrespective of the presence or value of the {{logParamsList}} parameter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15541) opt-in support to INFO log all parameters on error
[
https://issues.apache.org/jira/browse/SOLR-15541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380710#comment-17380710
]
Christine Poerschke commented on SOLR-15541:
The new parameter could be called (say) {{logAllParamsOnError}} with some or
all of the values below supported.
{code}
...&logAllParamsOnError=false # equivalent to existing behaviour
...&logAllParamsOnError=true # new opt-in behaviour
...&logAllParamsOnError=123,456 # log for status=123 and status=456 but not any
other status codes
...&logAllParamsOnError=400,0 # log for status=400 and status=0 (technically
status=0 is not an error, so this is slight misuse)
...&logAllParamsOnError=* # log for all status codes including status=0 (might
be too complex to support this)
{code}
{{logAllParamsStatusCodes}} could be an alternative name if we wanted to make
{{logAllParamsStatusCodes=400,0}} a legitimate use, noting that the difference
between non-use of {{logParamsList}} and use of {{logAllParamsStatusCodes=0}}
is the logging of non-original request parameters.
illustrative log extracts:
* without {{logParamsList}} use
{code}
# curl
"http://localhost:8983/solr/gettingstarted/select?q=*:*&fl=id&opaqueRequestId=foobar&logAllParamsOnError=*";
2021-07-14 15:42:48.356 INFO (qtp712627377-24) [c:gettingstarted s:shard2
r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request
[gettingstarted_shard2_replica_n4] webapp=/solr path=/select
params={q=*:*&opaqueRequestId=foobar&fl=id&logAllParamsOnError=*}
rid=localhost-5 hits=48 status=0 QTime=5
allParams={q=*:*&opaqueRequestId=foobar&df=_text_&echoParams=explicit&fl=id&logAllParamsOnError=*&rows=10&rid=localhost-5}
{code}
* with {{logParamsList}} use
{code}
# curl
"http://localhost:8983/solr/gettingstarted/select?q=*:*&fl=id&opaqueRequestId=barfoo&logAllParamsOnError=*&logParamsList=opaqueRequestId";
2021-07-14 15:44:51.488 INFO (qtp712627377-82) [c:gettingstarted s:shard1
r:core_node3 x:gettingstarted_shard1_replica_n1] o.a.s.c.S.Request
[gettingstarted_shard1_replica_n1] webapp=/solr path=/select
params={opaqueRequestId=barfoo} rid=localhost-6 hits=48 status=0 QTime=13
allParams={q=*:*&opaqueRequestId=barfoo&df=_text_&echoParams=explicit&fl=id&logAllParamsOnError=*&logParamsList=opaqueRequestId&rows=10&rid=localhost-6}
{code}
> opt-in support to INFO log all parameters on error
> --
>
> Key: SOLR-15541
> URL: https://issues.apache.org/jira/browse/SOLR-15541
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> * The
> [logParamsList|https://solr.apache.org/guide/8_9/common-query-parameters.html#logparamslist-parameter]
> parameter (available from Solr 4.7 onwards via SOLR-5672) is useful if full
> request logging on each of multiple shards is just 'too much' and/or if the
> content being logged is to be redacted e.g. to only log opaque request
> identifiers but not request details.
> ** A downside of reduced logging is that less detail is available when
> investigating issues.
> * The
> [echoParams|https://solr.apache.org/guide/8_9/common-query-parameters.html#echoparams-parameter]
> parameter controls what information about request parameters is included in
> the response header.
> ** With respect to investating of issues it's worth noting here that
> {{echoParams=explicit}} is the default value and that routine use of
> {{echoParams=all}} would return more details to the client but that details
> of within-Solr requests e.g. requests using the {{group.distributed.first}}
> and {{group.distributed.second}} [group
> parameters|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.9.0/solr/solrj/src/java/org/apache/solr/common/params/GroupParams.java#L60-L66]
> would _not_ be captured.
> This ticket proposes to add a new parameter, called (say)
> {{logAllParamsOnError}} whose use will result in all parameters being logged
> on error, irrespective of the presence or value of the {{logParamsList}}
> parameter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] cpoerschke opened a new pull request #220: SOLR-15541: Add logAllParamsOnError parameter support.
cpoerschke opened a new pull request #220: URL: https://github.com/apache/solr/pull/220 https://issues.apache.org/jira/browse/SOLR-15541 Not yet done/Yet to do list: * [ ] Solr Ref Guide update * [ ] comprehensive testing * [ ] solr/CHANGES.txt entry -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman opened a new pull request #283: Ability to customize serviceAccountName for SolrCloud and SolrPrometheusExporter
HoustonPutman opened a new pull request #283: URL: https://github.com/apache/solr-operator/pull/283 Resolves #264 The option will be available via: **SolrCloud** ```yaml spec: customSolrKubeOptions: podOptions: serviceAccountName: "" ``` **SolrPrometheusExporter** ```yaml spec: customKubeOptions: podOptions: serviceAccountName: "" ``` -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-880030205 fwiw ~ I just checked 8.9 and it shows the zk passwords as REDACTED in the UI, so I'm not even sure how useful this change is at this point ?!? probably just going to leave it open for now vs. merging ... -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15525) Provide zkCredentialsProvider and zkACLProvider that loads credentials from a file or env vars instead of sys props
[
https://issues.apache.org/jira/browse/SOLR-15525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter updated SOLR-15525:
--
Priority: Minor (was: Major)
> Provide zkCredentialsProvider and zkACLProvider that loads credentials from a
> file or env vars instead of sys props
> ---
>
> Key: SOLR-15525
> URL: https://issues.apache.org/jira/browse/SOLR-15525
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Timothy Potter
>Assignee: Timothy Potter
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, the {{VMParamsSingleSetCredentialsDigestZkCredentialsProvider}}
> and {{VMParamsAllAndReadonlyDigestZkACLProvider}} load ZK credentials from
> Java system properties. Solr should provide an alternative impl to load this
> information from a file (and maybe env vars too). This avoids leaking the
> credentials in the JVM system properties that get logged as well as shown in
> the UI.
> It would also be nice if this file could store the credentials encrypted, as
> suggested by SOLR-11655, however that requires a global encryption password
> (such as http://www.jasypt.org/) so is merely security through obscurity b/c
> anyone with shell access could track down this encryption password and
> decrypt the ZK credentials in the file. Of course every Solr node has its own
> private key for the PKI auth frmk, but that's not helpful for this problem
> because the encryption key needs to be shared among all the nodes so they can
> decrypt the ZK creds. So I'm going to skip that part for now and just
> implement loading the plain-text creds from a file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] madrob commented on pull request #13: SOLR-14690: QueryResultKey.[nc_]minExactCount
madrob commented on pull request #13: URL: https://github.com/apache/solr/pull/13#issuecomment-880037020 Would it be more straightforward to use a solrconfig.xml that has auto warm count set to zero on the caches of interest? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] benediktarnold commented on issue #282: Allow changing the livenessPrope settings for prometheus exporter
benediktarnold commented on issue #282: URL: https://github.com/apache/solr-operator/issues/282#issuecomment-880044518 > Maybe one solution is to add an actual health-check handler to the PrometheusExporter itself (in Solr), that just checks that the metrics cache is healthy, and the jetty server responds. That seems to be a good idea. I'll look into the code and will come up with a PR or at least an issue in the solr repo. > A second question, what version of the prometheus exporter are you using? It seems weird to me that additional calls to `/metrics` would be that expensive, given that all the metrics _should_ be cached in the first place. Maybe it's very expensive to generate the long response? I thought so as well. I'm using the exporter that comes with the solr 8.7.0 Images. I'm about to upgrade to 8.9.0 and I'll let you know if that brings any advantages. I made a snapshot of a metric response once and it was about 24MB (~100 small collections on 3 solr nodes). The peak CPU usage of the exporter is far bigger than the CPU usage of my whole solr cluster. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] madrob commented on pull request #214: SOLR-15428: Integrate the OpenJDK JMH micro benchmark framework for m…
madrob commented on pull request #214: URL: https://github.com/apache/solr/pull/214#issuecomment-880056637 Can you add a task for `gradlew helpJmh` describing the various flags and usages that developers should consider? Should be straightforward as adding a line to `help.gradle` and a new file under `help/` directory. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15428) Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and performance comparisons and investigation.
[ https://issues.apache.org/jira/browse/SOLR-15428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380780#comment-17380780 ] Mark Robert Miller commented on SOLR-15428: --- I have made use of 3 categories of benchmarks. It might be nice to use naming that makes it easy to separate benchmarks at this level via the include argument. # Low level Java micro-benchmarks. Basic benchmarks of ByteBuffers, Collections, etc. The performance characteristics can change by JVM and JVM version and you often want to add in alternate implementations (for example, to compare HashMap with HPPC or FastUtil). These also provide valuable baseline information as you build and look at other micro-benchmarks. # Low level Solr micro-benchmarks. For example, benchmarking JavaBin encode and decode. # High level integration benchmarking. For example, benchmarking addDocument against a mini Solr cluster. > Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and > performance comparisons and investigation. > --- > > Key: SOLR-15428 > URL: https://issues.apache.org/jira/browse/SOLR-15428 > Project: Solr > Issue Type: New Feature >Reporter: Mark Robert Miller >Priority: Major > Attachments: bench.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > I’ve spent a fair amount of time over the years on work around integrating > Lucene’s benchmark framework into Solr and while I’ve used this with > additional local work off and on, JMH has become somewhat of a standard for > micro benchmarks on the JVM. I have some work that provides an initial > integration, allowing for more targeted micro benchmarks as well as more > integration type benchmarking using JettySolrRunner. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15330) Solr 7.5 memory leak and crash with sql injection type queries
[ https://issues.apache.org/jira/browse/SOLR-15330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380784#comment-17380784 ] Michael Gibney commented on SOLR-15330: --- Sorry for the delayed response. I _would_ guess this is likely to interact with SOLR-13336 in some way; particularly if by "doesn't happen on 8.8" you mean "doesn't crash the servers on 8.8" -- fwiw the fix for SOLR-13336 should still result in these types of queries failing (throwing an exception), but should prevent them from taking down clusters. That said, I'm still a bit uncertain: I was kind of expecting the query-time analysis chain to be capable of producing a graph, but as best I can tell, the chain you posted would _not_ produce a graph. Is it possible that there are other fieldTypes involved, with different query-time analysis? If there's no "smoking gun" graph-producing query-time analysis chain, then some _other_ component may have been constructing enormous boolean queries as a consequence of this input? Perhaps even an issue in some other component that was incidentally fixed between 7.5 and 8.8? These are complete shots in the dark, but I'm not sure what else can be done with the information available. If 8.8 fixes the issue for you, then perhaps it makes sense to not sink further energy into this issue. On the other hand, now that your clusters aren't crashing, if that means you're getting proper exceptions thrown for this kind of input, the stack traces could help illuminate the underlying cause. If in your logs you're getting stack traces for this type of input and post them, I'd be happy to take a look. > Solr 7.5 memory leak and crash with sql injection type queries > -- > > Key: SOLR-15330 > URL: https://issues.apache.org/jira/browse/SOLR-15330 > Project: Solr > Issue Type: Bug > Components: query, Server >Affects Versions: 7.5 > Environment: Java 8 on CentOS 7. >Reporter: Jitesh J Vidhani >Priority: Major > > We have a set of standalone solr nodes running on Solr 7.5. We recently had a > few episodes where the entire cluster crashed and died all together. Digging > in a little, we found the culprits were some SQL injection attacks happening > on our site where the search term had SQL injection in it and that was fed > into the q param in solr. I was able to take a stable solr and isolate it and > just run 1 query and make it crash. Every time I would run a regular query > and see it work and then just change the q= parameter and that would time out > and eventually crash the solr instance. Here is the q param for the query I > ran: > q=-6792)))+UNION+ALL+SELECT+NULL,NULL,NULL,NULL,CHR(113)||CHR(98)||CHR(118)||CHR(113)||CHR(113)||CHR(104)||CHR(68)||CHR(86)||CHR(114)||CHR(109)||CHR(97)||CHR(89)||CHR(89)||CHR(112)||CHR(76)||CHR(90)||CHR(105)||CHR(113)||CHR(86)||CHR(102)||CHR(97)||CHR(108)||CHR(89)||CHR(83)||CHR(81)||CHR(107)||CHR(69)||CHR(111)||CHR(97)||CHR(75)||CHR(87)||CHR(68)||CHR(108)||CHR(73)||CHR(68)||CHR(86)||CHR(118)||CHR(101)||CHR(71)||CHR(78)||CHR(106)||CHR(106)||CHR(76)||CHR(65)||CHR(82)||CHR(113)||CHR(106)||CHR(98)||CHR(98)||CHR(113)+FROM+DUAL--+gKiW > I even stripped out the "||" characters and replaced them with "," and it > still crashes. Please note these were SQL injection attacks and not real good > queries. The Solr GC log exposes the problem and shows the memory footprint > ballooning (from 2GB to 18GB within a minute) to the point where full garbage > collection fails and the Solr instance is unresponsive. So 1 query is able to > push it to the tipping point and consume 18GB of memory. > I have tried searching for long description texts but that works fine. So > something with these characters is probably causing this. Does anyone know > how/why this might be happening? -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #218: SOLR-15536: Rewrite /c//shards v2 APIs using annotations
gerlowskija commented on a change in pull request #218:
URL: https://github.com/apache/solr/pull/218#discussion_r669893442
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/api/SplitShardAPI.java
##
@@ -0,0 +1,87 @@
+/*
+ * 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.solr.handler.admin.api;
+
+import org.apache.commons.collections.MapUtils;
+import org.apache.commons.lang3.StringUtils;
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.api.PayloadObj;
+import org.apache.solr.client.solrj.request.beans.AddReplicaPropertyPayload;
+import org.apache.solr.client.solrj.request.beans.SplitShardPayload;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CommonAdminParams;
+import org.apache.solr.handler.admin.CollectionsHandler;
+
+import java.util.HashMap;
+import java.util.Map;
+
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.POST;
+import static org.apache.solr.common.params.CollectionAdminParams.COLLECTION;
+import static
org.apache.solr.common.params.CollectionAdminParams.PROPERTY_PREFIX;
+import static org.apache.solr.common.params.CommonParams.ACTION;
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+/**
+ * V2 API for splitting an existing shard up into multiple pieces.
+ *
+ * This API (POST /v2/collections/collectionName/shards {'split': {...}}) is
analogous to the v1
+ * /admin/collections?action=SPLITSHARD command.
+ *
+ * @see SplitShardPayload
+ */
+@EndPoint(
+path = {"/c/{collection}/shards", "/collections/{collection}/shards"},
+method = POST,
+permission = COLL_EDIT_PERM)
+public class SplitShardAPI {
+ private static final String V2_SPLIT_CMD = "split";
+
+ private final CollectionsHandler collectionsHandler;
+
+ public SplitShardAPI(CollectionsHandler collectionsHandler) {
+this.collectionsHandler = collectionsHandler;
+ }
+
+ @Command(name = V2_SPLIT_CMD)
+ public void splitShard(PayloadObj obj) throws Exception {
+final SplitShardPayload v2Body = obj.get();
+final Map v1Params = v2Body.toMap(new HashMap<>());
+v1Params.put(ACTION,
CollectionParams.CollectionAction.SPLITSHARD.toLower());
+v1Params.put(COLLECTION,
obj.getRequest().getPathTemplateValues().get(COLLECTION));
+
+if (StringUtils.isNotEmpty(v2Body.splitKey)) {
+ v1Params.put(CommonAdminParams.SPLIT_KEY, v2Body.splitKey);
+}
+if (MapUtils.isNotEmpty(v2Body.coreProperties)) {
+ flattenMapWithPrefix(v2Body.coreProperties, v1Params, PROPERTY_PREFIX);
+}
+collectionsHandler.handleRequestBody(wrapParams(obj.getRequest(),
v1Params), obj.getResponse());
+ }
+
+ private void flattenMapWithPrefix(Map toFlatten, Map destination,
Review comment:
Sometimes laziness or obliviousness gets in the way, but I'm always for
DRY in theory. Will fix.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #218: SOLR-15536: Rewrite /c//shards v2 APIs using annotations
gerlowskija commented on a change in pull request #218:
URL: https://github.com/apache/solr/pull/218#discussion_r669898730
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/request/beans/AddReplicaPayload.java
##
@@ -0,0 +1,71 @@
+/*
+ * 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.solr.client.solrj.request.beans;
+
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.common.util.ReflectMapWriter;
+
+import java.util.List;
+import java.util.Map;
+
+public class AddReplicaPayload implements ReflectMapWriter {
+ @JsonProperty
+ public String shard;
+
+ @JsonProperty
+ public String _route_;
+
+ // TODO Could 'node' be replaced (in v2 and v1) by just specifying a
'createNodeSet' of size 1?
Review comment:
OK, thanks for the +1 on the idea. I'll delegate it to a separate
ticket, since changing the API brings in 8x deprecation and other concerns.
(See SOLR-15542)
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15542) Combine 'node', 'createNodeSet' parameters for ADDREPLICA API
Jason Gerlowski created SOLR-15542:
--
Summary: Combine 'node', 'createNodeSet' parameters for ADDREPLICA
API
Key: SOLR-15542
URL: https://issues.apache.org/jira/browse/SOLR-15542
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Jason Gerlowski
The ADDREPLICA "collection-admin" API has two parameters that are redundant
with one another:
* {{node}} exists for users to explicitly specify the node to place the new
replica on.
* {{createNodeSet}} lets users specify a number of nodes that Solr will then
choose a "winner" from.
When {{createNodeSet}}'s value is a single node though, it behaves identically
to using the separate {{node}} option (AFAIK).
If this is truly the case (and I'm not just missing something), we should
deprecate {{node}} and instead direct all users to use {{createNodeSet}}
instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #218: SOLR-15536: Rewrite /c//shards v2 APIs using annotations
gerlowskija commented on a change in pull request #218:
URL: https://github.com/apache/solr/pull/218#discussion_r669899451
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/request/beans/AddReplicaPayload.java
##
@@ -0,0 +1,71 @@
+/*
+ * 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.solr.client.solrj.request.beans;
+
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.common.util.ReflectMapWriter;
+
+import java.util.List;
+import java.util.Map;
+
+public class AddReplicaPayload implements ReflectMapWriter {
+ @JsonProperty
+ public String shard;
+
+ @JsonProperty
+ public String _route_;
+
+ // TODO Could 'node' be replaced (in v2 and v1) by just specifying a
'createNodeSet' of size 1?
+ @JsonProperty
+ public String node;
+
+ // TODO Should this just be 'nodeSet' to match the name used by create-shard
and other APIs?
Review comment:
I think a separate ticket, since there's technically deprecation and
other concerns that come up here. Maybe I can handle it as a part of
SOLR-15542, which I created based on your comment above?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] thelabdude commented on pull request #219: SOLR-15525: Allow Zookeeper ACL credentials to be passed via env vars instead of Java system properties
thelabdude commented on pull request #219: URL: https://github.com/apache/solr/pull/219#issuecomment-880157912 actually, the UI is not the only concern here, the output of commands like `ps waux` might also show the Java sys props, so going to proceed as planned -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a change in pull request #218: SOLR-15536: Rewrite /c//shards v2 APIs using annotations
gerlowskija commented on a change in pull request #218: URL: https://github.com/apache/solr/pull/218#discussion_r669902144 ## File path: solr/solrj/src/java/org/apache/solr/common/params/CommonAdminParams.java ## @@ -27,6 +27,8 @@ String IN_PLACE_MOVE = "inPlaceMove"; /** Method to use for shard splitting. */ String SPLIT_METHOD = "splitMethod"; + /** Key to use during shard splitting */ + String SPLIT_KEY = "split.key"; Review comment: That'd be my preference, yep. This constant only uses dot-delimiting since that's what the v1 API used up to this point. And it's only used for the v1 API, so there's the convention doesn't spill into v2-land. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] epugh commented on a change in pull request #218: SOLR-15536: Rewrite /c//shards v2 APIs using annotations
epugh commented on a change in pull request #218:
URL: https://github.com/apache/solr/pull/218#discussion_r669904361
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/request/beans/AddReplicaPayload.java
##
@@ -0,0 +1,71 @@
+/*
+ * 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.solr.client.solrj.request.beans;
+
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.common.util.ReflectMapWriter;
+
+import java.util.List;
+import java.util.Map;
+
+public class AddReplicaPayload implements ReflectMapWriter {
+ @JsonProperty
+ public String shard;
+
+ @JsonProperty
+ public String _route_;
+
+ // TODO Could 'node' be replaced (in v2 and v1) by just specifying a
'createNodeSet' of size 1?
+ @JsonProperty
+ public String node;
+
+ // TODO Should this just be 'nodeSet' to match the name used by create-shard
and other APIs?
Review comment:
I like doing it as part of SOLR-15542 as well.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15542) Combine 'node', 'createNodeSet' parameters for ADDREPLICA API
[
https://issues.apache.org/jira/browse/SOLR-15542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380832#comment-17380832
]
David Eric Pugh commented on SOLR-15542:
Could the parameter just be {{nodeSet}} everywhere?
> Combine 'node', 'createNodeSet' parameters for ADDREPLICA API
> -
>
> Key: SOLR-15542
> URL: https://issues.apache.org/jira/browse/SOLR-15542
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jason Gerlowski
>Priority: Minor
>
> The ADDREPLICA "collection-admin" API has two parameters that are redundant
> with one another:
> * {{node}} exists for users to explicitly specify the node to place the new
> replica on.
> * {{createNodeSet}} lets users specify a number of nodes that Solr will then
> choose a "winner" from.
> When {{createNodeSet}}'s value is a single node though, it behaves
> identically to using the separate {{node}} option (AFAIK).
> If this is truly the case (and I'm not just missing something), we should
> deprecate {{node}} and instead direct all users to use {{createNodeSet}}
> instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman opened a new pull request #284: Add ephemeral option for zk storage.
HoustonPutman opened a new pull request #284: URL: https://github.com/apache/solr-operator/pull/284 Resolves: #259 Since https://github.com/pravega/zookeeper-operator/pull/215 was merged, the Zookeeper Operator has had the ability to deploy Zookeeper with Ephemeral Storage. All we have to do is provide this as an option through the SolrCloud CRD, and solr helm chart. Still contemplating about the default value. - Default to persistent (the current implementation) - Default to ephemeral - Default to the Solr storage type. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #271: Upgrade Zookeeper Operator dependency to v0.2.10
HoustonPutman commented on issue #271: URL: https://github.com/apache/solr-operator/issues/271#issuecomment-880212868 `v0.2.11` is now available. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman commented on issue #278: CRD metadata.annotations too long when updating using `kubectl apply`
HoustonPutman commented on issue #278: URL: https://github.com/apache/solr-operator/issues/278#issuecomment-880220722 I'll close this for now. In case other users face the issue and search for this error, they can find this issue to resolve 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] HoustonPutman closed issue #278: CRD metadata.annotations too long when updating using `kubectl apply`
HoustonPutman closed issue #278: URL: https://github.com/apache/solr-operator/issues/278 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-15543) docker tests should fail more transparently if 'setfacl' is not available
Chris M. Hostetter created SOLR-15543:
-
Summary: docker tests should fail more transparently if 'setfacl'
is not available
Key: SOLR-15543
URL: https://issues.apache.org/jira/browse/SOLR-15543
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
a handful of docker cases depend on {{prepare_dir_to_mount}} in {{shared.sh}}
which ends with...
{code:java}
# The /var/solr mountpoint is owned by solr, so when we bind mount there our
directory,
# owned by the current user in the host, will show as owned by solr, and our
attempts
# to write to it as the user will fail. To deal with that, set the ACL to
allow that.
# If you can't use setfacl (eg on macOS), you'll have to chown the directory
to 8983, or apply world
# write permissions.
if command -v setfacl &> /dev/null; then
setfacl -m "u:$userid:rwx" "$folder"
fi
}
{code}
I don't really understand that comment (is setfacl not available on macs? do
docker tests currently not work on macs?) but more concerning is that if
setfacl isn't available on the host OS, then the necessary ACLs just aren't
added – which means these tests fail down the road when the code being tested
tries to use these directories with the specified userid.
I think we should change this logic such that if {{setfacl}} isn't available,
or if it exits with non zero status, then the test fails with a clear error
about the need for {{setfacl}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15543) docker tests should fail more transparently if 'setfacl' is not available
[
https://issues.apache.org/jira/browse/SOLR-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380888#comment-17380888
]
Chris M. Hostetter commented on SOLR-15543:
---
FWIW: i discovered this because apparently recent ubuntu dists stoped including
the {{acl}} pacakge that provides {{setfacl}} by default
> docker tests should fail more transparently if 'setfacl' is not available
> -
>
> Key: SOLR-15543
> URL: https://issues.apache.org/jira/browse/SOLR-15543
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> a handful of docker cases depend on {{prepare_dir_to_mount}} in {{shared.sh}}
> which ends with...
> {code:java}
> # The /var/solr mountpoint is owned by solr, so when we bind mount there
> our directory,
> # owned by the current user in the host, will show as owned by solr, and
> our attempts
> # to write to it as the user will fail. To deal with that, set the ACL to
> allow that.
> # If you can't use setfacl (eg on macOS), you'll have to chown the
> directory to 8983, or apply world
> # write permissions.
> if command -v setfacl &> /dev/null; then
> setfacl -m "u:$userid:rwx" "$folder"
> fi
> }
> {code}
> I don't really understand that comment (is setfacl not available on macs? do
> docker tests currently not work on macs?) but more concerning is that if
> setfacl isn't available on the host OS, then the necessary ACLs just aren't
> added – which means these tests fail down the road when the code being tested
> tries to use these directories with the specified userid.
>
> I think we should change this logic such that if {{setfacl}} isn't available,
> or if it exits with non zero status, then the test fails with a clear error
> about the need for {{setfacl}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-15428) Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and performance comparisons and investigation.
[ https://issues.apache.org/jira/browse/SOLR-15428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17380893#comment-17380893 ] Mark Robert Miller commented on SOLR-15428: --- I took a look at 9 build and confirmed there no longer appears to be a test-framework jar distributed - so there should not be much we have to do license wise in that case. > Integrate the OpenJDK JMH micro benchmark framework for micro benchmarks and > performance comparisons and investigation. > --- > > Key: SOLR-15428 > URL: https://issues.apache.org/jira/browse/SOLR-15428 > Project: Solr > Issue Type: New Feature >Reporter: Mark Robert Miller >Priority: Major > Attachments: bench.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > I’ve spent a fair amount of time over the years on work around integrating > Lucene’s benchmark framework into Solr and while I’ve used this with > additional local work off and on, JMH has become somewhat of a standard for > micro benchmarks on the JVM. I have some work that provides an initial > integration, allowing for more targeted micro benchmarks as well as more > integration type benchmarking using JettySolrRunner. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this incompatible
issue?
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
>
> {code}
>
> Add some fields in Solr8
>
>
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior? how do we handle this incompatible
> issue?
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this incompatible
issue?
Add comment:
This also impacts deletebyId
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this incompatible
issue?
Add comment:
This also impact deletebyId
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
>
> {code}
>
> Add some fields in Solr8
>
>
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior? how do we handle this incompatible
> issue?
>
> Add comment:
> This also impacts deletebyId
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-15540) Duplicated adding document for update when Solr7 upgrade to Solr8
[
https://issues.apache.org/jira/browse/SOLR-15540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
samuel ma updated SOLR-15540:
-
Description:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this incompatible
issue?
Add comment:
This also impact deletebyId
was:
We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the query
operation is fine. But when we try to add the doc (with the same doc id,
actually is an update operation) to Solr8, we actually see 2 doc with the same
id, which means the update did not remove the Solr7 doc.
Below is the schema.xml configuration for Solr7.
{code:java}
id
{code}
Add some fields in Solr8
I can see in Sol7 code
{code:java}
DirectUpdateHandler2.updateDocOrDocValues{code}
use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
updateTerm. is this an expected behavior? how do we handle this incompatible
issue?
> Duplicated adding document for update when Solr7 upgrade to Solr8
> -
>
> Key: SOLR-15540
> URL: https://issues.apache.org/jira/browse/SOLR-15540
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: update, UpdateRequestProcessors
>Affects Versions: 8.8.2
> Environment: SolrCloud Solr 8.8.2
>Reporter: samuel ma
>Priority: Major
>
> We upgrade Solr7.7.2 to Solr8.8.2, keep using the Solr 7 index data, the
> query operation is fine. But when we try to add the doc (with the same doc
> id, actually is an update operation) to Solr8, we actually see 2 doc with the
> same id, which means the update did not remove the Solr7 doc.
> Below is the schema.xml configuration for Solr7.
> {code:java}
> multiValued="false" />
> id
>
> {code}
>
> Add some fields in Solr8
>
>
>
> I can see in Sol7 code
> {code:java}
> DirectUpdateHandler2.updateDocOrDocValues{code}
> use the idTerm as updateTerm, but in this case Solr8 use rootTerm as the
> updateTerm. is this an expected behavior? how do we handle this incompatible
> issue?
>
> Add comment:
> This also impact deletebyId
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
