[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 887 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/887/ Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data\tlog\tlog.004: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data\tlog\tlog.004: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1\data C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard1_replica1 C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data\tlog\tlog.004: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data\tlog\tlog.004: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1\data C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1\collection1_shard2_replica1 C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node1 C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node2\collection1_shard1_replica2\data\tlog\tlog.004: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.TestCloudRecovery_D5A116FC7DDFDE9C-001\tempDir-001\node2\collection1_shard1_replica2\data\tlog\tlog.004: The process cannot access the file because it is being used by another process.
[jira] [Commented] (LUCENE-7705) Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the max token length
[ https://issues.apache.org/jira/browse/LUCENE-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005894#comment-16005894 ] Erick Erickson commented on LUCENE-7705: Fair enough, I suppose you could get log flies 20 bazillion bytes long. WDYT about generating multiple tokens when the length is exceeded? > Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the > max token length > - > > Key: LUCENE-7705 > URL: https://issues.apache.org/jira/browse/LUCENE-7705 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Amrit Sarkar >Assignee: Erick Erickson >Priority: Minor > Attachments: LUCENE-7705, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch > > > SOLR-10186 > [~erickerickson]: Is there a good reason that we hard-code a 256 character > limit for the CharTokenizer? In order to change this limit it requires that > people copy/paste the incrementToken into some new class since incrementToken > is final. > KeywordTokenizer can easily change the default (which is also 256 bytes), but > to do so requires code rather than being able to configure it in the schema. > For KeywordTokenizer, this is Solr-only. For the CharTokenizer classes > (WhitespaceTokenizer, UnicodeWhitespaceTokenizer and LetterTokenizer) > (Factories) it would take adding a c'tor to the base class in Lucene and > using it in the factory. > Any objections? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7705) Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the max token length
[ https://issues.apache.org/jira/browse/LUCENE-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005892#comment-16005892 ] Robert Muir commented on LUCENE-7705: - Sorry, I think its a very bad idea to log tokens in lucene's analysis chains for any reason. > Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the > max token length > - > > Key: LUCENE-7705 > URL: https://issues.apache.org/jira/browse/LUCENE-7705 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Amrit Sarkar >Assignee: Erick Erickson >Priority: Minor > Attachments: LUCENE-7705, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch > > > SOLR-10186 > [~erickerickson]: Is there a good reason that we hard-code a 256 character > limit for the CharTokenizer? In order to change this limit it requires that > people copy/paste the incrementToken into some new class since incrementToken > is final. > KeywordTokenizer can easily change the default (which is also 256 bytes), but > to do so requires code rather than being able to configure it in the schema. > For KeywordTokenizer, this is Solr-only. For the CharTokenizer classes > (WhitespaceTokenizer, UnicodeWhitespaceTokenizer and LetterTokenizer) > (Factories) it would take adding a c'tor to the base class in Lucene and > using it in the factory. > Any objections? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7705) Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the max token length
[
https://issues.apache.org/jira/browse/LUCENE-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005888#comment-16005888
]
Erick Erickson commented on LUCENE-7705:
One nit and one suggestion and one question in addition to Robert's comments:
The nit:
there's a pattern of a bunch of these:
updateJ("{\"add\":{\"doc\":
{\"id\":1,\"letter\":\"letter\"}},\"commit\":{}}",null);
.
.
then:
assertU(commit());
It's unnecessary to do the commit with the updateJ calls. the commit at the end
will take care of it all. It's a little less efficient to commit with each doc.
Frankly I doubt that'd be measurable, performance wise, but let's take them out
anyway.
The suggestion:
When we do stop accruing characters e.g. in CharTokenizer, let's log an INFO
level message to that effect, something like
log.info("Splitting token at {} chars", maxTokenLen);
That way people will have a clue where to look. I think INFO is appropriate
rather than WARN or ERROR since it's perfectly legitimate to truncate input,
I'm thinking OCR text for instance. Maybe dump the token we've accumulated so
far?
I worded it at "splitting" because (and there are tests for this) that the next
token picks up where the first left off. So if the max length is 3, and the
input is "whitespace", we get several tokens as a result,
"whi", "tes", "pac", and "e".
I suppose that means that the offsets are also incremented. Is that really what
we want here? Or should we instead throw away the extra tokens? [~rcmuir], what
do you think is correct? This is not a _change_ in behavior, the current code
does the same thing just a hard-coded 255 limit. I'm checking if this is
intended behavior.
If we do want to throw away the extra, we could spin through the buffer until
we encountered a non char then return the part < maxTokenLen. If we did that we
could also log the entire token and the truncated version if we wanted.
Otherwise precommit passes and all tests pass.
> Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the
> max token length
> -
>
> Key: LUCENE-7705
> URL: https://issues.apache.org/jira/browse/LUCENE-7705
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-7705, LUCENE-7705.patch, LUCENE-7705.patch,
> LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch,
> LUCENE-7705.patch
>
>
> SOLR-10186
> [~erickerickson]: Is there a good reason that we hard-code a 256 character
> limit for the CharTokenizer? In order to change this limit it requires that
> people copy/paste the incrementToken into some new class since incrementToken
> is final.
> KeywordTokenizer can easily change the default (which is also 256 bytes), but
> to do so requires code rather than being able to configure it in the schema.
> For KeywordTokenizer, this is Solr-only. For the CharTokenizer classes
> (WhitespaceTokenizer, UnicodeWhitespaceTokenizer and LetterTokenizer)
> (Factories) it would take adding a c'tor to the base class in Lucene and
> using it in the factory.
> Any objections?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_131) - Build # 6558 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6558/ Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 35762 lines...] -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8 [forbidden-apis] Reading bundled API signatures: jdk-non-portable [forbidden-apis] Reading bundled API signatures: jdk-reflection [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.5 [forbidden-apis] Reading API signatures: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\tools\forbiddenApis\base.txt [forbidden-apis] Reading API signatures: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\tools\forbiddenApis\servlet-api.txt [forbidden-apis] Reading API signatures: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\tools\forbiddenApis\solr.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning classes for violations... [forbidden-apis] Forbidden method invocation: java.util.Collections#shuffle(java.util.List) [Use shuffle(List, Random) instead so that it can be reproduced] [forbidden-apis] in org.apache.solr.client.solrj.impl.CloudSolrClient (CloudSolrClient.java:1288) [forbidden-apis] Scanned 944 (and 762 related) class file(s) for forbidden API invocations (in 1.45s), 1 error(s). BUILD FAILED C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:775: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:117: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build.xml:381: The following error occurred while executing this line: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\common-build.xml:527: Check for forbidden API calls failed, see log. Total time: 83 minutes 53 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts [WARNINGS] Skipping publisher since build result is FAILURE Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-6.6 - Build # 1 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.6/1/
1 tests failed.
FAILED: org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery
Error Message:
Expected a collection with one shard and two replicas null Last available
state:
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
"replicationFactor":"2", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node1":{ "core":"MissingSegmentRecoveryTest_shard1_replica2",
"base_url":"http://127.0.0.1:57526/solr;,
"node_name":"127.0.0.1:57526_solr", "state":"active",
"leader":"true"}, "core_node2":{
"core":"MissingSegmentRecoveryTest_shard1_replica1",
"base_url":"http://127.0.0.1:51929/solr;,
"node_name":"127.0.0.1:51929_solr", "state":"down",
"router":{"name":"compositeId"}, "maxShardsPerNode":"1",
"autoAddReplicas":"false"}
Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state:
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
"core_node1":{
"core":"MissingSegmentRecoveryTest_shard1_replica2",
"base_url":"http://127.0.0.1:57526/solr;,
"node_name":"127.0.0.1:57526_solr",
"state":"active",
"leader":"true"},
"core_node2":{
"core":"MissingSegmentRecoveryTest_shard1_replica1",
"base_url":"http://127.0.0.1:51929/solr;,
"node_name":"127.0.0.1:51929_solr",
"state":"down",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"}
at
__randomizedtesting.SeedInfo.seed([AAC2E18160FEC499:FA97798239DF7284]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
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:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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
[jira] [Assigned] (SOLR-10660) Add reverse Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein reassigned SOLR-10660:
-
Assignee: Joel Bernstein
> Add reverse Stream Evaluator
>
>
> Key: SOLR-10660
> URL: https://issues.apache.org/jira/browse/SOLR-10660
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10660.patch
>
>
> The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
> Syntax:
> {code}
> a = rev(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10660) Add reverse Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005826#comment-16005826
]
ASF subversion and git services commented on SOLR-10660:
Commit 477b7ea66e71a47221bbf83f53dcd31636f9c461 in lucene-solr's branch
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=477b7ea ]
SOLR-10660: Add reverse Stream Evaluator
> Add reverse Stream Evaluator
>
>
> Key: SOLR-10660
> URL: https://issues.apache.org/jira/browse/SOLR-10660
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10660.patch
>
>
> The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
> Syntax:
> {code}
> a = rev(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10431) Make it possible to invoke v2 api calls using SolrJ
[ https://issues.apache.org/jira/browse/SOLR-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005824#comment-16005824 ] Cao Manh Dat commented on SOLR-10431: - Thanks [~noble.paul] and [~shalinmangar] > Make it possible to invoke v2 api calls using SolrJ > --- > > Key: SOLR-10431 > URL: https://issues.apache.org/jira/browse/SOLR-10431 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, > SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-10431) Make it possible to invoke v2 api calls using SolrJ
[ https://issues.apache.org/jira/browse/SOLR-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cao Manh Dat closed SOLR-10431. --- Resolution: Fixed Fix Version/s: master (7.0) > Make it possible to invoke v2 api calls using SolrJ > --- > > Key: SOLR-10431 > URL: https://issues.apache.org/jira/browse/SOLR-10431 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul >Assignee: Cao Manh Dat > Fix For: master (7.0) > > Attachments: SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, > SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10660) Add reverse Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10660:
--
Description:
The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
Syntax:
{code}
a = rev(colA)
{code}
was:
The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
Syntax:
{code}
a = reverse(colA)
{code}
> Add reverse Stream Evaluator
>
>
> Key: SOLR-10660
> URL: https://issues.apache.org/jira/browse/SOLR-10660
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10660.patch
>
>
> The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
> Syntax:
> {code}
> a = rev(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10660) Add reverse Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10660:
--
Attachment: SOLR-10660.patch
Patch with tests
> Add reverse Stream Evaluator
>
>
> Key: SOLR-10660
> URL: https://issues.apache.org/jira/browse/SOLR-10660
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10660.patch
>
>
> The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
> Syntax:
> {code}
> a = reverse(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10617) JDBCStream: support more data types
[ https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005815#comment-16005815 ] Dennis Gove edited comment on SOLR-10617 at 5/11/17 2:43 AM: - bq. Does the Interface at the bottom need to be in its own source file per our guidelines? The interface is only used internally. I've moved it inside the class body so it's a clear part of the JDBCStream class. bq. How does the java.sql.Array bit work? I haven't encountered sql ARRAY type before, and I'm not seeing anything on it in the docs/tests/etc. Some databases are able to return Array objects. For example, Postgres's jsonb function jsonb_build_array (https://www.postgresql.org/docs/9.5/static/functions-json.html) can result in an array existing in the resultset. The idea here is that an object array would be placed in the Tuple under the field name. was (Author: dpgove): bq. Does the Interface at the bottom need to be in its own source file per our guidelines? The interface is only used internally. I've moved it inside the class body so it's a clear part of the JDBCStream class. bq. How does the java.sql.Array bit work? I haven't encountered sql ARRAY type before, and I'm not seeing anything on it in the docs/tests/etc. Some databases are able to return Array objects. For example, Postgres's jsonb function jsonb_build_array (https://www.postgresql.org/docs/9.5/static/functions-json.html) can result in an array existing in the resultset. > JDBCStream: support more data types > --- > > Key: SOLR-10617 > URL: https://issues.apache.org/jira/browse/SOLR-10617 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch > > > It would be nice if JDBCStream could support Decimal types as well as > Timestamp-related types, and CLOBs. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10617) JDBCStream: support more data types
[ https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005815#comment-16005815 ] Dennis Gove edited comment on SOLR-10617 at 5/11/17 2:42 AM: - bq. Does the Interface at the bottom need to be in its own source file per our guidelines? The interface is only used internally. I've moved it inside the class body so it's a clear part of the JDBCStream class. bq. How does the java.sql.Array bit work? I haven't encountered sql ARRAY type before, and I'm not seeing anything on it in the docs/tests/etc. Some databases are able to return Array objects. For example, Postgres's jsonb function jsonb_build_array (https://www.postgresql.org/docs/9.5/static/functions-json.html) can result in an array existing in the resultset. was (Author: dpgove): > Does the Interface at the bottom need to be in its own source file per our > guidelines? The interface is only used internally. I've moved it inside the class body so it's a clear part of the JDBCStream class. > How does the java.sql.Array bit work? I haven't encountered sql ARRAY type > before, and I'm not seeing anything on it in the docs/tests/etc. Some databases are able to return Array objects. For example, Postgres's jsonb function jsonb_build_array (https://www.postgresql.org/docs/9.5/static/functions-json.html) can result in an array existing in the resultset. > JDBCStream: support more data types > --- > > Key: SOLR-10617 > URL: https://issues.apache.org/jira/browse/SOLR-10617 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch > > > It would be nice if JDBCStream could support Decimal types as well as > Timestamp-related types, and CLOBs. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10617) JDBCStream: support more data types
[ https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005815#comment-16005815 ] Dennis Gove commented on SOLR-10617: > Does the Interface at the bottom need to be in its own source file per our > guidelines? The interface is only used internally. I've moved it inside the class body so it's a clear part of the JDBCStream class. > How does the java.sql.Array bit work? I haven't encountered sql ARRAY type > before, and I'm not seeing anything on it in the docs/tests/etc. Some databases are able to return Array objects. For example, Postgres's jsonb function jsonb_build_array (https://www.postgresql.org/docs/9.5/static/functions-json.html) can result in an array existing in the resultset. > JDBCStream: support more data types > --- > > Key: SOLR-10617 > URL: https://issues.apache.org/jira/browse/SOLR-10617 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch > > > It would be nice if JDBCStream could support Decimal types as well as > Timestamp-related types, and CLOBs. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10617) JDBCStream: support more data types
[ https://issues.apache.org/jira/browse/SOLR-10617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-10617: --- Attachment: SOLR-10617.patch This all looks good. I've just added a new patch with some additional comments on why in open() we switch from using the Java class type to the SQL data type. > JDBCStream: support more data types > --- > > Key: SOLR-10617 > URL: https://issues.apache.org/jira/browse/SOLR-10617 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: James Dyer >Assignee: James Dyer >Priority: Minor > Attachments: SOLR-10617.patch, SOLR-10617.patch, SOLR-10617.patch > > > It would be nice if JDBCStream could support Decimal types as well as > Timestamp-related types, and CLOBs. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10431) Make it possible to invoke v2 api calls using SolrJ
[ https://issues.apache.org/jira/browse/SOLR-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005810#comment-16005810 ] ASF subversion and git services commented on SOLR-10431: Commit 5a25ef0e77c2fdffcc2ea00988724c292858dea4 in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5a25ef0 ] SOLR-10431: Fix precommit > Make it possible to invoke v2 api calls using SolrJ > --- > > Key: SOLR-10431 > URL: https://issues.apache.org/jira/browse/SOLR-10431 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul >Assignee: Cao Manh Dat > Attachments: SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, > SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10431) Make it possible to invoke v2 api calls using SolrJ
[ https://issues.apache.org/jira/browse/SOLR-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005793#comment-16005793 ] ASF subversion and git services commented on SOLR-10431: Commit cc8b5bab0bdad4d57ac3764e9c3b313cb07fcddc in lucene-solr's branch refs/heads/master from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cc8b5ba ] SOLR-10431: Make it possible to invoke v2 api calls using SolrJ > Make it possible to invoke v2 api calls using SolrJ > --- > > Key: SOLR-10431 > URL: https://issues.apache.org/jira/browse/SOLR-10431 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul >Assignee: Cao Manh Dat > Attachments: SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, > SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch, SOLR-10431.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7705) Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the max token length
[
https://issues.apache.org/jira/browse/LUCENE-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005739#comment-16005739
]
Robert Muir commented on LUCENE-7705:
-
Why do the tokenizer ctor arg take {{Integer}} instead of {{int}}? They check
for null and throws an exception in that case, but I think its better to encode
the correct argument type in the method signature. This would also mean you can
re-enable TestRandomChains for the newly-added ctors.
I think if basic tokenizers like WhitespaceTokenizer have new ctors that take
{{int}}, and throw exception on illegal values for this parameter because some
aren't permitted, that these new ctors really could use a bit better docs:
{quote}
@param maxTokenLen max token length the tokenizer will emit
{quote}
Instead, maybe something like:
{quote}
@param maxTokenLen maximum token length the tokenizer will emit. Must not be
negative.
@throws IllegalArgumentException if maxTokenLen is invalid.
{quote}
Also I am concerned about the allowable value ranges and the disabling of tests
as far as correctness. Instead if {{int}} is used instead of {{Integer}} this
test can be re-enabled which may find/prevent crazy bugs. e.g. I worry a bit
what will these Tokenizers do in each case if maxTokenLen is 0 (which is
allowed), will they loop forever or crash, etc?
The maximum value of the range is also suspicious. What happens with any
{{CharTokenizer}}-based tokenizer if i supply a value > IO_BUFFER_SIZE? Maybe
it behaves correctly, maybe not. I think {{Integer.MAX_VALUE}} is a trap for a
number of reasons: enormous values will likely only blow up anyway (limited to
32766 in the index), if they don't they may create hellacious threadlocal
memory usage in buffers, bad/malicious input could take out JVMs, etc.
Maybe follow the example of StandardTokenizer here:
{code}
/** Absolute maximum sized token */
public static final int MAX_TOKEN_LENGTH_LIMIT = 1024 * 1024;
...
* @throws IllegalArgumentException if the given length is outside of the
* range [1, {@value #MAX_TOKEN_LENGTH_LIMIT}].
...
if (length < 1) {
throw new IllegalArgumentException("maxTokenLength must be greater than
zero");
} else if (length > MAX_TOKEN_LENGTH_LIMIT) {
throw new IllegalArgumentException("maxTokenLength may not exceed " +
MAX_TOKEN_LENGTH_LIMIT);
}
{code}
> Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the
> max token length
> -
>
> Key: LUCENE-7705
> URL: https://issues.apache.org/jira/browse/LUCENE-7705
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Amrit Sarkar
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: LUCENE-7705, LUCENE-7705.patch, LUCENE-7705.patch,
> LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch,
> LUCENE-7705.patch
>
>
> SOLR-10186
> [~erickerickson]: Is there a good reason that we hard-code a 256 character
> limit for the CharTokenizer? In order to change this limit it requires that
> people copy/paste the incrementToken into some new class since incrementToken
> is final.
> KeywordTokenizer can easily change the default (which is also 256 bytes), but
> to do so requires code rather than being able to configure it in the schema.
> For KeywordTokenizer, this is Solr-only. For the CharTokenizer classes
> (WhitespaceTokenizer, UnicodeWhitespaceTokenizer and LetterTokenizer)
> (Factories) it would take adding a c'tor to the base class in Lucene and
> using it in the factory.
> Any objections?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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 # 1830 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1830/ 2 tests failed. FAILED: org.apache.solr.update.AutoCommitTest.testMaxTime Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([84FBD18FCEF0C9DA:1E0FAC6D506A55E6]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896) at org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:270) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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:745) Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:529=standard=0=20=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:889) ... 40 more FAILED: org.apache.solr.update.HardAutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during
[jira] [Updated] (LUCENE-7821) classic parser range query parsing is sloppy about "TO"
[
https://issues.apache.org/jira/browse/LUCENE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated LUCENE-7821:
-
Attachment: LUCENE-7821.patch
patch with simple test demonstrating problems
> classic parser range query parsing is sloppy about "TO"
> ---
>
> Key: LUCENE-7821
> URL: https://issues.apache.org/jira/browse/LUCENE-7821
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7821.patch
>
>
> A post on the solr-user mailing list drew my attention to the fact that this
> is apparently a valid range query under the QueryParser.jj grammer (both for
> the classic parser and the solr variant -- i didn't check flexible)...
> {noformat}
> [x z] // parsed the same as [x TO z]
> {noformat}
> it's parsed as a valid range query even though there is no {{ TO }} -- even
> though there is nothing in the docs to suggest that the {{ TO }} is intended
> to be optional.
> Furthermore, in my experimenting i realized that how the grammer looks for
> the {{ TO }} keyword seems to be a bit sloppy, making some range queries that
> should be easy to validate (because they are unambiguous) fail to parse...
> {noformat}
> [TO TO z] // fails
> [a TO TO] // fails
> [a TO "TO"] // works, but why should quoting be neccessary here?
> {noformat}
>
> If the "sloppy" parsing behavior is intentional, then the docs should reflect
> that the {{ TO }} is optional -- but it seems like in general we should make
> these other unambiguous cases parse cleanly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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 # 1296 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1296/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.update.HardAutoCommitTest.testCommitWithin Error Message: Exception during query Stack Trace: java.lang.RuntimeException: Exception during query at __randomizedtesting.SeedInfo.seed([FC35F2639600D0CA:46E79D1B152E3EDF]:0) at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:896) at org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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.lang.RuntimeException: REQUEST FAILED: xpath=//result[@numFound=1] xml response was: 00 request was:q=id:529=standard=0=20=2.2 at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:889) ... 40 more FAILED: org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter Error
[jira] [Created] (LUCENE-7821) classic parser range query parsing is sloppy about "TO"
Hoss Man created LUCENE-7821:
Summary: classic parser range query parsing is sloppy about "TO"
Key: LUCENE-7821
URL: https://issues.apache.org/jira/browse/LUCENE-7821
Project: Lucene - Core
Issue Type: Bug
Reporter: Hoss Man
A post on the solr-user mailing list drew my attention to the fact that this is
apparently a valid range query under the QueryParser.jj grammer (both for the
classic parser and the solr variant -- i didn't check flexible)...
{noformat}
[x z] // parsed the same as [x TO z]
{noformat}
it's parsed as a valid range query even though there is no {{ TO }} -- even
though there is nothing in the docs to suggest that the {{ TO }} is intended to
be optional.
Furthermore, in my experimenting i realized that how the grammer looks for the
{{ TO }} keyword seems to be a bit sloppy, making some range queries that
should be easy to validate (because they are unambiguous) fail to parse...
{noformat}
[TO TO z] // fails
[a TO TO] // fails
[a TO "TO"] // works, but why should quoting be neccessary here?
{noformat}
If the "sloppy" parsing behavior is intentional, then the docs should reflect
that the {{ TO }} is optional -- but it seems like in general we should make
these other unambiguous cases parse cleanly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7705) Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the max token length
[ https://issues.apache.org/jira/browse/LUCENE-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005672#comment-16005672 ] Erick Erickson commented on LUCENE-7705: Amrit: I'm using LUCENE-7705 (note no .patch extension). Is that the right one? > Allow CharTokenizer-derived tokenizers and KeywordTokenizer to configure the > max token length > - > > Key: LUCENE-7705 > URL: https://issues.apache.org/jira/browse/LUCENE-7705 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Amrit Sarkar >Assignee: Erick Erickson >Priority: Minor > Attachments: LUCENE-7705, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, LUCENE-7705.patch, > LUCENE-7705.patch > > > SOLR-10186 > [~erickerickson]: Is there a good reason that we hard-code a 256 character > limit for the CharTokenizer? In order to change this limit it requires that > people copy/paste the incrementToken into some new class since incrementToken > is final. > KeywordTokenizer can easily change the default (which is also 256 bytes), but > to do so requires code rather than being able to configure it in the schema. > For KeywordTokenizer, this is Solr-only. For the CharTokenizer classes > (WhitespaceTokenizer, UnicodeWhitespaceTokenizer and LetterTokenizer) > (Factories) it would take adding a c'tor to the base class in Lucene and > using it in the factory. > Any objections? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 862 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/862/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([3BD1A0B7027C7B9C:C29C33183E093616]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:284) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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)
[JENKINS] Lucene-Solr-Tests-6.x - Build # 889 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/889/ 2 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([A8734D8E1C329B0B:23549E5F5D34308F]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856) at org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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
[jira] [Commented] (SOLR-10301) Create meta-documentation for how to write in asciidoc
[
https://issues.apache.org/jira/browse/SOLR-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005568#comment-16005568
]
Cassandra Targett commented on SOLR-10301:
--
There are now a few docs in place, in the {{solr/solr-ref-guide/meta-docs}}
directory:
* {{asciidoc-syntax.adoc}} - covers basics of the asciidoc syntax, with links
to more details.
* {{editing-tools.adoc}} - is the start of some tools you can use to make
writing in asciidoc easier.
* {{jekyll.adoc}} - describes how we're using Jekyll and how to work with the
templates and config files defined.
* {{pdf.adoc}} - describes how the PDF is built, and how to control various
elements of the design, layout, and styling.
> Create meta-documentation for how to write in asciidoc
> --
>
> Key: SOLR-10301
> URL: https://issues.apache.org/jira/browse/SOLR-10301
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>
> If we want to encourage new users and non-committers to contribute patches
> for the Ref Guide, we should document some basics on how to write in
> Asciidoc(tor) format, and how to install/use various tools to improve the
> experience.
> Some basic style guidelines may also be helpful, to ensure a consistent
> experience once docs are published.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10300) Create meta-documentation on processes and policies to publish the Ref Guide
[
https://issues.apache.org/jira/browse/SOLR-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005558#comment-16005558
]
Cassandra Targett commented on SOLR-10300:
--
The main document I've written for publishing processes is in
{{solr/solr-ref-guide/meta-docs/publish.adoc}}. This describes how to build
both the PDF and HTML versions, and how to publish them to their respective
homes (including holding a VOTE, etc.).
A README in {{solr/solr-ref-guide}} describes the dependencies to build locally.
Anything else required? I believe the remaining processes will be just like any
other code change but could be missing something.
Note SOLR-10301 is meant to cover how-tos for modifying templates and content.
> Create meta-documentation on processes and policies to publish the Ref Guide
>
>
> Key: SOLR-10300
> URL: https://issues.apache.org/jira/browse/SOLR-10300
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>
> The Confluence-based Ref Guide has a good set of policies and procedures for
> publishing the Ref Guide at
> https://cwiki.apache.org/confluence/display/solr/**+Internal+MetaDocs.
> Some of the current docs will transfer nicely to the new model. However, new
> processes will be required for publishing online versions of the guide since
> that is brand new.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10300) Create meta-documentation on processes and policies to publish the Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett reassigned SOLR-10300: Assignee: Cassandra Targett > Create meta-documentation on processes and policies to publish the Ref Guide > > > Key: SOLR-10300 > URL: https://issues.apache.org/jira/browse/SOLR-10300 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > > The Confluence-based Ref Guide has a good set of policies and procedures for > publishing the Ref Guide at > https://cwiki.apache.org/confluence/display/solr/**+Internal+MetaDocs. > Some of the current docs will transfer nicely to the new model. However, new > processes will be required for publishing online versions of the guide since > that is brand new. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10595) Redirect Confluence pages to new HTML Guide
[
https://issues.apache.org/jira/browse/SOLR-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10595:
Attachment: new-page-urls.txt
bq. ask infra to modify the cwiki configs so any
{{https://cwiki.apache.org/confluence/display/solr/.*}} URLs get rewritten ...
Hmmm... the only hitch to that plan is that for pages with "special" characters
in their names, cwiki doesn's use URLs with the space ({{/solr/}} in them, and
just uses the pageId as the URL...
* Cross Data Center Replication (CDCR)
** https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=62687462
* Collections / Core Admin
** https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=32604191
* Plugins & Stats Screen
** https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=32604180
...i think there are handul more like that (with "/" in their title)
In any case, i'm attaching a tab delimited file based on the page-tree.xml that
cassandra provided with the {{pageId,new-short-name,Original Title}} of every
cwiki page -- we can ultimately use this to create whatever type of redirect
mapping we need (mod_rewrite {{RewriteMap}} dbm file, javascript, whatever...)
File created via with the following perl one liner, followed by a little manual
cleanup...
{code}
perl -nle 'if (/ new-page-urls.txt
{code}
> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
> Attachments: new-page-urls.txt, page-tree.xml
>
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence
> to the new HTML version.
> I'm undecided if this is the best idea, I can see pros and cons to it. On the
> pro side, I think it helps firmly establish the move away from Confluence and
> helps users adjust to the new location. But I could see the argument that
> redirecting is overly invasive or unnecessary and we should just add a big
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell
> Confluence to add to the HEAD of each page to auto-redirect. With some
> probably simple modifications to it, we could get people to the right page in
> the HTML site:
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10296) Convert existing Ref Guide and post-conversion cleanup
[
https://issues.apache.org/jira/browse/SOLR-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-10296.
--
Resolution: Fixed
Assignee: Cassandra Targett
Per Hoss' comment in SOLR-10290, the conversion is complete and we've merged
this with master:
https://issues.apache.org/jira/browse/SOLR-10290?focusedCommentId=16005503=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16005503
https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=95968c69
> Convert existing Ref Guide and post-conversion cleanup
> --
>
> Key: SOLR-10296
> URL: https://issues.apache.org/jira/browse/SOLR-10296
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>
> We have developed several tools and scripts for converting the Ref Guide out
> of Confluence which get us most of the way to a fully converted set of pages.
> However, we already know that there are several issues that could not be
> automated.
> From https://github.com/ctargett/refguide-asciidoc-poc/issues/27, we have
> this list:
> * The conversion process will insert TODOs for several items that we thought
> might be problematic during conversion; these need to be reviewed and
> resolved. Some of these items are also covered in the below topics.
> * Block elements in tables. The current version of the PDF creation tool we
> are using does not handle those properly (see
> https://github.com/ctargett/refguide-asciidoc-poc/issues/13). In some cases,
> we should remove the table entirely and present the content in a new way
> (using, most often, [labled
> lists|http://asciidoctor.org/docs/user-manual/#labeled-list] instead).
> * Review and (usually) remove huge Tables of Contents from the top of pages.
> The current design of the online version will automatically create a TOC for
> the page, we don't need another one and in some cases this TOC was
> hand-created so can't be removed via conversion.
> * Non-image attachments. Some SVG files will be converted to images, but they
> should not be treated as images.
> * Failed link conversions. Despite my best attempts, many dummy URLs are
> treated by Confluence as real URLs (meaning, dummy URLs like
> {{http://:/solr}} are coded in Confluence's XHTML with tags).
> These will be converted as URLs but will throw errors during the conversion
> process. In some cases, the URLs aren't just these example URLs but are
> indicative of a real problem that needs to be resolved.
> * Spurious tags. Some API pages have a list of available calls
> structured as a list but without being a real ordered or unordered list.
> These will convert badly. The issue
> https://github.com/ctargett/refguide-asciidoc-poc/issues/31 has a list of
> pages where this might be a problem.
> * Appropriate Lead Paragraphs. The stylesheet for HTML pages will make the
> first paragraph of every HTML page a slightly larger font, by way of
> introduction. In many cases, the first paragraph is not really ready for that
> sort of treatment and should be revised to be a more succinct introduction to
> the feature or further contents of the page.
> More problems may be added to this issue as items that specifically need to
> be cleaned up.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10628) Less verbose output from bin/solr create
[
https://issues.apache.org/jira/browse/SOLR-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005540#comment-16005540
]
Cassandra Targett commented on SOLR-10628:
--
+1 to a verbose (-V) option as long as the "short" form provides
success/failure feedback as you've indicated it will.
> Less verbose output from bin/solr create
>
>
> Key: SOLR-10628
> URL: https://issues.apache.org/jira/browse/SOLR-10628
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Jan Høydahl
>
> Creating a collection with {{bin/solr create}} today is too verbose:
> {noformat}
> $ bin/solr create -c foo
> Connecting to ZooKeeper at localhost:9983 ...
> INFO - 2017-05-08 09:06:54.409;
> org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider; Cluster at
> localhost:9983 ready
> Uploading
> /Users/janhoy/git/lucene-solr/solr/server/solr/configsets/data_driven_schema_configs/conf
> for config foo to ZooKeeper at localhost:9983
> Creating new collection 'foo' using command:
> http://localhost:8983/solr/admin/collections?action=CREATE=foo=1=1=1=foo
> {
> "responseHeader":{
> "status":0,
> "QTime":4178},
> "success":{"192.168.127.248:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":2959},
> "core":"foo_shard1_replica1"}}}
> {noformat}
> A normal user don't need all this info. Propose to move all the details to
> verbose mode ({{-V)}} and let the default be the following instead:
> {noformat}
> $ bin/solr create -c foo
> Connecting to ZooKeeper at localhost:9983 ...
> Created collection 'foo' with 1 shard(s), 1 replica(s) using config-set
> 'data_driven_schema_configs'
> {noformat}
> Error messages must of course still be verbose.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10595) Redirect Confluence pages to new HTML Guide
[ https://issues.apache.org/jira/browse/SOLR-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett updated SOLR-10595: - Attachment: page-tree.xml Adding page-tree.xml from Confluence conversion. > Redirect Confluence pages to new HTML Guide > --- > > Key: SOLR-10595 > URL: https://issues.apache.org/jira/browse/SOLR-10595 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > Attachments: page-tree.xml > > > Once the new Ref Guide is live, we may want to redirect pages from Confluence > to the new HTML version. > I'm undecided if this is the best idea, I can see pros and cons to it. On the > pro side, I think it helps firmly establish the move away from Confluence and > helps users adjust to the new location. But I could see the argument that > redirecting is overly invasive or unnecessary and we should just add a big > warning to the page instead. > At any rate, if we do decide to do it, I found some Javascript we could tell > Confluence to add to the HEAD of each page to auto-redirect. With some > probably simple modifications to it, we could get people to the right page in > the HTML site: > https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949 > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10595) Redirect Confluence pages to new HTML Guide
[
https://issues.apache.org/jira/browse/SOLR-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005522#comment-16005522
]
Hoss Man commented on SOLR-10595:
-
the only downside to the javascript approach is that search engines would never
"de-index" the cwiki pages in favor of the new ones.
I think the ideal solution would be:
# ask infra to modify the cwiki configs so any
{{https://cwiki.apache.org/confluence/display/solr/.*}} URLs get rewritten to
something like {{https://lucene.apache.org/solr/guide/old/*}}
# setup our own rewrite mapping rules for each URL from {{/solr/guide/old/.*}}
to ... whatever
(doing 2 redirects means we can directly tweak the mappings later if we decide
we want to, w/o neeing to involve infra)
> Redirect Confluence pages to new HTML Guide
> ---
>
> Key: SOLR-10595
> URL: https://issues.apache.org/jira/browse/SOLR-10595
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>
> Once the new Ref Guide is live, we may want to redirect pages from Confluence
> to the new HTML version.
> I'm undecided if this is the best idea, I can see pros and cons to it. On the
> pro side, I think it helps firmly establish the move away from Confluence and
> helps users adjust to the new location. But I could see the argument that
> redirecting is overly invasive or unnecessary and we should just add a big
> warning to the page instead.
> At any rate, if we do decide to do it, I found some Javascript we could tell
> Confluence to add to the HEAD of each page to auto-redirect. With some
> probably simple modifications to it, we could get people to the right page in
> the HTML site:
> https://community.atlassian.com/t5/Confluence-questions/How-to-apply-redirection-on-all-pages-on-a-space/qaq-p/229949
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10290) New Publication Model for Solr Reference Guide
[ https://issues.apache.org/jira/browse/SOLR-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005503#comment-16005503 ] Hoss Man commented on SOLR-10290: - I just squash merged jira/solr-10290 into master https://git1-us-west.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=95968c69 > New Publication Model for Solr Reference Guide > -- > > Key: SOLR-10290 > URL: https://issues.apache.org/jira/browse/SOLR-10290 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > > The current Solr Ref Guide is hosted at cwiki.apache.org, a Confluence > installation. There are numerous reasons to be dissatisfied with the current > setup, a few of which are: > * Confluence as a product is no longer designed for our use case and our type > of content. > * The writing/editing experience is painful and a barrier for all users, who > need to learn a lot of Confluence-specific syntax just to help out with some > content. > * Non-committers can't really help improve documentation except to point out > problems and hope someone else fixes them. > * We really can't maintain online documentation for different versions. Users > on versions other than the one that hasn't been released yet are only given a > PDF to work with. > I made a proposal in Aug 2016 ([email > link|http://mail-archives.apache.org/mod_mbox/lucene-dev/201608.mbox/%3CCAKrJsP%3DqMLVZhb8xR2C27mfNFfEJ6b%3DPcjxPz4f3fq7G371B_g%40mail.gmail.com%3E]) > to move the Ref Guide from Confluence to a new system that relies on > asciidoc-formatted text files integrated with the Solr source code. > This is an umbrella issue for the sub-tasks and related decisions to make > that proposal a reality. A lot of work has already been done as part of a > proof-of-concept, but there are many things left to do. Some of the items to > be completed include: > * Creation of a branch and moving the early POC work I've done to the project > * Conversion the content and clean up of unavoidable post-conversion issues > * Decisions about location of source files, branching strategy and hosting > for online versions > * Meta-documentation for publication process, beginner tips, etc. (whatever > else people need or want) > * Integration of build processes with the broader project > For reference, a demo of what the new ref guide might look like is currently > online at http://people.apache.org/~ctargett/RefGuidePOC/. > Creation of sub-tasks to follow shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10669) bulk [subquery] result transformer
[
https://issues.apache.org/jira/browse/SOLR-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-10669:
Description:
\[subquery] process docs one by one, it's might be necessary to speedup them
somehow. We can either:
- specialise to -ToParentBlockJoinCollector- (ok it seems dead already
LUCENE-6959), though {{ParentChildrenBlockJoinQuery}} might be just a good
engine for SOLR-10144
- it's probably done like queries macro generator, but I'm afraid it won't be
fast for \{!join}
- or probably just run separate queries in parallel.
Please share, ideas, opinions and usecases.
> bulk [subquery] result transformer
> --
>
> Key: SOLR-10669
> URL: https://issues.apache.org/jira/browse/SOLR-10669
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
>
> \[subquery] process docs one by one, it's might be necessary to speedup them
> somehow. We can either:
> - specialise to -ToParentBlockJoinCollector- (ok it seems dead already
> LUCENE-6959), though {{ParentChildrenBlockJoinQuery}} might be just a good
> engine for SOLR-10144
> - it's probably done like queries macro generator, but I'm afraid it won't
> be fast for \{!join}
> - or probably just run separate queries in parallel.
> Please share, ideas, opinions and usecases.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10669) bulk [subquery] result transformer
Mikhail Khludnev created SOLR-10669: --- Summary: bulk [subquery] result transformer Key: SOLR-10669 URL: https://issues.apache.org/jira/browse/SOLR-10669 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Mikhail Khludnev -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10521) sort by string field of the nested child when searching with {!parent}
[
https://issues.apache.org/jira/browse/SOLR-10521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005427#comment-16005427
]
Mikhail Khludnev commented on SOLR-10521:
-
[~jove4015],
Thanks for feedback.
bq. Would it perhaps make more sense, and be easier on the QueryComponent
I wouldn't touch it ever, too many stuff has been injected into it already.
However, solid approach always seems promising. Perhaps, it can be done in the
dedicated component, and might be considered as a step in SOLR-10144
bq. I feel like it would be easier to modify the "fl" parameter
right, we already have \[child], and \[subquery] (I'm sorry about that). The
problem is that {{sort}}, {{fl}} has completely different scope. Just one case,
we might {{fl}} non-indexed child field, and {{sort}} by non-stored child field
too.
> sort by string field of the nested child when searching with {!parent}
> --
>
> Key: SOLR-10521
> URL: https://issues.apache.org/jira/browse/SOLR-10521
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10521-6x.patch, SOLR-10521.patch, SOLR-10521.patch,
> SOLR-10521.patch, SOLR-10521.patch, SOLR-10521-raw.patch
>
>
> The idea is to integrate Lucene's {{ToParentBlockJoinSortField}}
> The approach to hookup -it- is -a little bit tricky-:
> -{{sort=\{!childfield bjq=$q field=COLOR_s}desc}}-
> {{sort=\childfield(COLOR_s,) desc}}
> the question no.1 wdyt about the syntax?
> internally it creates a function query with valueSource which produces
> {{ToParentBlockJoinSortField}}
> The main challenge is picking Solr field type from
> {{ToParentBlockJoinSortField}}, because as-is it's broken on {{mergeIds}} -
> ByteRefs need to be properly marshaled and unmarshalled by a field type from
> the child scope.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005412#comment-16005412
]
Judith Silverman edited comment on SOLR-6203 at 5/10/17 9:03 PM:
-
Short and sweet.
I see from the diff that we still haven't standardized nomenclature in the
master branch:
"Sort withinGroupSort = rb.getGroupingSpec().getSortWithinGroup();"
I thought you had already split out a patch for that, but I must be thinking of
something else.
Thanks,
Judith
was (Author: judith):
Short and sweet.
I see from the diff that we still haven't standardized nomenclature:
"Sort withinGroupSort = rb.getGroupingSpec().getSortWithinGroup();"
I thought you had already split out a patch for that, but I must be thinking of
something else.
Thanks,
Judith
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005412#comment-16005412
]
Judith Silverman commented on SOLR-6203:
Short and sweet.
I see from the diff that we still haven't standardized nomenclature:
"Sort withinGroupSort = rb.getGroupingSpec().getSortWithinGroup();"
I thought you had already split out a patch for that, but I must be thinking of
something else.
Thanks,
Judith
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7880) Update commons-cli to 1.3.1, fix usage of deprecated classes/methods
[ https://issues.apache.org/jira/browse/SOLR-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005406#comment-16005406 ] Mike Drob commented on SOLR-7880: - [~elyograg] - Do you want to take a look at this again? Commons-cli is up to 1.4, and we've dropped the morphlines contrib, so there patch needs a few updates, but in general I think it's a good idea. > Update commons-cli to 1.3.1, fix usage of deprecated classes/methods > > > Key: SOLR-7880 > URL: https://issues.apache.org/jira/browse/SOLR-7880 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Affects Versions: 5.2.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey > Fix For: 5.5 > > Attachments: SOLR-7880.patch, SOLR-7880.patch, SOLR-7880.patch > > > While looking at SOLR-7847, I noticed that commons-cli was an old version, > and once I upgraded it in the ivy config, found that SolrCLI is using > deprecated classes/methods. > This issue is to complete the upgrade and fix the deprecations. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10667) Solr packaging doesn't include Learn To Rank examples
Grant Ingersoll created SOLR-10667: -- Summary: Solr packaging doesn't include Learn To Rank examples Key: SOLR-10667 URL: https://issues.apache.org/jira/browse/SOLR-10667 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.5 Reporter: Grant Ingersoll I did an ant package on branch_6x and the resulting tarball doesn't have the LTR (learn to rank) examples included (things like the config.json, the model loading python script, etc.) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10668) add a test for sort=childfield(name,$another_bjq) desc
Mikhail Khludnev created SOLR-10668: --- Summary: add a test for sort=childfield(name,$another_bjq) desc Key: SOLR-10668 URL: https://issues.apache.org/jira/browse/SOLR-10668 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Reporter: Mikhail Khludnev Not a big deal, just a test, I should have one somewhere around. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10479) support HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction) options
[
https://issues.apache.org/jira/browse/SOLR-10479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005399#comment-16005399
]
Mikhail Khludnev commented on SOLR-10479:
-
Looked through code. I'd say it's needed for ages. I only worry about whitebox
test. It's great to have sort of full flow test, here it can be negative (set
to zero, no results). Anyway, it's usually too boring to test such loops. I
think it's absolutely good to go.
> support
> HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction)
> options
> -
>
> Key: SOLR-10479
> URL: https://issues.apache.org/jira/browse/SOLR-10479
> Project: Solr
> Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10479.patch, SOLR-10479.patch
>
>
> If a request sends no {{timeAllowed}} threshold (or if it sends a very
> generous threshold) then that request can potentially be retried on 'very
> many' servers in the cloud.
> Via the
> {{HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction)}}
> options the number of servers tried can be restricted via configuration e.g.
> {code}
> class="solr.HttpShardHandlerFactory">
> 2
> 0.50
>
> {code}
> would on a six-replica-and-all-replicas-active collection/shard restrict
> sending to three replicas i.e. max(2, 0.50 x 6) and if the collection/shard
> temporarily becomes
> three-replicas-active-and-three-replicas-recovering-or-down then sending is
> restricted to two replicas i.e. max(2, 0.50 x 3) temporarily.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4000 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4000/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC All tests passed Build Log: [...truncated 4467 lines...] [junit4] JVM J1: stdout was not empty, see: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/backward-codecs/test/temp/junit4-J1-20170510_204058_0456242731457081395094.sysout [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGFPE (0x8) at pc=0x7fff8a2ec143, pid=20546, tid=0x4003 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build 1.8.0_131-b11) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode bsd-amd64 compressed oops) [junit4] # Problematic frame: [junit4] # C [libsystem_kernel.dylib+0x11143] __commpage_gettimeofday+0x43 [junit4] # [junit4] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/backward-codecs/test/J1/hs_err_pid20546.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] <<< JVM J1: EOF [...truncated 2 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre/bin/java -XX:+UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/heapdumps -ea -esa -Dtests.prefix=tests -Dtests.seed=C571A774EC9A9581 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=7.0.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp -Djava.io.tmpdir=./temp -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/backward-codecs/test/temp -Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/clover/db -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=7.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX -Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/backward-codecs/test/J1 -Djunit4.childvm.id=1 -Djunit4.childvm.count=2 -Dtests.leaveTemporary=false -Dtests.filterstacks=true -Dtests.disableHdfs=true -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dfile.encoding=US-ASCII -classpath
[jira] [Updated] (SOLR-10666) Add rank transformation Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10666:
--
Fix Version/s: master (7.0)
> Add rank transformation Stream Evaluator
>
>
> Key: SOLR-10666
> URL: https://issues.apache.org/jira/browse/SOLR-10666
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> The *rank* Stream Evaluator performs a rank transformation on an array of
> numbers.
> Syntax:
> {code}
> a = rank(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10633) Add cosAngle Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005339#comment-16005339
]
Joel Bernstein commented on SOLR-10633:
---
This will require an upgrade to Apache Commons Math 3.6
> Add cosAngle Stream Evaluator
> -
>
> Key: SOLR-10633
> URL: https://issues.apache.org/jira/browse/SOLR-10633
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
>
> This ticket will add a cosAngle Stream Evaluator to calculate the cosine
> angle between two vectors.
> {code}
> a = cosAngle(colA, colB)
> {code}
> The implementation is provided by Apache Math Commons
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 886 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/886/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseParallelGC
1 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.core.TestConfigSetImmutable
Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\tempDir-007:
java.nio.file.DirectoryNotEmptyException:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\tempDir-007
Stack Trace:
java.io.IOException: Could not remove the following files (in the order of
attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\tempDir-007:
java.nio.file.DirectoryNotEmptyException:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\tempDir-007
at __randomizedtesting.SeedInfo.seed([42A93524278304E5]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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 12974 lines...]
[junit4] Suite: org.apache.solr.core.TestConfigSetImmutable
[junit4] 2> Creating dataDir:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\init-core-data-001
[junit4] 2> 2301242 INFO
(SUITE-TestConfigSetImmutable-seed#[42A93524278304E5]-worker) []
o.a.s.SolrTestCaseJ4 Using TrieFields
[junit4] 2> 2301243 INFO
(SUITE-TestConfigSetImmutable-seed#[42A93524278304E5]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via:
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
[junit4] 2> 2301245 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.a.s.SolrTestCaseJ4 ###Starting testAddSchemaFieldsImmutable
[junit4] 2> 2301938 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.a.s.SolrTestCaseJ4 initCore
[junit4] 2> 2301938 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.a.s.SolrTestCaseJ4 initCore end
[junit4] 2> 2301939 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.a.s.SolrTestCaseJ4 Writing core.properties file to
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestConfigSetImmutable_42A93524278304E5-001\tempDir-003\cores\core
[junit4] 2> 2301943 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.e.j.s.Server jetty-9.3.14.v20161028
[junit4] 2> 2301944 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@12b98e9{/solr,null,AVAILABLE}
[junit4] 2> 2301947 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.e.j.s.AbstractConnector Started
ServerConnector@a02568{HTTP/1.1,[http/1.1]}{127.0.0.1:50704}
[junit4] 2> 2301947 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.e.j.s.Server Started @2307610ms
[junit4] 2> 2301947 INFO
(TEST-TestConfigSetImmutable.testAddSchemaFieldsImmutable-seed#[42A93524278304E5])
[] o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=50704,
[jira] [Resolved] (SOLR-2029) Support for Index Time Document Boost in SolrContentHandler
[ https://issues.apache.org/jira/browse/SOLR-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob resolved SOLR-2029. - Resolution: Won't Fix Can't do this anymore since Lucene no longer supports index time boosts. > Support for Index Time Document Boost in SolrContentHandler > --- > > Key: SOLR-2029 > URL: https://issues.apache.org/jira/browse/SOLR-2029 > Project: Solr > Issue Type: Improvement > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 1.4.1 >Reporter: Jayendra Patil > Attachments: SolrContentHandler.patch > > > We are using the extract request handler to index rich content documents with > other metadata. > However, SolrContentHandler does not seem to support the parameter for > applying index time document boost. > Basically, including document.setDocumentBoost(boost). -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 319 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/319/ No tests ran. Build Log: [...truncated 25997 lines...] prepare-release-no-sign: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.04 sec (6.4 MB/sec) [smoker] check changes HTML... [smoker] download lucene-6.6.0-src.tgz... [smoker] 29.6 MB in 0.04 sec (842.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.6.0.tgz... [smoker] 67.6 MB in 0.08 sec (881.7 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-6.6.0.zip... [smoker] 78.0 MB in 0.09 sec (868.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-6.6.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6252 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.6.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6252 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-6.6.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 229 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (22.9 MB/sec) [smoker] check changes HTML... [smoker] download solr-6.6.0-src.tgz... [smoker] 38.4 MB in 0.05 sec (759.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-6.6.0.tgz... [smoker] 138.6 MB in 0.18 sec (749.8 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-6.6.0.zip... [smoker] 139.7 MB in 0.17 sec (818.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-6.6.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-6.6.0.tgz... [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8 [smoker] Creating Solr home directory /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] bin/solr start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [smoker] Started Solr server on port 8983 (pid=19328). Happy searching! [smoker] [smoker]
[jira] [Created] (SOLR-10666) Add rank transformation Stream Evaluator
Joel Bernstein created SOLR-10666:
-
Summary: Add rank transformation Stream Evaluator
Key: SOLR-10666
URL: https://issues.apache.org/jira/browse/SOLR-10666
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein
The *rank* Stream Evaluator performs a rank transformation on an array of
numbers.
Syntax:
{code}
a = rank(colA)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10214) clean up BlockCache metrics
[ https://issues.apache.org/jira/browse/SOLR-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki resolved SOLR-10214. -- Resolution: Fixed Fix Version/s: 6.6 SOLR-1 exposed these stats using the new metrics API. > clean up BlockCache metrics > --- > > Key: SOLR-10214 > URL: https://issues.apache.org/jira/browse/SOLR-10214 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Yonik Seeley > Fix For: 6.6 > > Attachments: SOLR-10214.patch, SOLR-10214.patch > > > Many (most) of the block cache metrics are unused (I assume just inherited > from Blur) and unmaintained (i.e. most will be 0). Currently only the size > and number of evictions is tracked. > We should remove unused stats and start tracking > - number of lookups (or number of misses) > - number of hits > - number of inserts > - number of store failures -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki resolved SOLR-1. -- Resolution: Fixed > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10564) NPE in QueryComponent when RTG
[
https://issues.apache.org/jira/browse/SOLR-10564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-10564:
Attachment: SOLR-10564.patch
Added a very basic level test in
SolrCloudExampleTest::testLoadDocsIntoGettingStartedCollection()
Didn't want to add or subtract much so went on with and added relevant lines.
Requesting someone to kindly review as this is a legit bug.
> NPE in QueryComponent when RTG
> --
>
> Key: SOLR-10564
> URL: https://issues.apache.org/jira/browse/SOLR-10564
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.5
>Reporter: Markus Jelsma
> Fix For: master (7.0)
>
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png,
> screenshot-4.png, screenshot-5.png, SOLR-10564.patch, SOLR-10564.patch
>
>
> The following URL:
> {code}
> /get?fl=queries,prob_*,view_score,feedback_score=
> {code}
> Kindly returns the document.
> This once, however:
> {code}
> /select?qt=/get=queries,prob_*,view_score,feedback_score=
> {code}
> throws:
> {code}
> 2017-04-25 10:23:26.222 ERROR (qtp1873653341-28693) [c:documents s:shard1
> r:core_node3 x:documents_shard1_replica1] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1226)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1077)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:777)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:756)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:428)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2440)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:723)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:529)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:347)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:298)
> {code}
> This is thrown when i do it manually, but the error does not appear when Solr
> issues those same queries under the hood.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10594) Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
[
https://issues.apache.org/jira/browse/SOLR-10594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005269#comment-16005269
]
Mikhail Khludnev commented on SOLR-10594:
-
[~noble.paul]
Could you check the last patch? It should work for two concurrent updates as
follows:
- Zookeeper will order updates, assigns versions and send watcher events in
order.
- Since {{SolrCore.reload()}} is protected with the own synchronised section,
cores are reloaded twice in the same correct order.
Therefore, if we remove reload on GET from {{SolrConfigHandler}} and reloadLock
from it, we will at least correctly handle two concurrent config updates.
That's really enough I suppose, and I'm just not sure about ordering between
the second and the third updates, but it might work too.
The current code is probably exposed to the risk you mentioned, anyway. And
it's not really possible to step back to pre
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commitdiff;h=cbd3b02
since that behaviour caused two core reload on single update and breaks a
plenty of CLI/example tests. It was like this: test applied config change, got
confirmation and stop the instance, while the second redundant reload occurs.
And it seems like it's not easy to make reload safe for shutdown.
Would you mind if I commit the last patch?
> Revise SolrConfigHandler.reloadLock after SolrCloudExampleTest fix
> --
>
> Key: SOLR-10594
> URL: https://issues.apache.org/jira/browse/SOLR-10594
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mikhail Khludnev
> Attachments: SOLR-10594 no reload on config GET.patch,
> SOLR-10594.patch
>
>
> SOLR-10588 fixed {{SolrCloudExampleTest}} by introducing ill dependency
> {{SolrCore --> SolrConfigHandler.reloadLock}} let's think how we can design
> it better. And it's also worth to think about overall flow: core reload is
> triggered by Zk listener and SolrConfigHandler see SOLR-10588
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10000) Instrument Solr caches
[ https://issues.apache.org/jira/browse/SOLR-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005259#comment-16005259 ] ASF subversion and git services commented on SOLR-1: Commit 376d7649ff78c50e2e3f3ed49e78fa2b1d9aad4e in lucene-solr's branch refs/heads/branch_6x from [~ab] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=376d764 ] SOLR-1: Expose cache statistics using metrics API (partial port from master). > Instrument Solr caches > -- > > Key: SOLR-1 > URL: https://issues.apache.org/jira/browse/SOLR-1 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki > Fix For: 6.6 > > Attachments: SOLR-1.patch > > > The stats captured for solr caches should be exposed in the new metrics api > and configured reporters. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-5103: -- Component/s: Plugin system > Plugin Improvements > --- > > Key: SOLR-5103 > URL: https://issues.apache.org/jira/browse/SOLR-5103 > Project: Solr > Issue Type: Improvement > Components: Plugin system >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll > Fix For: 6.0 > > > I think for 5.0, we should make it easier to add plugins by defining a plugin > package, ala a Hadoop Job jar, which is a self--contained archive of a plugin > that can be easily installed (even from the UI!) and configured > programmatically. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10590) Add Cross Correlation Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10590:
--
Fix Version/s: master (7.0)
> Add Cross Correlation Stream Evaluator
> --
>
> Key: SOLR-10590
> URL: https://issues.apache.org/jira/browse/SOLR-10590
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> Now that we have basic correlation (SOLR-10582) implemented we can use it at
> as a basis for cross correlation. Apache commons math apparently does not
> have a cross correlation implementation, so it will need to be implemented.
> The basic approach taken will be to slide columnA along columnB and perform
> the correlation calculation until correlation is either 1.0 or max lag has
> been reached.
> Both *auto-correlation* and *auto-regression* can be built on top the
> cross-collation function.
> If anyone has an alternative more efficient approach or knows of an existing
> implementation that can be plugged in, please let me know.
> Syntax:
> {code}
> let(a=expr,
> b=expr,
> c=col(a, fieldName),
> d=col(b, fieldName),
> tuple(corr=xcorr(c,d,10)))
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10633) Add cosAngle Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10633:
--
Fix Version/s: master (7.0)
> Add cosAngle Stream Evaluator
> -
>
> Key: SOLR-10633
> URL: https://issues.apache.org/jira/browse/SOLR-10633
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
>
> This ticket will add a cosAngle Stream Evaluator to calculate the cosine
> angle between two vectors.
> {code}
> a = cosAngle(colA, colB)
> {code}
> The implementation is provided by Apache Math Commons
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10665) POC for a PF4J based plugin system
Jan Høydahl created SOLR-10665: -- Summary: POC for a PF4J based plugin system Key: SOLR-10665 URL: https://issues.apache.org/jira/browse/SOLR-10665 Project: Solr Issue Type: Sub-task Components: Plugin system Reporter: Jan Høydahl Assignee: Jan Høydahl In SOLR-5103 we have been discussing improvements to Solr plugin system, with ability to bundle a plugin as zip, and easily install from shell or Admin UI. This first sub task aims to create a working POC to demonstrate how PF4J can be used to bring a very simple plugin packaging and installation system to Solr with a minimum of effort. Code speaks louder than words :) The POC effort will be a quite large patch and will be cutting some corners to get the feature in the hands of people who can test and evaluate. If there is consensus to add this to Solr, there will be other sub tasks to split up the elephant into committable chunks. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10660) Add reverse Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10660:
--
Fix Version/s: master (7.0)
> Add reverse Stream Evaluator
>
>
> Key: SOLR-10660
> URL: https://issues.apache.org/jira/browse/SOLR-10660
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
> Syntax:
> {code}
> a = reverse(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10662) Add length Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10662:
--
Fix Version/s: master (7.0)
> Add length Stream Evaluator
>
>
> Key: SOLR-10662
> URL: https://issues.apache.org/jira/browse/SOLR-10662
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> The *length* Stream Evaluator returns the length of an array.
> Syntax:
> {code}
> a = length(colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10661) Add subarray Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10661:
--
Fix Version/s: master (7.0)
> Add subarray Stream Evaluator
> -
>
> Key: SOLR-10661
> URL: https://issues.apache.org/jira/browse/SOLR-10661
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> The subarray Stream Evaluator returns a sub range of an array.
> Syntax:
> {code}
> a = subarray(colA, offset, length)
> {code}
> {code}
> a = subarray(colA, offset)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10663) Add distance Stream Evaluator
[ https://issues.apache.org/jira/browse/SOLR-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-10663: -- Fix Version/s: master (7.0) > Add distance Stream Evaluator > - > > Key: SOLR-10663 > URL: https://issues.apache.org/jira/browse/SOLR-10663 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein > Fix For: master (7.0) > > > The *distance* Stream Evaluator will find the Euclidean distance between two > arrays of numbers. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10664) Add scale Stream Evaluator
[
https://issues.apache.org/jira/browse/SOLR-10664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-10664:
--
Fix Version/s: master (7.0)
> Add scale Stream Evaluator
> --
>
> Key: SOLR-10664
> URL: https://issues.apache.org/jira/browse/SOLR-10664
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
>
> The *scale* Stream Evaluator scales an array by multiplying all the values of
> an array by a number and returns the scaled array.
> Syntax:
> {code}
> a = scale(10, colA)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10664) Add scale Stream Evaluator
Joel Bernstein created SOLR-10664:
-
Summary: Add scale Stream Evaluator
Key: SOLR-10664
URL: https://issues.apache.org/jira/browse/SOLR-10664
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein
The *scale* Stream Evaluator scales an array by multiplying all the values of
an array by a number and returns the scaled array.
Syntax:
{code}
a = scale(10, colA)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10663) Add distance Stream Evaluator
Joel Bernstein created SOLR-10663: - Summary: Add distance Stream Evaluator Key: SOLR-10663 URL: https://issues.apache.org/jira/browse/SOLR-10663 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein The *distance* Stream Evaluator will find the Euclidean distance between two arrays of numbers. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10646) bin/solr should not pass security credentials for start command
[
https://issues.apache.org/jira/browse/SOLR-10646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005140#comment-16005140
]
Jan Høydahl commented on SOLR-10646:
Can anyone confirm whether Kerberos inter-node auth works on Windows? If not
we'll open another JIRA for it.
> bin/solr should not pass security credentials for start command
> ---
>
> Key: SOLR-10646
> URL: https://issues.apache.org/jira/browse/SOLR-10646
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10646.patch
>
>
> Spinoff from SOLR-8440
> It is unnecessary to pass auth parameters as Java options on the cmdline for
> {{bin/solr start}}, as Solr does not need these to start, and it potentially
> exposes passwords in plain text in the UI.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 345 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/345/ 2 tests failed. FAILED: org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv Error Message: java.lang.RuntimeException: Error from server at http://127.0.0.1:38858/solr/test_col: Async exception during distributed update: Error from server at http://127.0.0.1:5/solr/test_col_shard1_replica1: Server Errorrequest: http://127.0.0.1:5/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A38858%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2 Remote error message: Failed synchronous update on shard StdNode: http://127.0.0.1:46265/solr/test_col_shard1_replica2/ update: org.apache.solr.client.solrj.request.UpdateRequest@4f046945 Stack Trace: java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from server at http://127.0.0.1:38858/solr/test_col: Async exception during distributed update: Error from server at http://127.0.0.1:5/solr/test_col_shard1_replica1: Server Error request: http://127.0.0.1:5/solr/test_col_shard1_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A38858%2Fsolr%2Ftest_col_shard2_replica2%2F=javabin=2 Remote error message: Failed synchronous update on shard StdNode: http://127.0.0.1:46265/solr/test_col_shard1_replica2/ update: org.apache.solr.client.solrj.request.UpdateRequest@4f046945 at __randomizedtesting.SeedInfo.seed([14D79D4EC8D64DB9:22C3FF08428B77A8]:0) at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281) at org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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
[jira] [Comment Edited] (SOLR-8776) Support RankQuery in grouping
[
https://issues.apache.org/jira/browse/SOLR-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005060#comment-16005060
]
Diego Ceccarelli edited comment on SOLR-8776 at 5/10/17 5:40 PM:
-
Hi all, I updated the PR (https://github.com/apache/lucene-solr/pull/162),
highlights:
[~romseygeek],[~martijn.v.groningen] now the patch relies on the new grouping
code :) I had to add a new {{protected}} constructor to {{TopGroupsCollector}}
to inject my own {{GroupReducer}}. Could you please take a look at let me know
if it makes sense? also in
[SecondPassGroupingCollector#L54|https://github.com/bloomberg/lucene-solr/blob/c22a9017649406c5673c9b72878ad66a20d9b8d2/lucene/grouping/src/java/org/apache/lucene/search/grouping/SecondPassGroupingCollector.java#L54]
{code:title=SecondPassGroupingCollector.java|borderStyle=solid}
public SecondPassGroupingCollector(GroupSelector groupSelector,
Collection groups, GroupReducer reducer) {
//System.out.println("SP init");
//Do we want to check if groups is null here? instead of checking at line
62?
if (groups.isEmpty()) {
throw new IllegalArgumentException("no groups to collect (groups is
empty)");
}
this.groupSelector = Objects.requireNonNull(groupSelector);
this.groupSelector.setGroups(groups);
this.groups = Objects.requireNonNull(groups);
{code}
I would check if {{groups != null}} before {{groups.isEmpty()}}.
2. I changed the logic to rerank groups and not only documents: for example if
a user ask to rerank the top 100 documents: {{q=greetings=10=\{!rerank
reRankQuery=$rqq reRankDocs=100 reRankWeight=3\}=(hi+hello+hey+hiya)}}:
* the top 100 groups matching {{greeting}} are retrieved;
* top 100 groups are reranked by {{rqq}};
* finally the top 10 reranked groups are returned;
* inside each group documents will be reranked as well.
(it's worth to note that for simplicity, in distribute mode first pass will
retrieve the top 100 groups from all the shards, the federator will compute the
top 100 groups and send them to the shards to get the reranking scores, and
finally the federator will return the top 10)
IMO the patch is now complete and I've working unit tests. Please, can someone
review it?
was (Author: diegoceccarelli):
Hi all, I updated the PR (https://github.com/apache/lucene-solr/pull/162),
highlights:
[~romseygeek],[~martijn.v.groningen] now the patch relies on the new grouping
code :) I had to add a new {{protected}} constructor to {{TopGroupsCollector}}
to inject my own {{GroupReducer}}. Could you please take a look at let me know
if it makes sense? also in
[SecondPassGroupingCollector#L54|https://github.com/bloomberg/lucene-solr/blob/c22a9017649406c5673c9b72878ad66a20d9b8d2/lucene/grouping/src/java/org/apache/lucene/search/grouping/SecondPassGroupingCollector.java#L54]
{code:title=SecondPassGroupingCollector.java|borderStyle=solid}
public SecondPassGroupingCollector(GroupSelector groupSelector,
Collection groups, GroupReducer reducer) {
//System.out.println("SP init");
//Do we want to check if groups is null here? instead of checking at line
62?
if (groups.isEmpty()) {
throw new IllegalArgumentException("no groups to collect (groups is
empty)");
}
this.groupSelector = Objects.requireNonNull(groupSelector);
this.groupSelector.setGroups(groups);
this.groups = Objects.requireNonNull(groups);
{code}
I would check if {{groups != null}} before {{groups.isEmpty()}}.
2. I changed the logic to rerank groups and not only documents: for example if
a user ask to rerank the top 100 documents: {{q=greetings=10=\{!rerank
reRankQuery=$rqq reRankDocs=100 reRankWeight=3\}=(hi+hello+hey+hiya)}}:
* the top 100 groups matching {{greeting}} are retrieved;
* top 100 groups are reranked by {{rqq}};
* finally the top 10 reranked groups are returned;
* inside each group documents will be reranked as well.
(it's worth to note that for simplicity, in distribute mode first pass will
retrieve the top 100 groups from all the shards, the federator will compute the
top 100 groups to the shards to get the reranking scores, and finally the
federator will select the top 10)
IMO the patch is now complete and I've working unit tests. Please, can someone
review it?
> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 6.0
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: 6.0
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
>
[jira] [Created] (SOLR-10662) Add length Stream Evaluator
Joel Bernstein created SOLR-10662:
-
Summary: Add length Stream Evaluator
Key: SOLR-10662
URL: https://issues.apache.org/jira/browse/SOLR-10662
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein
The *length* Stream Evaluator returns the length of an array.
Syntax:
{code}
a = length(colA)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8776) Support RankQuery in grouping
[
https://issues.apache.org/jira/browse/SOLR-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005060#comment-16005060
]
Diego Ceccarelli edited comment on SOLR-8776 at 5/10/17 5:39 PM:
-
Hi all, I updated the PR (https://github.com/apache/lucene-solr/pull/162),
highlights:
[~romseygeek],[~martijn.v.groningen] now the patch relies on the new grouping
code :) I had to add a new {{protected}} constructor to {{TopGroupsCollector}}
to inject my own {{GroupReducer}}. Could you please take a look at let me know
if it makes sense? also in
[SecondPassGroupingCollector#L54|https://github.com/bloomberg/lucene-solr/blob/c22a9017649406c5673c9b72878ad66a20d9b8d2/lucene/grouping/src/java/org/apache/lucene/search/grouping/SecondPassGroupingCollector.java#L54]
{code:title=SecondPassGroupingCollector.java|borderStyle=solid}
public SecondPassGroupingCollector(GroupSelector groupSelector,
Collection groups, GroupReducer reducer) {
//System.out.println("SP init");
//Do we want to check if groups is null here? instead of checking at line
62?
if (groups.isEmpty()) {
throw new IllegalArgumentException("no groups to collect (groups is
empty)");
}
this.groupSelector = Objects.requireNonNull(groupSelector);
this.groupSelector.setGroups(groups);
this.groups = Objects.requireNonNull(groups);
{code}
I would check if {{groups != null}} before {{groups.isEmpty()}}.
2. I changed the logic to rerank groups and not only documents: for example if
a user ask to rerank the top 100 documents: {{q=greetings=10=\{!rerank
reRankQuery=$rqq reRankDocs=100 reRankWeight=3\}=(hi+hello+hey+hiya)}}:
* the top 100 groups matching {{greeting}} are retrieved;
* top 100 groups are reranked by {{rqq}};
* finally the top 10 reranked groups are returned;
* inside each group documents will be reranked as well.
(it's worth to note that for simplicity, in distribute mode first pass will
retrieve the top 100 groups from all the shards, the federator will compute the
top 100 groups to the shards to get the reranking scores, and finally the
federator will select the top 10)
IMO the patch is now complete and I've working unit tests. Please, can someone
review it?
was (Author: diegoceccarelli):
Hi all, I updated the PR (https://github.com/apache/lucene-solr/pull/162),
highlights:
[~romseygeek],[~martijn.v.groningen] now the patch relies on the new grouping
code :) I had to add a new {{protected}} constructor to {{TopGroupsCollector}}
to inject my own {{GroupReducer}}. Could you please take a look at let me know
if it makes sense? also in
[SecondPassGroupingCollector#L54|https://github.com/bloomberg/lucene-solr/blob/c22a9017649406c5673c9b72878ad66a20d9b8d2/lucene/grouping/src/java/org/apache/lucene/search/grouping/SecondPassGroupingCollector.java#L54]
{code:title=SecondPassGroupingCollector.java|borderStyle=solid}
public SecondPassGroupingCollector(GroupSelector groupSelector,
Collection groups, GroupReducer reducer) {
//System.out.println("SP init");
//Do we want to check if groups is null here? instead of checking at line
62?
if (groups.isEmpty()) {
throw new IllegalArgumentException("no groups to collect (groups is
empty)");
}
this.groupSelector = Objects.requireNonNull(groupSelector);
this.groupSelector.setGroups(groups);
this.groups = Objects.requireNonNull(groups);
{code}
I would check if {{groups != null}} before {{groups.isEmpty()}}.
2. I changed the logic of reranking to rerank groups, for example if a user
ask to rerank the top 100 documents: {{q=greetings=10=\{!rerank
reRankQuery=$rqq reRankDocs=100 reRankWeight=3\}=(hi+hello+hey+hiya)}}:
* the top 100 groups matching {{greeting}} are retrieved;
* top 100 groups are reranked by {{rqq}};
* finally the top 10 reranked groups are returned;
* inside each group documents will be reranked as well.
IMO the patch is now complete and I've working unit tests. Please, can someone
review my patch?
> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 6.0
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: 6.0
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together
> (see also [3]). In some situations Grouping can be replaced by Collapse and
> Expand Results
[jira] [Created] (SOLR-10661) Add subarray Stream Evaluator
Joel Bernstein created SOLR-10661:
-
Summary: Add subarray Stream Evaluator
Key: SOLR-10661
URL: https://issues.apache.org/jira/browse/SOLR-10661
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein
The subarray Stream Evaluator returns a sub range of an array.
Syntax:
{code}
a = subarray(colA, offset, length)
{code}
{code}
a = subarray(colA, offset)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6368) Admin UI should include a query parser playground
[ https://issues.apache.org/jira/browse/SOLR-6368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-6368: -- Component/s: Admin UI > Admin UI should include a query parser playground > - > > Key: SOLR-6368 > URL: https://issues.apache.org/jira/browse/SOLR-6368 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: Varun Thacker >Priority: Minor > > When I type in a query it gets parsed differently at search time ( > debug=query) than what I sees in the Analysis tab. > I will happen when my queries are phrase queries, and has query time > shingles/ multi word synonyms. The reason being the Analyzer sees it as 1 > token when doing a regular search VS multiple tokens when seeing it via the > Analysis -> Field Value ( Query ) text box > There could be two options - > 1. In Admin UI -> Analysis -> Field Value ( Query ) text box we should also > provide another text box for 'defType'. And the query gets parsed via the > QParser specified. Briefly looking at FieldAnalysisRequestHandler it's not > obvious to me if this is possible though. > 2. Add another tab in the Admin UI which shows how a query gets parsed given > the QueryParser -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10660) Add reverse Stream Evaluator
Joel Bernstein created SOLR-10660:
-
Summary: Add reverse Stream Evaluator
Key: SOLR-10660
URL: https://issues.apache.org/jira/browse/SOLR-10660
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein
The *reverse* Stream Evaluator reverses the sort order of an array of numbers.
Syntax:
{code}
a = reverse(colA)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9510) child level facet exclusions
[
https://issues.apache.org/jira/browse/SOLR-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dr Oleg Savrasov updated SOLR-9510:
---
Attachment: SOLR_9510.patch
I created the previous patch using IDEA tool. Normally it works, but this time
it looks like it has issues with patch format. Will you try this one, please?
> child level facet exclusions
>
>
> Key: SOLR-9510
> URL: https://issues.apache.org/jira/browse/SOLR-9510
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, faceting, query parsers
>Reporter: Mikhail Khludnev
> Attachments: SOLR_9510.patch, SOLR_9510.patch
>
>
> h2. Challenge
> * Since SOLR-5743 achieved block join child level facets with counts roll-up
> to parents, there is a demand for filter exclusions.
> h2. Context
> * Then, it's worth to consider JSON Facets as an engine for this
> functionality rather than support a separate component.
> * During a discussion in SOLR-8998 [a solution for block join with child
> level
> exclusion|https://issues.apache.org/jira/browse/SOLR-8998?focusedCommentId=15487095=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15487095]
> has been found.
>
> h2. Proposal
> It's proposed to provide a bit of syntax sugar to make it user friendly,
> believe it or not.
> h2. List of improvements
> * introducing a local parameter {{filters}} for {{\{!parent}} query parser
> referring to _multiple_ filters queries via parameter name: {{\{!parent
> filters=$child.fq ..}..=color:Red=size:XL}}
> these _filters_ are intersected with a child query supplied as a subordinate
> clause.
> * introducing {{\{!filters params=$child.fq excludeTags=color
> v=$subq}=text:word={!tag=color}color:Red=size:XL}} it
> intersects a subordinate clause (here it's {{subq}} param, and the trick is
> to refer to the same query from {{\{!parent}}}), with multiple filters
> supplied via parameter name {{params=$child.fq}}, it also supports
> {{excludeTags}}.
> h2. Notes
> Regarding the latter parser, the alternative approach might be to move into
> {{domain:\{..}}} instruction of json facet. From the implementation
> perspective, it's desired to optimize with bitset processing, however I
> suppose it's might be deferred until some initial level of maturity.
> h2. Example
> {code}
> q={!parent which=type_s:book filters=$child.fq
> v=$childquery}=comment_t:good={!tag=author}author_s:yonik={!tag=stars}stars_i:(5
> 3)=json=on={
> comments_for_author:{
> type:query,
> q:"{!filters params=$child.fq excludeTags=author v=$childquery}",
> "//note":"author filter is excluded",
> domain:{
> blockChildren:"type_s:book",
> "//":"applying filters here might be more promising"
>}, facet:{
>authors:{
> type:terms,
> field:author_s,
> facet: {
> in_books: "unique(_root_)"
> }
> }
>}
> } ,
> comments_for_stars:{
> type:query,
> q:"{!filters params=$child.fq excludeTags=stars v=$childquery}",
> "//note":"stars_i filter is excluded",
> domain:{
> blockChildren:"type_s:book"
>}, facet:{
>stars:{
> type:terms,
> field:stars_i,
> facet: {
> in_books: "unique(_root_)"
> }
> }
> }
> }
> }
> {code}
> Votes? Opinions?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8776) Support RankQuery in grouping
[
https://issues.apache.org/jira/browse/SOLR-8776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005060#comment-16005060
]
Diego Ceccarelli commented on SOLR-8776:
Hi all, I updated the PR (https://github.com/apache/lucene-solr/pull/162),
highlights:
[~romseygeek],[~martijn.v.groningen] now the patch relies on the new grouping
code :) I had to add a new {{protected}} constructor to {{TopGroupsCollector}}
to inject my own {{GroupReducer}}. Could you please take a look at let me know
if it makes sense? also in
[SecondPassGroupingCollector#L54|https://github.com/bloomberg/lucene-solr/blob/c22a9017649406c5673c9b72878ad66a20d9b8d2/lucene/grouping/src/java/org/apache/lucene/search/grouping/SecondPassGroupingCollector.java#L54]
{code:title=SecondPassGroupingCollector.java|borderStyle=solid}
public SecondPassGroupingCollector(GroupSelector groupSelector,
Collection groups, GroupReducer reducer) {
//System.out.println("SP init");
//Do we want to check if groups is null here? instead of checking at line
62?
if (groups.isEmpty()) {
throw new IllegalArgumentException("no groups to collect (groups is
empty)");
}
this.groupSelector = Objects.requireNonNull(groupSelector);
this.groupSelector.setGroups(groups);
this.groups = Objects.requireNonNull(groups);
{code}
I would check if {{groups != null}} before {{groups.isEmpty()}}.
2. I changed the logic of reranking to rerank groups, for example if a user
ask to rerank the top 100 documents: {{q=greetings=10=\{!rerank
reRankQuery=$rqq reRankDocs=100 reRankWeight=3\}=(hi+hello+hey+hiya)}}:
* the top 100 groups matching {{greeting}} are retrieved;
* top 100 groups are reranked by {{rqq}};
* finally the top 10 reranked groups are returned;
* inside each group documents will be reranked as well.
IMO the patch is now complete and I've working unit tests. Please, can someone
review my patch?
> Support RankQuery in grouping
> -
>
> Key: SOLR-8776
> URL: https://issues.apache.org/jira/browse/SOLR-8776
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 6.0
>Reporter: Diego Ceccarelli
>Priority: Minor
> Fix For: 6.0
>
> Attachments: 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch,
> 0001-SOLR-8776-Support-RankQuery-in-grouping.patch
>
>
> Currently it is not possible to use RankQuery [1] and Grouping [2] together
> (see also [3]). In some situations Grouping can be replaced by Collapse and
> Expand Results [4] (that supports reranking), but i) collapse cannot
> guarantee that at least a minimum number of groups will be returned for a
> query, and ii) in the Solr Cloud setting you will have constraints on how to
> partition the documents among the shards.
> I'm going to start working on supporting RankQuery in grouping. I'll start
> attaching a patch with a test that fails because grouping does not support
> the rank query and then I'll try to fix the problem, starting from the non
> distributed setting (GroupingSearch).
> My feeling is that since grouping is mostly performed by Lucene, RankQuery
> should be refactored and moved (or partially moved) there.
> Any feedback is welcome.
> [1] https://cwiki.apache.org/confluence/display/solr/RankQuery+API
> [2] https://cwiki.apache.org/confluence/display/solr/Result+Grouping
> [3]
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201507.mbox/%3ccahm-lpuvspest-sw63_8a6gt-wor6ds_t_nb2rope93e4+s...@mail.gmail.com%3E
> [4]
> https://cwiki.apache.org/confluence/display/solr/Collapse+and+Expand+Results
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005038#comment-16005038
]
Christine Poerschke commented on SOLR-6203:
---
Thanks Judith! Returning to this, the {{ss}} vs. {{groupSortSpec}} refactor
thing just tripped me up again, so have gone and split it out to SOLR-10659 for
clarity. Hope that makes sense.
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nate Dire
>Assignee: Christine Poerschke
> Attachments: README, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch, SOLR-6203.patch,
> SOLR-6203.patch, SOLR-6203.patch, SOLR-6203-unittest.patch,
> SOLR-6203-unittest.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10659) remove ResponseBuilder.getSortSpec use in SearchGroupShardResponseProcessor
[ https://issues.apache.org/jira/browse/SOLR-10659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-10659: --- Attachment: SOLR-10659.patch > remove ResponseBuilder.getSortSpec use in SearchGroupShardResponseProcessor > --- > > Key: SOLR-10659 > URL: https://issues.apache.org/jira/browse/SOLR-10659 > Project: Solr > Issue Type: Task >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-10659.patch > > > For clarity splitting this short but very subtle refactor out from the > SOLR-6203 bug fix effort. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10659) remove ResponseBuilder.getSortSpec use in SearchGroupShardResponseProcessor
Christine Poerschke created SOLR-10659: -- Summary: remove ResponseBuilder.getSortSpec use in SearchGroupShardResponseProcessor Key: SOLR-10659 URL: https://issues.apache.org/jira/browse/SOLR-10659 Project: Solr Issue Type: Task Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor Attachments: SOLR-10659.patch For clarity splitting this short but very subtle refactor out from the SOLR-6203 bug fix effort. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10656) Collection re-registering after deletion
[ https://issues.apache.org/jira/browse/SOLR-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-10656. --- Resolution: Not A Problem > Collection re-registering after deletion > > > Key: SOLR-10656 > URL: https://issues.apache.org/jira/browse/SOLR-10656 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.5.1 > Environment: Linux / Ubuntu >Reporter: Victor Igumnov > Labels: bug > > Taking a single node down in a multi-node solr cloud cluster and then issuing > a delete collection command will succeed with a HTTP 200. The collection will > be removed from ZK and the data files removed from the active nodes. Once the > downed node is brought back into the cluster the deleted collection > re-registers it self with zookeeper and is actively queryable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10656) Collection re-registering after deletion
[ https://issues.apache.org/jira/browse/SOLR-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16005007#comment-16005007 ] Victor Igumnov commented on SOLR-10656: --- Looks like Solr 6.5.x defaults to true for the legacyCloud option if not defined. Thank you for the hint on tracking it down. https://github.com/apache/lucene-solr/blob/branch_6_5/solr/core/src/java/org/apache/solr/cloud/Overseer.java#L760 This issue can be closed, just unexpected behavior. > Collection re-registering after deletion > > > Key: SOLR-10656 > URL: https://issues.apache.org/jira/browse/SOLR-10656 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 6.5.1 > Environment: Linux / Ubuntu >Reporter: Victor Igumnov > Labels: bug > > Taking a single node down in a multi-node solr cloud cluster and then issuing > a delete collection command will succeed with a HTTP 200. The collection will > be removed from ZK and the data files removed from the active nodes. Once the > downed node is brought back into the cluster the deleted collection > re-registers it self with zookeeper and is actively queryable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10643) Throttling strategy for triggers and policy executions
[ https://issues.apache.org/jira/browse/SOLR-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-10643: - Attachment: SOLR-10643.patch This patch addresses problem #2. Changes: # Introduced an action throttle with a default wait of 5 seconds -- it'd be nice to configure this wait time but currently there is no way of setting such properties. I'll open another issue for a set-properties autoscaling api. # Added TriggerIntegrationTest.testTriggerThrottling for testing throttling # Added NodeLostTriggerTest.testListenerAcceptance for testing that state is maintained if listener is not ready > Throttling strategy for triggers and policy executions > -- > > Key: SOLR-10643 > URL: https://issues.apache.org/jira/browse/SOLR-10643 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Labels: autoscaling > Fix For: master (7.0) > > Attachments: SOLR-10643.patch, SOLR-10643.patch > > > We must ensure that triggers and policy executions: > # Do not step on each other's toes by concurrent executions > # Do not fire/execute too frequently > # Do not stack up -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 826 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/826/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor131.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1079) at org.apache.solr.core.SolrCore.(SolrCore.java:943) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:917) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:555) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.update.HdfsTransactionLog at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130) at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:153) at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:110) at org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108) at sun.reflect.GeneratedConstructorAccessor131.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:760) at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:822) at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1079) at org.apache.solr.core.SolrCore.(SolrCore.java:943) at org.apache.solr.core.SolrCore.(SolrCore.java:830) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:917) at org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:555) at com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) at __randomizedtesting.SeedInfo.seed([1E1E49C4042C73EA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:302) at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870) at
[jira] [Commented] (SOLR-9527) Solr RESTORE api doesn't distribute the replicas uniformly
[ https://issues.apache.org/jira/browse/SOLR-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004912#comment-16004912 ] ASF subversion and git services commented on SOLR-9527: --- Commit 201e2125f4db3b4fd1ecfe5ddef5471f305fc1f0 in lucene-solr's branch refs/heads/branch_6_6 from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=201e212 ] SOLR-9527: Improve distribution of replicas when restoring a collection > Solr RESTORE api doesn't distribute the replicas uniformly > --- > > Key: SOLR-9527 > URL: https://issues.apache.org/jira/browse/SOLR-9527 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.1 >Reporter: Hrishikesh Gadre >Assignee: Varun Thacker > Fix For: 6.6, master (7.0) > > Attachments: SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, > SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, Solr 9527.pdf > > > Please refer to this email thread for details, > http://lucene.markmail.org/message/ycun4x5nx7lwj5sk?q=solr+list:org%2Eapache%2Elucene%2Esolr-user+order:date-backward=1 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10636) SolrJmxReporterTest.testReloadCore() failure
[
https://issues.apache.org/jira/browse/SOLR-10636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki resolved SOLR-10636.
--
Resolution: Fixed
Fix Version/s: master (7.0)
> SolrJmxReporterTest.testReloadCore() failure
>
>
> Key: SOLR-10636
> URL: https://issues.apache.org/jira/browse/SOLR-10636
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
> Fix For: master (7.0)
>
>
> Policeman Jenkins found a reproducing master seed
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19576/]:
> {noformat}
> Checking out Revision 0ed39b2774c1c39faf5a6c4cfc9cb68540b16f11
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testReloadCore
> -Dtests.seed=99ADA8D4144B3862 -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=lg-UG -Dtests.timezone=Asia/Kuala_Lumpur -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.51s J2 | SolrJmxReporterTest.testReloadCore <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<12> but
> was:<14>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([99ADA8D4144B3862:13E9B07D64A4C2CE]:0)
>[junit4]> at
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testReloadCore(SolrJmxReporterTest.java:159)
>[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:563)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=733, maxMBSortInHeap=5.806746063323367,
> sim=RandomSimilarity(queryNorm=false): {}, locale=lg-UG,
> timezone=Asia/Kuala_Lumpur
>[junit4] 2> NOTE: Linux 4.4.0-75-generic i386/Oracle Corporation 9-ea
> (32-bit)/cpus=12,threads=1,free=107155920,total=447479808
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10636) SolrJmxReporterTest.testReloadCore() failure
[
https://issues.apache.org/jira/browse/SOLR-10636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004882#comment-16004882
]
ASF subversion and git services commented on SOLR-10636:
Commit 69783f6403b01c4358578344801c5133ce0b812d in lucene-solr's branch
refs/heads/master from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=69783f6 ]
SOLR-10636 Increase randomness of metric names to avoid conflicts with
non-test scopes.
> SolrJmxReporterTest.testReloadCore() failure
>
>
> Key: SOLR-10636
> URL: https://issues.apache.org/jira/browse/SOLR-10636
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki
>
> Policeman Jenkins found a reproducing master seed
> [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19576/]:
> {noformat}
> Checking out Revision 0ed39b2774c1c39faf5a6c4cfc9cb68540b16f11
> (refs/remotes/origin/master)
> [...]
>[junit4] 2> NOTE: reproduce with: ant test
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testReloadCore
> -Dtests.seed=99ADA8D4144B3862 -Dtests.multiplier=3 -Dtests.slow=true
> -Dtests.locale=lg-UG -Dtests.timezone=Asia/Kuala_Lumpur -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.51s J2 | SolrJmxReporterTest.testReloadCore <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<12> but
> was:<14>
>[junit4]> at
> __randomizedtesting.SeedInfo.seed([99ADA8D4144B3862:13E9B07D64A4C2CE]:0)
>[junit4]> at
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testReloadCore(SolrJmxReporterTest.java:159)
>[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:563)
> [...]
>[junit4] 2> NOTE: test params are: codec=Asserting(Lucene70): {},
> docValues:{}, maxPointsInLeafNode=733, maxMBSortInHeap=5.806746063323367,
> sim=RandomSimilarity(queryNorm=false): {}, locale=lg-UG,
> timezone=Asia/Kuala_Lumpur
>[junit4] 2> NOTE: Linux 4.4.0-75-generic i386/Oracle Corporation 9-ea
> (32-bit)/cpus=12,threads=1,free=107155920,total=447479808
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10295) Decide online location for Ref Guide HTML pages
[
https://issues.apache.org/jira/browse/SOLR-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004878#comment-16004878
]
Cassandra Targett commented on SOLR-10295:
--
I think this issue has been discussed enough, and add-on issues filed where it
makes sense.
I'll close this in the next day or so if there aren't any other thoughts on
this for now.
> Decide online location for Ref Guide HTML pages
> ---
>
> Key: SOLR-10295
> URL: https://issues.apache.org/jira/browse/SOLR-10295
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>
> One of the biggest decisions we need to make is where to put the new Solr Ref
> Guide. Confluence at least had the whole web-hosting bits figured out; we
> have to figure that out on our own.
> An obvious (maybe only to me) choice is to integrate the Ref Guide with the
> Solr Website. However, due to the size of the Solr Ref Guide (nearly 200
> pages), I believe trying to publish it solely with existing CMS tools will
> create problems similar to those described in the Lucene ReleaseTodo when it
> comes to publishing the Lucene/Solr javadocs (see
> https://wiki.apache.org/lucene-java/ReleaseTodo#Website_.2B-.3D_javadocs).
> A solution exists already, and it's what is done for the javadocs. From the
> above link:
> {quote}
> The solution: skip committing javadocs to the source tree, then staging, then
> publishing, and instead commit javadocs directly to the production tree.
> Ordinarily this would be problematic, because the CMS wants to keep the
> production tree in sync with the staging tree, so anything it finds in the
> production tree that's not in the staging tree gets nuked. However, the CMS
> has a built-in mechanism to allow exceptions to the
> keep-production-in-sync-with-staging rule: extpaths.txt.
> {quote}
> This solution (for those who don't know already) is to provide a static text
> file (extpaths.txt) that includes the javadoc paths that should be presented
> in production, but which won't exist in CMS staging environments. This way,
> we can publish HTML files directly to production and they will be preserved
> when the staging-production trees are synced.
> The rest of the process would be quite similar to what is documented in the
> ReleaseTodo in sections following the link above - use SVN to update the CMS
> production site and update extpaths.txt properly. We'd do this in the
> {{solr}} section of the CMS obviously, and not the {{lucene}} section.
> A drawback to this approach is that we won't have a staging area to view the
> Guide before publication. Files would be generated and go to production
> directly. We may want to put a process in place to give some additional
> confidence that things look right first (someone's people.apache.org
> directory? a pre-pub validation script that tests...something...?), and agree
> on what we'd be voting on when a vote to release comes up. However, the CMS
> is pretty much the only option that I can think of...other ideas are welcome
> if they might work.
> We also need to agree on URL paths that make sense, considering we'll have a
> new "site" for each major release - something like
> {{http://lucene.apache.org/solr/ref-guide/6_1}} might work? Other thoughts
> are welcome on this point also.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10294) Decide branching strategy for Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-10294. -- Resolution: Fixed > Decide branching strategy for Ref Guide > --- > > Key: SOLR-10294 > URL: https://issues.apache.org/jira/browse/SOLR-10294 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett > > Since one of the reasons to move off Confluence is to provide online docs for > specific versions of Solr, we should agree up front how we'll manage working > with the branches. > There are two general proposals on the table so far: > # Make all changes in 'master' (trunk) and backport to branches for > releasing the content. We'd need to merge "backward" into upcoming > release branch. > # Make all changes in branch_6x (or branch_7x, etc.) and only move > things to master when they are only applicable to unreleased next > major version. We'd merge 6x "forward" when it's time for next major > version. > Some discussion on this started in the mailing list, so I'll copy the > feedback received so far on this as comments to this issue. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10297) Resolve Ref Guide build errors
[
https://issues.apache.org/jira/browse/SOLR-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004873#comment-16004873
]
Cassandra Targett commented on SOLR-10297:
--
The cause of these errors is from the fact we're using {{:doctype: book}} (line
146 in build.xml).
We could experiment with {{:doctype: article}}, which is the default and
doesn't have these rules. I did this before, and now that I'm thinking of it I
think it causes some really unfortunate page breaks that we can't control.
I dislike the idea of adding an extra header to very short pages just to avoid
an error that doesn't actually hurt anything. Yes, it's an error according to
the rules of the converter, but it's not a failure, and some future content
reworking may make them go away.
> Resolve Ref Guide build errors
> --
>
> Key: SOLR-10297
> URL: https://issues.apache.org/jira/browse/SOLR-10297
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
> Attachments: build-errors-HTML-20170315.txt,
> build-errors-PDF-20170315.txt
>
>
> The asciidoctor tools used to build the HTML and PDF versions of the Ref
> Guide validate the pages during the build and throw errors during the build
> when there are problems. Usually these problems are not fatal, but they do
> indicate inconsistencies in the content that should be resolved. Almost all
> of the time they are problems with inconsistent heading levels - a h5 follows
> a h2 for example.
> These errors should be cleaned up so we only see errors we should worry about
> going forward.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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 (32bit/jdk-9-ea+168) - Build # 19601 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19601/ Java: 32bit/jdk-9-ea+168 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats Error Message: Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1 Stack Trace: java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1 at __randomizedtesting.SeedInfo.seed([12F4B0C2BD89A2E0:DD6AD5FB3278CABF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:143) at org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:77) 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:563) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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) Build Log: [...truncated 1693 lines...] [junit4] JVM J2: stderr was not empty,
[jira] [Commented] (SOLR-4787) Join Contrib
[
https://issues.apache.org/jira/browse/SOLR-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004864#comment-16004864
]
Erick Erickson commented on SOLR-4787:
--
Samuel:
In a word "no". Patches are built against whatever version of the source
happens to be current when developing them. Until they're committed, no jars
are built or archived. Once committed, the JIRA will be closed and marked
"fixed". This particular source patch is over 2 years old and hasn't been kept
up to date for whatever reason.
Your choices are
1> check out code from that time frame
2> update the patch to build against the current code base.
If you do the latter, please contribute the patch back!
> Join Contrib
>
>
> Key: SOLR-4787
> URL: https://issues.apache.org/jira/browse/SOLR-4787
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.2.1
>Reporter: Joel Bernstein
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-4787-deadlock-fix.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch, SOLR-4787.patch,
> SOLR-4787.patch, SOLR-4787.patch, SOLR-4787-pjoin-long-keys.patch,
> SOLR-4787-with-testcase-fix.patch,
> SOLR-4797-hjoin-multivaluekeys-nestedJoins.patch,
> SOLR-4797-hjoin-multivaluekeys-trunk.patch
>
>
> This contrib provides a place where different join implementations can be
> contributed to Solr. This contrib currently includes 3 join implementations.
> The initial patch was generated from the Solr 4.3 tag. Because of changes in
> the FieldCache API this patch will only build with Solr 4.2 or above.
> *HashSetJoinQParserPlugin aka hjoin*
> The hjoin provides a join implementation that filters results in one core
> based on the results of a search in another core. This is similar in
> functionality to the JoinQParserPlugin but the implementation differs in a
> couple of important ways.
> The first way is that the hjoin is designed to work with int and long join
> keys only. So, in order to use hjoin, int or long join keys must be included
> in both the to and from core.
> The second difference is that the hjoin builds memory structures that are
> used to quickly connect the join keys. So, the hjoin will need more memory
> then the JoinQParserPlugin to perform the join.
> The main advantage of the hjoin is that it can scale to join millions of keys
> between cores and provide sub-second response time. The hjoin should work
> well with up to two million results from the fromIndex and tens of millions
> of results from the main query.
> The hjoin supports the following features:
> 1) Both lucene query and PostFilter implementations. A *"cost"* > 99 will
> turn on the PostFilter. The PostFilter will typically outperform the Lucene
> query when the main query results have been narrowed down.
> 2) With the lucene query implementation there is an option to build the
> filter with threads. This can greatly improve the performance of the query if
> the main query index is very large. The "threads" parameter turns on
> threading. For example *threads=6* will use 6 threads to build the filter.
> This will setup a fixed threadpool with six threads to handle all hjoin
> requests. Once the threadpool is created the hjoin will always use it to
> build the filter. Threading does not come into play with the PostFilter.
> 3) The *size* local parameter can be used to set the initial size of the
> hashset used to perform the join. If this is set above the number of results
> from the fromIndex then the you can avoid hashset resizing which improves
> performance.
> 4) Nested filter queries. The local parameter "fq" can be used to nest a
> filter query within the join. The nested fq will filter the results of the
> join query. This can point to another join to support nested joins.
> 5) Full caching support for the lucene query implementation. The filterCache
> and queryResultCache should work properly even with deep nesting of joins.
> Only the queryResultCache comes into play with the PostFilter implementation
> because PostFilters are not cacheable in the filterCache.
> The syntax of the hjoin is similar to the JoinQParserPlugin except that the
> plugin is referenced by the string "hjoin" rather then "join".
> fq=\{!hjoin fromIndex=collection2 from=id_i to=id_i threads=6
> fq=$qq\}user:customer1=group:5
> The example filter query above will search the fromIndex (collection2) for
> "user:customer1" applying the local fq parameter to filter the results. The
> lucene filter query will be built using 6 threads. This query will generate a
> list of values from the "from" field that will be used to filter the main
>
[jira] [Updated] (SOLR-10419) All collection APIs should use the new Policy framework for replica placement
[ https://issues.apache.org/jira/browse/SOLR-10419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-10419: - Summary: All collection APIs should use the new Policy framework for replica placement (was: Collection CREATE command to use the new Policy syntax for replica placement) > All collection APIs should use the new Policy framework for replica placement > - > > Key: SOLR-10419 > URL: https://issues.apache.org/jira/browse/SOLR-10419 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10506) Possible memory leak upon collection reload
[
https://issues.apache.org/jira/browse/SOLR-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004852#comment-16004852
]
Jörg Rathlev commented on SOLR-10506:
-
Oh, right, good point! So, the SchemaWatcher needs to keep a strong reference
to the ZkIndexSchemaReader but then that should be cleaned up in the SolrCore's
onClose hook. I'll try to run another test with a memory profiler in the next
couple of days to see if that solves the issue.
> Possible memory leak upon collection reload
> ---
>
> Key: SOLR-10506
> URL: https://issues.apache.org/jira/browse/SOLR-10506
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.5
>Reporter: Torsten Bøgh Köster
> Attachments: solr_collection_reload_13_cores.png,
> solr_gc_path_via_zk_WatchManager.png
>
>
> Upon manual Solr Collection reloading, references to the closed {{SolrCore}}
> are not fully removed by the garbage collector as a strong reference to the
> {{ZkIndexSchemaReader}} is held in a ZooKeeper {{Watcher}} that watches for
> schema changes.
> In our case, this leads to a massive memory leak as managed resources are
> still referenced by the closed {{SolrCore}}. Our Solr cloud environment
> utilizes rather large managed resources (synonyms, stopwords). To reproduce,
> we fired out environment up and reloaded the collection 13 times. As a result
> we fully exhausted our heap. A closer look with the Yourkit profiler revealed
> 13 {{SolrCore}} instances, still holding strong references to the garbage
> collection root (see screenshot 1).
> Each {{SolrCore}} instance holds a single path with strong references to the
> gc root via a `Watcher` in `ZkIndexSchemaReader` (see screenshot 2). The
> {{ZkIndexSchemaReader}} registers a close hook in the {{SolrCore}} but the
> Zookeeper is not removed upon core close.
> We supplied a Github Pull Request
> (https://github.com/apache/lucene-solr/pull/197) that extracts the zookeeper
> `Watcher` as a static inner class. To eliminate the memory leak, the schema
> reader is held inside a `WeakReference` and the reference is explicitly
> removed on core close.
> Initially I wanted to supply a test case but unfortunately did not find a
> good starting point ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10506) Possible memory leak upon collection reload
[
https://issues.apache.org/jira/browse/SOLR-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004822#comment-16004822
]
Mike Drob commented on SOLR-10506:
--
Well, the stopWatching method is only called when a core is closed. Maybe it
should be called in postClose to be safe? I'm not familiar enough with the
internals of a SolrCore lifecycle to judge this.
The implementation details of it being a weak reference mean that it can return
null without stopWatching/clear ever being called. If the GC decides that it
needs memory then your schema reader will suddenly be gone. So an open core
using lots of memory will eventually lose the reference before it should.
> Possible memory leak upon collection reload
> ---
>
> Key: SOLR-10506
> URL: https://issues.apache.org/jira/browse/SOLR-10506
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Server
>Affects Versions: 6.5
>Reporter: Torsten Bøgh Köster
> Attachments: solr_collection_reload_13_cores.png,
> solr_gc_path_via_zk_WatchManager.png
>
>
> Upon manual Solr Collection reloading, references to the closed {{SolrCore}}
> are not fully removed by the garbage collector as a strong reference to the
> {{ZkIndexSchemaReader}} is held in a ZooKeeper {{Watcher}} that watches for
> schema changes.
> In our case, this leads to a massive memory leak as managed resources are
> still referenced by the closed {{SolrCore}}. Our Solr cloud environment
> utilizes rather large managed resources (synonyms, stopwords). To reproduce,
> we fired out environment up and reloaded the collection 13 times. As a result
> we fully exhausted our heap. A closer look with the Yourkit profiler revealed
> 13 {{SolrCore}} instances, still holding strong references to the garbage
> collection root (see screenshot 1).
> Each {{SolrCore}} instance holds a single path with strong references to the
> gc root via a `Watcher` in `ZkIndexSchemaReader` (see screenshot 2). The
> {{ZkIndexSchemaReader}} registers a close hook in the {{SolrCore}} but the
> Zookeeper is not removed upon core close.
> We supplied a Github Pull Request
> (https://github.com/apache/lucene-solr/pull/197) that extracts the zookeeper
> `Watcher` as a static inner class. To eliminate the memory leak, the schema
> reader is held inside a `WeakReference` and the reference is explicitly
> removed on core close.
> Initially I wanted to supply a test case but unfortunately did not find a
> good starting point ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10654) Expose Metrics in Prometheus format
[
https://issues.apache.org/jira/browse/SOLR-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004814#comment-16004814
]
Keith Laban commented on SOLR-10654:
Jan, I think the problem would still be that each handler would most likely
need their own very specific custom response format. If we were to do this we
would need to expose them as a raw Filter or Servlet instead of a
SolrRequestHandler. I'm not aware of anywhere else in solr where this is
happening. The other option would be to add a custom response writer format for
each metrics type, kind of like Iike I did here.
> Expose Metrics in Prometheus format
> ---
>
> Key: SOLR-10654
> URL: https://issues.apache.org/jira/browse/SOLR-10654
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Reporter: Keith Laban
>
> Expose metrics via a `wt=prometheus` response type.
> Example scape_config in prometheus.yml:
> {code}
> scrape_configs:
> - job_name: 'solr'
> metrics_path: '/solr/admin/metrics'
> params:
> wt: ["prometheus"]
> static_configs:
> - targets: ['localhost:8983']
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
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 # 1295 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1295/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([5BD5F8BB65E3CF09:39B806FAAA6DAF37]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201) 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:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) 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:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) 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 12802 lines...] [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest [junit4] 2> Creating dataDir:
[jira] [Commented] (SOLR-9527) Solr RESTORE api doesn't distribute the replicas uniformly
[ https://issues.apache.org/jira/browse/SOLR-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004810#comment-16004810 ] Varun Thacker commented on SOLR-9527: - Thanks all for contributing! > Solr RESTORE api doesn't distribute the replicas uniformly > --- > > Key: SOLR-9527 > URL: https://issues.apache.org/jira/browse/SOLR-9527 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.1 >Reporter: Hrishikesh Gadre >Assignee: Varun Thacker > Fix For: 6.6, master (7.0) > > Attachments: SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, > SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, Solr 9527.pdf > > > Please refer to this email thread for details, > http://lucene.markmail.org/message/ycun4x5nx7lwj5sk?q=solr+list:org%2Eapache%2Elucene%2Esolr-user+order:date-backward=1 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-9527) Solr RESTORE api doesn't distribute the replicas uniformly
[ https://issues.apache.org/jira/browse/SOLR-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker resolved SOLR-9527. - Resolution: Fixed Fix Version/s: master (7.0) 6.6 > Solr RESTORE api doesn't distribute the replicas uniformly > --- > > Key: SOLR-9527 > URL: https://issues.apache.org/jira/browse/SOLR-9527 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.1 >Reporter: Hrishikesh Gadre >Assignee: Varun Thacker > Fix For: 6.6, master (7.0) > > Attachments: SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, > SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, Solr 9527.pdf > > > Please refer to this email thread for details, > http://lucene.markmail.org/message/ycun4x5nx7lwj5sk?q=solr+list:org%2Eapache%2Elucene%2Esolr-user+order:date-backward=1 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9527) Solr RESTORE api doesn't distribute the replicas uniformly
[ https://issues.apache.org/jira/browse/SOLR-9527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16004807#comment-16004807 ] ASF subversion and git services commented on SOLR-9527: --- Commit 1adeebdd92a96233836f83f6144da9eead65a2cf in lucene-solr's branch refs/heads/branch_6x from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1adeebd ] SOLR-9527: Improve distribution of replicas when restoring a collection > Solr RESTORE api doesn't distribute the replicas uniformly > --- > > Key: SOLR-9527 > URL: https://issues.apache.org/jira/browse/SOLR-9527 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 6.1 >Reporter: Hrishikesh Gadre >Assignee: Varun Thacker > Fix For: 6.6, master (7.0) > > Attachments: SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, > SOLR-9527.patch, SOLR-9527.patch, SOLR-9527.patch, Solr 9527.pdf > > > Please refer to this email thread for details, > http://lucene.markmail.org/message/ycun4x5nx7lwj5sk?q=solr+list:org%2Eapache%2Elucene%2Esolr-user+order:date-backward=1 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
