[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2092 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2092/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.MoveReplicaTest Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:52699 within 3 ms Stack Trace: org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:52699 within 3 ms at __randomizedtesting.SeedInfo.seed([C1B3EDDBBA331902]:0) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:184) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:121) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:103) at org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:233) at org.apache.solr.cloud.SolrCloudTestCase$Builder.build(SolrCloudTestCase.java:200) at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:192) at org.apache.solr.cloud.MoveReplicaTest.setupCluster(MoveReplicaTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:52699 within 3 ms at org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:232) at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:176) ... 31 more FAILED: junit.framework.TestSuite.org.apache.solr.cloud.MoveReplicaTest Error Message: 4 threads leaked from SUITE scope at org.apache.solr.cloud.MoveReplicaTest: 1) Thread[id=2263, name=Thread-313, state=WAITING, group=TGRP-MoveReplicaTest] at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1252) at java.lang.Thread.join(Thread.java:1326) at org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313) at org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:313) at org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:496) 2) Thread[id=2264, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, group=TGRP-MoveReplicaTest] at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method) at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:223) at
[jira] [Commented] (SOLR-12612) Accept any key in cluster properties
[
https://issues.apache.org/jira/browse/SOLR-12612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639265#comment-16639265
]
Noble Paul commented on SOLR-12612:
---
cluster properties is a json file. Let's not have a prefix like {{"ext."}} .
Instead, let's just keep a top level key , called {{"ext"}} all user properties
must go into that
> Accept any key in cluster properties
>
>
> Key: SOLR-12612
> URL: https://issues.apache.org/jira/browse/SOLR-12612
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.4, master (8.0)
>Reporter: jefferyyuan
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: 7.5, master (8.0)
>
> Attachments: SOLR-12612-docs.patch
>
>
> Cluster properties is a good place to store configuration data that's shared
> in the whole cluster: solr and other (authorized) apps can easily read and
> update them.
>
> It would be very useful if we can store extra data in cluster properties
> which would act as a centralized property management system between solr and
> its related apps (like manager or monitor apps).
>
> And the change would be also very simple.
> We can also require all extra property starts with prefix like: extra_
>
> PR: https://github.com/apache/lucene-solr/pull/429
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12739) Make autoscaling policy based replica placement the default strategy for placing replicas
[ https://issues.apache.org/jira/browse/SOLR-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639219#comment-16639219 ] Shalin Shekhar Mangar commented on SOLR-12739: -- Nightly testing revealed no failures which was curious so I wrote more tests. Turns out there was a bug in usePolicyFramework helper method which fell back on previous logic when the "defaults" section was not present in cluster properties. Starting another round of tests with this patch. > Make autoscaling policy based replica placement the default strategy for > placing replicas > - > > Key: SOLR-12739 > URL: https://issues.apache.org/jira/browse/SOLR-12739 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12739.patch, SOLR-12739.patch > > > Today the default placement strategy is the same one used since Solr 4.x > which is to select nodes on a round robin fashion. I propose to make the > autoscaling policy based replica placement as the default policy for placing > replicas. > This is related to SOLR-12648 where even though we have default cluster > preferences, we don't use them unless a policy is also configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12739) Make autoscaling policy based replica placement the default strategy for placing replicas
[ https://issues.apache.org/jira/browse/SOLR-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-12739: - Attachment: SOLR-12739.patch > Make autoscaling policy based replica placement the default strategy for > placing replicas > - > > Key: SOLR-12739 > URL: https://issues.apache.org/jira/browse/SOLR-12739 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12739.patch, SOLR-12739.patch > > > Today the default placement strategy is the same one used since Solr 4.x > which is to select nodes on a round robin fashion. I propose to make the > autoscaling policy based replica placement as the default policy for placing > replicas. > This is related to SOLR-12648 where even though we have default cluster > preferences, we don't use them unless a policy is also configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12835) Document statistics exposed by the Query Result Cache when maxRamMB is configured
Shalin Shekhar Mangar created SOLR-12835: Summary: Document statistics exposed by the Query Result Cache when maxRamMB is configured Key: SOLR-12835 URL: https://issues.apache.org/jira/browse/SOLR-12835 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: documentation Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 7.6, master (8.0) Document the stats exposed by LRUCache when maxRamMB is configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12835) Document statistics exposed by the Query Result Cache when maxRamMB is configured
[ https://issues.apache.org/jira/browse/SOLR-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639187#comment-16639187 ] ASF subversion and git services commented on SOLR-12835: Commit ab50275baea80b3fc41a5054708ec490cab0fa06 in lucene-solr's branch refs/heads/branch_7x from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ab50275 ] SOLR-12835: Document statistics exposed by the Query Result Cache when maxRamMB is configured (cherry picked from commit ace0db7a0a02e441055badca1687afd25b037f23) > Document statistics exposed by the Query Result Cache when maxRamMB is > configured > - > > Key: SOLR-12835 > URL: https://issues.apache.org/jira/browse/SOLR-12835 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12835.patch > > > Document the stats exposed by LRUCache when maxRamMB is configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12835) Document statistics exposed by the Query Result Cache when maxRamMB is configured
[ https://issues.apache.org/jira/browse/SOLR-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-12835. -- Resolution: Fixed > Document statistics exposed by the Query Result Cache when maxRamMB is > configured > - > > Key: SOLR-12835 > URL: https://issues.apache.org/jira/browse/SOLR-12835 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12835.patch > > > Document the stats exposed by LRUCache when maxRamMB is configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12835) Document statistics exposed by the Query Result Cache when maxRamMB is configured
[ https://issues.apache.org/jira/browse/SOLR-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639186#comment-16639186 ] ASF subversion and git services commented on SOLR-12835: Commit ace0db7a0a02e441055badca1687afd25b037f23 in lucene-solr's branch refs/heads/master from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ace0db7 ] SOLR-12835: Document statistics exposed by the Query Result Cache when maxRamMB is configured > Document statistics exposed by the Query Result Cache when maxRamMB is > configured > - > > Key: SOLR-12835 > URL: https://issues.apache.org/jira/browse/SOLR-12835 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12835.patch > > > Document the stats exposed by LRUCache when maxRamMB is configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12835) Document statistics exposed by the Query Result Cache when maxRamMB is configured
[ https://issues.apache.org/jira/browse/SOLR-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-12835: - Attachment: SOLR-12835.patch > Document statistics exposed by the Query Result Cache when maxRamMB is > configured > - > > Key: SOLR-12835 > URL: https://issues.apache.org/jira/browse/SOLR-12835 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12835.patch > > > Document the stats exposed by LRUCache when maxRamMB is configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12834) Expose ram based cache eviction statistics from FastLRUCache
Shalin Shekhar Mangar created SOLR-12834: Summary: Expose ram based cache eviction statistics from FastLRUCache Key: SOLR-12834 URL: https://issues.apache.org/jira/browse/SOLR-12834 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: metrics Reporter: Shalin Shekhar Mangar Fix For: 7.6, master (8.0) The LRUCache used for query result caches expose the following stats: # maxRamMB # ramBytesUsed # evictionsRamUsage The last one is not relevant to FastLRUCache as its behavior is to either evict by size or by heap but not both. However, the first two should be exposed by FastLRUCache as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida edited comment on LUCENE-8524 at 10/5/18 2:11 AM:
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file (and also unk.def if needed,) it is used for
"unknown word" handling, is sufficient, I think.
was (Author: tomoko uchida):
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular,
[jira] [Comment Edited] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida edited comment on LUCENE-8524 at 10/5/18 1:14 AM:
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary seed (CSVs) when building the
dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
was (Author: tomoko uchida):
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary when building the dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular, individual numbers and combining diacritics are
[jira] [Commented] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639118#comment-16639118
]
Tomoko Uchida commented on LUCENE-8524:
---
I have not looked closely this yet, so it is my intuition rather than strong
opinion...
About problem A:
I think this is not a problem of tokenizer itself but the built-in dictionary.
Nori includes mecab-ko-dic ([https://bitbucket.org/eunjeon/mecab-ko-dic]) as
built-in dectionary, it is a derivative of MeCab IPADIC
([https://sourceforge.net/projects/mecab/]), a widely used Japanese dictionary.
JapaneseTokeniezr (a.k.a Kuromoji), this includes mecab ipadic, behaves in the
same manner. In fact, original MeCab does not handle such non-CJK tokens
correnctly.
I cannot say it is a fault of MeCab IPADIC, it was originally built for
handling Japanse texts, before Unicode era.
But we can apply patches to the dictionary when building the dictionary.
A patch to `seed/char.def` file, it is used for "unknown word" handling, is
sufficient, I think.
> Nori (Korean) analyzer tokenization issues
> --
>
> Key: LUCENE-8524
> URL: https://issues.apache.org/jira/browse/LUCENE-8524
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/analysis
>Reporter: Trey Jones
>Priority: Major
>
> I opened this originally as an [Elastic
> bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
> but was asked to re-file it here. (Sorry for the poor formatting.
> "pre-formatted" isn't behaving.)
> *Elastic version*
> {
> "name" : "adOS8gy",
> "cluster_name" : "elasticsearch",
> "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
> "version" : {
> "number" : "6.4.0",
> "build_flavor" : "default",
> "build_type" : "deb",
> "build_hash" : "595516e",
> "build_date" : "2018-08-17T23:18:47.308994Z",
> "build_snapshot" : false,
> "lucene_version" : "7.4.0",
> "minimum_wire_compatibility_version" : "5.6.0",
> "minimum_index_compatibility_version" : "5.0.0"
> },
> "tagline" : "You Know, for Search"
> }
> *Plugins installed:* [analysis-icu, analysis-nori]
> *JVM version:*
> openjdk version "1.8.0_181"
> OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
> OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
> *OS version:*
> Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
> x86_64 GNU/Linux
> *Description of the problem including expected versus actual behavior:*
> I've uncovered a number of oddities in tokenization in the Nori analyzer. All
> examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
> Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
> order of importance:
> A. Tokens are split on different character POS types (which seem to not quite
> line up with Unicode character blocks), which leads to weird results for
> non-CJK tokens:
> * εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
> symbol) + μί/SL(Foreign language)
> * ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol)
> + k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
> ͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
> k/SL(Foreign language) + ̚/SY(Other symbol)
> * Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
> лтичко/SL(Foreign language) + ̄/SY(Other symbol)
> * don't is tokenized as don + t; same for don’t (with a curly apostrophe).
> * אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
> * Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
> While it is still possible to find these words using Nori, there are many
> more chances for false positives when the tokens are split up like this. In
> particular, individual numbers and combining diacritics are indexed
> separately (e.g., in the Cyrillic example above), which can lead to a
> performance hit on large corpora like Wiktionary or Wikipedia.
> Work around: use a character filter to get rid of combining diacritics before
> Nori processes the text. This doesn't solve the Greek, Hebrew, or English
> cases, though.
> Suggested fix: Characters in related Unicode blocks—like "Greek" and "Greek
> Extended", or "Latin" and "IPA Extensions"—should not trigger token splits.
> Combining diacritics should not trigger token splits. Non-CJK text should be
> tokenized on spaces and punctuation, not by character type shifts.
> Apostrophe-like characters should not trigger token splits (though I could
> see someone disagreeing on this one).
> B. The character "arae-a" (ㆍ, U+318D) is sometimes used instead of a middle
> dot (·, U+00B7) for
> [lists|https://en.wikipedia.org/wiki/Korean_punctuation#Differences_from_European_punctuation].
>
[jira] [Commented] (SOLR-12821) IndexSizeTriggerTest.testMixedBounds() failures
[
https://issues.apache.org/jira/browse/SOLR-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639090#comment-16639090
]
Steve Rowe commented on SOLR-12821:
---
This seed, from
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22974/], reproduces
for me 10/10 iterations locally:
{noformat}
Checking out Revision 5fb384c9898176d34fffe2b310a0a815d8aebecb
(refs/remotes/origin/master)
[...]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=IndexSizeTriggerTest -Dtests.method=testMixedBounds
-Dtests.seed=E6A8AE36FC0DDD9D -Dtests.multiplier=3 -Dtests.slow=true
-Dtests.locale=cu -Dtests.timezone=US/Michigan -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] FAILURE 49.7s J0 | IndexSizeTriggerTest.testMixedBounds <<<
[junit4]> Throwable #1: java.lang.AssertionError: expected:
but was:
[junit4]>at
__randomizedtesting.SeedInfo.seed([E6A8AE36FC0DDD9D:EC2B119BB1B6D6C7]:0)
[junit4]>at
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds(IndexSizeTriggerTest.java:669)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4]>at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4]>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4]>at
java.base/java.lang.reflect.Method.invoke(Method.java:566)
[junit4]>at java.base/java.lang.Thread.run(Thread.java:835)
[...]
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene80):
{foo=PostingsFormat(name=MockRandom), id=PostingsFormat(name=LuceneFixedGap)},
docValues:{}, maxPointsInLeafNode=1799, maxMBSortInHeap=7.400351308980122,
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@2bc18aeb),
locale=cu, timezone=US/Michigan
[junit4] 2> NOTE: Linux 4.15.0-32-generic amd64/Oracle Corporation 12-ea
(64-bit)/cpus=8,threads=1,free=127512616,total=518979584
{noformat}
> IndexSizeTriggerTest.testMixedBounds() failures
> ---
>
> Key: SOLR-12821
> URL: https://issues.apache.org/jira/browse/SOLR-12821
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Tests
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2077/],
> reproduced 5/5 iterations for me on Linux:
> {noformat}
> Checking out Revision 03c9c04353ce1b5ace33fddd5bd99059e63ed507
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=IndexSizeTriggerTest -Dtests.method=testMixedBounds
> -Dtests.seed=9336AB152EE44632 -Dtests.slow=true -Dtests.locale=hr
> -Dtests.timezone=America/Guayaquil -Dtests.asserts=true
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 50.8s J1 | IndexSizeTriggerTest.testMixedBounds <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> expected: but was:
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([9336AB152EE44632:99B514B8635F4D68]:0)
>[junit4]> at
> org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds(IndexSizeTriggerTest.java:669)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene80):
> {foo=PostingsFormat(name=MockRandom), id=PostingsFormat(name=Direct)},
> docValues:{_version_=DocValuesFormat(name=Asserting),
> foo=DocValuesFormat(name=Asserting), id=DocValuesFormat(name=Lucene70)},
> maxPointsInLeafNode=452, maxMBSortInHeap=5.552665847709986,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@cc0bab0),
> locale=hr, timezone=America/Guayaquil
>[junit4] 2> NOTE: SunOS 5.11 amd64/Oracle Corporation 1.8.0_172
> (64-bit)/cpus=3,threads=1,free=191495432,total=518979584
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor
[ https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639043#comment-16639043 ] jefferyyuan commented on SOLR-12833: Here is the PR: [https://github.com/apache/lucene-solr/pull/463/files] > Use timed-out lock in DistributedUpdateProcessor > > > Key: SOLR-12833 > URL: https://issues.apache.org/jira/browse/SOLR-12833 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors >Affects Versions: 7.5, master (8.0) >Reporter: jefferyyuan >Priority: Minor > Fix For: master (8.0) > > > There is a synchronize block that blocks other update requests whose IDs fall > in the same hash bucket. The update waits forever until it gets the lock at > the synchronize block, this can be a problem in some cases. > > Some add/update requests (for example updates with spatial/shape analysis) > like may take time (30+ seconds or even more), this would the request time > out and fail. > Client may retry the same requests multiple times or several minutes, this > would make things worse. > The server side receives all the update requests but all except one can do > nothing, have to wait there. This wastes precious memory and cpu resource. > We have seen the case 2000+ threads are blocking at the synchronize lock, and > only a few updates are making progress. Each thread takes 3+ mb memory which > causes OOM. > Also if the update can't get the lock in expected time range, its better to > fail fast. > > We can have one configuration in solrconfig.xml: > updateHandler/versionLock/timeInMill, so users can specify how long they want > to wait the version bucket lock. > The default value can be -1, so it behaves same - wait forever until it gets > the lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-12-ea+12) - Build # 2859 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2859/ Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseSerialGC 35 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.component.CustomHighlightComponentTest Error Message: Could not find collection:collection54 Stack Trace: java.lang.AssertionError: Could not find collection:collection54 at __randomizedtesting.SeedInfo.seed([1BAB5915F17526D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.handler.component.CustomHighlightComponentTest.setupCluster(CustomHighlightComponentTest.java:125) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 1) Thread[id=873, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeJettyTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest: 1) Thread[id=873, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeJettyTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835) at __randomizedtesting.SeedInfo.seed([AB9BD139E74B2441]:0) FAILED: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest.testMultiThreaded Error Message: Captured an uncaught exception in thread: Thread[id=872, name=DocThread-0, state=RUNNABLE, group=TGRP-LargeVolumeJettyTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=872, name=DocThread-0, state=RUNNABLE, group=TGRP-LargeVolumeJettyTest] Caused by: java.lang.AssertionError: DocThread-0---IOException occured when talking to server at: https://127.0.0.1:43561/solr/collection1 at
[GitHub] lucene-solr pull request #429: Accept any key in cluster properties
Github user jefferyyuan closed the pull request at: https://github.com/apache/lucene-solr/pull/429 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #463: Use timed-out lock in DistributedUpdateProces...
GitHub user jefferyyuan opened a pull request: https://github.com/apache/lucene-solr/pull/463 Use timed-out lock in DistributedUpdateProcessor You can merge this pull request into a Git repository by running: $ git pull https://github.com/jefferyyuan/lucene-solr master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/463.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #463 commit 94069b287997218ed1503c898fe9f1ab999093f7 Author: yyuan2 Date: 2018-10-04T23:15:19Z Use timed-out lock in DistributedUpdateProcessor --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12833) Use timed-out lock in DistributedUpdateProcessor
jefferyyuan created SOLR-12833: -- Summary: Use timed-out lock in DistributedUpdateProcessor Key: SOLR-12833 URL: https://issues.apache.org/jira/browse/SOLR-12833 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: update, UpdateRequestProcessors Affects Versions: 7.5, master (8.0) Reporter: jefferyyuan Fix For: master (8.0) There is a synchronize block that blocks other update requests whose IDs fall in the same hash bucket. The update waits forever until it gets the lock at the synchronize block, this can be a problem in some cases. Some add/update requests (for example updates with spatial/shape analysis) like may take time (30+ seconds or even more), this would the request time out and fail. Client may retry the same requests multiple times or several minutes, this would make things worse. The server side receives all the update requests but all except one can do nothing, have to wait there. This wastes precious memory and cpu resource. We have seen the case 2000+ threads are blocking at the synchronize lock, and only a few updates are making progress. Each thread takes 3+ mb memory which causes OOM. Also if the update can't get the lock in expected time range, its better to fail fast. We can have one configuration in solrconfig.xml: updateHandler/versionLock/timeInMill, so users can specify how long they want to wait the version bucket lock. The default value can be -1, so it behaves same - wait forever until it gets the lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12737) Let Solr init script create SOLR_PID_DIR
[
https://issues.apache.org/jira/browse/SOLR-12737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639021#comment-16639021
]
Shawn Heisey commented on SOLR-12737:
-
The patch assumes that every variable definition is at the very beginning of
the line in the include script, but that is not a strict requirement for that
file. Things defined in that file still work if there is whitespace at the
beginning of every line, but this directory creation wouldn't work if that were
the case.
Seems much better to source the file like bin/solr does, setting the variables
in the environment, rather than rely on a very strict format requirement.
The init script is the correct place to do this. If it were done in bin/solr,
it wouldn't work because a regular user typically doesn't have permission to
create directories in system locations like /run.
I wonder if the group permission should be changed to $RUNAS as well (with
output redirected to /dev/null just in case there's not a group with the same
name as the user).
> Let Solr init script create SOLR_PID_DIR
>
>
> Key: SOLR-12737
> URL: https://issues.apache.org/jira/browse/SOLR-12737
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 6.6.5, 7.4
> Environment: CentOS 7.5
>Reporter: Andreas Hubold
>Priority: Major
> Labels: patch, patch-available
> Attachments: init-script-mkdir-pid-dir.patch
>
>
> It would be great if the Solr init script could create the configured
> SOLR_PID_DIR with permissions for the Solr user, if it doesn't exist.
> The use case is to store the PID file for the Solr service in a directory
> below the /run directory, which is typically mounted as tmpfs file system and
> empty after reboot. For example, with "{{SOLR_PID_DIR=/run/solr}}" in
> solr.in.sh, Solr will be unable to write its PID file after reboot because
> the solr subdirectory does not exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12832) Java core dmp file is being created with a huge filesize (32gb) and due to which solr server is going to hung mode
[ https://issues.apache.org/jira/browse/SOLR-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639000#comment-16639000 ] Shawn Heisey commented on SOLR-12832: - Jira is not a support portal. Requests for help need to go to the mailing list or the IRC channel. When you created this issue, there would have been some very prominent red text outlining this fact. When you use one of these support resources, we will need things like logfiles. Core dumps are not created by Solr. That would be a function of either java, or more likely, the operating system. The project strongly recommends not using IBM Java. It has known bugs with Lucene/Solr code. Use either Oracle or OpenJDK. > Java core dmp file is being created with a huge filesize (32gb) and due to > which solr server is going to hung mode > -- > > Key: SOLR-12832 > URL: https://issues.apache.org/jira/browse/SOLR-12832 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 5.5.1 >Reporter: Yaswanth >Priority: Major > Labels: performance > > All of a sudden the solr api is going in hung mode and when we look into the > reason we do see its taking up the diskspace by creating a huge java core > dump file in this case its 32GB. > > Here are the more details: > Solr version : 5.5.0 > JVM: IBM Java 1.7.0 > JVM Memory setup: 40GB (total system memory is 128GB) > This is happening occasionally and right now as a workaround we are just > clearing up that huge java.core dmp file to make it work. And the major thing > is that we couldn't able to open this file in any tools to see what's causing > the java.core dump file. > > So we really need some help here on how / where to start debugging what's the > issue is? > > Any basic things to be verified here in this case? please let me know as this > causing a huge impact. > > Thanks, -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-12832) Java core dmp file is being created with a huge filesize (32gb) and due to which solr server is going to hung mode
[ https://issues.apache.org/jira/browse/SOLR-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey closed SOLR-12832. --- > Java core dmp file is being created with a huge filesize (32gb) and due to > which solr server is going to hung mode > -- > > Key: SOLR-12832 > URL: https://issues.apache.org/jira/browse/SOLR-12832 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 5.5.1 >Reporter: Yaswanth >Priority: Major > Labels: performance > > All of a sudden the solr api is going in hung mode and when we look into the > reason we do see its taking up the diskspace by creating a huge java core > dump file in this case its 32GB. > > Here are the more details: > Solr version : 5.5.0 > JVM: IBM Java 1.7.0 > JVM Memory setup: 40GB (total system memory is 128GB) > This is happening occasionally and right now as a workaround we are just > clearing up that huge java.core dmp file to make it work. And the major thing > is that we couldn't able to open this file in any tools to see what's causing > the java.core dump file. > > So we really need some help here on how / where to start debugging what's the > issue is? > > Any basic things to be verified here in this case? please let me know as this > causing a huge impact. > > Thanks, -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12832) Java core dmp file is being created with a huge filesize (32gb) and due to which solr server is going to hung mode
[ https://issues.apache.org/jira/browse/SOLR-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey resolved SOLR-12832. - Resolution: Invalid > Java core dmp file is being created with a huge filesize (32gb) and due to > which solr server is going to hung mode > -- > > Key: SOLR-12832 > URL: https://issues.apache.org/jira/browse/SOLR-12832 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search >Affects Versions: 5.5.1 >Reporter: Yaswanth >Priority: Major > Labels: performance > > All of a sudden the solr api is going in hung mode and when we look into the > reason we do see its taking up the diskspace by creating a huge java core > dump file in this case its 32GB. > > Here are the more details: > Solr version : 5.5.0 > JVM: IBM Java 1.7.0 > JVM Memory setup: 40GB (total system memory is 128GB) > This is happening occasionally and right now as a workaround we are just > clearing up that huge java.core dmp file to make it work. And the major thing > is that we couldn't able to open this file in any tools to see what's causing > the java.core dump file. > > So we really need some help here on how / where to start debugging what's the > issue is? > > Any basic things to be verified here in this case? please let me know as this > causing a huge impact. > > Thanks, -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-12-ea+12) - Build # 7551 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7551/ Java: 64bit/jdk-12-ea+12 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 18 tests failed. FAILED: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple Error Message: Waiting for collection testSimple2 null Live Nodes: [127.0.0.1:61054_solr, 127.0.0.1:61057_solr, 127.0.0.1:61062_solr] Last available state: null Stack Trace: java.lang.AssertionError: Waiting for collection testSimple2 null Live Nodes: [127.0.0.1:61054_solr, 127.0.0.1:61057_solr, 127.0.0.1:61062_solr] Last available state: null at __randomizedtesting.SeedInfo.seed([903A43695CF27FF5:A88967977B01AB24]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:280) at org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:110) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at
[jira] [Updated] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-12811: -- Description: This ticket will add the *enclosingDisk*, *getRadius, getCenter* and *getSupportPoints* Stream Evaluators. The enclosingDisk function will calculate the smallest circle that encloses a 2D data set. The implementation is provided by *Apache Commons Math.* (was: This ticket will add the *enclosingDisk*, *getRadius, getCenter* and *getSupportPoints* Stream Evaluators. The enclosingDIsk function will calculate the smallest circle that encloses a 2D data set. The implementation is provided by *Apache Commons Math.*) > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-12811.patch > > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDisk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12121) JWT Authentication plugin
[
https://issues.apache.org/jira/browse/SOLR-12121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638903#comment-16638903
]
Jan Høydahl commented on SOLR-12121:
Spun off the Principal transfer logic to new issue SOLR-12799 and marked that
issue as a requirement to be committed before this one.
> JWT Authentication plugin
> -
>
> Key: SOLR-12121
> URL: https://issues.apache.org/jira/browse/SOLR-12121
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: image-2018-08-27-13-04-04-183.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A new Authentication plugin that will accept a [Json Web
> Token|https://en.wikipedia.org/wiki/JSON_Web_Token] (JWT) in the
> Authorization header and validate it by checking the cryptographic signature.
> The plugin will not perform the authentication itself but assert that the
> user was authenticated by the service that issued the JWT token.
> JWT defined a number of standard claims, and user principal can be fetched
> from the {{sub}} (subject) claim and passed on to Solr. The plugin will
> always check the {{exp}} (expiry) claim and optionally enforce checks on the
> {{iss}} (issuer) and {{aud}} (audience) claims.
> The first version of the plugin will only support RSA signing keys and will
> support fetching the public key of the issuer through a [Json Web
> Key|https://tools.ietf.org/html/rfc7517] (JWK) file, either from a https URL
> or from local file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+12) - Build # 22974 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22974/ Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseSerialGC 45 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest Error Message: 12 threads leaked from SUITE scope at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest: 1) Thread[id=3008, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835)2) Thread[id=3011, name=zkConnectionManagerCallback-1464-thread-1, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054) at java.base@12-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114) at java.base@12-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base@12-ea/java.lang.Thread.run(Thread.java:835)3) Thread[id=450, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835)4) Thread[id=3010, name=TEST-StreamDecoratorTest.testParallelHavingStream-seed#[FFC6CFB8D579E95C]-EventThread, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)5) Thread[id=3014, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835)6) Thread[id=452, name=TEST-StreamDecoratorTest.testParallelExecutorStream-seed#[FFC6CFB8D579E95C]-EventThread, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@12-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@12-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@12-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)7) Thread[id=451, name=TEST-StreamDecoratorTest.testParallelExecutorStream-seed#[FFC6CFB8D579E95C]-SendThread(127.0.0.1:33231), state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1054)8) Thread[id=456, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835)9) Thread[id=3015, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835) 10) Thread[id=457, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@12-ea/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@12-ea/java.lang.Thread.run(Thread.java:835) 11)
[jira] [Updated] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trey Jones updated LUCENE-8524:
---
Description:
I opened this originally as an [Elastic
bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
but was asked to re-file it here.
*Elastic version*
{
"name" : "adOS8gy",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
"version" : {
"number" : "6.4.0",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "595516e",
"build_date" : "2018-08-17T23:18:47.308994Z",
"build_snapshot" : false,
"lucene_version" : "7.4.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
*Plugins installed:* [analysis-icu, analysis-nori]
*JVM version:*
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
*OS version:*
Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
x86_64 GNU/Linux
*Description of the problem including expected versus actual behavior:*
I've uncovered a number of oddities in tokenization in the Nori analyzer. All
examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
order of importance:
A. Tokens are split on different character POS types (which seem to not quite
line up with Unicode character blocks), which leads to weird results for
non-CJK tokens:
* εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
symbol) + μί/SL(Foreign language)
* ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol) +
k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
k/SL(Foreign language) + ̚/SY(Other symbol)
* Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
лтичко/SL(Foreign language) + ̄/SY(Other symbol)
* don't is tokenized as don + t; same for don’t (with a curly apostrophe).
* אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
* Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
While it is still possible to find these words using Nori, there are many more
chances for false positives when the tokens are split up like this. In
particular, individual numbers and combining diacritics are indexed separately
(e.g., in the Cyrillic example above), which can lead to a performance hit on
large corpora like Wiktionary or Wikipedia.
Work around: use a character filter to get rid of combining diacritics before
Nori processes the text. This doesn't solve the Greek, Hebrew, or English
cases, though.
Suggested fix: Characters in related Unicode blocks—like "Greek" and "Greek
Extended", or "Latin" and "IPA Extensions"—should not trigger token splits.
Combining diacritics should not trigger token splits. Non-CJK text should be
tokenized on spaces and punctuation, not by character type shifts.
Apostrophe-like characters should not trigger token splits (though I could see
someone disagreeing on this one).
B. The character "arae-a" (ㆍ, U+318D) is sometimes used instead of a middle dot
(·, U+00B7) for
[lists|https://en.wikipedia.org/wiki/Korean_punctuation#Differences_from_European_punctuation].
When the arae-a is used, everything after the first one ends up in one giant
token. 도로ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구 is tokenized as 도로 + ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구.
* Note that "HANGUL *LETTER* ARAEA" (ㆍ, U+318D) is used this way, while
"HANGUL *JUNGSEONG* ARAEA" (ᆞ, U+119E) is used to create syllable blocks for
which there is no precomposed Unicode character.
Work around: use a character filter to convert arae-a (U+318D) to a space.
Suggested fix: split tokens on all instances of arae-a (U+318D).
C. Nori splits tokens on soft hyphens (U+00AD) and zero-width non-joiners
(U+200C), splitting tokens that should not be split.
* hyphenation (with a soft hyphen in the middle) is tokenized as hyphen +
ation.
* بازیهای (with a zero-width non-joiner) is tokenized as بازی + های.
Work around: use a character filter to strip soft hyphens and zero-width
non-joiners before Nori.
Suggested fix: Nori should strip soft hyphens and zero-width non-joiners.
D. Analyzing 그레이맨 generates an extra empty token after it. There may be others,
but this is the only one I've found. Work around: at a min length token filter
with a minimum length of 1.
E. Analyzing 튜토리얼 generates a token with an extra space at the end of it. There
may be others, but this is the only one I've found. No work around needed, I
guess, since this is only the internal representation of the token. I'm not
sure if it has any negative effects.
*Steps to reproduce:*
1.
[JENKINS] Lucene-Solr-repro - Build # 1611 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1611/ [...truncated 31 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/920/consoleText [repro] Revision: 66b01fcff961d47d853f890c10556fc56748f7d6 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testMixedBounds -Dtests.seed=86AD5E841EA5649D -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Kashgar -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 5fb384c9898176d34fffe2b310a0a815d8aebecb [repro] git fetch [repro] git checkout 66b01fcff961d47d853f890c10556fc56748f7d6 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3437 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -Dtests.seed=86AD5E841EA5649D -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=sv -Dtests.timezone=Asia/Kashgar -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 13540 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 5fb384c9898176d34fffe2b310a0a815d8aebecb [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12832) Java core dmp file is being created with a huge filesize (32gb) and due to which solr server is going to hung mode
Yaswanth created SOLR-12832: --- Summary: Java core dmp file is being created with a huge filesize (32gb) and due to which solr server is going to hung mode Key: SOLR-12832 URL: https://issues.apache.org/jira/browse/SOLR-12832 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: search Affects Versions: 5.5.1 Reporter: Yaswanth All of a sudden the solr api is going in hung mode and when we look into the reason we do see its taking up the diskspace by creating a huge java core dump file in this case its 32GB. Here are the more details: Solr version : 5.5.0 JVM: IBM Java 1.7.0 JVM Memory setup: 40GB (total system memory is 128GB) This is happening occasionally and right now as a workaround we are just clearing up that huge java.core dmp file to make it work. And the major thing is that we couldn't able to open this file in any tools to see what's causing the java.core dump file. So we really need some help here on how / where to start debugging what's the issue is? Any basic things to be verified here in this case? please let me know as this causing a huge impact. Thanks, -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2846 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2846/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate
Error Message:
{}
Stack Trace:
java.lang.AssertionError: {}
at
__randomizedtesting.SeedInfo.seed([CCF30D640453E076:91BB13EDCB954639]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate(TestSimLargeCluster.java:695)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Build Log:
[...truncated 13604 lines...]
[junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster
[junit4] 2> 2229868 INFO
(SUITE-TestSimLargeCluster-seed#[CCF30D640453E076]-worker) []
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
test.solr.allowed.securerandom=null &
[jira] [Created] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
Trey Jones created LUCENE-8524:
--
Summary: Nori (Korean) analyzer tokenization issues
Key: LUCENE-8524
URL: https://issues.apache.org/jira/browse/LUCENE-8524
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Reporter: Trey Jones
I opened this originally as an [Elastic
bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
but was asked to re-file it here.
*Elastic version*
{{{}}
{{ "name" : "adOS8gy",}}
{{ "cluster_name" : "elasticsearch",}}
{{ "cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",}}
{{ "version" : {}}
{{ "number" : "6.4.0",}}
{{ "build_flavor" : "default",}}
{{ "build_type" : "deb",}}
{{ "build_hash" : "595516e",}}
{{ "build_date" : "2018-08-17T23:18:47.308994Z",}}
{{ "build_snapshot" : false,}}
{{ "lucene_version" : "7.4.0",}}
{{ "minimum_wire_compatibility_version" : "5.6.0",}}
{{ "minimum_index_compatibility_version" : "5.0.0"}}
{{ },}}
{{ "tagline" : "You Know, for Search"}}
{{}}}
*Plugins installed:* [analysis-icu, analysis-nori]
*JVM version:*
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
*OS version:*
Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
x86_64 GNU/Linux
*Description of the problem including expected versus actual behavior:*
I've uncovered a number of oddities in tokenization in the Nori analyzer. All
examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
order of importance:
A. Tokens are split on different character POS types (which seem to not quite
line up with Unicode character blocks), which leads to weird results for
non-CJK tokens:
* `εἰμί` is tokenized as three tokens: `ε/SL(Foreign language) + ἰ/SY(Other
symbol) + μί/SL(Foreign language)`
* `ka̠k̚t͡ɕ͈a̠k̚` is tokenized as `ka/SL(Foreign language) + ̠/SY(Other symbol)
+ k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
k/SL(Foreign language) + ̚/SY(Other symbol)`
* `Ба̀лтичко̄` is tokenized as `ба/SL(Foreign language) + ̀/SY(Other symbol) +
лтичко/SL(Foreign language) + ̄/SY(Other symbol)`
* `don't` is tokenized as `don + t`; same for `don’t` (with a curly apostrophe).
* `אוֹג׳וּ` is tokenized as `אוֹג/SY(Other symbol) + וּ/SY(Other symbol)`
* `Мoscow` (with a Cyrillic М and the rest in Latin) is tokenized as `м + oscow`
While it is still possible to find these words using Nori, there are many more
chances for false positives when the tokens are split up like this. In
particular, individual numbers and combining diacritics are indexed separately
(e.g., the `/` in the Cyrillic example above), which can lead to a performance
hit on large corpora like Wiktionary or Wikipedia.
Work around: use a character filter to get rid of combining diacritics before
Nori processes the text. This doesn't solve the Greek, Hebrew, or English
cases, though.
Suggested fix: Characters in related Unicode blocks—like "Greek" and "Greek
Extended", or "Latin" and "IPA Extensions"—should not trigger token splits.
Combining diacritics should not trigger token splits. Non-CJK text should be
tokenized on spaces and punctuation, not by character type shifts.
Apostrophe-like characters should not trigger token splits (though I could see
someone disagreeing on this one).
B. The character "arae-a" (ㆍ, U+318D) is sometimes used instead of a middle dot
(·, U+00B7) for
[lists|https://en.wikipedia.org/wiki/Korean_punctuation#Differences_from_European_punctuation].
When the arae-a is used, everything after the first one ends up in one giant
token. `도로ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구` is tokenized as `도로 + ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구`.
* Note that "HANGUL *LETTER* ARAEA" (ㆍ, U+318D) is used this way, while "HANGUL
*JUNGSEONG* ARAEA" (ᆞ, U+119E) is used to create syllable blocks for which
there is no precomposed Unicode character.
Work around: use a character filter to convert arae-a (U+318D) to a space.
Suggested fix: split tokens on all instances of arae-a (U+318D).
C. Nori splits tokens on soft hyphens (U+00AD) and zero-width non-joiners
(U+200C), splitting tokens that should not be split.
* `hyphenation` (with a soft hyphen in the middle) is tokenized as `hyphen +
ation`.
* `بازیهای ` (with a zero-width non-joiner) is tokenized as `بازی + های`.
Work around: use a character filter to strip soft hyphens and zero-width
non-joiners before Nori.
Suggested fix: Nori should strip soft hyphens and zero-width non-joiners.
D. Analyzing 그레이맨 generates an extra empty token after it. There may be others,
but this is the only one I've found. Work around: at a min length token filter
with a minimum length of 1.
E. Analyzing 튜토리얼 generates a token with
[jira] [Updated] (LUCENE-8524) Nori (Korean) analyzer tokenization issues
[
https://issues.apache.org/jira/browse/LUCENE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trey Jones updated LUCENE-8524:
---
Description:
I opened this originally as an [Elastic
bug|https://github.com/elastic/elasticsearch/issues/34283#issuecomment-426940784],
but was asked to re-file it here. (Sorry for the poor formatting.
"pre-formatted" isn't behaving.)
*Elastic version*
{
"name" : "adOS8gy",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "GVS7gpVBQDGwtHl3xnJbLw",
"version" : {
"number" : "6.4.0",
"build_flavor" : "default",
"build_type" : "deb",
"build_hash" : "595516e",
"build_date" : "2018-08-17T23:18:47.308994Z",
"build_snapshot" : false,
"lucene_version" : "7.4.0",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
*Plugins installed:* [analysis-icu, analysis-nori]
*JVM version:*
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-1~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
*OS version:*
Linux vagrantes6 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
x86_64 GNU/Linux
*Description of the problem including expected versus actual behavior:*
I've uncovered a number of oddities in tokenization in the Nori analyzer. All
examples are from [Korean Wikipedia|https://ko.wikipedia.org/] or [Korean
Wiktionary|https://ko.wiktionary.org/] (including non-CJK examples). In rough
order of importance:
A. Tokens are split on different character POS types (which seem to not quite
line up with Unicode character blocks), which leads to weird results for
non-CJK tokens:
* εἰμί is tokenized as three tokens: ε/SL(Foreign language) + ἰ/SY(Other
symbol) + μί/SL(Foreign language)
* ka̠k̚t͡ɕ͈a̠k̚ is tokenized as ka/SL(Foreign language) + ̠/SY(Other symbol) +
k/SL(Foreign language) + ̚/SY(Other symbol) + t/SL(Foreign language) +
͡ɕ͈/SY(Other symbol) + a/SL(Foreign language) + ̠/SY(Other symbol) +
k/SL(Foreign language) + ̚/SY(Other symbol)
* Ба̀лтичко̄ is tokenized as ба/SL(Foreign language) + ̀/SY(Other symbol) +
лтичко/SL(Foreign language) + ̄/SY(Other symbol)
* don't is tokenized as don + t; same for don’t (with a curly apostrophe).
* אוֹג׳וּ is tokenized as אוֹג/SY(Other symbol) + וּ/SY(Other symbol)
* Мoscow (with a Cyrillic М and the rest in Latin) is tokenized as м + oscow
While it is still possible to find these words using Nori, there are many more
chances for false positives when the tokens are split up like this. In
particular, individual numbers and combining diacritics are indexed separately
(e.g., in the Cyrillic example above), which can lead to a performance hit on
large corpora like Wiktionary or Wikipedia.
Work around: use a character filter to get rid of combining diacritics before
Nori processes the text. This doesn't solve the Greek, Hebrew, or English
cases, though.
Suggested fix: Characters in related Unicode blocks—like "Greek" and "Greek
Extended", or "Latin" and "IPA Extensions"—should not trigger token splits.
Combining diacritics should not trigger token splits. Non-CJK text should be
tokenized on spaces and punctuation, not by character type shifts.
Apostrophe-like characters should not trigger token splits (though I could see
someone disagreeing on this one).
B. The character "arae-a" (ㆍ, U+318D) is sometimes used instead of a middle dot
(·, U+00B7) for
[lists|https://en.wikipedia.org/wiki/Korean_punctuation#Differences_from_European_punctuation].
When the arae-a is used, everything after the first one ends up in one giant
token. 도로ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구 is tokenized as 도로 + ㆍ지반ㆍ수자원ㆍ건설환경ㆍ건축ㆍ화재설비연구.
* Note that "HANGUL *LETTER* ARAEA" (ㆍ, U+318D) is used this way, while
"HANGUL *JUNGSEONG* ARAEA" (ᆞ, U+119E) is used to create syllable blocks for
which there is no precomposed Unicode character.
Work around: use a character filter to convert arae-a (U+318D) to a space.
Suggested fix: split tokens on all instances of arae-a (U+318D).
C. Nori splits tokens on soft hyphens (U+00AD) and zero-width non-joiners
(U+200C), splitting tokens that should not be split.
* hyphenation (with a soft hyphen in the middle) is tokenized as hyphen +
ation.
* بازیهای (with a zero-width non-joiner) is tokenized as بازی + های.
Work around: use a character filter to strip soft hyphens and zero-width
non-joiners before Nori.
Suggested fix: Nori should strip soft hyphens and zero-width non-joiners.
D. Analyzing 그레이맨 generates an extra empty token after it. There may be others,
but this is the only one I've found. Work around: at a min length token filter
with a minimum length of 1.
E. Analyzing 튜토리얼 generates a token with an extra space at the end of it. There
may be others, but this is the only one I've found. No work around needed, I
guess, since this is only the internal representation of the token. I'm not
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1142 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1142/ No tests ran. Build Log: [...truncated 23269 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2432 links (1984 relative) to 3172 anchors in 246 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail:
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-12-ea+12) - Build # 2858 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2858/ Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseSerialGC 13 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([F6B8A8A9CFBC5846:CD520B1FA825954A]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.queryWithPreferReplicaTypes(CloudSolrClientTest.java:957) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferReplicaTypesTest(CloudSolrClientTest.java:891) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) FAILED:
[jira] [Commented] (SOLR-12791) Add Metrics reporting for AuthenticationPlugin
[
https://issues.apache.org/jira/browse/SOLR-12791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638599#comment-16638599
]
Jan Høydahl commented on SOLR-12791:
Thanks Ishan, appreciate that.
I have commented directly in the PR with some questions I have myself.
> Add Metrics reporting for AuthenticationPlugin
> --
>
> Key: SOLR-12791
> URL: https://issues.apache.org/jira/browse/SOLR-12791
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, metrics
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Propose to add Metrics support for all Auth plugins. Will let abstract
> {{AuthenticationPlugin}} base class implement {{SolrMetricProducer}} and keep
> the counters, such as:
> * requests
> * req authenticated
> * req pass-through (no credentials and blockUnknown false)
> * req with auth failures due to wrong or malformed credentials
> * req auth failures due to missing credentials
> * errors
> * timeouts
> * timing stats
> Each implementation still needs to increment the counters etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222759868
--- Diff:
solr/core/src/java/org/apache/solr/security/AuthenticationPlugin.java ---
@@ -52,11 +80,73 @@
public abstract boolean doAuthenticate(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws Exception;
+ /**
+ * This method is called by SolrDispatchFilter in order to initiate
authentication.
+ * It does some standard metrics counting.
+ */
+ public final boolean authenticate(ServletRequest request,
ServletResponse response, FilterChain filterChain) throws Exception {
+Timer.Context timer = requestTimes.time();
+requests.inc();
+try {
+ return doAuthenticate(request, response, filterChain);
+} catch(Exception e) {
+ numErrors.mark();
+ throw e;
+} finally {
+ long elapsed = timer.stop();
+ totalTime.inc(elapsed);
+}
+ }
/**
* Cleanup any per request data
*/
public void closeRequest() {
}
+ @Override
+ public void initializeMetrics(SolrMetricManager manager, String
registryName, String tag, final String scope) {
+this.metricManager = manager;
+this.registryName = registryName;
+// Metrics
+registry = manager.registry(registryName);
+numErrors = manager.meter(this, registryName, "errors",
getCategory().toString(), scope);
+numTimeouts = manager.meter(this, registryName, "timeouts",
getCategory().toString(), scope);
--- End diff --
No plugins currently log timeouts. I think it should perhaps be removed and
instead re-introduced if we see that some auth plugins with external network
depenedencies feel the need for logging number of (external) timeouts.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222761151
--- Diff:
solr/core/src/java/org/apache/solr/security/AuthenticationPlugin.java ---
@@ -52,11 +80,73 @@
public abstract boolean doAuthenticate(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws Exception;
+ /**
+ * This method is called by SolrDispatchFilter in order to initiate
authentication.
+ * It does some standard metrics counting.
+ */
+ public final boolean authenticate(ServletRequest request,
ServletResponse response, FilterChain filterChain) throws Exception {
+Timer.Context timer = requestTimes.time();
+requests.inc();
+try {
+ return doAuthenticate(request, response, filterChain);
+} catch(Exception e) {
+ numErrors.mark();
+ throw e;
+} finally {
+ long elapsed = timer.stop();
+ totalTime.inc(elapsed);
+}
+ }
/**
* Cleanup any per request data
*/
public void closeRequest() {
}
+ @Override
+ public void initializeMetrics(SolrMetricManager manager, String
registryName, String tag, final String scope) {
+this.metricManager = manager;
+this.registryName = registryName;
+// Metrics
+registry = manager.registry(registryName);
+numErrors = manager.meter(this, registryName, "errors",
getCategory().toString(), scope);
+numTimeouts = manager.meter(this, registryName, "timeouts",
getCategory().toString(), scope);
+requests = manager.counter(this, registryName, "requests",
getCategory().toString(), scope);
+numAuthenticated = manager.counter(this, registryName,
"authenticated", getCategory().toString(), scope);
+numPassThrough = manager.counter(this, registryName, "passThrough",
getCategory().toString(), scope);
+numWrongCredentials = manager.counter(this, registryName,
"failWrongCredentials", getCategory().toString(), scope);
--- End diff --
If auth does not succeed we log either wrong credentials, invalid
credentials (e.g. malformed, if basicAuth header does not contain a ':'),
missing credentials (if no header at all). Not all plugins will be able to
distinguish between all these, such as hadoop plugin which I raised a question
about in the JIRA. Should we have a more coarse-grained metric on this? Perhaps
these are enough: `numAuthenticated`, `numPassThrough`, `numFailedAuth` and
`numErrors`?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222761691
--- Diff:
solr/core/src/java/org/apache/solr/security/AuthenticationPlugin.java ---
@@ -52,11 +80,73 @@
public abstract boolean doAuthenticate(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws Exception;
+ /**
+ * This method is called by SolrDispatchFilter in order to initiate
authentication.
+ * It does some standard metrics counting.
+ */
+ public final boolean authenticate(ServletRequest request,
ServletResponse response, FilterChain filterChain) throws Exception {
+Timer.Context timer = requestTimes.time();
+requests.inc();
+try {
+ return doAuthenticate(request, response, filterChain);
+} catch(Exception e) {
+ numErrors.mark();
+ throw e;
+} finally {
+ long elapsed = timer.stop();
+ totalTime.inc(elapsed);
+}
+ }
/**
* Cleanup any per request data
*/
public void closeRequest() {
}
+ @Override
+ public void initializeMetrics(SolrMetricManager manager, String
registryName, String tag, final String scope) {
+this.metricManager = manager;
+this.registryName = registryName;
+// Metrics
+registry = manager.registry(registryName);
+numErrors = manager.meter(this, registryName, "errors",
getCategory().toString(), scope);
+numTimeouts = manager.meter(this, registryName, "timeouts",
getCategory().toString(), scope);
+requests = manager.counter(this, registryName, "requests",
getCategory().toString(), scope);
+numAuthenticated = manager.counter(this, registryName,
"authenticated", getCategory().toString(), scope);
+numPassThrough = manager.counter(this, registryName, "passThrough",
getCategory().toString(), scope);
+numWrongCredentials = manager.counter(this, registryName,
"failWrongCredentials", getCategory().toString(), scope);
+numInvalidCredentials = manager.counter(this, registryName,
"failInvalidCredentials", getCategory().toString(), scope);
+numMissingCredentials = manager.counter(this, registryName,
"failMissingCredentials", getCategory().toString(), scope);
+requestTimes = manager.timer(this, registryName, "requestTimes",
getCategory().toString(), scope);
+totalTime = manager.counter(this, registryName, "totalTime",
getCategory().toString(), scope);
+metricNames.addAll(Arrays.asList("errors", "timeouts", "requests",
"authenticated", "passThrough",
+"failWrongCredentials", "failMissingCredentials",
"failInvalidCredentials", "requestTimes", "totalTime"));
+ }
+
+ @Override
+ public String getName() {
+return this.getClass().getName();
+ }
+
+ @Override
+ public String getDescription() {
+return this.getClass().getName();
--- End diff --
I did not want to extend the API surface of the Auth plugins to require a
description, Any suggestions of how to obtain better description from somewhere
else?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222759422
--- Diff:
solr/core/src/java/org/apache/solr/security/AuthenticationPlugin.java ---
@@ -52,11 +80,73 @@
public abstract boolean doAuthenticate(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws Exception;
+ /**
+ * This method is called by SolrDispatchFilter in order to initiate
authentication.
+ * It does some standard metrics counting.
+ */
+ public final boolean authenticate(ServletRequest request,
ServletResponse response, FilterChain filterChain) throws Exception {
+Timer.Context timer = requestTimes.time();
+requests.inc();
+try {
+ return doAuthenticate(request, response, filterChain);
+} catch(Exception e) {
+ numErrors.mark();
+ throw e;
--- End diff --
Is this re-throw safe?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222759139
--- Diff:
solr/core/src/java/org/apache/solr/security/AuthenticationPlugin.java ---
@@ -20,16 +20,44 @@
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import java.io.Closeable;
+import java.util.Arrays;
import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+
+import com.codahale.metrics.Counter;
+import com.codahale.metrics.Meter;
+import com.codahale.metrics.MetricRegistry;
+import com.codahale.metrics.Timer;
+import org.apache.solr.core.SolrInfoBean;
+import org.apache.solr.metrics.SolrMetricManager;
+import org.apache.solr.metrics.SolrMetricProducer;
/**
*
* @lucene.experimental
*/
-public abstract class AuthenticationPlugin implements Closeable {
+public abstract class AuthenticationPlugin implements Closeable,
SolrInfoBean, SolrMetricProducer {
--- End diff --
I chose to add the `SolrMetricsProducer` on the base class instead of
letting each Auth plugin choose to implement it or not. The effect will be that
plugins that do not change their code to increment counters will be logged as 0
for these counters. But the `requests` count, `requestTimes` stats, `totalTime`
and `errors` will still be logged by the base class on behalf of all plugins
even if they don't increment the other counters.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222757598
--- Diff: solr/core/src/java/org/apache/solr/core/SolrInfoBean.java ---
@@ -34,7 +34,7 @@
* Category of Solr component.
*/
enum Category { CONTAINER, ADMIN, CORE, QUERY, UPDATE, CACHE,
HIGHLIGHTER, QUERYPARSER, SPELLCHECKER,
-SEARCHER, REPLICATION, TLOG, INDEX, DIRECTORY, HTTP, OTHER }
+SEARCHER, REPLICATION, TLOG, INDEX, DIRECTORY, HTTP, SECURITY, OTHER }
--- End diff --
I chose a new category because over time I'd like to add metrics also for
Authorization plugins and Auditlog plugins (all components registered in
security.json). An alternative could have been `CONTAINER` I guess?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 920 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/920/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([86AD5E841EA5649D:8C2EE129531E6FC7]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMixedBounds(IndexSizeTriggerTest.java:572) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 14347 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [junit4] 2> 1995949 INFO (SUITE-IndexSizeTriggerTest-seed#[86AD5E841EA5649D]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null &
[jira] [Commented] (LUCENE-8520) TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
[
https://issues.apache.org/jira/browse/LUCENE-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638563#comment-16638563
]
Lucene/Solr QA commented on LUCENE-8520:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
13s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 4m 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 4m 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 4m 8s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 48m
34s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 67m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8520 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12942372/LUCENE-8520.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 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 / a0487b0 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/100/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/100/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
> ---
>
> Key: LUCENE-8520
> URL: https://issues.apache.org/jira/browse/LUCENE-8520
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8520.patch
>
>
> From my Jenkins
> [http://jenkins.sarowe.net/job/Lucene-core-weekly-monster-master-HDD/365/],
> reproduces for me locally:
> {noformat}
> Checking out Revision 964cc88cee7d62edf03a923e3217809d630af5d5
> (refs/remotes/origin/master)
> [...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterMaxDocs
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestIndexWriterMaxDocs -Dtests.method=testExactlyAtTrueLimit
> -Dtests.seed=4544F11B4D9BB14C -Dtests.nightly=true -Dtests.slow=true
> -Dtests.monster=true -Dtests.locale=ko-KR -Dtests.timezone=Atlantic/Jan_Mayen
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 1597s J0 | TestIndexWriterMaxDocs.testExactlyAtTrueLimit
> <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> expected:<2147483519> but was:<2165>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([4544F11B4D9BB14C:AAE52DEAF347C094]:0)
>[junit4]> at
> org.apache.lucene.index.TestIndexWriterMaxDocs.testExactlyAtTrueLimit(TestIndexWriterMaxDocs.java:71)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-master-HDD/lucene/build/core/test/J0/temp/lucene.index.TestIndexWriterMaxDocs_4544F11B4D9BB14C-001
>[junit4] 2> Sep 30, 2018 6:47:23 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> WARNING: Will linger awaiting termination of 1 leaked
> thread(s).
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> SEVERE: 1 thread leaked from SUITE scope at
>
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 22973 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22973/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 51261 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj1381534293
[ecj-lint] Compiling 521 source files to /tmp/ecj1381534293
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 14. WARNING in
[jira] [Commented] (SOLR-12814) Metrics history causing "HttpParser URI is too large >8192" when many collections
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638497#comment-16638497
]
ASF subversion and git services commented on SOLR-12814:
Commit 46a530a04e8ac31265d3bbb2bde264360373c5aa in lucene-solr's branch
refs/heads/branch_7x from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=46a530a ]
SOLR-12814: Metrics history causing "HttpParser URI is too large >8192" when
many collections
This fixes #461
(cherry picked from commit 5fb384c9898176d34fffe2b310a0a815d8aebecb)
> Metrics history causing "HttpParser URI is too large >8192" when many
> collections
> -
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Assignee: Jan Høydahl
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Fix For: 7.5.1, 7.6, master (8.0)
>
> Attachments: longmetricsquery.txt, screencapture-cloud-graph.png,
> screencapture-nodes-actual-IP.png, screenshot-debug.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12814) Metrics history causing "HttpParser URI is too large >8192" when many collections
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638500#comment-16638500
]
ASF subversion and git services commented on SOLR-12814:
Commit 2f8cae6c285fc8a756a48a3dc5999775659ce4ae in lucene-solr's branch
refs/heads/branch_7_5 from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2f8cae6 ]
SOLR-12814: Metrics history causing "HttpParser URI is too large >8192" when
many collections
This fixes #461
(cherry picked from commit 5fb384c9898176d34fffe2b310a0a815d8aebecb)
> Metrics history causing "HttpParser URI is too large >8192" when many
> collections
> -
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Assignee: Jan Høydahl
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Fix For: 7.5.1, 7.6, master (8.0)
>
> Attachments: longmetricsquery.txt, screencapture-cloud-graph.png,
> screencapture-nodes-actual-IP.png, screenshot-debug.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause
[ https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638504#comment-16638504 ] Jim Ferenczi commented on LUCENE-8479: -- Thanks [~janhoy] for fixing and sorry for the noise > QueryBuilder#analyzeGraphPhrase should respect max boolean clause > - > > Key: LUCENE-8479 > URL: https://issues.apache.org/jira/browse/LUCENE-8479 > Project: Lucene - Core > Issue Type: Test >Reporter: Jim Ferenczi >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: LUCENE-8479.patch, LUCENE-8479.patch > > > Currently there is no limit in the number of span queries that can be mixed > by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands > of paths. We should apply the same limit than analyzeGraphBoolean which > throws TooManyClauses exception when the number of expanded paths is greater > than BooleanQuery#MAX_CLAUSE_COUNT. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12814) Metrics history causing "HttpParser URI is too large >8192" when many collections
[
https://issues.apache.org/jira/browse/SOLR-12814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638494#comment-16638494
]
ASF subversion and git services commented on SOLR-12814:
Commit 5fb384c9898176d34fffe2b310a0a815d8aebecb in lucene-solr's branch
refs/heads/master from [~janhoy]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5fb384c ]
SOLR-12814: Metrics history causing "HttpParser URI is too large >8192" when
many collections
This fixes #461
> Metrics history causing "HttpParser URI is too large >8192" when many
> collections
> -
>
> Key: SOLR-12814
> URL: https://issues.apache.org/jira/browse/SOLR-12814
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics, SolrCloud
>Affects Versions: 7.5
> Environment: 3x zookeeper and 3x solr cloud servers,
> 50 test collections with 0 data in them
>Reporter: matthew medway
>Assignee: Jan Høydahl
>Priority: Major
> Labels: URI, header, http, httpparser, large, metrics, solr,
> solrcloud, too, uri
> Fix For: 7.5.1, 7.6, master (8.0)
>
> Attachments: longmetricsquery.txt, screencapture-cloud-graph.png,
> screencapture-nodes-actual-IP.png, screenshot-debug.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you have a lot of collections, like 50 or more, the new metrics page in
> version 7.5 can't run its queries because the default
> solr.jetty.request.header.size and solr.jetty.response.header.size values are
> too small.
> If I up the header values from 8192 to 65536 the commands will work.
> command to change the defaults:
> {code:java}
> sed -i 's/\"solr.jetty.request.header.size\"
> default=\"8192\"/\"solr.jetty.request.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> sed -i 's/\"solr.jetty.response.header.size\"
> default=\"8192\"/\"solr.jetty.response.header.size\" default=\"65536\"/g'
> /opt/solr/server/etc/jetty.xml
> {code}
> before changing the header size log:
> {code:java}
> 2018-09-27 13:06:45.434 INFO (qtp534906248-14) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:07:45.527 WARN (qtp534906248-17) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:07:45.530 INFO (qtp534906248-16) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:08:45.621 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> 2018-09-27 13:08:45.625 INFO (qtp534906248-15) [ ] o.a.s.s.HttpSolrCall
> [admin] webapp=null path=/admin/metrics
> params={wt=javabin=2=solr.jvm:os.processCpuLoad=solr.node:CONTAINER.fs.coreRoot.usableSpace=solr.jvm:os.systemLoadAverage=solr.jvm:memory.heap.used}
> status=0 QTime=0
> 2018-09-27 13:09:45.725 WARN (qtp534906248-20) [ ] o.e.j.h.HttpParser URI is
> too large >8192
> {code}
> After changing the header size log:
> {code:java}
> attached as a file because its very long and ugly{code}
> Is it possible to break up this command into batches so that it can run
> without modifying the header sizes?
> Thanks!
> -Matt
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8523) Fix typo for JapaneseNumberFilterFactory usage
[ https://issues.apache.org/jira/browse/LUCENE-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638488#comment-16638488 ] ankush jhalani commented on LUCENE-8523: Submitted [https://github.com/apache/lucene-solr/pull/462] for fix. > Fix typo for JapaneseNumberFilterFactory usage > -- > > Key: LUCENE-8523 > URL: https://issues.apache.org/jira/browse/LUCENE-8523 > Project: Lucene - Core > Issue Type: Bug >Reporter: ankush jhalani >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Javadocs for JapaneseNumberFilterFactory have a typo - > [https://lucene.apache.org/core/7_5_0/analyzers-kuromoji/org/apache/lucene/analysis/ja/JapaneseNumberFilterFactory.html] > Instead of > > We should have > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 844 - Still Failing!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/844/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 51205 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /var/tmp/ecj1892002493
[ecj-lint] Compiling 494 source files to /var/tmp/ecj1892002493
[ecj-lint] --
[ecj-lint] 1. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[GitHub] lucene-solr pull request #462: LUCENE-8523: Fix typo for JapaneseNumberFilte...
GitHub user ajhalani opened a pull request: https://github.com/apache/lucene-solr/pull/462 LUCENE-8523: Fix typo for JapaneseNumberFilterFactory usage You can merge this pull request into a Git repository by running: $ git pull https://github.com/ajhalani/lucene-solr LUCENE-8523 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/462.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #462 commit 1f6a7eb88036a9e0ffed90de5d5bf816dbe0d486 Author: ajhalani Date: 2018-10-04T16:33:52Z LUCENE-8523: Fix typo for JapaneseNumberFilterFactory usage --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8523) Fix typo for JapaneseNumberFilterFactory usage
ankush jhalani created LUCENE-8523: -- Summary: Fix typo for JapaneseNumberFilterFactory usage Key: LUCENE-8523 URL: https://issues.apache.org/jira/browse/LUCENE-8523 Project: Lucene - Core Issue Type: Bug Reporter: ankush jhalani Javadocs for JapaneseNumberFilterFactory have a typo - [https://lucene.apache.org/core/7_5_0/analyzers-kuromoji/org/apache/lucene/analysis/ja/JapaneseNumberFilterFactory.html] Instead of We should have -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8522) Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
[
https://issues.apache.org/jira/browse/LUCENE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638472#comment-16638472
]
Ignacio Vera commented on LUCENE-8522:
--
Thanks [~kwri...@metacarta.com], I will dig into this.
> Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
>
>
> Key: LUCENE-8522
> URL: https://issues.apache.org/jira/browse/LUCENE-8522
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: 7.4, 7.5
>Reporter: Ema Panz
>Assignee: Ignacio Vera
>Priority: Critical
>
> When using the WGS84 coordinates system and querying with a polygon touching
> one of the "negative" borders, Solr throws a "NullPointerException" error.
> The query is performed with the "intersect" function over a GeoJson polygon
> specified with the coordinates:
> { "coordinates":[[[-180,90],[-180,-90],[180,-90],[180,90],[-180,90]]] }
>
> The queried field has been defined as:
> {code:java}
> class="solr.SpatialRecursivePrefixTreeFieldType"
>spatialContextFactory="Geo3D"
>geo="true"
>planetModel="WGS84"
>format="GeoJSON"
> />{code}
>
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.lucene.spatial.spatial4j.Geo3dShape.getBoundingBox(Geo3dShape.java:114)
> at
> org.apache.lucene.spatial.query.SpatialArgs.calcDistanceFromErrPct(SpatialArgs.java:63)
> at
> org.apache.lucene.spatial.query.SpatialArgs.resolveDistErr(SpatialArgs.java:84)
> at
> org.apache.lucene.spatial.prefix.RecursivePrefixTreeStrategy.makeQuery(RecursivePrefixTreeStrategy.java:182)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getQueryFromSpatialArgs(AbstractSpatialFieldType.java:368)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getFieldQuery(AbstractSpatialFieldType.java:340)
> at
> org.apache.solr.search.FieldQParserPlugin$1.parse(FieldQParserPlugin.java:45)
> at org.apache.solr.search.QParser.getQuery(QParser.java:169)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
> at
[jira] [Commented] (LUCENE-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause
[ https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638467#comment-16638467 ] ASF subversion and git services commented on LUCENE-8479: - Commit 5c4566b737b4ef0bf8683ede9ddfd68daddba0a0 in lucene-solr's branch refs/heads/branch_7x from [~janhoy] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c4566b ] LUCENE-8479: Fix precommit (cherry picked from commit 36c60251f2d99e173c7ca99d423b3d18156cad82) > QueryBuilder#analyzeGraphPhrase should respect max boolean clause > - > > Key: LUCENE-8479 > URL: https://issues.apache.org/jira/browse/LUCENE-8479 > Project: Lucene - Core > Issue Type: Test >Reporter: Jim Ferenczi >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: LUCENE-8479.patch, LUCENE-8479.patch > > > Currently there is no limit in the number of span queries that can be mixed > by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands > of paths. We should apply the same limit than analyzeGraphBoolean which > throws TooManyClauses exception when the number of expanded paths is greater > than BooleanQuery#MAX_CLAUSE_COUNT. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-8522) Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
[
https://issues.apache.org/jira/browse/LUCENE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera reassigned LUCENE-8522:
Assignee: Ignacio Vera
> Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
>
>
> Key: LUCENE-8522
> URL: https://issues.apache.org/jira/browse/LUCENE-8522
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: 7.4, 7.5
>Reporter: Ema Panz
>Assignee: Ignacio Vera
>Priority: Critical
>
> When using the WGS84 coordinates system and querying with a polygon touching
> one of the "negative" borders, Solr throws a "NullPointerException" error.
> The query is performed with the "intersect" function over a GeoJson polygon
> specified with the coordinates:
> { "coordinates":[[[-180,90],[-180,-90],[180,-90],[180,90],[-180,90]]] }
>
> The queried field has been defined as:
> {code:java}
> class="solr.SpatialRecursivePrefixTreeFieldType"
>spatialContextFactory="Geo3D"
>geo="true"
>planetModel="WGS84"
>format="GeoJSON"
> />{code}
>
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.lucene.spatial.spatial4j.Geo3dShape.getBoundingBox(Geo3dShape.java:114)
> at
> org.apache.lucene.spatial.query.SpatialArgs.calcDistanceFromErrPct(SpatialArgs.java:63)
> at
> org.apache.lucene.spatial.query.SpatialArgs.resolveDistErr(SpatialArgs.java:84)
> at
> org.apache.lucene.spatial.prefix.RecursivePrefixTreeStrategy.makeQuery(RecursivePrefixTreeStrategy.java:182)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getQueryFromSpatialArgs(AbstractSpatialFieldType.java:368)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getFieldQuery(AbstractSpatialFieldType.java:340)
> at
> org.apache.solr.search.FieldQParserPlugin$1.parse(FieldQParserPlugin.java:45)
> at org.apache.solr.search.QParser.getQuery(QParser.java:169)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> at
[jira] [Commented] (LUCENE-8522) Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
[
https://issues.apache.org/jira/browse/LUCENE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638458#comment-16638458
]
Karl Wright commented on LUCENE-8522:
-
[~ivera], I think this is your code?
> Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
>
>
> Key: LUCENE-8522
> URL: https://issues.apache.org/jira/browse/LUCENE-8522
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: 7.4, 7.5
>Reporter: Ema Panz
>Priority: Critical
>
> When using the WGS84 coordinates system and querying with a polygon touching
> one of the "negative" borders, Solr throws a "NullPointerException" error.
> The query is performed with the "intersect" function over a GeoJson polygon
> specified with the coordinates:
> { "coordinates":[[[-180,90],[-180,-90],[180,-90],[180,90],[-180,90]]] }
>
> The queried field has been defined as:
> {code:java}
> class="solr.SpatialRecursivePrefixTreeFieldType"
>spatialContextFactory="Geo3D"
>geo="true"
>planetModel="WGS84"
>format="GeoJSON"
> />{code}
>
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.lucene.spatial.spatial4j.Geo3dShape.getBoundingBox(Geo3dShape.java:114)
> at
> org.apache.lucene.spatial.query.SpatialArgs.calcDistanceFromErrPct(SpatialArgs.java:63)
> at
> org.apache.lucene.spatial.query.SpatialArgs.resolveDistErr(SpatialArgs.java:84)
> at
> org.apache.lucene.spatial.prefix.RecursivePrefixTreeStrategy.makeQuery(RecursivePrefixTreeStrategy.java:182)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getQueryFromSpatialArgs(AbstractSpatialFieldType.java:368)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getFieldQuery(AbstractSpatialFieldType.java:340)
> at
> org.apache.solr.search.FieldQParserPlugin$1.parse(FieldQParserPlugin.java:45)
> at org.apache.solr.search.QParser.getQuery(QParser.java:169)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> at
[jira] [Updated] (LUCENE-8522) Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
[
https://issues.apache.org/jira/browse/LUCENE-8522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ema Panz updated LUCENE-8522:
-
Summary: Spatial: Polygon touching the negative boundaries of WGS84 fails
on Solr (was: Spatial: Polygon youching the negative boundaries fails on Solr)
> Spatial: Polygon touching the negative boundaries of WGS84 fails on Solr
>
>
> Key: LUCENE-8522
> URL: https://issues.apache.org/jira/browse/LUCENE-8522
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Affects Versions: 7.4, 7.5
>Reporter: Ema Panz
>Priority: Critical
>
> When using the WGS84 coordinates system and querying with a polygon touching
> one of the "negative" borders, Solr throws a "NullPointerException" error.
> The query is performed with the "intersect" function over a GeoJson polygon
> specified with the coordinates:
> { "coordinates":[[[-180,90],[-180,-90],[180,-90],[180,90],[-180,90]]] }
>
> The queried field has been defined as:
> {code:java}
> class="solr.SpatialRecursivePrefixTreeFieldType"
>spatialContextFactory="Geo3D"
>geo="true"
>planetModel="WGS84"
>format="GeoJSON"
> />{code}
>
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.lucene.spatial.spatial4j.Geo3dShape.getBoundingBox(Geo3dShape.java:114)
> at
> org.apache.lucene.spatial.query.SpatialArgs.calcDistanceFromErrPct(SpatialArgs.java:63)
> at
> org.apache.lucene.spatial.query.SpatialArgs.resolveDistErr(SpatialArgs.java:84)
> at
> org.apache.lucene.spatial.prefix.RecursivePrefixTreeStrategy.makeQuery(RecursivePrefixTreeStrategy.java:182)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getQueryFromSpatialArgs(AbstractSpatialFieldType.java:368)
> at
> org.apache.solr.schema.AbstractSpatialFieldType.getFieldQuery(AbstractSpatialFieldType.java:340)
> at
> org.apache.solr.search.FieldQParserPlugin$1.parse(FieldQParserPlugin.java:45)
> at org.apache.solr.search.QParser.getQuery(QParser.java:169)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> at org.eclipse.jetty.server.Server.handle(Server.java:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
> at
[jira] [Created] (LUCENE-8522) Spatial: Polygon youching the negative boundaries fails on Solr
Ema Panz created LUCENE-8522:
Summary: Spatial: Polygon youching the negative boundaries fails
on Solr
Key: LUCENE-8522
URL: https://issues.apache.org/jira/browse/LUCENE-8522
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial3d
Affects Versions: 7.5, 7.4
Reporter: Ema Panz
When using the WGS84 coordinates system and querying with a polygon touching
one of the "negative" borders, Solr throws a "NullPointerException" error.
The query is performed with the "intersect" function over a GeoJson polygon
specified with the coordinates:
{ "coordinates":[[[-180,90],[-180,-90],[180,-90],[180,90],[-180,90]]] }
The queried field has been defined as:
{code:java}
{code}
{code:java}
java.lang.NullPointerException
at
org.apache.lucene.spatial.spatial4j.Geo3dShape.getBoundingBox(Geo3dShape.java:114)
at
org.apache.lucene.spatial.query.SpatialArgs.calcDistanceFromErrPct(SpatialArgs.java:63)
at
org.apache.lucene.spatial.query.SpatialArgs.resolveDistErr(SpatialArgs.java:84)
at
org.apache.lucene.spatial.prefix.RecursivePrefixTreeStrategy.makeQuery(RecursivePrefixTreeStrategy.java:182)
at
org.apache.solr.schema.AbstractSpatialFieldType.getQueryFromSpatialArgs(AbstractSpatialFieldType.java:368)
at
org.apache.solr.schema.AbstractSpatialFieldType.getFieldQuery(AbstractSpatialFieldType.java:340)
at
org.apache.solr.search.FieldQParserPlugin$1.parse(FieldQParserPlugin.java:45)
at org.apache.solr.search.QParser.getQuery(QParser.java:169)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:207)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:272)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:531)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:760)
at
[jira] [Commented] (SOLR-12584) Add basic auth credentials configuration to the Solr exporter for Prometheus/Grafana
[
https://issues.apache.org/jira/browse/SOLR-12584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638420#comment-16638420
]
Jan Høydahl commented on SOLR-12584:
Thanks for contributing. I just skimmed the patch, and a few piece of advice to
start with
* Please read
[https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file]
* In particular, name the file SOLR-12584.patch and avoid unrelated whitespace
changes
* I also see some unnecessary comments, some new lines that are commented out
etc. Please clean up, the patch should then be much smaller
Also, see my comment from August where I propose that
{quote}It should probably support the same env vars and password file as
bin/solr script does, so that users could configure the Exporter in the same
way they do with Solr itself."
{quote}
What I mean by that is that we should re-use the same way of configuring the
exporter as we already to for configuring Solr itself and e.g. the {{bin/solr}}
script, which is by setting two env.variables. See copy-paste from solr.in.sh:
{noformat}
# Settings for authentication
# Please configure only one of SOLR_AUTHENTICATION_CLIENT_BUILDER or
SOLR_AUTH_TYPE parameters
#SOLR_AUTHENTICATION_CLIENT_BUILDER="org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory"
#SOLR_AUTH_TYPE="basic"
#SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:SolrRocks"
{noformat}
This will also allow for type 'kerberos' and future auth types that may be
invented later.
> Add basic auth credentials configuration to the Solr exporter for
> Prometheus/Grafana
> --
>
> Key: SOLR-12584
> URL: https://issues.apache.org/jira/browse/SOLR-12584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, metrics, security
>Affects Versions: 7.3, 7.4
>Reporter: Dwane Hall
>Priority: Minor
> Labels: authentication, metrics, security
> Attachments: lucene-solr.patch
>
>
> The Solr exporter for Prometheus/Grafana provides a useful visual layer over
> the solr metrics api for monitoring the state of a Solr cluster. Currently
> this can not be configured and used on a secure Solr cluster with the Basic
> Authentication plugin enabled. The exporter does not provide a mechanism to
> configure/pass through basic auth credentials when SolrJ requests information
> from the metrics api endpoints and would be a useful addition for Solr users
> running a secure Solr instance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-11) - Build # 2857 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2857/ Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 16 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Could not find collection:collection1 Stack Trace: java.lang.AssertionError: Could not find collection:collection1 at __randomizedtesting.SeedInfo.seed([319EFF26648E0B91]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.TestCloudRecovery.setupCluster(TestCloudRecovery.java:70) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Could not find collection:collection1 Stack Trace: java.lang.AssertionError: Could not find collection:collection1 at __randomizedtesting.SeedInfo.seed([319EFF26648E0B91]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155) at org.apache.solr.cloud.TestCloudRecovery.setupCluster(TestCloudRecovery.java:70) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at
[jira] [Commented] (LUCENE-3922) Add Japanese Kanji number normalization to Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638360#comment-16638360 ] ankush jhalani commented on LUCENE-3922: I noticed the changes are available in master/branch_7x ([Test]JapaneseNumberFilter[Factory].java) Should we mark this closed? > Add Japanese Kanji number normalization to Kuromoji > --- > > Key: LUCENE-3922 > URL: https://issues.apache.org/jira/browse/LUCENE-3922 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.0-ALPHA >Reporter: Kazuaki Hiraga >Assignee: Christian Moen >Priority: Major > Labels: features > Attachments: LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, > LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, > LUCENE-3922.patch > > > Japanese people use Kanji numerals instead of Arabic numerals for writing > price, address and so on. i.e 12万4800円(124,800JPY), 二番町三ノ二(3-2 Nibancho) and > 十二月(December). So, we would like to normalize those Kanji numerals to Arabic > numerals (I don't think we need to have a capability to normalize to Kanji > numerals). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12584) Add basic auth credentials configuration to the Solr exporter for Prometheus/Grafana
[ https://issues.apache.org/jira/browse/SOLR-12584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] CDatta updated SOLR-12584: -- Attachment: lucene-solr.patch > Add basic auth credentials configuration to the Solr exporter for > Prometheus/Grafana > -- > > Key: SOLR-12584 > URL: https://issues.apache.org/jira/browse/SOLR-12584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication, metrics, security >Affects Versions: 7.3, 7.4 >Reporter: Dwane Hall >Priority: Minor > Labels: authentication, metrics, security > Attachments: lucene-solr.patch > > > The Solr exporter for Prometheus/Grafana provides a useful visual layer over > the solr metrics api for monitoring the state of a Solr cluster. Currently > this can not be configured and used on a secure Solr cluster with the Basic > Authentication plugin enabled. The exporter does not provide a mechanism to > configure/pass through basic auth credentials when SolrJ requests information > from the metrics api endpoints and would be a useful addition for Solr users > running a secure Solr instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12584) Add basic auth credentials configuration to the Solr exporter for Prometheus/Grafana
[ https://issues.apache.org/jira/browse/SOLR-12584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638361#comment-16638361 ] CDatta commented on SOLR-12584: --- Sorry for the delay. Please find attached below the patch. [^lucene-solr.patch] Please let me know. > Add basic auth credentials configuration to the Solr exporter for > Prometheus/Grafana > -- > > Key: SOLR-12584 > URL: https://issues.apache.org/jira/browse/SOLR-12584 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Authentication, metrics, security >Affects Versions: 7.3, 7.4 >Reporter: Dwane Hall >Priority: Minor > Labels: authentication, metrics, security > Attachments: lucene-solr.patch > > > The Solr exporter for Prometheus/Grafana provides a useful visual layer over > the solr metrics api for monitoring the state of a Solr cluster. Currently > this can not be configured and used on a secure Solr cluster with the Basic > Authentication plugin enabled. The exporter does not provide a mechanism to > configure/pass through basic auth credentials when SolrJ requests information > from the metrics api endpoints and would be a useful addition for Solr users > running a secure Solr instance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2091 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2091/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 51133 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /var/tmp/ecj911721550
[ecj-lint] Compiling 521 source files to /var/tmp/ecj911721550
[ecj-lint] --
[ecj-lint] 1. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint]
[jira] [Commented] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638330#comment-16638330 ] ASF subversion and git services commented on SOLR-12811: Commit 66b01fcff961d47d853f890c10556fc56748f7d6 in lucene-solr's branch refs/heads/branch_7x from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=66b01fc ] SOLR-12811: Add enclosingDisk and associated geometric Stream Evaluators > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-12811.patch > > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDIsk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638320#comment-16638320 ] ASF subversion and git services commented on SOLR-12811: Commit a0487b04ea0b676e3732e49de1ca0e38a91aab3c in lucene-solr's branch refs/heads/master from [~joel.bernstein] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a0487b0 ] SOLR-12811: Add enclosingDisk and associated geometric Stream Evaluators > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-12811.patch > > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDIsk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2845 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2845/ 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([2E981FB0B2B0EEF7:1716A6F09D4F2709]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:316) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventFromRestoredState Error Message: The trigger did not fire at all Stack Trace: java.lang.AssertionError: The trigger did not fire at all at __randomizedtesting.SeedInfo.seed([2E981FB0B2B0EEF7:2EAEAB709BBD4A9D]:0) at
[jira] [Updated] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-12811: -- Attachment: SOLR-12811.patch > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-12811.patch > > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDIsk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638243#comment-16638243 ] Joel Bernstein commented on SOLR-12811: --- Initial implementation with tests > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Attachments: SOLR-12811.patch > > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDIsk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-12811: -- Description: This ticket will add the *enclosingDisk*, *getRadius, getCenter* and *getSupportPoints* Stream Evaluators. The enclosingDIsk function will calculate the smallest circle that encloses a 2D data set. The implementation is provided by *Apache Commons Math.* (was: This ticket will add the *enclosingDisk*, *radius* and *center* Stream Evaluators. The enclosingDIsk function will calculate the smallest circle that encloses a 2D data set. The implementation is provided by Apache Commons Math) > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > This ticket will add the *enclosingDisk*, *getRadius, getCenter* and > *getSupportPoints* Stream Evaluators. The enclosingDIsk function will > calculate the smallest circle that encloses a 2D data set. The implementation > is provided by *Apache Commons Math.* -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12811) Add enclosingDisk and associated geometric Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-12811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-12811: -- Summary: Add enclosingDisk and associated geometric Stream Evaluators (was: Add enclosingDisk, radius and center Stream Evaluators) > Add enclosingDisk and associated geometric Stream Evaluators > > > Key: SOLR-12811 > URL: https://issues.apache.org/jira/browse/SOLR-12811 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > > This ticket will add the *enclosingDisk*, *radius* and *center* Stream > Evaluators. The enclosingDIsk function will calculate the smallest circle > that encloses a 2D data set. The implementation is provided by Apache Commons > Math -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+12) - Build # 22972 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22972/ Java: 64bit/jdk-12-ea+12 -XX:+UseCompressedOops -XX:+UseSerialGC 47 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestRandomFlRTGCloud Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([1364D9B33F5BABF2]:0) at org.apache.solr.cloud.TestRandomFlRTGCloud.createMiniSolrCloudCluster(TestRandomFlRTGCloud.java:149) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:875) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:835) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestRandomFlRTGCloud Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([1364D9B33F5BABF2]:0) at org.apache.solr.cloud.TestRandomFlRTGCloud.afterClass(TestRandomFlRTGCloud.java:156) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at
[jira] [Comment Edited] (LUCENE-8520) TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
[
https://issues.apache.org/jira/browse/LUCENE-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638070#comment-16638070
]
Ignacio Vera edited comment on LUCENE-8520 at 10/4/18 1:08 PM:
---
I have a look into this error and it looks like the test is incorrect now as we
do not count total hits by default.
Attached is a patch that performs the query so that all hits are computed.
was (Author: ivera):
I have a look into this error and it looks like the test is incorrect now as we
do not count total hots by default.
Attached is a patch that performs the query so that all hits are computed.
> TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
> ---
>
> Key: LUCENE-8520
> URL: https://issues.apache.org/jira/browse/LUCENE-8520
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8520.patch
>
>
> From my Jenkins
> [http://jenkins.sarowe.net/job/Lucene-core-weekly-monster-master-HDD/365/],
> reproduces for me locally:
> {noformat}
> Checking out Revision 964cc88cee7d62edf03a923e3217809d630af5d5
> (refs/remotes/origin/master)
> [...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterMaxDocs
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestIndexWriterMaxDocs -Dtests.method=testExactlyAtTrueLimit
> -Dtests.seed=4544F11B4D9BB14C -Dtests.nightly=true -Dtests.slow=true
> -Dtests.monster=true -Dtests.locale=ko-KR -Dtests.timezone=Atlantic/Jan_Mayen
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 1597s J0 | TestIndexWriterMaxDocs.testExactlyAtTrueLimit
> <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> expected:<2147483519> but was:<2165>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([4544F11B4D9BB14C:AAE52DEAF347C094]:0)
>[junit4]> at
> org.apache.lucene.index.TestIndexWriterMaxDocs.testExactlyAtTrueLimit(TestIndexWriterMaxDocs.java:71)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-master-HDD/lucene/build/core/test/J0/temp/lucene.index.TestIndexWriterMaxDocs_4544F11B4D9BB14C-001
>[junit4] 2> Sep 30, 2018 6:47:23 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> WARNING: Will linger awaiting termination of 1 leaked
> thread(s).
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> SEVERE: 1 thread leaked from SUITE scope at
> org.apache.lucene.index.TestIndexWriterMaxDocs:
>[junit4] 2>1) Thread[id=2505, name=Lucene Merge Thread #13,
> state=RUNNABLE, group=TGRP-TestIndexWriterMaxDocs]
>[junit4] 2> at
> org.apache.lucene.codecs.PushPostingsWriterBase.writeTerm(PushPostingsWriterBase.java:148)
>[junit4] 2> at
> org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter$TermsWriter.write(BlockTreeTermsWriter.java:865)
>[junit4] 2> at
> org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.write(BlockTreeTermsWriter.java:344)
>[junit4] 2> at
> org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:105)
>[junit4] 2> at
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsWriter.merge(PerFieldPostingsFormat.java:165)
>[junit4] 2> at
> org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:244)
>[junit4] 2> at
> org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:139)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4453)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4075)
>[junit4] 2> at
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:625)
>[junit4] 2> at
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:662)
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl tryToInterruptAll
>[junit4] 2> INFO: Starting to interrupt leaked threads:
>[junit4] 2>1) Thread[id=2505, name=Lucene Merge Thread #13,
> state=RUNNABLE, group=TGRP-TestIndexWriterMaxDocs]
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl tryToInterruptAll
>[junit4] 2> INFO: All leaked threads terminated.
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@72a4d8a0),
> locale=ko-KR, timezone=Atlantic/Jan_Mayen
>[junit4] 2>
[JENKINS] Lucene-Solr-Tests-7.x - Build # 919 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/919/
All tests passed
Build Log:
[...truncated 51276 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: /tmp/ecj410814933
[ecj-lint] Compiling 494 source files to /tmp/ecj410814933
[ecj-lint] --
[ecj-lint] 1. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 44)
[ecj-lint] new TestTokenStream1();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 2. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 45)
[ecj-lint] new TestTokenStream2();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/TestAssertions.java
(at line 47)
[ecj-lint] new TestTokenStream3();
[ecj-lint] ^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/TestMergeSchedulerExternal.java
(at line 130)
[ecj-lint] IndexWriter writer = new IndexWriter(dir, iwc);
[ecj-lint] ^^
[ecj-lint] Resource leak: 'writer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 120)
[ecj-lint] Analyzer analyzer = new MockAnalyzer(random());
[ecj-lint]
[ecj-lint] Resource leak: 'analyzer' is never closed
[ecj-lint] --
[ecj-lint] 6. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCachingTokenFilter.java
(at line 122)
[ecj-lint] CachingTokenFilter buffer = new CachingTokenFilter(input);
[ecj-lint]^^
[ecj-lint] Resource leak: 'buffer' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 29)
[ecj-lint] CharFilter cs = new CharFilter1(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 8. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 34)
[ecj-lint] CharFilter cs = new CharFilter2(new StringReader(""));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 9. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 39)
[ecj-lint] CharFilter cs = new CharFilter2(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] 10. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestCharFilter.java
(at line 44)
[ecj-lint] CharFilter cs = new CharFilter1(new CharFilter1(new
StringReader("")));
[ecj-lint]^^
[ecj-lint] Resource leak: 'cs' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 11. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 39)
[ecj-lint] DelegatingAnalyzerWrapper w2 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w2' is never closed
[ecj-lint] --
[ecj-lint] 12. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 50)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] 13. WARNING in
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/core/src/test/org/apache/lucene/analysis/TestDelegatingAnalyzerWrapper.java
(at line 71)
[ecj-lint] DelegatingAnalyzerWrapper w1 = new
DelegatingAnalyzerWrapper(Analyzer.GLOBAL_REUSE_STRATEGY) {
[ecj-lint] ^^
[ecj-lint] Resource leak: 'w1' is never closed
[ecj-lint] --
[ecj-lint] --
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 867 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/867/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly Error Message: Unexpected number of elements in the group for intGSF: 6 Stack Trace: java.lang.AssertionError: Unexpected number of elements in the group for intGSF: 6 at __randomizedtesting.SeedInfo.seed([DA8B4041B7600065:41302E19FA38323B]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:381) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.core.TestDynamicLoading.testDynamicLoading Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([DA8B4041B7600065:2C66D1640BDA5C5]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43)
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222658500
--- Diff:
solr/test-framework/src/java/org/apache/solr/cloud/SolrCloudTestCase.java ---
@@ -420,4 +425,68 @@ public static void ensureRunningJettys(int nodeCount,
int timeoutSeconds) throws
cluster.waitForAllNodes(timeoutSeconds);
}
+
+ static final List AUTH_METRICS_KEYS = Arrays.asList("errors",
"timeouts", "requests", "authenticated",
--- End diff --
Yep, a separate test base class for auth tests makes sense. Good idea. We
could then push down some other utility methods from the tests as well, I see
some duplication a few places.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user janhoy commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222657709
--- Diff: solr/core/src/java/org/apache/solr/core/CoreContainer.java ---
@@ -798,6 +798,12 @@ private void reloadSecurityProperties() {
SecurityConfHandler.SecurityConfig securityConfig =
securityConfHandler.getSecurityConfig(false);
initializeAuthorizationPlugin((Map)
securityConfig.getData().get("authorization"));
initializeAuthenticationPlugin((Map)
securityConfig.getData().get("authentication"));
+if (authenticationPlugin != null &&
authenticationPlugin.plugin.getMetricRegistry() == null) {
--- End diff --
Yea, I think you're right.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12737) Let Solr init script create SOLR_PID_DIR
[
https://issues.apache.org/jira/browse/SOLR-12737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Hubold updated SOLR-12737:
--
Attachment: (was: init-script-mkdir-pid-dir.patch)
> Let Solr init script create SOLR_PID_DIR
>
>
> Key: SOLR-12737
> URL: https://issues.apache.org/jira/browse/SOLR-12737
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 6.6.5, 7.4
> Environment: CentOS 7.5
>Reporter: Andreas Hubold
>Priority: Major
> Labels: patch, patch-available
> Attachments: init-script-mkdir-pid-dir.patch
>
>
> It would be great if the Solr init script could create the configured
> SOLR_PID_DIR with permissions for the Solr user, if it doesn't exist.
> The use case is to store the PID file for the Solr service in a directory
> below the /run directory, which is typically mounted as tmpfs file system and
> empty after reboot. For example, with "{{SOLR_PID_DIR=/run/solr}}" in
> solr.in.sh, Solr will be unable to write its PID file after reboot because
> the solr subdirectory does not exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8520) TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
[
https://issues.apache.org/jira/browse/LUCENE-8520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638176#comment-16638176
]
Jim Ferenczi commented on LUCENE-8520:
--
+1, good catch [~ivera] !
> TestIndexWriterMaxDocs.testExactlyAtTrueLimit() failure
> ---
>
> Key: LUCENE-8520
> URL: https://issues.apache.org/jira/browse/LUCENE-8520
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Steve Rowe
>Priority: Major
> Attachments: LUCENE-8520.patch
>
>
> From my Jenkins
> [http://jenkins.sarowe.net/job/Lucene-core-weekly-monster-master-HDD/365/],
> reproduces for me locally:
> {noformat}
> Checking out Revision 964cc88cee7d62edf03a923e3217809d630af5d5
> (refs/remotes/origin/master)
> [...]
>[junit4] Suite: org.apache.lucene.index.TestIndexWriterMaxDocs
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=TestIndexWriterMaxDocs -Dtests.method=testExactlyAtTrueLimit
> -Dtests.seed=4544F11B4D9BB14C -Dtests.nightly=true -Dtests.slow=true
> -Dtests.monster=true -Dtests.locale=ko-KR -Dtests.timezone=Atlantic/Jan_Mayen
> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 1597s J0 | TestIndexWriterMaxDocs.testExactlyAtTrueLimit
> <<<
>[junit4]> Throwable #1: java.lang.AssertionError:
> expected:<2147483519> but was:<2165>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([4544F11B4D9BB14C:AAE52DEAF347C094]:0)
>[junit4]> at
> org.apache.lucene.index.TestIndexWriterMaxDocs.testExactlyAtTrueLimit(TestIndexWriterMaxDocs.java:71)
>[junit4]> at java.lang.Thread.run(Thread.java:748)
>[junit4] 2> NOTE: leaving temporary files on disk at:
> /slow/jenkins/HDD-workspaces/Lucene-core-weekly-monster-master-HDD/lucene/build/core/test/J0/temp/lucene.index.TestIndexWriterMaxDocs_4544F11B4D9BB14C-001
>[junit4] 2> Sep 30, 2018 6:47:23 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> WARNING: Will linger awaiting termination of 1 leaked
> thread(s).
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
>[junit4] 2> SEVERE: 1 thread leaked from SUITE scope at
> org.apache.lucene.index.TestIndexWriterMaxDocs:
>[junit4] 2>1) Thread[id=2505, name=Lucene Merge Thread #13,
> state=RUNNABLE, group=TGRP-TestIndexWriterMaxDocs]
>[junit4] 2> at
> org.apache.lucene.codecs.PushPostingsWriterBase.writeTerm(PushPostingsWriterBase.java:148)
>[junit4] 2> at
> org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter$TermsWriter.write(BlockTreeTermsWriter.java:865)
>[junit4] 2> at
> org.apache.lucene.codecs.blocktree.BlockTreeTermsWriter.write(BlockTreeTermsWriter.java:344)
>[junit4] 2> at
> org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:105)
>[junit4] 2> at
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsWriter.merge(PerFieldPostingsFormat.java:165)
>[junit4] 2> at
> org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:244)
>[junit4] 2> at
> org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:139)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4453)
>[junit4] 2> at
> org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4075)
>[junit4] 2> at
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:625)
>[junit4] 2> at
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:662)
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl tryToInterruptAll
>[junit4] 2> INFO: Starting to interrupt leaked threads:
>[junit4] 2>1) Thread[id=2505, name=Lucene Merge Thread #13,
> state=RUNNABLE, group=TGRP-TestIndexWriterMaxDocs]
>[junit4] 2> Sep 30, 2018 6:47:43 PM
> com.carrotsearch.randomizedtesting.ThreadLeakControl tryToInterruptAll
>[junit4] 2> INFO: All leaked threads terminated.
>[junit4] 2> NOTE: test params are: codec=Lucene80,
> sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@72a4d8a0),
> locale=ko-KR, timezone=Atlantic/Jan_Mayen
>[junit4] 2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation
> 1.8.0_151 (64-bit)/cpus=16,threads=1,free=616857624,total=1299185664
>[junit4] 2> NOTE: All tests run in this JVM: [TestBasicModelIn,
> TestSparseFixedBitDocIdSet, TestAutomaton, TestRegExp,
> TestReaderWrapperDVTypeCheck, TestMultiMMap,
> TestLucene50StoredFieldsFormatHighCompression, TestNoMergeScheduler,
> TestLazyProxSkipping, TestPayloads, Test4GBStoredFields,
[jira] [Updated] (SOLR-12737) Let Solr init script create SOLR_PID_DIR
[
https://issues.apache.org/jira/browse/SOLR-12737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Hubold updated SOLR-12737:
--
Attachment: init-script-mkdir-pid-dir.patch
> Let Solr init script create SOLR_PID_DIR
>
>
> Key: SOLR-12737
> URL: https://issues.apache.org/jira/browse/SOLR-12737
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 6.6.5, 7.4
> Environment: CentOS 7.5
>Reporter: Andreas Hubold
>Priority: Major
> Labels: patch, patch-available
> Attachments: init-script-mkdir-pid-dir.patch
>
>
> It would be great if the Solr init script could create the configured
> SOLR_PID_DIR with permissions for the Solr user, if it doesn't exist.
> The use case is to store the PID file for the Solr service in a directory
> below the /run directory, which is typically mounted as tmpfs file system and
> empty after reboot. For example, with "{{SOLR_PID_DIR=/run/solr}}" in
> solr.in.sh, Solr will be unable to write its PID file after reboot because
> the solr subdirectory does not exist.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8516) Make WordDelimiterGraphFilter a Tokenizer
[
https://issues.apache.org/jira/browse/LUCENE-8516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638156#comment-16638156
]
Mike Sokolov commented on LUCENE-8516:
--
{quote}Can you elaborate? This rings a bell but I forget.
{quote}
LUCENE-8450 has the discussion. The basic idea there was to add some methods to
TokenStream that would be analogous to CharFilter.correctOffset so TokenFilters
could also apply offsets correctly.
> Make WordDelimiterGraphFilter a Tokenizer
> -
>
> Key: LUCENE-8516
> URL: https://issues.apache.org/jira/browse/LUCENE-8516
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8516.patch
>
>
> Being able to split tokens up at arbitrary points in a filter chain, in
> effect adding a second round of tokenization, can cause any number of
> problems when trying to keep tokenstreams to contract. The most common
> offender here is the WordDelimiterGraphFilter, which can produce broken
> offsets in a wide range of situations.
> We should make WDGF a Tokenizer in its own right, which should preserve all
> the functionality we need, but make reasoning about the resulting tokenstream
> much simpler.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12831) DeleteShardCmd doesn't remove all its data from Zookeeper
Andrzej Bialecki created SOLR-12831:
Summary: DeleteShardCmd doesn't remove all its data from Zookeeper
Key: SOLR-12831
URL: https://issues.apache.org/jira/browse/SOLR-12831
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.5, master (8.0)
Reporter: Andrzej Bialecki
After successful completion of {{DeleteShardCmd}} there's still some data in ZK
under {{/collections/}} that should've been removed:
* leaders/shardX
* leader_elect/shardX
* terms/shardX
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12831) DeleteShardCmd doesn't remove all its data from Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-12831:
-
Priority: Minor (was: Major)
> DeleteShardCmd doesn't remove all its data from Zookeeper
> -
>
> Key: SOLR-12831
> URL: https://issues.apache.org/jira/browse/SOLR-12831
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.5, master (8.0)
>Reporter: Andrzej Bialecki
>Priority: Minor
>
> After successful completion of {{DeleteShardCmd}} there's still some data in
> ZK under {{/collections/}} that should've been removed:
> * leaders/shardX
> * leader_elect/shardX
> * terms/shardX
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12739) Make autoscaling policy based replica placement the default strategy for placing replicas
[ https://issues.apache.org/jira/browse/SOLR-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-12739: - Attachment: SOLR-12739.patch > Make autoscaling policy based replica placement the default strategy for > placing replicas > - > > Key: SOLR-12739 > URL: https://issues.apache.org/jira/browse/SOLR-12739 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12739.patch > > > Today the default placement strategy is the same one used since Solr 4.x > which is to select nodes on a round robin fashion. I propose to make the > autoscaling policy based replica placement as the default policy for placing > replicas. > This is related to SOLR-12648 where even though we have default cluster > preferences, we don't use them unless a policy is also configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12739) Make autoscaling policy based replica placement the default strategy for placing replicas
[ https://issues.apache.org/jira/browse/SOLR-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638111#comment-16638111 ] Shalin Shekhar Mangar commented on SOLR-12739: -- Initial patch which makes the necessary changes. I expect a lot of tests will fail with this patch because of the changed assumptions. > Make autoscaling policy based replica placement the default strategy for > placing replicas > - > > Key: SOLR-12739 > URL: https://issues.apache.org/jira/browse/SOLR-12739 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12739.patch > > > Today the default placement strategy is the same one used since Solr 4.x > which is to select nodes on a round robin fashion. I propose to make the > autoscaling policy based replica placement as the default policy for placing > replicas. > This is related to SOLR-12648 where even though we have default cluster > preferences, we don't use them unless a policy is also configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1657 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1657/ 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeWithMultipleReplicasLost Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([A173528524A1CB0E]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([A173528524A1CB0E]:0) Build Log: [...truncated 15682 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build/solr-core/test/J0/temp/solr.cloud.autoscaling.sim.TestSimComputePlanAction_A173528524A1CB0E-001/init-core-data-001 [junit4] 2> 1044927 DEBUG (SUITE-TestSimComputePlanAction-seed#[A173528524A1CB0E]-worker) [] o.a.s.c.a.s.SimClusterStateProvider --- new Overseer leader: 127.0.0.1:1_solr [junit4] 2> 1044928 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Adding .auto_add_replicas and .scheduled_maintenance triggers [junit4] 2> 1044928 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Refreshing /autoscaling.json with znode version 0 [junit4] 2> 1044928 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Current znodeVersion 0, lastZnodeVersion -1 [junit4] 2> 1044929 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Processed trigger updates upto znodeVersion 0 [junit4] 2> 1044932 DEBUG (SUITE-TestSimComputePlanAction-seed#[A173528524A1CB0E]-worker) [] o.a.s.c.a.s.SimClusterStateProvider ** creating new collection states, currentVersion=0 [junit4] 2> 1044933 DEBUG (SUITE-TestSimComputePlanAction-seed#[A173528524A1CB0E]-worker) [] o.a.s.c.a.s.SimClusterStateProvider ** saved cluster state version 0 [junit4] 2> 1044933 INFO (SUITE-TestSimComputePlanAction-seed#[A173528524A1CB0E]-worker) [] o.a.s.h.a.MetricsHistoryHandler No .system collection, keeping metrics history in memory. [junit4] 2> 1044941 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.NodeLostTrigger NodeLostTrigger .auto_add_replicas - Initial livenodes: [127.0.0.1:1_solr] [junit4] 2> 1044943 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread -- clean old nodeAdded markers [junit4] 2> 1044943 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Current znodeVersion 0, lastZnodeVersion 0 [junit4] 2> 1044949 DEBUG (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.OverseerTriggerThread Refreshing /autoscaling.json with znode version 1 [junit4] 2> 1044949 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Processed trigger updates upto znodeVersion 1 [junit4] 2> 1044950 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread -- clean old nodeLost markers [junit4] 2> 1044950 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread -- clean old nodeAdded markers [junit4] 2> 1044950 DEBUG (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread Current znodeVersion 1, lastZnodeVersion 1 [junit4] 2> 1044950 INFO (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.s.SimCloudManager === Restarting OverseerTriggerThread and clearing object cache... [junit4] 2> 1044950 WARN (Simulated OverseerAutoScalingTriggerThread) [ ] o.a.s.c.a.OverseerTriggerThread OverseerTriggerThread woken up but we are closed, exiting. [junit4] 2> 1044951 DEBUG (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.ScheduledTriggers Shutting down scheduled thread pool executor now [junit4] 2> 1044951 DEBUG (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.ScheduledTriggers Shutting down action executor now [junit4] 2> 1044951 DEBUG (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.ScheduledTriggers Awaiting termination for action executor [junit4] 2> 1044951 DEBUG (TEST-TestSimComputePlanAction.testNodeAdded-seed#[A173528524A1CB0E]) [] o.a.s.c.a.ScheduledTriggers Awaiting termination for scheduled thread pool executor [junit4] 2> 1044961 DEBUG
[jira] [Commented] (LUCENE-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause
[ https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638086#comment-16638086 ] ASF subversion and git services commented on LUCENE-8479: - Commit fe819ea272dd001b6b0352a4d68009d4371e20f5 in lucene-solr's branch refs/heads/branch_7x from [~jim.ferenczi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fe819ea ] LUCENE-8479: QueryBuilder#analyzeGraphPhrase now throws TooManyClause exception if the number of expanded path reaches the BooleanQuery#maxClause limit. > QueryBuilder#analyzeGraphPhrase should respect max boolean clause > - > > Key: LUCENE-8479 > URL: https://issues.apache.org/jira/browse/LUCENE-8479 > Project: Lucene - Core > Issue Type: Test >Reporter: Jim Ferenczi >Priority: Major > Attachments: LUCENE-8479.patch, LUCENE-8479.patch > > > Currently there is no limit in the number of span queries that can be mixed > by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands > of paths. We should apply the same limit than analyzeGraphBoolean which > throws TooManyClauses exception when the number of expanded paths is greater > than BooleanQuery#MAX_CLAUSE_COUNT. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause
[ https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638084#comment-16638084 ] ASF subversion and git services commented on LUCENE-8479: - Commit 0f14bcd8ffc15cb5bd9281e1c9a61c17eb86 in lucene-solr's branch refs/heads/master from [~jim.ferenczi] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0f1 ] LUCENE-8479: QueryBuilder#analyzeGraphPhrase now throws TooManyClause exception if the number of expanded path reaches the BooleanQuery#maxClause limit. > QueryBuilder#analyzeGraphPhrase should respect max boolean clause > - > > Key: LUCENE-8479 > URL: https://issues.apache.org/jira/browse/LUCENE-8479 > Project: Lucene - Core > Issue Type: Test >Reporter: Jim Ferenczi >Priority: Major > Attachments: LUCENE-8479.patch, LUCENE-8479.patch > > > Currently there is no limit in the number of span queries that can be mixed > by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands > of paths. We should apply the same limit than analyzeGraphBoolean which > throws TooManyClauses exception when the number of expanded paths is greater > than BooleanQuery#MAX_CLAUSE_COUNT. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[ https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638063#comment-16638063 ] ASF subversion and git services commented on SOLR-12827: Commit 793a677d0f62e2bcfeae7e0abb42b5f7ab40126e in lucene-solr's branch refs/heads/master from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=793a677 ] SOLR-12827: Fix blurb in ref guide to say that the key is deprecated instead of saying that it is no longer supported. > Migrate cluster wide defaults syntax in cluster properties to a nested > structure > > > Key: SOLR-12827 > URL: https://issues.apache.org/jira/browse/SOLR-12827 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12827.patch > > > SOLR-12387 introduced cluster wide defaults for collection properties. > However, the syntax committed is flat and ugly e.g. collectionDefaults > instead of defaults/collection inspite of the latter being proposed by > Andrzej. Anyway, we should change the format now before it sees widespread > use. I propose to fix documentation to describe the new format and > auto-convert cluster properties to new syntax on startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[ https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-12827. -- Resolution: Fixed Assignee: Shalin Shekhar Mangar > Migrate cluster wide defaults syntax in cluster properties to a nested > structure > > > Key: SOLR-12827 > URL: https://issues.apache.org/jira/browse/SOLR-12827 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12827.patch > > > SOLR-12387 introduced cluster wide defaults for collection properties. > However, the syntax committed is flat and ugly e.g. collectionDefaults > instead of defaults/collection inspite of the latter being proposed by > Andrzej. Anyway, we should change the format now before it sees widespread > use. I propose to fix documentation to describe the new format and > auto-convert cluster properties to new syntax on startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[ https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638072#comment-16638072 ] ASF subversion and git services commented on SOLR-12827: Commit 60c75e4aadd2293036e1ba499eb4487968c2a17f in lucene-solr's branch refs/heads/branch_7x from [~shalinmangar] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60c75e4 ] SOLR-12827: Fix blurb in ref guide to say that the key is deprecated instead of saying that it is no longer supported. (cherry picked from commit 793a677d0f62e2bcfeae7e0abb42b5f7ab40126e) > Migrate cluster wide defaults syntax in cluster properties to a nested > structure > > > Key: SOLR-12827 > URL: https://issues.apache.org/jira/browse/SOLR-12827 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12827.patch > > > SOLR-12387 introduced cluster wide defaults for collection properties. > However, the syntax committed is flat and ugly e.g. collectionDefaults > instead of defaults/collection inspite of the latter being proposed by > Andrzej. Anyway, we should change the format now before it sees widespread > use. I propose to fix documentation to describe the new format and > auto-convert cluster properties to new syntax on startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[
https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638071#comment-16638071
]
ASF subversion and git services commented on SOLR-12827:
Commit 5b4814eb580ca8469e88d9a8eaea111c9d4ae287 in lucene-solr's branch
refs/heads/branch_7x from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5b4814e ]
SOLR-12827: Migrate cluster wide defaults syntax in cluster properties to a
nested structure
The cluster wide defaults structure has changed from {collectionDefaults:
{nrtReplicas : 2}} to {defaults : {collection : {nrtReplicas : 2}}}. The old
format continues to be supported and can be read from ZK as well as written
using the V2 set-obj-property syntax but it is deprecated and will be removed
in Solr 9. We recommend that users change their API calls to use the new format
going forward.
(cherry picked from commit 152fd966a7a23b4a5379d9b24ae731ef4fe58766)
> Migrate cluster wide defaults syntax in cluster properties to a nested
> structure
>
>
> Key: SOLR-12827
> URL: https://issues.apache.org/jira/browse/SOLR-12827
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12827.patch
>
>
> SOLR-12387 introduced cluster wide defaults for collection properties.
> However, the syntax committed is flat and ugly e.g. collectionDefaults
> instead of defaults/collection inspite of the latter being proposed by
> Andrzej. Anyway, we should change the format now before it sees widespread
> use. I propose to fix documentation to describe the new format and
> auto-convert cluster properties to new syntax on startup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[
https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638062#comment-16638062
]
Shalin Shekhar Mangar commented on SOLR-12827:
--
Thanks Andrzej. I'll change that to say:
{code}
NOTE: Until Solr 7.5, cluster properties supported a "collectionDefaults" key
which is now deprecated. Using the API
structure for Solr 7.4 or Solr 7.5 with "collectionDefaults" will continue to
work but the format of the properties
will automatically be converted to the new nested structure. Support for the
"collectionDefaults" key will be
removed in Solr 9.
{code}
> Migrate cluster wide defaults syntax in cluster properties to a nested
> structure
>
>
> Key: SOLR-12827
> URL: https://issues.apache.org/jira/browse/SOLR-12827
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12827.patch
>
>
> SOLR-12387 introduced cluster wide defaults for collection properties.
> However, the syntax committed is flat and ugly e.g. collectionDefaults
> instead of defaults/collection inspite of the latter being proposed by
> Andrzej. Anyway, we should change the format now before it sees widespread
> use. I propose to fix documentation to describe the new format and
> auto-convert cluster properties to new syntax on startup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[
https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638059#comment-16638059
]
Andrzej Bialecki commented on SOLR-12827:
--
+1.
Minor nit in the adoc: {{"collectionDefaults" key which is no longer
supported}} should probably read "deprecated" or not recommended, because it's
still supported.
> Migrate cluster wide defaults syntax in cluster properties to a nested
> structure
>
>
> Key: SOLR-12827
> URL: https://issues.apache.org/jira/browse/SOLR-12827
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12827.patch
>
>
> SOLR-12387 introduced cluster wide defaults for collection properties.
> However, the syntax committed is flat and ugly e.g. collectionDefaults
> instead of defaults/collection inspite of the latter being proposed by
> Andrzej. Anyway, we should change the format now before it sees widespread
> use. I propose to fix documentation to describe the new format and
> auto-convert cluster properties to new syntax on startup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 336 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/336/ 7 tests failed. FAILED: org.apache.solr.cloud.CollectionStateFormat2Test.testZkNodeLocation Error Message: Error from server at http://127.0.0.1:42945/solr: KeeperErrorCode = Session expired for /configs/conf Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42945/solr: KeeperErrorCode = Session expired for /configs/conf at __randomizedtesting.SeedInfo.seed([2C9726F0D2754A4:4D64F8CFA048DA50]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.CollectionStateFormat2Test.testZkNodeLocation(CollectionStateFormat2Test.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[
https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638029#comment-16638029
]
Shalin Shekhar Mangar commented on SOLR-12827:
--
This patch migrates the nested cluster properties format to:
{code}
{
"defaults" : {
"collection": {
"numShards": 2,
"numNrtReplicas": 2,
}
}
}
{code}
The old format can be read from ZK. It can also be written using the APIs.
However, it is auto-converted to the new format on reads and writes. We can get
rid of the conversion logic in Solr 9.
The patch also updates the reference guide to mention only the new format. I
added a note saying that the old API syntax continues to be supported but it
will be auto-converted.
I'll commit once tests and precommit pass.
> Migrate cluster wide defaults syntax in cluster properties to a nested
> structure
>
>
> Key: SOLR-12827
> URL: https://issues.apache.org/jira/browse/SOLR-12827
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Major
> Fix For: 7.6, master (8.0)
>
> Attachments: SOLR-12827.patch
>
>
> SOLR-12387 introduced cluster wide defaults for collection properties.
> However, the syntax committed is flat and ugly e.g. collectionDefaults
> instead of defaults/collection inspite of the latter being proposed by
> Andrzej. Anyway, we should change the format now before it sees widespread
> use. I propose to fix documentation to describe the new format and
> auto-convert cluster properties to new syntax on startup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12827) Migrate cluster wide defaults syntax in cluster properties to a nested structure
[ https://issues.apache.org/jira/browse/SOLR-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-12827: - Attachment: SOLR-12827.patch > Migrate cluster wide defaults syntax in cluster properties to a nested > structure > > > Key: SOLR-12827 > URL: https://issues.apache.org/jira/browse/SOLR-12827 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Major > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12827.patch > > > SOLR-12387 introduced cluster wide defaults for collection properties. > However, the syntax committed is flat and ugly e.g. collectionDefaults > instead of defaults/collection inspite of the latter being proposed by > Andrzej. Anyway, we should change the format now before it sees widespread > use. I propose to fix documentation to describe the new format and > auto-convert cluster properties to new syntax on startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user sigram commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222593938
--- Diff:
solr/test-framework/src/java/org/apache/solr/cloud/SolrCloudTestCase.java ---
@@ -420,4 +425,68 @@ public static void ensureRunningJettys(int nodeCount,
int timeoutSeconds) throws
cluster.waitForAllNodes(timeoutSeconds);
}
+
+ static final List AUTH_METRICS_KEYS = Arrays.asList("errors",
"timeouts", "requests", "authenticated",
--- End diff --
I think it would be better to put this whole section in a subclass of
SolrCloudTestCase, eg. SolrCloudAuthTestCase - there are only two tests that
need this stuff but there are hundreds of tests that extend this base class and
don't need this.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #457: SOLR-12791: Add Metrics reporting for Authent...
Github user sigram commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/457#discussion_r222587616
--- Diff: solr/core/src/java/org/apache/solr/core/CoreContainer.java ---
@@ -798,6 +798,12 @@ private void reloadSecurityProperties() {
SecurityConfHandler.SecurityConfig securityConfig =
securityConfHandler.getSecurityConfig(false);
initializeAuthorizationPlugin((Map)
securityConfig.getData().get("authorization"));
initializeAuthenticationPlugin((Map)
securityConfig.getData().get("authentication"));
+if (authenticationPlugin != null &&
authenticationPlugin.plugin.getMetricRegistry() == null) {
--- End diff --
Is this second check necessary? we know that just after the plugin was
created its metricRegistry is null, it's set only after `initializeMetrics` has
been called.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
