[GitHub] [lucene-solr] mocobeta commented on pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on pull request #1522: URL: https://github.com/apache/lucene-solr/pull/1522#issuecomment-631169757 Thanks for reviewing. I plan to merge the branch to the master in shortly (if there's no other feedback). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111627#comment-17111627 ] Noble Paul commented on SOLR-14384: --- Can we have a better description? I'm sure this may be required, but it's not clear why > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on a change in pull request #1528:
URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427655970
##
File path:
solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java
##
@@ -468,36 +467,6 @@ void checkResults(String label, NamedList results,
boolean failureIsFata
}
}
-
- //TODO should we not remove in the next release ?
- private void migrateStateFormat(ClusterState state, ZkNodeProps message,
NamedList results) throws Exception {
Review comment:
Had to remove 1,660 lines and add 568 to get rid of that comment :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on a change in pull request #1528:
URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427655602
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -491,6 +493,40 @@ public boolean isClosed() {
assert ObjectReleaseTracker.track(this);
}
+ /**
+ * Verifies if /clusterstate.json exists in Zookeepeer, and if it does
and is not empty, refuses to start and outputs
+ * a helpful message regarding collection migration.
+ *
+ * If /clusterstate.json exists and is empty, it is removed.
+ */
+ private void checkNoOldClusterstate(final SolrZkClient zkClient) throws
InterruptedException {
+try {
+ if (!zkClient.exists(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, true)) {
+return;
+ }
+
+ final byte[] data =
zkClient.getData(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, null, null, true);
+
+ if (data.length < 5) {
Review comment:
updated.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mrsoong commented on pull request #1502: SOLR-13203: Added 400 status code to exception in DynamicField
mrsoong commented on pull request #1502: URL: https://github.com/apache/lucene-solr/pull/1502#issuecomment-631138690 Hi @madrob. Just wanted to drop a friendly reminder that this PR is still waiting for the changed entry that you mentioned more than a week ago. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc edited a comment on pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc edited a comment on pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#issuecomment-631124718 > Didn't get all the way through the tests, so it might be there even though I didn't see it - would be nice to have a test that makes sure an older client that still sends `stateFormat=2` on a collection creation request would succeed. No there's nothing regarding this. Tested manually creating a collection using http://localhost:8983/solr/admin/collections?action=CREATE=sf2=1=1==_default=1 and it works. Note the unknown parameter at the end (stateFormat is unknown as well now). Is there an existing test where I can add this? I didn't find one. Or did you mean testing in a different way? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111605#comment-17111605 ] Ilan Ginzburg commented on SOLR-12823: -- I changed the status of [https://github.com/apache/lucene-solr/pull/1528] from Draft to Ready for review (and hopefully merge). Note the comment added in the PR, copying here: _Rebased on master. The recent fix to SOLR-14486 solved the failures in the autoscaling sim tests._ _I'm submitting this officially for review now (moving it out of draft PR)._ _Note there are two tests that are failing (that I marked [@ignore|https://github.com/ignore]) and that IMO should either be removed or deserve their own separate Jira for fixing (that I will create once this is merged). I suspect fixes are non trivial:_ * _TestZkChroot: I didn't find ways to reasonably start a test server with a different chroot than /solr to test if it's writing data to the right place in ZooKeeper. Played a while with MiniSolrCloudCluster but chroot seems to be quite hard coded deep in the test framework (passing an already chrooted ZK server defeats the purpose)._ * _BasicZkTest (I didn't dig further)._ > remove clusterstate.json in Lucene/Solr 8.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 8.0 > It stays empty unless you explicitly ask to create the collection with the > old "stateFormat" and there is no reason for one to create a collection with > the old stateFormat. > We should also remove the "stateFormat" argument in create collection > We should also remove MIGRATESTATEVERSION as well > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#issuecomment-631131151 Rebased on master. The recent fix to SOLR-14486 solved the failures in the autoscaling sim tests. I'm submitting this officially for review now (moving it out of draft PR). Note there are two tests that are failing (that I marked @Ignore) and that IMO should either be removed or deserve their own separate Jira for fixing (that I will create once this is merged). I suspect fixes are non trivial: - TestZkChroot: I didn't find ways to reasonably start a test server with a different chroot than /solr to test if it's writing data to the right place in ZooKeeper. Played a while with MiniSolrCloudCluster but chroot seems to be quite hard coded deep in the test framework (passing an already chrooted ZK server defeats the purpose). - BasicZkTest (I didn't dig further). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#issuecomment-631124718 > Didn't get all the way through the tests, so it might be there even though I didn't see it - would be nice to have a test that makes sure an older client that still sends `stateFormat=2` on a collection creation request would succeed. No there's nothing regarding this. Tested manually creating a collection using http://localhost:8983/solr/admin/collections?action=CREATE=sf2=1=1==_default=1 and it works. Note the unknown parameter at the end (stateFormat is unknown as well now). Is there an existing test when I can add this? I didn't find one. Or did you mean testing in a different way? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on a change in pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427636430 ## File path: solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java ## @@ -236,21 +235,19 @@ public void call(ClusterState clusterState, ZkNodeProps message, NamedList resul } String baseUrl = zkStateReader.getBaseUrlForNodeName(nodeName); -//in the new mode, create the replica in clusterstate prior to creating the core. +//create the replica in clusterstate (i.e. ZK) prior to creating the core. Review comment: Agreed, we should rename in many places. Although here state.json is appropriate since that's what happens. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on a change in pull request #1528:
URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427627276
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -491,6 +493,40 @@ public boolean isClosed() {
assert ObjectReleaseTracker.track(this);
}
+ /**
+ * Verifies if /clusterstate.json exists in Zookeepeer, and if it does
and is not empty, refuses to start and outputs
+ * a helpful message regarding collection migration.
+ *
+ * If /clusterstate.json exists and is empty, it is removed.
+ */
+ private void checkNoOldClusterstate(final SolrZkClient zkClient) throws
InterruptedException {
+try {
+ if (!zkClient.exists(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, true)) {
+return;
+ }
+
+ final byte[] data =
zkClient.getData(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, null, null, true);
+
+ if (data.length < 5) {
+// less than 5 chars is empty (it's likely just "{}"). This log will
only occur once.
+log.warn("{} no longer supported starting with Solr 9. Found empty
file on Zookeeper, deleting it.", ZkStateReader.UNSUPPORTED_CLUSTER_STATE);
+zkClient.delete(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, -1, true);
+ } else {
+// /clusterstate.json not empty: refuse to start but do not
automatically delete. A bit of a pain but user shouldn't
+// have older collections at this stage anyway.
+String message = ZkStateReader.UNSUPPORTED_CLUSTER_STATE + " no longer
supported starting with Solr 9. "
++ "It is present and not empty. Cannot start Solr. Please first
migrate collections to stateFormat=2 using an "
++ "older version of Solr or if you don't care about the data then
delete the file from "
++ "Zookeeper using a command line tool, for example: bin/solr zk
rm /clusterstate.json -z host:port";
+log.error(message);
+throw new SolrException(SolrException.ErrorCode.INVALID_STATE,
message);
+ }
+} catch (KeeperException e) {
+ log.error("", e);
Review comment:
Converting checked to unchecked exception. copied from init() further
down that deals with the same problem on access to ZK.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
janhoy commented on a change in pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427627240 ## File path: solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java ## @@ -236,21 +235,19 @@ public void call(ClusterState clusterState, ZkNodeProps message, NamedList resul } String baseUrl = zkStateReader.getBaseUrlForNodeName(nodeName); -//in the new mode, create the replica in clusterstate prior to creating the core. +//create the replica in clusterstate (i.e. ZK) prior to creating the core. Review comment: I think we still can use 'clusterstate' as a generic term? When I read it in a sentence like this I do not read it as the file clusterstate.json, but as the cluster state. Perhaps we could consistenly write it as "cluster state" instead? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc commented on a change in pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427625766 ## File path: solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java ## @@ -236,21 +235,19 @@ public void call(ClusterState clusterState, ZkNodeProps message, NamedList resul } String baseUrl = zkStateReader.getBaseUrlForNodeName(nodeName); -//in the new mode, create the replica in clusterstate prior to creating the core. +//create the replica in clusterstate (i.e. ZK) prior to creating the core. Review comment: "clusterstate" is used all over (including in the docs) to refer in general to the state of the cluster or collection stored in ZK. Will replace with state.json here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
mkhludnev commented on a change in pull request #1527:
URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427625556
##
File path: solr/core/src/java/org/apache/solr/request/SolrRequestInfo.java
##
@@ -52,35 +54,44 @@
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
public static SolrRequestInfo getRequestInfo() {
-return threadLocal.get();
+if (threadLocal.get().isEmpty()) return null;
+return threadLocal.get().peek();
}
public static void setRequestInfo(SolrRequestInfo info) {
-// TODO: temporary sanity check... this can be changed to just an assert
in the future
-SolrRequestInfo prev = threadLocal.get();
-if (prev != null) {
- log.error("Previous SolrRequestInfo was not closed! req={}",
prev.req.getOriginalParams());
- log.error("prev == info : {}", prev.req == info.req, new
RuntimeException());
+if (info == null) {
+ throw new IllegalArgumentException("SolrRequestInfo is null");
+} else {
+ threadLocal.get().push(info);
Review comment:
100 for sure
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14500) currency function doesn't work for asymmetric rates
[
https://issues.apache.org/jira/browse/SOLR-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murray Johnston updated SOLR-14500:
---
Attachment: test.patch
> currency function doesn't work for asymmetric rates
> ---
>
> Key: SOLR-14500
> URL: https://issues.apache.org/jira/browse/SOLR-14500
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Murray Johnston
>Priority: Minor
> Attachments: test.patch
>
>
> Given a currency field of CurrencyFieldType, the following asymmetric rates:
> {code:java}
>
> {code}
> and a price field with a value of "24.50,SGD"
> The following usage of the currency function as a pseudo-field in a query
> returns incorrect values:
> {code:java}
> curl -s
> 'http://10.43.41.81:32080/solr/product_details/select?fl=price,price_sgd%3Acurrency(price,SGD)=id%3A57373P16=*%3A*=1'
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":0,
> "params":{
> "q":"*:*",
> "fl":"price,price_sgd:currency(price,SGD)",
> "fq":"id:57373P16",
> "rows":"1"}},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "price":"24.50,SGD",
> "price_sgd":25.74}]
> }} {code}
> I have traced this to the fact that CurrencyFieldType.getValueSource returns
> a value that is first converted to the default currency. When dealing with
> asymmetric rates this always risks introducing conversion errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14500) currency function doesn't work for asymmetric rates
[
https://issues.apache.org/jira/browse/SOLR-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111552#comment-17111552
]
Murray Johnston commented on SOLR-14500:
I've added a patch to illustrate the issue
> currency function doesn't work for asymmetric rates
> ---
>
> Key: SOLR-14500
> URL: https://issues.apache.org/jira/browse/SOLR-14500
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Murray Johnston
>Priority: Minor
> Attachments: test.patch
>
>
> Given a currency field of CurrencyFieldType, the following asymmetric rates:
> {code:java}
>
> {code}
> and a price field with a value of "24.50,SGD"
> The following usage of the currency function as a pseudo-field in a query
> returns incorrect values:
> {code:java}
> curl -s
> 'http://10.43.41.81:32080/solr/product_details/select?fl=price,price_sgd%3Acurrency(price,SGD)=id%3A57373P16=*%3A*=1'
> {
> "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":0,
> "params":{
> "q":"*:*",
> "fl":"price,price_sgd:currency(price,SGD)",
> "fq":"id:57373P16",
> "rows":"1"}},
> "response":{"numFound":1,"start":0,"docs":[
> {
> "price":"24.50,SGD",
> "price_sgd":25.74}]
> }} {code}
> I have traced this to the fact that CurrencyFieldType.getValueSource returns
> a value that is first converted to the default currency. When dealing with
> asymmetric rates this always risks introducing conversion errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14501) Reduce retention period of Jetty NCSA request log
David Smiley created SOLR-14501: --- Summary: Reduce retention period of Jetty NCSA request log Key: SOLR-14501 URL: https://issues.apache.org/jira/browse/SOLR-14501 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Server Reporter: David Smiley The Jetty request logs (NCSA format, typically) are currently configured for 90 day retention. https://www.eclipse.org/jetty/documentation/current/configuring-jetty-request-logs.html solr/server/etc/jetty-requestlog.xmlThis file is partially redundant with Solr's Log4j2 based logging, but it has unique information useful for diagnosing a security breach or for seeing which of the clients in your environment are talking with Solr. Let's dial this down to 7 days, or even less (3?). BTW our Log4j2 logs are rotated by file size, not time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #1528: SOLR-12823: remove /clusterstate.json
madrob commented on a change in pull request #1528:
URL: https://github.com/apache/lucene-solr/pull/1528#discussion_r427580023
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -491,6 +493,40 @@ public boolean isClosed() {
assert ObjectReleaseTracker.track(this);
}
+ /**
+ * Verifies if /clusterstate.json exists in Zookeepeer, and if it does
and is not empty, refuses to start and outputs
+ * a helpful message regarding collection migration.
+ *
+ * If /clusterstate.json exists and is empty, it is removed.
+ */
+ private void checkNoOldClusterstate(final SolrZkClient zkClient) throws
InterruptedException {
+try {
+ if (!zkClient.exists(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, true)) {
+return;
+ }
+
+ final byte[] data =
zkClient.getData(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, null, null, true);
+
+ if (data.length < 5) {
Review comment:
Can we be more rigorous on the test here?
##
File path:
solr/core/src/java/org/apache/solr/cloud/api/collections/CreateCollectionCmd.java
##
@@ -236,21 +235,19 @@ public void call(ClusterState clusterState, ZkNodeProps
message, NamedList resul
}
String baseUrl = zkStateReader.getBaseUrlForNodeName(nodeName);
-//in the new mode, create the replica in clusterstate prior to
creating the core.
+//create the replica in clusterstate (i.e. ZK) prior to creating the
core.
Review comment:
s/clusterstate/state?
##
File path: solr/core/src/java/org/apache/solr/cloud/ZkController.java
##
@@ -491,6 +493,40 @@ public boolean isClosed() {
assert ObjectReleaseTracker.track(this);
}
+ /**
+ * Verifies if /clusterstate.json exists in Zookeepeer, and if it does
and is not empty, refuses to start and outputs
+ * a helpful message regarding collection migration.
+ *
+ * If /clusterstate.json exists and is empty, it is removed.
+ */
+ private void checkNoOldClusterstate(final SolrZkClient zkClient) throws
InterruptedException {
+try {
+ if (!zkClient.exists(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, true)) {
+return;
+ }
+
+ final byte[] data =
zkClient.getData(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, null, null, true);
+
+ if (data.length < 5) {
+// less than 5 chars is empty (it's likely just "{}"). This log will
only occur once.
+log.warn("{} no longer supported starting with Solr 9. Found empty
file on Zookeeper, deleting it.", ZkStateReader.UNSUPPORTED_CLUSTER_STATE);
+zkClient.delete(ZkStateReader.UNSUPPORTED_CLUSTER_STATE, -1, true);
+ } else {
+// /clusterstate.json not empty: refuse to start but do not
automatically delete. A bit of a pain but user shouldn't
+// have older collections at this stage anyway.
+String message = ZkStateReader.UNSUPPORTED_CLUSTER_STATE + " no longer
supported starting with Solr 9. "
++ "It is present and not empty. Cannot start Solr. Please first
migrate collections to stateFormat=2 using an "
++ "older version of Solr or if you don't care about the data then
delete the file from "
++ "Zookeeper using a command line tool, for example: bin/solr zk
rm /clusterstate.json -z host:port";
+log.error(message);
+throw new SolrException(SolrException.ErrorCode.INVALID_STATE,
message);
+ }
+} catch (KeeperException e) {
+ log.error("", e);
Review comment:
What are the conditions where this happens? log-and-throw is usually an
anti-pattern.
##
File path:
solr/core/src/java/org/apache/solr/cloud/api/collections/OverseerCollectionMessageHandler.java
##
@@ -468,36 +467,6 @@ void checkResults(String label, NamedList results,
boolean failureIsFata
}
}
-
- //TODO should we not remove in the next release ?
- private void migrateStateFormat(ClusterState state, ZkNodeProps message,
NamedList results) throws Exception {
Review comment:
Yay!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14500) currency function doesn't work for asymmetric rates
Murray Johnston created SOLR-14500:
--
Summary: currency function doesn't work for asymmetric rates
Key: SOLR-14500
URL: https://issues.apache.org/jira/browse/SOLR-14500
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Murray Johnston
Given a currency field of CurrencyFieldType, the following asymmetric rates:
{code:java}
{code}
and a price field with a value of "24.50,SGD"
The following usage of the currency function as a pseudo-field in a query
returns incorrect values:
{code:java}
curl -s
'http://10.43.41.81:32080/solr/product_details/select?fl=price,price_sgd%3Acurrency(price,SGD)=id%3A57373P16=*%3A*=1'
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":0,
"params":{
"q":"*:*",
"fl":"price,price_sgd:currency(price,SGD)",
"fq":"id:57373P16",
"rows":"1"}},
"response":{"numFound":1,"start":0,"docs":[
{
"price":"24.50,SGD",
"price_sgd":25.74}]
}} {code}
I have traced this to the fact that CurrencyFieldType.getValueSource returns a
value that is first converted to the default currency. When dealing with
asymmetric rates this always risks introducing conversion errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] NazerkeBS commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
NazerkeBS commented on a change in pull request #1527:
URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427552166
##
File path: solr/core/src/java/org/apache/solr/request/SolrRequestInfo.java
##
@@ -52,35 +54,44 @@
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
public static SolrRequestInfo getRequestInfo() {
-return threadLocal.get();
+if (threadLocal.get().isEmpty()) return null;
+return threadLocal.get().peek();
}
public static void setRequestInfo(SolrRequestInfo info) {
-// TODO: temporary sanity check... this can be changed to just an assert
in the future
-SolrRequestInfo prev = threadLocal.get();
-if (prev != null) {
- log.error("Previous SolrRequestInfo was not closed! req={}",
prev.req.getOriginalParams());
- log.error("prev == info : {}", prev.req == info.req, new
RuntimeException());
+if (info == null) {
+ throw new IllegalArgumentException("SolrRequestInfo is null");
+} else {
+ threadLocal.get().push(info);
Review comment:
what would you suggest for the stack size limit?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14470) Add streaming expressions to /export handler
[
https://issues.apache.org/jira/browse/SOLR-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111458#comment-17111458
]
David Smiley commented on SOLR-14470:
-
Sounds great but hopefully can be done in a layered way. "/export" has a
straight-forward purpose. Adding aggregations _directly_ to it concerns me;
it's then not some straight-forward component.
> Add streaming expressions to /export handler
>
>
> Key: SOLR-14470
> URL: https://issues.apache.org/jira/browse/SOLR-14470
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Export Writer, streaming expressions
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
>
> Many streaming scenarios would greatly benefit from the ability to perform
> partial rollups (or other transformations) as early as possible, in order to
> minimize the amount of data that has to be sent from shards to the
> aggregating node.
> This can be implemented as a subset of streaming expressions that process the
> data directly inside each local {{ExportHandler}} and outputs only the
> records from the resulting stream.
> Conceptually it would be similar to the way Hadoop {{Combiner}} works. As is
> the case with {{Combiner}}, because the input data is processed in batches
> there would be no guarantee that only 1 record per unique sort values would
> be emitted - in fact, in most cases multiple partial aggregations would be
> emitted. Still, in many scenarios this would allow reducing the amount of
> data to be sent by several orders of magnitude.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9355) missing releases from testbackwardscompatibility
[
https://issues.apache.org/jira/browse/LUCENE-9355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob resolved LUCENE-9355.
---
Assignee: Mike Drob
Resolution: Fixed
cherry-picked commits from branch_7 to branch_8 and that took care of it.
> missing releases from testbackwardscompatibility
>
>
> Key: LUCENE-9355
> URL: https://issues.apache.org/jira/browse/LUCENE-9355
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
>
> I'm not sure what needs to be added for the 7.7.3 release, but can you take a
> look at it [~noble] or figure out who to ask for help?
> {noformat}
>[smoker] confirm all releases have coverage in TestBackwardsCompatibility
>[smoker] find all past Lucene releases...
>[smoker] run TestBackwardsCompatibility..
>[smoker] Releases that don't seem to be tested:
>[smoker] 7.7.3
>[smoker] Traceback (most recent call last):
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1487, in
>[smoker] main()
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1413, in main
>[smoker] downloadOnly=c.download_only)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1465, in smokeTest
>[smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' %
> version, gitRevision, version, testArgs, baseURL)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 566, in unpackAndVerify
>[smoker] verifyUnpacked(java, project, artifact, unpackPath,
> gitRevision, version, testArgs, tmpDir, baseURL)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 752, in verifyUnpacked
>[smoker] confirmAllReleasesAreTestedForBackCompat(version, unpackPath)
>[smoker] File
> "/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
> line 1388, in confirmAllReleasesAreTestedForBackCompat
>[smoker] raise RuntimeError('some releases are not tested by
> TestBackwardsCompatibility?')
>[smoker] RuntimeError: some releases are not tested by
> TestBackwardsCompatibility?
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14484) NPE in ConcurrentUpdateHttp2SolrClient MDC logging
[
https://issues.apache.org/jira/browse/SOLR-14484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111446#comment-17111446
]
David Smiley commented on SOLR-14484:
-
I propose simply using {{String.valueOf(client.getBaseURL())}} instead, and
thus wind up with a simple "null" string in this case. WDYT?
> NPE in ConcurrentUpdateHttp2SolrClient MDC logging
> --
>
> Key: SOLR-14484
> URL: https://issues.apache.org/jira/browse/SOLR-14484
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 8.4.1
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14484-01.patch
>
>
> {{client.getBaseURL()}} can be null in {{ConcurrentUpdateHttp2SolrClient}}
> which can cause problems in MDC logging.
> We had the following error in the stacktrace. We were using Solr 8.4.1 from
> lily hbase-indexer which still uses log4j 1.2:
> {noformat}
> Error from server at http://127.0.0.1:45895/solr/collection1:
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:459)
> at org.apache.log4j.MDC.put0(MDC.java:150)
> at org.apache.log4j.MDC.put(MDC.java:85)
> at org.slf4j.impl.Log4jMDCAdapter.put(Log4jMDCAdapter.java:67)
> at org.slf4j.MDC.put(MDC.java:147)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient.addRunner(ConcurrentUpdateHttp2SolrClient.java:346)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient.waitForEmptyQueue(ConcurrentUpdateHttp2SolrClient.java:565)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111440#comment-17111440
]
Lucene/Solr QA commented on LUCENE-9376:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 12 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 22s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
3s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
12s{color} | {color:green} highlighter in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
16s{color} | {color:green} sandbox in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} suggest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
37s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 7m 50s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9376 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13003409/LUCENE-9376.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 57b7d8a8dbf |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/280/testReport/ |
| modules | C: lucene/core lucene/highlighter lucene/sandbox lucene/suggest
lucene/test-framework U: lucene |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/280/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
>
[jira] [Resolved] (LUCENE-9371) Make RegExp internal state more visible to support more rendering formats
[ https://issues.apache.org/jira/browse/LUCENE-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Harwood resolved LUCENE-9371. -- Resolution: Fixed Fixed in master and backported to branch_8x in https://github.com/apache/lucene-solr/commit/9d6c738ffce0c3164691f161ba8b92a615b1e062 > Make RegExp internal state more visible to support more rendering formats > - > > Key: LUCENE-9371 > URL: https://issues.apache.org/jira/browse/LUCENE-9371 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Mark Harwood >Assignee: Mark Harwood >Priority: Minor > > This is a proposal to open up read-only access to the internal state of > RegExp objects. > The RegExp parser provides a useful parsed object model for regular > expressions. Today it offers three rendering functions: > 1) To Automaton (for query execution) > 2) To string (for machine-readable regular expressions) > 3) To StringTree (for debug purposes) > There are at least 2 other rendering functions that would be useful: > a) To "Explain" format (like the plain-English descriptions used in [regex > debugging tools|https://regex101.com/r/2DUzac/1]) > b) To Query (queries used to accelerate regex searches by providing an > approximation of the search terms and [hitting an ngram > index|https://github.com/wikimedia/search-extra/blob/master/docs/source_regex.md]) > To support these and other renderings/transformations it would be useful to > open read-only access to the fields held in RegExp objects - either through > making them public finals or offering getter access methods. This would free > the RegExp class from having to support all possible transformations. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] markharwood merged pull request #1529: Lucene-9371: Allow external access to RegExp's parsed structure (#1521)
markharwood merged pull request #1529: URL: https://github.com/apache/lucene-solr/pull/1529 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] markharwood opened a new pull request #1529: Lucene-9371: Allow external access to RegExp's parsed structure (#1521)
markharwood opened a new pull request #1529: URL: https://github.com/apache/lucene-solr/pull/1529 Made RegExp internal fields public final to allow external classes to render eg English explanations of pattern logic Backport of https://github.com/apache/lucene-solr/pull/1521 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14486) Autoscaling simulation framework should stop using /clusterstate.json
[
https://issues.apache.org/jira/browse/SOLR-14486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111353#comment-17111353
]
Andrzej Bialecki commented on SOLR-14486:
-
I changed the implementation so that it maintains individual collection states
and their versions, and maintains corresponding /state.json files. This
actually makes the caching and locking behavior in {{SimClusterStateProvider}}
easier to understand - and it also keeps the state in pseudo-ZK exactly as if
it was created by real Solr.
> Autoscaling simulation framework should stop using /clusterstate.json
> -
>
> Key: SOLR-14486
> URL: https://issues.apache.org/jira/browse/SOLR-14486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0)
>
>
> Spin-off from SOLR-12823.
> In theory the simulation framework doesn't actually use this file, but
> {{SimClusterStateProvider}} relies on its versioning to keep its internal
> data structures in sync. This should be changed to use individual
> DocCollection / state.json znodeVersion instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14486) Autoscaling simulation framework should stop using /clusterstate.json
[
https://issues.apache.org/jira/browse/SOLR-14486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-14486.
-
Fix Version/s: master (9.0)
Resolution: Fixed
> Autoscaling simulation framework should stop using /clusterstate.json
> -
>
> Key: SOLR-14486
> URL: https://issues.apache.org/jira/browse/SOLR-14486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0)
>
>
> Spin-off from SOLR-12823.
> In theory the simulation framework doesn't actually use this file, but
> {{SimClusterStateProvider}} relies on its versioning to keep its internal
> data structures in sync. This should be changed to use individual
> DocCollection / state.json znodeVersion instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14486) Autoscaling simulation framework should stop using /clusterstate.json
[
https://issues.apache.org/jira/browse/SOLR-14486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111349#comment-17111349
]
ASF subversion and git services commented on SOLR-14486:
Commit 57b7d8a8dbf16f0e01c8b13a6c7fd30cdef486c7 in lucene-solr's branch
refs/heads/master from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=57b7d8a ]
SOLR-14486: Autoscaling simulation framework should stop using
/clusterstate.json.
> Autoscaling simulation framework should stop using /clusterstate.json
> -
>
> Key: SOLR-14486
> URL: https://issues.apache.org/jira/browse/SOLR-14486
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: master (9.0)
>
>
> Spin-off from SOLR-12823.
> In theory the simulation framework doesn't actually use this file, but
> {{SimClusterStateProvider}} relies on its versioning to keep its internal
> data structures in sync. This should be changed to use individual
> DocCollection / state.json znodeVersion instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9371) Make RegExp internal state more visible to support more rendering formats
[ https://issues.apache.org/jira/browse/LUCENE-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111342#comment-17111342 ] Mark Harwood commented on LUCENE-9371: -- Resolved in [https://github.com/apache/lucene-solr/commit/44fc5b989a6e6ff8d4581dd0a25174208425f3f6] I'll backport to branch_8x too given it's a non-breaking change > Make RegExp internal state more visible to support more rendering formats > - > > Key: LUCENE-9371 > URL: https://issues.apache.org/jira/browse/LUCENE-9371 > Project: Lucene - Core > Issue Type: Improvement > Components: core/search >Reporter: Mark Harwood >Assignee: Mark Harwood >Priority: Minor > > This is a proposal to open up read-only access to the internal state of > RegExp objects. > The RegExp parser provides a useful parsed object model for regular > expressions. Today it offers three rendering functions: > 1) To Automaton (for query execution) > 2) To string (for machine-readable regular expressions) > 3) To StringTree (for debug purposes) > There are at least 2 other rendering functions that would be useful: > a) To "Explain" format (like the plain-English descriptions used in [regex > debugging tools|https://regex101.com/r/2DUzac/1]) > b) To Query (queries used to accelerate regex searches by providing an > approximation of the search terms and [hitting an ngram > index|https://github.com/wikimedia/search-extra/blob/master/docs/source_regex.md]) > To support these and other renderings/transformations it would be useful to > open read-only access to the fields held in RegExp objects - either through > making them public finals or offering getter access methods. This would free > the RegExp class from having to support all possible transformations. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] markharwood merged pull request #1521: Lucene-9371: Allow external access to RegExp's parsed structure
markharwood merged pull request #1521: URL: https://github.com/apache/lucene-solr/pull/1521 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111325#comment-17111325
]
Erick Erickson commented on LUCENE-9376:
[~asalamon74] Please mention me when you raise one of these, so far I've only
caught them by chance and I don't want your work to be ignored.
Just an at-symbol and start typing my name will bring it up.
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
>
[jira] [Assigned] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned LUCENE-9376:
--
Assignee: Erick Erickson
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ecj-lint] TokenStream tokenStream = new MockAnalyzer(random(),
> MockTokenizer.SIMPLE,
> [ecj-lint] true,
>
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111312#comment-17111312 ] Dawid Weiss commented on SOLR-14497: Well, a patch will still apply (even if stripped prefix is required). I'm not concerned too much about Github integration: if we can't move things reasonably on github then so be it. Pull requests can be filed with relative ease against new repository (on github as well). > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111309#comment-17111309 ] Jan Høydahl commented on SOLR-14497: Agree with Uwe we should set some conditions for when to split the main git repo. Removing ant from master could be one such condition. We also need to think hard and long about how to treat open PRs and patches. PRs belong to the 'lucene-solr' repo, and I wonder if we could bulk move lucene-PRs to the new 'lucene' github repo and all solr-PRs to the new 'solr' github repo? Also, PRs and patches will likely not apply once we start moving things around in the repos post-split... > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14499) New Solr TLP site
Jan Høydahl created SOLR-14499: -- Summary: New Solr TLP site Key: SOLR-14499 URL: https://issues.apache.org/jira/browse/SOLR-14499 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Jan Høydahl # Get setup solr-site repo (start from lucene-site repo) # Setup a temporary "work in progress" page on solr.apache.org # Remove all lucene TLP, lucene-core and pylucene content, including templates and css etc # Move Solr index.html as main index file # Simplify folder structure for Pelican # Publish the new site -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111295#comment-17111295 ] Dawid Weiss commented on SOLR-14497: Thanks Jan, very clear. > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-14497: --- Description: This issue is about the process of moving Solr to become an Apache TLP. Se [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] for a tabular view of possible changes. *TODO*: Add sub tasks. h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # Determine how to split web site # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] was: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # Determine how to split web site # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Se > [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] > for a tabular view of possible changes. > *TODO*: Add sub tasks. > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111285#comment-17111285 ] Jan Høydahl commented on SOLR-14497: I started a WIKI page at [https://cwiki.apache.org/confluence/display/LUCENE/Solr+TLP+needed+changes] with a table view of where I think we'll end up after the move. It makes it easier to visualize the changes needed, at least for me. Feel free to expand on the table in any way you see fit, or to discuss. > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Elements to handle (as sub-tasks)? > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
dweiss commented on pull request #1522: URL: https://github.com/apache/lucene-solr/pull/1522#issuecomment-630892331 It's fine, although the snippet I copy-pasted showed a way which I think is more elegant in the long term: separates the actual property configuration bit from its declaration in the task. The difference is subtle - if we move the task to buildSrc, for example, the configuration can still happen in the relevant part of the script but the task stays precompiled and ready. These are tiny things that definitely can be polished later on. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated LUCENE-9376:
---
Status: Patch Available (was: Open)
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ecj-lint] TokenStream tokenStream = new MockAnalyzer(random(),
> MockTokenizer.SIMPLE,
> [ecj-lint] true,
>
[jira] [Updated] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated LUCENE-9376:
---
Attachment: LUCENE-9376.patch
> Fix or suppress 20 resource leak precommit warnings in lucene/search
>
>
> Key: LUCENE-9376
> URL: https://issues.apache.org/jira/browse/LUCENE-9376
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: LUCENE-9376.patch
>
>
> There are 20 resource leak precommit warnings in org/apache/lucene/search:
> {noformat}
> [ecj-lint] 71. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 414)
> [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 72. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
> (at line 557)
> [ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
> [ecj-lint] ^
> [ecj-lint] Resource leak: 'w' is never closed
> --
> [ecj-lint] 73. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'mgr' is not closed at this location
> --
> [ecj-lint] 74. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
> (at line 185)
> [ecj-lint] throw error.get();
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'w' is not closed at this location
> --
> [ecj-lint] 75. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
> (at line 49)
> [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 76. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
> (at line 313)
> [ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
> new SearcherFactory());
> [ecj-lint] ^^
> [ecj-lint] Resource leak: 'sm' is never closed
> --
> [ecj-lint] 79. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
> (at line 52)
> [ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
> MultiReader().getContext(), new Term("foo", "bar"), true)));
> [ecj-lint]
> ^
> [ecj-lint] Resource leak: '' is never closed
> --
> [ecj-lint] 15. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
> (at line 554)
> [ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
> [ecj-lint]
> [ecj-lint] Resource leak: 'docs' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
> (at line 598)
> [ecj-lint] IndexReader indexReaderWithTermVecCache =
> [ecj-lint] ^^^
> [ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
> --
> [ecj-lint] 1. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
> (at line 1365)
> [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
> [ecj-lint]
> [ecj-lint] Resource leak: 'analyzer' is never closed
> --
> [ecj-lint] 2. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
> (at line 379)
> [ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
> rTokenStream =
> [ecj-lint]
>
> [ecj-lint] Resource leak: 'rTokenStream' is never closed
> --
> [ecj-lint] 3. WARNING in
> /Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
> (at line 108)
> [ecj-lint] TokenStream tokenStream = new MockAnalyzer(random(),
> MockTokenizer.SIMPLE,
> [ecj-lint] true,
>
[jira] [Updated] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
[
https://issues.apache.org/jira/browse/LUCENE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Salamon updated LUCENE-9376:
---
Description:
There are 20 resource leak precommit warnings in org/apache/lucene/search:
{noformat}
[ecj-lint] 71. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
(at line 414)
[ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
--
[ecj-lint] 72. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
(at line 557)
[ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir);
[ecj-lint] ^
[ecj-lint] Resource leak: 'w' is never closed
--
[ecj-lint] 73. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
(at line 185)
[ecj-lint] throw error.get();
[ecj-lint] ^^
[ecj-lint] Resource leak: 'mgr' is not closed at this location
--
[ecj-lint] 74. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
(at line 185)
[ecj-lint] throw error.get();
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w' is not closed at this location
--
[ecj-lint] 75. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
(at line 49)
[ecj-lint] LineFileDocs docs = new LineFileDocs(random());
[ecj-lint]
[ecj-lint] Resource leak: 'docs' is never closed
--
[ecj-lint] 76. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
(at line 313)
[ecj-lint] SearcherManager sm = new SearcherManager(writer, false, false,
new SearcherFactory());
[ecj-lint] ^^
[ecj-lint] Resource leak: 'sm' is never closed
--
[ecj-lint] 79. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
(at line 52)
[ecj-lint] new TermQuery(new Term("foo", "bar"), TermStates.build(new
MultiReader().getContext(), new Term("foo", "bar"), true)));
[ecj-lint]
^
[ecj-lint] Resource leak: '' is never closed
--
[ecj-lint] 15. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
(at line 554)
[ecj-lint] final LineFileDocs docs = new LineFileDocs(random());
[ecj-lint]
[ecj-lint] Resource leak: 'docs' is never closed
--
[ecj-lint] 1. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
(at line 598)
[ecj-lint] IndexReader indexReaderWithTermVecCache =
[ecj-lint] ^^^
[ecj-lint] Resource leak: 'indexReaderWithTermVecCache' is never closed
--
[ecj-lint] 1. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
(at line 1365)
[ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
--
[ecj-lint] 2. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
(at line 379)
[ecj-lint] final BaseTermVectorsFormatTestCase.RandomTokenStream
rTokenStream =
[ecj-lint]
[ecj-lint] Resource leak: 'rTokenStream' is never closed
--
[ecj-lint] 3. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
(at line 108)
[ecj-lint] TokenStream tokenStream = new MockAnalyzer(random(),
MockTokenizer.SIMPLE,
[ecj-lint] true,
MockTokenFilter.ENGLISH_STOPSET).tokenStream(fieldName, text);
[ecj-lint]
^^^
--
[ecj-lint] 4. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/sandbox/src/test/org/apache/lucene/search/TestTermAutomatonQuery.java
(at line 426)
[ecj-lint] RandomIndexWriter w = new RandomIndexWriter(random(), dir, iwc);
[ecj-lint] ^
[ecj-lint] Resource leak: 'w' is never closed
--
[ecj-lint] 1. WARNING in
[jira] [Created] (LUCENE-9376) Fix or suppress 20 resource leak precommit warnings in lucene/search
Andras Salamon created LUCENE-9376:
--
Summary: Fix or suppress 20 resource leak precommit warnings in
lucene/search
Key: LUCENE-9376
URL: https://issues.apache.org/jira/browse/LUCENE-9376
Project: Lucene - Core
Issue Type: Sub-task
Reporter: Andras Salamon
There are 20 resource leak precommit warnings in org/apache/lucene/search:
{noformat}
[ecj-lint] 71. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
(at line 414) [ecj-lint] 71. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
(at line 414) [ecj-lint] MockAnalyzer analyzer = new MockAnalyzer(random());
[ecj-lint] [ecj-lint] Resource leak: 'analyzer' is never
closed-- [ecj-lint] 72. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestFuzzyQuery.java
(at line 557) [ecj-lint] RandomIndexWriter w = new
RandomIndexWriter(random(), dir); [ecj-lint] ^ [ecj-lint]
Resource leak: 'w' is never closed-- [ecj-lint] 73. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
(at line 185) [ecj-lint] throw error.get(); [ecj-lint] ^^
[ecj-lint] Resource leak: 'mgr' is not closed at this location-- [ecj-lint] 74.
WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestLRUQueryCache.java
(at line 185) [ecj-lint] throw error.get(); [ecj-lint] ^^
[ecj-lint] Resource leak: 'w' is not closed at this location-- [ecj-lint] 75.
WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSameScoresWithThreads.java
(at line 49) [ecj-lint] LineFileDocs docs = new LineFileDocs(random());
[ecj-lint] [ecj-lint] Resource leak: 'docs' is never
closed-- [ecj-lint] 76. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestSearcherManager.java
(at line 313) [ecj-lint] SearcherManager sm = new SearcherManager(writer,
false, false, new SearcherFactory()); [ecj-lint] ^^ [ecj-lint]
Resource leak: 'sm' is never closed-- [ecj-lint] 79. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/core/src/test/org/apache/lucene/search/TestTermQuery.java
(at line 52) [ecj-lint] new TermQuery(new Term("foo", "bar"),
TermStates.build(new MultiReader().getContext(), new Term("foo", "bar"),
true))); [ecj-lint]
^ [ecj-lint] Resource leak: '' is
never closed-- [ecj-lint] 15. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/test-framework/src/java/org/apache/lucene/search/ShardSearchingTestBase.java
(at line 554) [ecj-lint] final LineFileDocs docs = new
LineFileDocs(random()); [ecj-lint] [ecj-lint] Resource
leak: 'docs' is never closed-- [ecj-lint] 1. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java
(at line 598) [ecj-lint] IndexReader indexReaderWithTermVecCache = [ecj-lint]
^^^ [ecj-lint] Resource leak:
'indexReaderWithTermVecCache' is never closed-- [ecj-lint] 1. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
(at line 1365) [ecj-lint] Analyzer analyzer = new SynonymAnalyzer(synonyms);
[ecj-lint] [ecj-lint] Resource leak: 'analyzer' is never
closed-- [ecj-lint] 2. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/TokenSourcesTest.java
(at line 379) [ecj-lint] final
BaseTermVectorsFormatTestCase.RandomTokenStream rTokenStream = [ecj-lint]
[ecj-lint]
Resource leak: 'rTokenStream' is never closed-- [ecj-lint] 3. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/highlighter/src/test/org/apache/lucene/search/highlight/custom/HighlightCustomQueryTest.java
(at line 108) [ecj-lint] TokenStream tokenStream = new MockAnalyzer(random(),
MockTokenizer.SIMPLE, [ecj-lint] true,
MockTokenFilter.ENGLISH_STOPSET).tokenStream(fieldName, text); [ecj-lint]
^^^--
[ecj-lint] 4. WARNING in
/Users/andrassalamon/src/lucene-solr-upstream/lucene/sandbox/src/test/org/apache/lucene/search/TestTermAutomatonQuery.java
(at line 426) [ecj-lint] RandomIndexWriter w = new
[jira] [Commented] (SOLR-14105) Http2SolrClient SSL not working in branch_8x
[
https://issues.apache.org/jira/browse/SOLR-14105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111236#comment-17111236
]
Tim Taranov commented on SOLR-14105:
[~janhoy] unfortunately we can't retest this with the unreleased version of
solr in the specific configuration where these issues occur - we've had to roll
back to solr 8.3.1 for the time being. I'll retest this after solr 8.6 is
released.
> Http2SolrClient SSL not working in branch_8x
>
>
> Key: SOLR-14105
> URL: https://issues.apache.org/jira/browse/SOLR-14105
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.5
>Reporter: Jan Høydahl
>Assignee: Kevin Risden
>Priority: Major
> Attachments: SOLR-14105.patch
>
>
> In branch_8x we upgraded to Jetty 9.4.24. This causes the following
> exceptions when attempting to start server with SSL:
> {noformat}
> 2019-12-17 14:46:16.646 ERROR (main) [ ] o.a.s.c.SolrCore
> null:org.apache.solr.common.SolrException: Error instantiating
> shardHandlerFactory class [HttpShardHandlerFactory]:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:633)
> ...
> Caused by: java.lang.RuntimeException:
> java.lang.UnsupportedOperationException: X509ExtendedKeyManager only
> supported on Server
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:224)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient.(Http2SolrClient.java:154)
> at
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.build(Http2SolrClient.java:833)
> at
> org.apache.solr.handler.component.HttpShardHandlerFactory.init(HttpShardHandlerFactory.java:321)
> at
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:51)
> ... 50 more
> Caused by: java.lang.UnsupportedOperationException: X509ExtendedKeyManager
> only supported on Server
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.newSniX509ExtendedKeyManager(SslContextFactory.java:1273)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.getKeyManagers(SslContextFactory.java:1255)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.load(SslContextFactory.java:374)
> at
> org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:245)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14498) BlockCache gets stuck not accepting new stores
[
https://issues.apache.org/jira/browse/SOLR-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki reassigned SOLR-14498:
---
Assignee: Andrzej Bialecki
> BlockCache gets stuck not accepting new stores
> --
>
> Key: SOLR-14498
> URL: https://issues.apache.org/jira/browse/SOLR-14498
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 6.5, 6.6.5, master (9.0), 7.7.3, 8.5.1
>Reporter: Jakub Zytka
>Assignee: Andrzej Bialecki
>Priority: Major
>
> {{BlockCache}} uses two components: "storage", i.e. {{banks}} and "eviction
> mechanism", i.e {{cache}}, implemented by caffeine cache.
> The relation between them is that "storage" enforces a strict limit for the
> number of entries (
> {{numberOfBlocksPerBank * numberOfBanks}}) whereas the "eviction mechanism"
> takes care of freeing entries from the storage thanks to {{maximumSize}} set
> for the caffeine cache to {{numberOfBlocksPerBank * numberOfBanks - 1}}.
> The storage relies on caffeine cache to eventually free at least 1 entry from
> the storage. If that doesn't happen the {{BlockCache}} starts to fail all new
> stores.
> As it turns out, the caffeine cache may not reduce it's size to the desired
> {{maximumSize}} for as long as no {{put}} or {{getIfPresent}} which *finds an
> entry* is executed.
> With a sufficiently unlucky read pattern, the block cache may be rendered
> useless (0 hit ratio):
> cache poisoned by non-reusable entries; new, reusable entries are not stored
> and thus not reused.
> Further info may be found in
> [https://github.com/ben-manes/caffeine/issues/420]
>
> Change in caffeine that triggers it's internal cleanup mechanism regardless
> of whether getIfPresent gets a hit has been implemented in
> [https://github.com/ben-manes/caffeine/commit/7239bb0dda2af1e7301e8f66a5df28215b5173bc]
> and is due to be released in caffeine 2.8.4
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
dsmiley commented on a change in pull request #1527:
URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427323443
##
File path: solr/core/src/java/org/apache/solr/request/SolrRequestInfo.java
##
@@ -52,35 +54,44 @@
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
public static SolrRequestInfo getRequestInfo() {
-return threadLocal.get();
+if (threadLocal.get().isEmpty()) return null;
+return threadLocal.get().peek();
}
public static void setRequestInfo(SolrRequestInfo info) {
-// TODO: temporary sanity check... this can be changed to just an assert
in the future
-SolrRequestInfo prev = threadLocal.get();
-if (prev != null) {
- log.error("Previous SolrRequestInfo was not closed! req={}",
prev.req.getOriginalParams());
- log.error("prev == info : {}", prev.req == info.req, new
RuntimeException());
+if (info == null) {
+ throw new IllegalArgumentException("SolrRequestInfo is null");
+} else {
+ threadLocal.get().push(info);
Review comment:
Good idea!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
dsmiley commented on a change in pull request #1527: URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427323730 ## File path: solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java ## @@ -456,6 +457,7 @@ public void doFilter(ServletRequest _request, ServletResponse _response, FilterC GlobalTracer.get().clearContext(); consumeInputFully(request, response); + SolrRequestInfo.reset(); Review comment: That is what `reset` _does_ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14498) BlockCache gets stuck not accepting new stores
[
https://issues.apache.org/jira/browse/SOLR-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakub Zytka updated SOLR-14498:
---
Affects Version/s: master (9.0)
> BlockCache gets stuck not accepting new stores
> --
>
> Key: SOLR-14498
> URL: https://issues.apache.org/jira/browse/SOLR-14498
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query
>Affects Versions: 6.5, 6.6.5, master (9.0), 7.7.3, 8.5.1
>Reporter: Jakub Zytka
>Priority: Major
>
> {{BlockCache}} uses two components: "storage", i.e. {{banks}} and "eviction
> mechanism", i.e {{cache}}, implemented by caffeine cache.
> The relation between them is that "storage" enforces a strict limit for the
> number of entries (
> {{numberOfBlocksPerBank * numberOfBanks}}) whereas the "eviction mechanism"
> takes care of freeing entries from the storage thanks to {{maximumSize}} set
> for the caffeine cache to {{numberOfBlocksPerBank * numberOfBanks - 1}}.
> The storage relies on caffeine cache to eventually free at least 1 entry from
> the storage. If that doesn't happen the {{BlockCache}} starts to fail all new
> stores.
> As it turns out, the caffeine cache may not reduce it's size to the desired
> {{maximumSize}} for as long as no {{put}} or {{getIfPresent}} which *finds an
> entry* is executed.
> With a sufficiently unlucky read pattern, the block cache may be rendered
> useless (0 hit ratio):
> cache poisoned by non-reusable entries; new, reusable entries are not stored
> and thus not reused.
> Further info may be found in
> [https://github.com/ben-manes/caffeine/issues/420]
>
> Change in caffeine that triggers it's internal cleanup mechanism regardless
> of whether getIfPresent gets a hit has been implemented in
> [https://github.com/ben-manes/caffeine/commit/7239bb0dda2af1e7301e8f66a5df28215b5173bc]
> and is due to be released in caffeine 2.8.4
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14498) BlockCache gets stuck not accepting new stores
Jakub Zytka created SOLR-14498:
--
Summary: BlockCache gets stuck not accepting new stores
Key: SOLR-14498
URL: https://issues.apache.org/jira/browse/SOLR-14498
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: query
Affects Versions: 8.5.1, 7.7.3, 6.6.5, 6.5
Reporter: Jakub Zytka
{{BlockCache}} uses two components: "storage", i.e. {{banks}} and "eviction
mechanism", i.e {{cache}}, implemented by caffeine cache.
The relation between them is that "storage" enforces a strict limit for the
number of entries (
{{numberOfBlocksPerBank * numberOfBanks}}) whereas the "eviction mechanism"
takes care of freeing entries from the storage thanks to {{maximumSize}} set
for the caffeine cache to {{numberOfBlocksPerBank * numberOfBanks - 1}}.
The storage relies on caffeine cache to eventually free at least 1 entry from
the storage. If that doesn't happen the {{BlockCache}} starts to fail all new
stores.
As it turns out, the caffeine cache may not reduce it's size to the desired
{{maximumSize}} for as long as no {{put}} or {{getIfPresent}} which *finds an
entry* is executed.
With a sufficiently unlucky read pattern, the block cache may be rendered
useless (0 hit ratio):
cache poisoned by non-reusable entries; new, reusable entries are not stored
and thus not reused.
Further info may be found in [https://github.com/ben-manes/caffeine/issues/420]
Change in caffeine that triggers it's internal cleanup mechanism regardless of
whether getIfPresent gets a hit has been implemented in
[https://github.com/ben-manes/caffeine/commit/7239bb0dda2af1e7301e8f66a5df28215b5173bc]
and is due to be released in caffeine 2.8.4
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on pull request #1522: URL: https://github.com/apache/lucene-solr/pull/1522#issuecomment-630789427 I fixed it on https://github.com/apache/lucene-solr/commit/51c15b8660b9d6a3e5979bf1e53a98262db413e9 (and accidentally logged "merge" commit in the master https://github.com/apache/lucene-solr/commit/3b09d30e69795388e655275d23f1e83be0556da7; sorry.) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9333) Gradle task equivalent to ant's "change-to-html"
[ https://issues.apache.org/jira/browse/LUCENE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1731#comment-1731 ] ASF subversion and git services commented on LUCENE-9333: - Commit 51c15b8660b9d6a3e5979bf1e53a98262db413e9 in lucene-solr's branch refs/heads/master from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=51c15b8 ] LUCENE-9333: Use DirectoryProperty instead of directly having Provider; move script file to input field. > Gradle task equivalent to ant's "change-to-html" > > > Key: LUCENE-9333 > URL: https://issues.apache.org/jira/browse/LUCENE-9333 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on pull request #1522: URL: https://github.com/apache/lucene-solr/pull/1522#issuecomment-630779242 I think you can do the same "Provider -> DirectoryProperty" change in the changes-to-html task that you modified yesterday. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r427252786
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * 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.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
Thanks!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r427249419
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * 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.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
Thank you,
https://github.com/apache/lucene-solr/pull/1522/commits/778701c97120fbc2e6578a545d7719ac19d82d75
works for me.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1708#comment-1708 ] Robert Muir commented on SOLR-14142: Days, bytes, maybe there are lots of options towards a good default. Have not even looked into jetty options around all this: there is no need to blow scope, I don't want to tackle this crap here. If you are interested, please open an issue and do the research and upload/test a patch. This patch is tested and works, it just changes the default and remove deprecations. That's why I think retention is best handled as another issue. > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111085#comment-17111085 ] Uwe Schindler commented on SOLR-14497: -- As already discussed on Mailing list, I'd suggest to not move too fast forward with that. I'd suggest to focus on master branch and leave 8.x alone. I'd also wait for the Gradle migration to be finalized: I don't want to be disturbed in this process yet. As this is/was infrastructure affecting both projects, we should start with a "stable state". > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Elements to handle (as sub-tasks)? > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-14497: - Description: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # Determine how to split web site # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] was: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # Deterine how to split web site # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Elements to handle (as sub-tasks)? > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Determine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-14497: - Description: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # Deterine how to split web site # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] was: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Elements to handle (as sub-tasks)? > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # Deterine how to split web site > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Web Site: clone lucene/solr-site Git Repo, add a TLP marking tag > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111080#comment-17111080 ] Uwe Schindler commented on SOLR-14142: -- Maybe make days to keep confirgurable and start with 7 days. I agree, that's a different issue. > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111079#comment-17111079 ] Uwe Schindler commented on SOLR-14142: -- I agree. Because of the security question coming in from somebody who was hacked, this is a good information. I would restrict it to even shorter time. > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14419) Query DLS {"param":"ref"}
[
https://issues.apache.org/jira/browse/SOLR-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111061#comment-17111061
]
Cao Manh Dat commented on SOLR-14419:
-
Hi [~mkhl], I'm going to look into the patch tomorrow.
> Query DLS {"param":"ref"}
> -
>
> Key: SOLR-14419
> URL: https://issues.apache.org/jira/browse/SOLR-14419
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14419.patch, SOLR-14419.patch, SOLR-14419.patch
>
>
> What we can do with plain params:
> {{q=\{!parent which=$prnts}...=type:parent}}
> obviously I want to have something like this in Query DSL:
> {code}
> { "query": { "parents":{ "which":{"param":"prnts"}, "query":"..."}}
> "params": {
> "prnts":"type:parent"
>}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111015#comment-17111015 ] Robert Muir commented on SOLR-14142: Please, lets open a separate issue for that. It is completely unrelated. > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14497) Move the project to become Apache TLP
[ https://issues.apache.org/jira/browse/SOLR-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated SOLR-14497: --- Description: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Proceed with LUCENE-9375. # [add more here] was: This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Reorganize Lucene repository (remove Solr, move lucene folder upward). # [add more here] > Move the project to become Apache TLP > - > > Key: SOLR-14497 > URL: https://issues.apache.org/jira/browse/SOLR-14497 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dawid Weiss >Priority: Major > > This issue is about the process of moving Solr to become an Apache TLP. > Elements to handle (as sub-tasks)? > h4. Preparation > # Figure out formal steps to be taken with Apache Board to set up TLP > project for Solr. > # Figure out the initial committership, PMC members, chair. > # Separate the code (and build) from Lucene so that Solr can be built > independently. This applies to 8.x and master (9.x). > # Determine what happens with mailing lists (and their archives). Are new > mailing lists going to be set up or the existing ones aliased somehow? > # Determine what happens with CI and build servers. > # [add more here] > h4. Execution > # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. > # Send an information about any potential mailing list changes, etc. to > previous addresses. > # Add redirects from old Solr site/ javadoc/ any other addresses to TLP > locations. > # [add more here] > h4. Post-transition > # Proceed with LUCENE-9375. > # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9375) Post Solr TLP move cleanup tasks
[ https://issues.apache.org/jira/browse/LUCENE-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9375: Description: Please comment on SOLR-14497 unless it's Lucene specific. # Reorganize Lucene repository (remove Solr, move lucene folder upward). was:Please comment on SOLR-14497 unless it's Lucene specific. > Post Solr TLP move cleanup tasks > > > Key: LUCENE-9375 > URL: https://issues.apache.org/jira/browse/LUCENE-9375 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Priority: Major > > Please comment on SOLR-14497 unless it's Lucene specific. > > # Reorganize Lucene repository (remove Solr, move lucene folder upward). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9375) Post Solr TLP move cleanup tasks
Dawid Weiss created LUCENE-9375: --- Summary: Post Solr TLP move cleanup tasks Key: LUCENE-9375 URL: https://issues.apache.org/jira/browse/LUCENE-9375 Project: Lucene - Core Issue Type: Task Reporter: Dawid Weiss Please comment on SOLR-14497 unless it's Lucene specific. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14497) Move the project to become Apache TLP
Dawid Weiss created SOLR-14497: -- Summary: Move the project to become Apache TLP Key: SOLR-14497 URL: https://issues.apache.org/jira/browse/SOLR-14497 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Dawid Weiss This issue is about the process of moving Solr to become an Apache TLP. Elements to handle (as sub-tasks)? h4. Preparation # Figure out formal steps to be taken with Apache Board to set up TLP project for Solr. # Figure out the initial committership, PMC members, chair. # Separate the code (and build) from Lucene so that Solr can be built independently. This applies to 8.x and master (9.x). # Determine what happens with mailing lists (and their archives). Are new mailing lists going to be set up or the existing ones aliased somehow? # Determine what happens with CI and build servers. # [add more here] h4. Execution # Code: clone Lucene/Solr git to Solr TLP, add a TLP marking tag. # Send an information about any potential mailing list changes, etc. to previous addresses. # Add redirects from old Solr site/ javadoc/ any other addresses to TLP locations. # [add more here] h4. Post-transition # Reorganize Lucene repository (remove Solr, move lucene folder upward). # [add more here] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
dweiss commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r427124063
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * 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.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
This works for me and is what I had in mind:
```
configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
- task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation') {
+docsDir = project.layout.dir provider { project.docroot }
+ }
// TODO: uncomment this line after fixing all broken links.
// (we can't fix the cross-project links until ant build is disabled.)
@@ -38,7 +39,7 @@ configure(subprojects.findAll { it.path in [':lucene',
':solr'] }) {
class CheckBrokenLinksTask extends DefaultTask {
@InputDirectory
- final Provider docsDir = project.providers.provider {
project.docroot }
+ final DirectoryProperty docsDir = project.objects.directoryProperty()
@InputFile
File script =
project.rootProject.file("dev-tools/scripts/checkJavadocLinks.py")
@@ -56,7 +57,7 @@ class CheckBrokenLinksTask extends DefaultTask {
args = [
"-B",
script.absolutePath,
- docsDir.get().absolutePath
+ docsDir.get().asFile
]
}
}
```
Any version is fine though, I don't mind.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110952#comment-17110952 ] Jan Høydahl commented on SOLR-12823: SOLR-14303 is for deprecating /admin/zookeeper > remove clusterstate.json in Lucene/Solr 8.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 8.0 > It stays empty unless you explicitly ask to create the collection with the > old "stateFormat" and there is no reason for one to create a collection with > the old stateFormat. > We should also remove the "stateFormat" argument in create collection > We should also remove MIGRATESTATEVERSION as well > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-9679) Exception when removing zk node /security.json
[
https://issues.apache.org/jira/browse/SOLR-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110945#comment-17110945
]
Jan Høydahl commented on SOLR-9679:
---
I updated the PR with a unit test. Please review.
> Exception when removing zk node /security.json
> --
>
> Key: SOLR-9679
> URL: https://issues.apache.org/jira/browse/SOLR-9679
> Project: Solr
> Issue Type: Bug
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> To reproduce:
> # Upload {{security.json}} to zk
> # {{bin/solr zk rm zk:/security.json -z localhost:9983}}
> {noformat}
> 2016-10-22 22:17:32.264 DEBUG (main-EventThread) [ ] o.a.s.c.c.SolrZkClient
> Submitting job to respond to event WatchedEvent state:SyncConnected
> type:NodeDeleted path:/security.json
> 2016-10-22 22:17:32.265 DEBUG
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader Updating [/security.json] ...
> 2016-10-22 22:17:32.266 ERROR
> (zkCallback-3-thread-1-processing-n:192.168.0.11:8983_solr) [ ]
> o.a.s.c.c.ZkStateReader A ZK error has occurred
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /security.json
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1155)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:356)
> at
> org.apache.solr.common.cloud.SolrZkClient$7.execute(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
> at
> org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:353)
> at
> org.apache.solr.common.cloud.ZkStateReader$3.process(ZkStateReader.java:455)
> at
> org.apache.solr.common.cloud.SolrZkClient$3.lambda$process$0(SolrZkClient.java:268)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm not sure what should happen, but it would be sweet to be able to disable
> security by simply removing the znode... [~noble.paul] ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
dweiss commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r427089469
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * 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.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
For reference - the difference is that Input is just the file,
InputFIle is the file and its contents (!).
https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/InputFile.html
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r427087643
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * 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.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
of course it's a directory, sorry!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-14384: Status: Patch Available (was: Open) > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
mkhludnev commented on a change in pull request #1527: URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427066314 ## File path: solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java ## @@ -456,6 +457,7 @@ public void doFilter(ServletRequest _request, ServletResponse _response, FilterC GlobalTracer.get().clearContext(); consumeInputFully(request, response); + SolrRequestInfo.reset(); Review comment: there we need to check that stack have fully cleared and disposed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mkhludnev commented on a change in pull request #1527: SOLR-14384 Stack SolrRequestInfo
mkhludnev commented on a change in pull request #1527:
URL: https://github.com/apache/lucene-solr/pull/1527#discussion_r427064514
##
File path: solr/core/src/java/org/apache/solr/request/SolrRequestInfo.java
##
@@ -52,35 +54,44 @@
private static final Logger log =
LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
public static SolrRequestInfo getRequestInfo() {
-return threadLocal.get();
+if (threadLocal.get().isEmpty()) return null;
+return threadLocal.get().peek();
}
public static void setRequestInfo(SolrRequestInfo info) {
-// TODO: temporary sanity check... this can be changed to just an assert
in the future
-SolrRequestInfo prev = threadLocal.get();
-if (prev != null) {
- log.error("Previous SolrRequestInfo was not closed! req={}",
prev.req.getOriginalParams());
- log.error("prev == info : {}", prev.req == info.req, new
RuntimeException());
+if (info == null) {
+ throw new IllegalArgumentException("SolrRequestInfo is null");
+} else {
+ threadLocal.get().push(info);
Review comment:
Shouldn't we limit maximum stack depth?
What if one component leak SolrRequestInfo accidentally, like push it on
every request but refuse to pop it when exception occur. Thus it may steadily
flood heap. Or I miss something?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-14488) Making replica from leader configurable
[
https://issues.apache.org/jira/browse/SOLR-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-14488:
Comment: was deleted
(was: Hi [~cpoerschke], my plan here is introduce another block for config tlog
replica and pull replica. Putting everything under of , seems counterintuitive to
me. Something like this
{code}
... same content as tag in ...
{code})
> Making replica from leader configurable
> ---
>
> Key: SOLR-14488
> URL: https://issues.apache.org/jira/browse/SOLR-14488
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Right now, users can't configure related parameters for replicating from
> leader process. Like {{commitReserveDuration}}, throttling, etc.
> The default 10s value of {{commitReserveDuration}} can making replicate from
> leader failed constantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14488) Making replica from leader configurable
[
https://issues.apache.org/jira/browse/SOLR-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110894#comment-17110894
]
Cao Manh Dat commented on SOLR-14488:
-
Hi [~cpoerschke], my plan here is introduce another block for config tlog
replica and pull replica. Putting everything under of , seems counterintuitive to
me. Something like this
{code}
... same content as tag in ...
{code}
> Making replica from leader configurable
> ---
>
> Key: SOLR-14488
> URL: https://issues.apache.org/jira/browse/SOLR-14488
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Right now, users can't configure related parameters for replicating from
> leader process. Like {{commitReserveDuration}}, throttling, etc.
> The default 10s value of {{commitReserveDuration}} can making replicate from
> leader failed constantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
