[jira] [Commented] (SOLR-9184) Add convenience method to ModifiableSolrParams

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937779#comment-15937779
 ] 

ASF subversion and git services commented on SOLR-9184:
---

Commit 583fec1a58b41a0562529e6228a29728a790d87c in lucene-solr's branch 
refs/heads/master from koji
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=583fec1 ]

SOLR-9184: Add a static convenience method ModifiableSolrParams#of(SolrParams) 
which returns the same instance if it already is modifiable, otherwise creates 
a new ModifiableSolrParams instance.


> Add convenience method to ModifiableSolrParams
> --
>
> Key: SOLR-9184
> URL: https://issues.apache.org/jira/browse/SOLR-9184
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jörg Rathlev
>Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-9184.patch, SOLR-9184.patch
>
>
> Add a static convenience method {{ModifiableSolrParams#of(SolrParams)}} which 
> returns the same instance if it already is modifiable, otherwise creates a 
> new {{ModifiableSolrParams}} instance.
> Rationale: when writing custom SearchComponents, we find that we often need 
> to ensure that the SolrParams are modifiable. The copy constructor of 
> ModifiableSolrParams always creates a copy, even if the SolrParms already are 
> modifiable.
> Alternatives: The method could also be added as a convenience method in 
> SolrParams itself, which already has static helper methods for wrapDefaults 
> and wrapAppended.



--
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 (64bit/jdk-9-ea+161) - Build # 19238 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19238/
Java: 64bit/jdk-9-ea+161 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val changed' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/ey_vo/sw", "path":"/test1", 
"httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val changed' for 
path 'x' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/ey_vo/sw",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([EEE2169414D774E9:36AF3BC3E30AD149]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:249)
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:547)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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 

[jira] [Comment Edited] (SOLR-10323) SpellingQueryConverter does not remove ":" char when using fielded queries

[Amrit Sarkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936915#comment-15936915
 ] 

Amrit Sarkar edited comment on SOLR-10323 at 3/23/17 5:41 AM:
--

SOLR-10323.patch uploaded which will ignore ":" and "(" throughout the original 
term. This fixes our problem but an overhead comes around as the 
SpellingQueryConverter will break if the original term is like:

foo:bar(random)  ===> [bar, random], in current code, this happens already
foo:bar:bar ===> [bar, bar], in current code, this happens already

and there is no way to escape it like:
foo:bar\(random)
foo:bar\:bar

But this will work perfectly with other special characters like underscores, 
highen and alphanumerics.

I will add relevant test cases very soon if we have a +1 with the stated 
compromise.


was (Author: sarkaramr...@gmail.com):
SOLR-10323.patch uploaded which will ignore ":" and "(" throughout the original 
term. This fixes our problem but an overhead comes around as the 
SpellingQueryConverter will break if the original term is like:

foo:bar(random)  ===> [bar, random]
foo:bar:bar ===> [bar, bar], in current code, this happens already

and there is no way to escape it like:
foo:bar\(random)
foo:bar\:bar

But this will work perfectly with other special characters like underscores, 
highen and alphanumerics.

I will add relevant test cases very soon if we have a +1 with the stated 
compromise.

> SpellingQueryConverter does not remove ":" char when using fielded queries
> --
>
> Key: SOLR-10323
> URL: https://issues.apache.org/jira/browse/SOLR-10323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: Michael Pellegrini
> Attachments: SOLR-10323.patch
>
>
> If you pass a fielded query to {{SpellingQueryConverter.convert}}, it returns 
> a token that is prefixed with a ":" char.
> Example: The query "foo:bar" is converted to ":bar"
> This bug seems to have been introduced by the fix for SOLR-2556. Before this 
> patch, {{SpellingQueryConverter.convert}} returned tokens without the leading 
> colon char.



--
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-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937734#comment-15937734
 ] 

Amrit Sarkar commented on LUCENE-7729:
--

bq. len > 0 (as a comment) but in all cases you probably mean len > 1?
Yes, that is correct.

bq. Let me give a better example of length 3: aab would fail to match aaab. I 
just wrote a test for that to confirm it failed. Here's another example of 
length 4 that may be more clear: A separator of acab would fail to be detected 
in acacab.
I see. The implemented is flawed, the algorithm I thought is incomplete and 
though some minor tweaking will make it work surely. I never considered 
repetitive pattern in the separator.

bq.  To be clear, I never asked or recommended. 
David, I completely understand and aware, I just pointed out the conversation 
which motivates me to look into it. I am thankful to you for taking your time 
out to provide healthy insights and feedback on the patch. I will not get 
discouraged if some of my work doesn't get into the main project, even I want 
to contribute which is useful not flawed.

With that, I will check out SimplePatternTokenizer and the Automation part. 
Thank you for your time again, really appreciate that. Should I leave this JIRA 
as it is? or instead atleast fix the implementation?

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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_121) - Build # 798 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/798/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseSerialGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<0>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([96DFF943D4A29425:429AB21A33F427DE]: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.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
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)


FAILED:  

[jira] [Commented] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937656#comment-15937656
 ] 

David Smiley commented on LUCENE-7729:
--

BTW in multiple places in your code as comments plus this issue commentary I've 
seen this: {{len > 0}} (as a comment) but in all cases you probably mean {{len 
> 1}}?

RE resetting a failed match: Good point that your patch addresses the specific 
example I gave, and apparently any separator of length 2. Let me give a better 
example of length 3:  {{aab}} would fail to match {{aaab}}.  I just wrote a 
test for that to confirm it failed.  Here's another example of length 4 that 
may be more clear:  A separator of {{acab}} would fail to be detected in 
{{acacab}}.

testBreakOnCustomSeparator: you commented out a couple assertions because they 
didn't apply if the separator is > 1 length.  Instead you could add a condition 
to only test when length 1.

RE my proposed single char constructor org: this is just syntactic sugar (i.e. 
convenience).  A bunch of changes in your diff would then be able to stay the 
same.

bq. I observed the code and understood it will not require major refactoring to 
change the current implementation for arbitrary length string.

Yeah I figured.  I envy the time you have on your hands to implement a feature 
that nobody has (yet) asked for :-)  To be clear, I never asked or recommended. 
 I sometimes work on something fun to me too; scratch some itch.

Speaking of scratching itches... check out SimplePatternTokenizer (recently 
added to Lucene) and how it works with an Automaton.  Now I'm sure *that* would 
be useful to users; the original Highlighter (via Solr at least) had a regexp 
passage splitter.  One possible direction you might take is to leave 
CustomSeparatorBreakIterator be and instead do one taking a regexp/automaton... 
and then if some user wants to split on a string then they could use this guy.

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937602#comment-15937602
 ] 

David Smiley commented on SOLR-10229:
-

bq. if we're going to go to the trouble of trying to change/cleanup how most 
tests use/depend on their schema (or a new unified test schema w/additions) 
then it would be nice to also move towards more of a "declarative" model of 
what th test needs and let the scaffolding assume any field/fieldtype 
properties the test doesn't declare can be randomized.

+1 fantastic

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
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 (32bit/jdk1.8.0_121) - Build # 6468 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6468/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Unexpected number of elements in the group for intGSF: 6

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 6
at 
__randomizedtesting.SeedInfo.seed([25C63AD846935237:BE7D54800BCB6069]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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)




Build Log:
[...truncated 12533 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-10310) By default, stop splitting on whitespace prior to analysis in edismax and "Lucene"/standard query parsers

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937599#comment-15937599
 ] 

David Smiley commented on SOLR-10310:
-

If this will also lose the semantics of autoGeneratePhraseQueries (as hinted in 
SOLR-10348 it will), I think this is a step back -- at least for 
English/western languages, most especially (where autoGeneratePhraseQueries is 
recommended).  The technical difficulties that led to the incompatibility of 
"sow=false" and autoGeneratePhraseQueries were based on Lucene being unable to 
treat token streams as graphs.  Of course as you know, this was recently solved.

> By default, stop splitting on whitespace prior to analysis in edismax and 
> "Lucene"/standard query parsers
> -
>
> Key: SOLR-10310
> URL: https://issues.apache.org/jira/browse/SOLR-10310
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> SOLR-9185 introduced an option on the edismax and standard query parsers to 
> not perform pre-analysis whitespace splitting: the {{sow=false}} request 
> param.
> On master/7.0, we should make {{sow=false}} the default.



--
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-6615) Refactor code to use String constants

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937569#comment-15937569
 ] 

ASF subversion and git services commented on SOLR-6615:
---

Commit 95be4eba246275a5d7fb29904ae30257bcda in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95be4eb ]

SOLR-6615: use constants for 'id', '_route_', '_version_'


> Refactor code to use String constants
> -
>
> Key: SOLR-6615
> URL: https://issues.apache.org/jira/browse/SOLR-6615
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Solr codebase is full of string constants used in place and the same string 
> is declared in multiple places . We need to define the constants in a common 
> place and need to reuse them 



--
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-10016) SQL should support sorting by random_

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937566#comment-15937566
 ] 

Kevin Risden commented on SOLR-10016:
-

The Calcite reference (https://calcite.apache.org/docs/reference.html) mentions 
RAND() and RAND_INTEGER(). I haven't tried to use these with the Solr Calcite 
piece. Might have to get more creative about the SQL query but a thought.

> SQL should support sorting by random_
> ---
>
> Key: SOLR-10016
> URL: https://issues.apache.org/jira/browse/SOLR-10016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Attachments: SOLR-10016.patch
>
>
> I tried using the handy sort=random_ feature in normal queries with SQL 
> and it failed:
> {code} 
> curl --data-urlencode "stmt=select rating, movie_id, user_id from ratings 
> order by random_5150 asc" \
> >  "http://localhost:8983/solr/ratings/sql;
> {"result-set":{"docs":[
> {"EXCEPTION":"Fields in the sort spec must be included in the field 
> list:random_5150","EOF":true}]}}
> {code}
> I'd like to take a stab at fixing this if there are no objections to me doing 
> so?



--
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-10016) SQL should support sorting by random_

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937559#comment-15937559
 ] 

Kevin Risden commented on SOLR-10016:
-

Just going to share my two cents on this (not fully fleshed out):

I don't know if adding a field to the schema for each custom field is the right 
approach. This would get very unwieldy. Instead, is it possible to do this by 
implemented a custom function that isn't in the schema? Something like random() 
or random(SEED). I don't know the right place to hook this into Calcite right 
now but it seems like this would be possible? It may also be the case that 
Calcite has some functions built in already?

> SQL should support sorting by random_
> ---
>
> Key: SOLR-10016
> URL: https://issues.apache.org/jira/browse/SOLR-10016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Attachments: SOLR-10016.patch
>
>
> I tried using the handy sort=random_ feature in normal queries with SQL 
> and it failed:
> {code} 
> curl --data-urlencode "stmt=select rating, movie_id, user_id from ratings 
> order by random_5150 asc" \
> >  "http://localhost:8983/solr/ratings/sql;
> {"result-set":{"docs":[
> {"EXCEPTION":"Fields in the sort spec must be included in the field 
> list:random_5150","EOF":true}]}}
> {code}
> I'd like to take a stab at fixing this if there are no objections to me doing 
> so?



--
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-10279) The autoAddReplica feature can result in SolrCores being assigned new shards.

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937531#comment-15937531
 ] 

Mark Miller commented on SOLR-10279:


Originally this was titled for SOLR-10279 legacyCloud=false, but there appear 
to be harder to hit in a test but similar issues with lagacyCloud=true.

> The autoAddReplica feature can result in SolrCores being assigned new shards.
> -
>
> Key: SOLR-10279
> URL: https://issues.apache.org/jira/browse/SOLR-10279
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-10279.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-10279) The autoAddReplica feature can result in SolrCores being assigned new shards.

[Mark Miller (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-10279:
---
Summary: The autoAddReplica feature can result in SolrCores being assigned 
new shards.  (was: The autoAddReplica feature can result in SolrCores being 
assigned new shards when using legacyCloud=false.)

> The autoAddReplica feature can result in SolrCores being assigned new shards.
> -
>
> Key: SOLR-10279
> URL: https://issues.apache.org/jira/browse/SOLR-10279
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-10279.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] [Resolved] (SOLR-9994) Add support for CollapseQParser with PointFields

[Cao Manh Dat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cao Manh Dat resolved SOLR-9994.

   Resolution: Fixed
 Assignee: Cao Manh Dat
Fix Version/s: 6.6
   master (7.0)

> Add support for CollapseQParser with PointFields
> 
>
> Key: SOLR-9994
> URL: https://issues.apache.org/jira/browse/SOLR-9994
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: master (7.0), 6.6
>
> Attachments: SOLR-9994.patch, SOLR-9994.patch, SOLR-9994.patch
>
>
> Followup task of SOLR-8396



--
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-9994) Add support for CollapseQParser with PointFields

[Cao Manh Dat (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937520#comment-15937520
 ] 

Cao Manh Dat commented on SOLR-9994:


Made a mistake on commit message at branch master :P, so here are the log

Commit b7042c1f6e449d7eb33a9daaabda0e0d2a53e95b in lucene-solr's branch 
refs/heads/master from Cao Manh Dat
[ 
https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;a=commit;h=b7042c1f6e449d7eb33a9daaabda0e0d2a53e95b
 ]
Add support for CollapseQParser with PointFields

> Add support for CollapseQParser with PointFields
> 
>
> Key: SOLR-9994
> URL: https://issues.apache.org/jira/browse/SOLR-9994
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Fix For: master (7.0), 6.6
>
> Attachments: SOLR-9994.patch, SOLR-9994.patch, SOLR-9994.patch
>
>
> Followup task of SOLR-8396



--
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-9994) Add support for CollapseQParser with PointFields

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937515#comment-15937515
 ] 

ASF subversion and git services commented on SOLR-9994:
---

Commit 444db592cb53dcecc063139a1c5fc5a088ca1079 in lucene-solr's branch 
refs/heads/branch_6x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=444db59 ]

SOLR-9994: Add support for CollapseQParser with PointFields


> Add support for CollapseQParser with PointFields
> 
>
> Key: SOLR-9994
> URL: https://issues.apache.org/jira/browse/SOLR-9994
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9994.patch, SOLR-9994.patch, SOLR-9994.patch
>
>
> Followup task of SOLR-8396



--
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-6615) Refactor code to use String constants

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937508#comment-15937508
 ] 

Noble Paul edited comment on SOLR-6615 at 3/23/17 1:20 AM:
---

Commit eb587772ddecaea371b20feb955a197e80699f22 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb58777 ]

SOLR-6615: use constants for id, \_route_, \_version_



was (Author: jira-bot):
Commit eb587772ddecaea371b20feb955a197e80699f22 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb58777 ]

SOLR-6615: use constants for 'id', '_route_', '_version_'


> Refactor code to use String constants
> -
>
> Key: SOLR-6615
> URL: https://issues.apache.org/jira/browse/SOLR-6615
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Solr codebase is full of string constants used in place and the same string 
> is declared in multiple places . We need to define the constants in a common 
> place and need to reuse them 



--
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-6615) Refactor code to use String constants

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937508#comment-15937508
 ] 

ASF subversion and git services commented on SOLR-6615:
---

Commit eb587772ddecaea371b20feb955a197e80699f22 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eb58777 ]

SOLR-6615: use constants for 'id', '_route_', '_version_'


> Refactor code to use String constants
> -
>
> Key: SOLR-6615
> URL: https://issues.apache.org/jira/browse/SOLR-6615
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> Solr codebase is full of string constants used in place and the same string 
> is declared in multiple places . We need to define the constants in a common 
> place and need to reuse them 



--
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-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937420#comment-15937420
 ] 

Erick Erickson commented on SOLR-10229:
---

gimmeAField.builder().withName("ohmy").withType("int").withAttribute("stored", 
"true").build()?

and anything not specified by withAttribute is randomizable? Wordy, but 
understandable.

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
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-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937403#comment-15937403
 ] 

ASF subversion and git services commented on SOLR-7452:
---

Commit 725cd4e2f546a71ccf43218ffc88739a3e05a260 in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=725cd4e ]

SOLR-7452: facet refinement - don't generate domain if skipping bucket


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
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-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937405#comment-15937405
 ] 

ASF subversion and git services commented on SOLR-7452:
---

Commit 5194861115708f68c6cde5e66bf9d1c6a3178934 in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5194861 ]

SOLR-7452: facet refinement - don't generate domain if skipping bucket


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
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-9045) make RecoveryStrategy settings configurable

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-9045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937304#comment-15937304
 ] 

Tomás Fernández Löbbe commented on SOLR-9045:
-

I'm a bit too late to this discussion (being released right now as part of 
6.5), but as part of the work in SOLR-10233, I was planning to make 
{{RecoveryStrategy}} an interface, with the current implementation being the 
default, but also add a new {{ReplicateOnlyRecoveryStrategy}} that skips peer 
sync, and jumps directly to replication particularly for "Passive Replicas" (or 
whatever name they end up having). Just FYI, feel free to comment in SOLR-10233

> make RecoveryStrategy settings configurable
> ---
>
> Key: SOLR-9045
> URL: https://issues.apache.org/jira/browse/SOLR-9045
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (7.0), 6x
>
> Attachments: SOLR-9045.patch
>
>
> objectives:
>  * to allow users to change RecoveryStrategy settings such as maxRetries and 
> startingRecoveryDelay
>  * to support configuration of a custom recovery strategy e.g. SOLR-9044
> patch summary:
>  * support for optional  solrconfig.xml element added (if 
> element is present then its class attribute is optional)
>  * RecoveryStrategy settings now have getters/setters
>  * RecoveryStrategy.Builder added (and RecoveryStrategy constructor made 
> non-public in favour of RecoveryStrategy.Builder.create)
>  * protected RecoveryStrategy.getReplicateLeaderUrl method factored out 
> (ConfigureRecoveryStrategyTest$CustomRecoveryStrategyBuilder test illustrates 
> how SOLR-9044 might override the method)
>  * ConfigureRecoveryStrategyTest.java using 
> solrconfig-configurerecoverystrategy.xml or 
> solrconfig-customrecoverystrategy.xml
> illustrative solrconfig.xml snippets:
>  * change a RecoveryStrategy setting
> {code}
>   
> 250
>   
> {code}
> * configure a custom class
> {code}
>class="org.apache.solr.core.ConfigureRecoveryStrategyTest$CustomRecoveryStrategyBuilder">
> recovery_base_url
>   
> {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-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937252#comment-15937252
 ] 

Hoss Man commented on SOLR-10229:
-

random 2cents observation:

if we're going to go to the trouble of trying to change/cleanup how most tests 
use/depend on their schema (or a new unified test schema w/additions) then it 
would be nice to also move towards more of a "declarative" model of what th 
test *needs* and let the scaffolding assume any field/fieldtype properties the 
test doesn't declare can be randomized.

for example: a test should be able to declare that it _needs_ a field named 
{{do_something_with_this_field}} that is an "integer" and has "docValues=true" 
but other unspecified things (like whether it's a points based int field or a 
trie based int field, or whether it's stored or indexed) should be left to the 
helper method to randomize.

this should, in theory, help us find bugs that currently fall through the 
cracks because people don't realize their code has implict dependencies on 
certain field/type atttributes.

continuing our previous example: someone might today write theat test to use a 
{{do_something_with_this_field_i}} field name so they can leverage an existing 
{{\*_i}} dynamic field because they know they want something "integer" based, 
w/o considering the possibility that maybe the only reason their code works is 
because that dynamicField has docValues=true *AND* is stored=true.

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



--
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 # 777 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/777/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([69E34D0133E6C078:3CB3A5939F1F0F88]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1394)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1087)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1057)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:232)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+161) - Build # 19235 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19235/
Java: 64bit/jdk-9-ea+161 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
Earlier: [16991, 16991, -1], now: [16991, 16991, 16991]

Stack Trace:
java.lang.AssertionError: Earlier: [16991, 16991, -1], now: [16991, 16991, 
16991]
at 
__randomizedtesting.SeedInfo.seed([680A1CD59F251E98:E05E230F31D97360]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:530)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:161)
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:547)
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:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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 

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937094#comment-15937094
 ] 

ASF GitHub Bot commented on SOLR-10249:
---

Github user millerjeff0 commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107526774
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -321,9 +369,16 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
   try {
 response = getLatestVersion();
   } catch (Exception e) {
-LOG.error("Master at: " + masterUrl + " is not available. Index 
fetch failed. Exception: " + e.getMessage());
-return false;
-  }
+final String errorMsg = e.getMessage();
--- End diff --

Great point, thanks


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



--
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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[millerjeff0]

Github user millerjeff0 commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107526774
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -321,9 +369,16 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
   try {
 response = getLatestVersion();
   } catch (Exception e) {
-LOG.error("Master at: " + masterUrl + " is not available. Index 
fetch failed. Exception: " + e.getMessage());
-return false;
-  }
+final String errorMsg = e.getMessage();
--- End diff --

Great point, thanks


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-10342) cleanup build.xml and ivy.xml related TODO items so they re-use lucene/solr variables/conventions

[Hoss Man (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-10342.
-
Resolution: Fixed

I think these commits on the SOLR-10290 branch cover everything we need to 
worry about...

* 017b890f7cdde1e1c7ec4b73ed8943db7eff370d
* 85bb18003830846b036751ae3137a1efacaaa79d

> cleanup build.xml and ivy.xml related TODO items so they re-use lucene/solr 
> variables/conventions
> -
>
> Key: SOLR-10342
> URL: https://issues.apache.org/jira/browse/SOLR-10342
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>




--
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-10346) Clean up static page HTML top nav

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937063#comment-15937063
 ] 

Hoss Man commented on SOLR-10346:
-

bq. Home link. This should be made dynamic to update automatically for each 
version the Guide applies to

the link text already pulls in the version# from a site variable, and now that 
i've committed SOLR-10342 that will match the common-build.xml specified 
version.

bq. Solr Resources. Links to Javadocs, Source code and Community page of Solr 
website. Javadoc links should be dynamic.

This is currently a little tricky -- while the "home" link text is part of the 
{{topnav.html}} template (and can refer to site variables) the template then 
loops over entries in {{topnav.yml}} for the other various links -- and there's 
no way (that i know of) to have entries in {{topnav.yml}} refer to site 
variables.

the 2 solutions i can think of:

* remove {{topnav.yml}} and hardcode the html we want in {{topnav.html}} -- 
using the existing jekyll site variable for the javadocs URL
* rename {{topnav.yml}} to {{topnav.yml.template}} and let the existing 
build.xml logic do variable substitution using ant properties (this build.xml 
logic already exists so we can use ant variables in  {{_config.yml.template}})

> Clean up static page HTML top nav
> -
>
> Key: SOLR-10346
> URL: https://issues.apache.org/jira/browse/SOLR-10346
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
> Attachments: SRG-top-nav-20170322.png
>
>
> For demo purposes, the top navigation bar for the HTML version of the Ref 
> Guide includes some stuff we probably don't want in production. This should 
> be cleaned up and finalized.
> I'll attach a screenshot of the current nav for reference. It currently has 
> these sections:
> * Home link. This should be made dynamic to update automatically for each 
> version the Guide applies to
> * News. Probably don't need this? Today it goes nowhere, but it could go to 
> the News section of the Solr website.
> * Jekyll Resources. Links to stuff about Jekyll. We don't want this.
> * Solr Resources. Links to Javadocs, Source code and Community page of Solr 
> website. Javadoc links should be dynamic.
> * Feedback. Javascript to open local Mail application to send an email. 
> Currently goes to my apache.org address, which I don't want.
> * Search box. This can stay, and we can modify it to do whatever we want it 
> to do when SOLR-10299 is resolved.



--
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-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937061#comment-15937061
 ] 

Amrit Sarkar commented on LUCENE-7729:
--

Regarding,

bq. Just curious; is this feature driven by a search-app requirement or ...

This is follow-up of the conversation we had for SOLR-10153:
bq. David:  Hmmm; do we even need hl.bs.type==CUSTOM if the user sets 
hl.bs.separatorChar? I guess it should be set so that there is consistency in 
mapping the type to an algorithm. Though maybe use the value SEPARATOR? And 
maybe just name this hl.bs.separator to open the door for possibly using an 
arbitrary length string in the future?

I observed the code and understood it will not require major refactoring to 
change the current implementation for arbitrary length string.

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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-10348) unexpected sow=false interaction with defaultSearchField

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937053#comment-15937053
 ] 

Steve Rowe edited comment on SOLR-10348 at 3/22/17 8:24 PM:


I'm working up a patch on SOLR-10310 that will remove 
{{autoGeneratePhraseQueries="true"}} from most field types in most test and 
example schemas on master.  The problem on this issue will remain on branch_6x 
though, without similar changes.  I'll dig.


was (Author: steve_rowe):
I'm working up a patch on SOLR-10310 that will remove 
{{autoGeneratePhraseQueries="true"}} from most field types in most test and 
example schemas on master (see LUCENE-.  The problem on this issue will remain 
on branch_6x though, without similar changes.  I'll dig.

> unexpected sow=false interaction with defaultSearchField
> 
>
> Key: SOLR-10348
> URL: https://issues.apache.org/jira/browse/SOLR-10348
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10348.patch
>
>
> Came across this as part of SOLR-10264 test development, walkback extract 
> shown below, will attach patch used to reproduce.
> {code}
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7417 INFO  (qtp45246903-42) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=21
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=true
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7421 INFO  (qtp45246903-35) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=1
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=false
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7424 ERROR (qtp45246903-40) [x:collection1] 
> o.a.s.h.RequestHandlerBase 
> org.apache.solr.search.QueryParserConfigurationException: Field 'text': 
> fieldAutoGenPhraseQueries == true is disallowed when sow/splitOnWhitespace == 
> false
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:953)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:692)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Term(QueryParser.java:424)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Clause(QueryParser.java:281)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Query(QueryParser.java:225)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:134)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:212)
> [junit4]   2>at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:53)
> [junit4]   2>at 
> org.apache.solr.search.QParser.getQuery(QParser.java:168)
> [junit4]   2>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:161)
> [junit4]   2>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:268)
> [junit4]   2>at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> [junit4]   2>at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)
> {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-10348) unexpected sow=false interaction with defaultSearchField

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937058#comment-15937058
 ] 

Steve Rowe commented on SOLR-10348:
---

See LUCENE-7533 for information about sow=false/auto-gen=true incompatibility 
in the classic Lucene QP, which also applies to Solr query parsers.

> unexpected sow=false interaction with defaultSearchField
> 
>
> Key: SOLR-10348
> URL: https://issues.apache.org/jira/browse/SOLR-10348
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10348.patch
>
>
> Came across this as part of SOLR-10264 test development, walkback extract 
> shown below, will attach patch used to reproduce.
> {code}
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7417 INFO  (qtp45246903-42) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=21
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=true
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7421 INFO  (qtp45246903-35) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=1
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=false
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7424 ERROR (qtp45246903-40) [x:collection1] 
> o.a.s.h.RequestHandlerBase 
> org.apache.solr.search.QueryParserConfigurationException: Field 'text': 
> fieldAutoGenPhraseQueries == true is disallowed when sow/splitOnWhitespace == 
> false
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:953)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:692)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Term(QueryParser.java:424)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Clause(QueryParser.java:281)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Query(QueryParser.java:225)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:134)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:212)
> [junit4]   2>at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:53)
> [junit4]   2>at 
> org.apache.solr.search.QParser.getQuery(QParser.java:168)
> [junit4]   2>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:161)
> [junit4]   2>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:268)
> [junit4]   2>at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> [junit4]   2>at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)
> {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] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amrit Sarkar updated LUCENE-7729:
-
Attachment: (was: LUCENE-7729.patch)

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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-10348) unexpected sow=false interaction with defaultSearchField

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937053#comment-15937053
 ] 

Steve Rowe commented on SOLR-10348:
---

I'm working up a patch on SOLR-10310 that will remove 
{{autoGeneratePhraseQueries="true"}} from most field types in most test and 
example schemas on master (see LUCENE-.  The problem on this issue will remain 
on branch_6x though, without similar changes.  I'll dig.

> unexpected sow=false interaction with defaultSearchField
> 
>
> Key: SOLR-10348
> URL: https://issues.apache.org/jira/browse/SOLR-10348
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10348.patch
>
>
> Came across this as part of SOLR-10264 test development, walkback extract 
> shown below, will attach patch used to reproduce.
> {code}
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7417 INFO  (qtp45246903-42) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=21
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=true
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7421 INFO  (qtp45246903-35) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=1
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=false
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7424 ERROR (qtp45246903-40) [x:collection1] 
> o.a.s.h.RequestHandlerBase 
> org.apache.solr.search.QueryParserConfigurationException: Field 'text': 
> fieldAutoGenPhraseQueries == true is disallowed when sow/splitOnWhitespace == 
> false
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:953)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:692)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Term(QueryParser.java:424)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Clause(QueryParser.java:281)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Query(QueryParser.java:225)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:134)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:212)
> [junit4]   2>at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:53)
> [junit4]   2>at 
> org.apache.solr.search.QParser.getQuery(QParser.java:168)
> [junit4]   2>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:161)
> [junit4]   2>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:268)
> [junit4]   2>at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> [junit4]   2>at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)
> {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] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amrit Sarkar updated LUCENE-7729:
-
Attachment: LUCENE-7729.patch

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amrit Sarkar updated LUCENE-7729:
-
Attachment: LUCENE-7729.patch

Thank you David for looking into this. Updated: LUCENE-7729.patch

bq. One issue with the implementation I see is that if it starts to find a 
match but ultimately doesn't, then the position is not reset back to the start 
(plus 1). This means hypothetically a string separator of ab would fail to find 
the substring in the input aab. I didn't try with your patch but do you concur? 

It is taken care in the following section in the original patch:
CustomSeparatorBreakIterator::advanceForward()::72
CustomSeparatorBreakIterator::advanceBackward()::121

{code}
if(sep_index != separator.length() - 1) { // separator len > 1
  sep_index = separator.length() - 1;
  if(c == separator.charAt(sep_index)){ //check the current token match 
with last element
sep_index --;
  }
}
{code}
{code}
if(sep_index != 0) { //separator len > 0
  sep_index = 0;
  if (c == separator.charAt(sep_index)) { //check the current token 
match with first element
sep_index ++;
  }
}
{code}

I have added relevant test cases to prove the same:

TestCustomSeparatorBreakIterator::testFollowingPrecedingBreakOnCustomSeparator::100
{code}separator = "xz";{code}

bq. I'm a little concerned about possible overhead for this mode. Maybe 
subclassing to override advanceForward and advanceBackward would make sense. If 
this were an inner class to do the string, then a factory method instead of 
constructor could be used. I think CustomSeparatorBreakIterator should continue 
to accept a single char constructor arg; I imagine most uses of this would 
remain to be one character.

I am not able to find an overhead for this implementation. String of length>0 
is acceptable which is kind of better than just single char, no? I understand 
the most use cases will not demand more than single char, that's why we 
specially have whitespace, but having string arg as default brings no harm as 
internally char-by-char matching is done.

Thank you for the valuable coding standard tips too. Ishan corrected me on 
above stated points on other JIRA and it slipped my mind that I already 
attached a patch for this one with improper indentation and style. I will take 
care of this in future for sure.

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch, LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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-10016) SQL should support sorting by random_

[Timothy Potter (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Potter updated SOLR-10016:
--
Attachment: SOLR-10016.patch

Here's a patch (-p0 style) prepared against branch_6_5 that adds the ability to 
sort SQL query results using Solr's random_SEED trick (via RandomStream).

To use this, your SQL would look something like:
{code}
curl --data-urlencode "stmt=select movie_id, user_id from ratings order by 
_random_ asc limit 100" "http://localhost:8983/solr/ratings/sql;
{code}

Unlike with score, the _random_ sort field doesn't need to be included in the 
results, which I felt was unnecessary since it's just a random number.

Still needs a test but wanted to post something up to get initial feedback.

Ideally, we'd be able to sort by any ValueSource as well as include the value 
of a ValueSource in the results. However, it seems like we need to expose the 
name and type of every possible ValueSource in the SolrSchema.getRelDataType 
return value? [~joel.bernstein] or [~risdenk] any suggestions on the best way 
to support any ValueSource in a SQL query? Seems like that would force the user 
to have to use LIMIT afaik, ValueSource's aren't exportable. Also, let me know 
if this approach is acceptable for random sorting.

> SQL should support sorting by random_
> ---
>
> Key: SOLR-10016
> URL: https://issues.apache.org/jira/browse/SOLR-10016
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Attachments: SOLR-10016.patch
>
>
> I tried using the handy sort=random_ feature in normal queries with SQL 
> and it failed:
> {code} 
> curl --data-urlencode "stmt=select rating, movie_id, user_id from ratings 
> order by random_5150 asc" \
> >  "http://localhost:8983/solr/ratings/sql;
> {"result-set":{"docs":[
> {"EXCEPTION":"Fields in the sort spec must be included in the field 
> list:random_5150","EOF":true}]}}
> {code}
> I'd like to take a stab at fixing this if there are no objections to me doing 
> so?



--
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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107514287
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean status;
--- End diff --

perhaps rename "status" to "successful" (getter too)?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936999#comment-15936999
 ] 

ASF GitHub Bot commented on SOLR-10249:
---

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107513516
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -321,9 +369,16 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
   try {
 response = getLatestVersion();
   } catch (Exception e) {
-LOG.error("Master at: " + masterUrl + " is not available. Index 
fetch failed. Exception: " + e.getMessage());
-return false;
-  }
+final String errorMsg = e.getMessage();
--- End diff --

Granted e.getMessage() was what this code was doing before you made changes 
but can you please use e.toString() instead?  IMO, e.getMessage() should rarely 
if ever be called instead of e.toString() because e.toString() critically 
contains the name of the exception itself.  The "message" alone can be unclear 
without the exception class.  Consider `FileNotFoundException` and there are 
others.


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



--
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-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937002#comment-15937002
 ] 

ASF GitHub Bot commented on SOLR-10249:
---

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107514287
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
+private final String message;
+private final boolean status;
--- End diff --

perhaps rename "status" to "successful" (getter too)?


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



--
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-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937001#comment-15937001
 ] 

ASF GitHub Bot commented on SOLR-10249:
---

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107512860
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -311,7 +359,7 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
 Replica replica = getLeaderReplica();
 CloudDescriptor cd = 
solrCore.getCoreDescriptor().getCloudDescriptor();
 if (cd.getCoreNodeName().equals(replica.getName())) {
-  return false;
+  return IndexFetchResult.CORE_NODE_IS_REPLICA;
--- End diff --

Maybe call this NOT_LEADER ?  Even a leader is a replica (it's the _role_ a 
replica plays).  Granted many of us promote this ambiguity because we haven't 
clearly/consistently labelled a non-leader, e.g. a follower.


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



--
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-10249) Allow index fetching to return a detailed result instead of a true/false value

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15937000#comment-15937000
 ] 

ASF GitHub Bot commented on SOLR-10249:
---

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107514170
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
--- End diff --

I really like how you modeled this return object.


> Allow index fetching to return a detailed result instead of a true/false value
> --
>
> Key: SOLR-10249
> URL: https://issues.apache.org/jira/browse/SOLR-10249
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 6.4.1
> Environment: Any
>Reporter: Jeff Miller
>Priority: Trivial
>  Labels: easyfix, newbie
> Fix For: 6.5
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> This gives us the ability to see into why a replication might of failed and 
> act on it if we need to.  We use this enhancement for logging conditions so 
> we can quantify what is happening with replication, get success rates, etc.
> The idea is to create a public static class IndexFetchResult as an inner 
> class to IndexFetcher that has strings that hold statuses that could occur 
> while fetching an index.



--
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

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107513516
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -321,9 +369,16 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
   try {
 response = getLatestVersion();
   } catch (Exception e) {
-LOG.error("Master at: " + masterUrl + " is not available. Index 
fetch failed. Exception: " + e.getMessage());
-return false;
-  }
+final String errorMsg = e.getMessage();
--- End diff --

Granted e.getMessage() was what this code was doing before you made changes 
but can you please use e.toString() instead?  IMO, e.getMessage() should rarely 
if ever be called instead of e.toString() because e.toString() critically 
contains the name of the exception itself.  The "message" alone can be unclear 
without the exception class.  Consider `FileNotFoundException` and there are 
others.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107512860
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -311,7 +359,7 @@ boolean fetchLatestIndex(boolean forceReplication, 
boolean forceCoreReload) thro
 Replica replica = getLeaderReplica();
 CloudDescriptor cd = 
solrCore.getCoreDescriptor().getCloudDescriptor();
 if (cd.getCoreNodeName().equals(replica.getName())) {
-  return false;
+  return IndexFetchResult.CORE_NODE_IS_REPLICA;
--- End diff --

Maybe call this NOT_LEADER ?  Even a leader is a replica (it's the _role_ a 
replica plays).  Granted many of us promote this ambiguity because we haven't 
clearly/consistently labelled a non-leader, e.g. a follower.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[GitHub] lucene-solr pull request #169: Add status return for replication SOLR-10249

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/169#discussion_r107514170
  
--- Diff: solr/core/src/java/org/apache/solr/handler/IndexFetcher.java ---
@@ -161,6 +163,52 @@
 
   private Integer soTimeout;
 
+  private static final String INTERRUPT_RESPONSE_MESSAGE = "Interrupted 
while waiting for modify lock";
+
+  public static class IndexFetchResult {
--- End diff --

I really like how you modeled this return object.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-10348) unexpected sow=false interaction with defaultSearchField

[Christine Poerschke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christine Poerschke updated SOLR-10348:
---
Attachment: SOLR-10348.patch

> unexpected sow=false interaction with defaultSearchField
> 
>
> Key: SOLR-10348
> URL: https://issues.apache.org/jira/browse/SOLR-10348
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10348.patch
>
>
> Came across this as part of SOLR-10264 test development, walkback extract 
> shown below, will attach patch used to reproduce.
> {code}
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7417 INFO  (qtp45246903-42) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=21
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=true
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7421 INFO  (qtp45246903-35) [x:collection1] 
> o.a.s.c.S.Request [collection1]  webapp=/solr path=/select 
> params={q=managed_en_field:happy+test=on=true=xml} hits=1 
> status=0 QTime=1
> [junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=false
> [junit4]   1> cpoerschke debug: query=managed_en_field:happy test
> [junit4]   2> 7424 ERROR (qtp45246903-40) [x:collection1] 
> o.a.s.h.RequestHandlerBase 
> org.apache.solr.search.QueryParserConfigurationException: Field 'text': 
> fieldAutoGenPhraseQueries == true is disallowed when sow/splitOnWhitespace == 
> false
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:953)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:692)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Term(QueryParser.java:424)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Clause(QueryParser.java:281)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.Query(QueryParser.java:225)
> [junit4]   2>at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:134)
> [junit4]   2>at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:212)
> [junit4]   2>at 
> org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:53)
> [junit4]   2>at 
> org.apache.solr.search.QParser.getQuery(QParser.java:168)
> [junit4]   2>at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:161)
> [junit4]   2>at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:268)
> [junit4]   2>at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
> [junit4]   2>at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)
> {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-10348) unexpected sow=false interaction with defaultSearchField

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-10348:
--

 Summary: unexpected sow=false interaction with defaultSearchField
 Key: SOLR-10348
 URL: https://issues.apache.org/jira/browse/SOLR-10348
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Priority: Minor


Came across this as part of SOLR-10264 test development, walkback extract shown 
below, will attach patch used to reproduce.
{code}
[junit4]   1> cpoerschke debug: newFieldName=managed_en_field
[junit4]   1> cpoerschke debug: query=managed_en_field:happy test
[junit4]   2> 7417 INFO  (qtp45246903-42) [x:collection1] o.a.s.c.S.Request 
[collection1]  webapp=/solr path=/select 
params={q=managed_en_field:happy+test=on=true=xml} hits=1 
status=0 QTime=21
[junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=true
[junit4]   1> cpoerschke debug: query=managed_en_field:happy test
[junit4]   2> 7421 INFO  (qtp45246903-35) [x:collection1] o.a.s.c.S.Request 
[collection1]  webapp=/solr path=/select 
params={q=managed_en_field:happy+test=on=true=xml} hits=1 
status=0 QTime=1
[junit4]   1> cpoerschke debug: newFieldName=managed_en_field sow=false
[junit4]   1> cpoerschke debug: query=managed_en_field:happy test
[junit4]   2> 7424 ERROR (qtp45246903-40) [x:collection1] 
o.a.s.h.RequestHandlerBase 
org.apache.solr.search.QueryParserConfigurationException: Field 'text': 
fieldAutoGenPhraseQueries == true is disallowed when sow/splitOnWhitespace == 
false
[junit4]   2>at 
org.apache.solr.parser.QueryParser.newFieldQuery(QueryParser.java:62)
[junit4]   2>at 
org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:953)
[junit4]   2>at 
org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:692)
[junit4]   2>at 
org.apache.solr.parser.QueryParser.Term(QueryParser.java:424)
[junit4]   2>at 
org.apache.solr.parser.QueryParser.Clause(QueryParser.java:281)
[junit4]   2>at 
org.apache.solr.parser.QueryParser.Query(QueryParser.java:225)
[junit4]   2>at 
org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:134)
[junit4]   2>at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:212)
[junit4]   2>at 
org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:53)
[junit4]   2>at 
org.apache.solr.search.QParser.getQuery(QParser.java:168)
[junit4]   2>at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:161)
[junit4]   2>at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:268)
[junit4]   2>at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:173)
[junit4]   2>at 
org.apache.solr.core.SolrCore.execute(SolrCore.java:2464)
{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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Andi Vajda]

On Tue, 21 Mar 2017, jim ferenczi wrote:


Please vote for release candidate 1 for Lucene/Solr 6.5.0


+1

I checked out branch_6_5 and built PyLucene with it, all tests pass.

Andi..



The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95

You can run the smoke tester directly with this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95

Here's my +1
SUCCESS! [0:49:02.989006]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-10347) Remove index level boost support from "documents" section of the admin UI

[JIRA]

Tomás Fernández Löbbe created SOLR-10347:


 Summary: Remove index level boost support from "documents" section 
of the admin UI
 Key: SOLR-10347
 URL: https://issues.apache.org/jira/browse/SOLR-10347
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Admin UI
Reporter: Tomás Fernández Löbbe


Index-time boost is deprecated since LUCENE-6819



--
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-10345) I posted 3 documents from post.jar but when i partial update the document means just update one field then then after updating i searched for a word it doesn't reply su

[Waleed Raza (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936972#comment-15936972
 ] 

Waleed Raza commented on SOLR-10345:


just removing copy field i solved my problem :)

> I posted 3 documents from post.jar but when i partial update the document 
> means just update one field then then after updating i searched for a word it 
> doesn't reply successfully.means after partial update it lost the contents of 
> the documents.
> 
>
> Key: SOLR-10345
> URL: https://issues.apache.org/jira/browse/SOLR-10345
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.4.2
>Reporter: Waleed Raza
>




--
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-10345) I posted 3 documents from post.jar but when i partial update the document means just update one field then then after updating i searched for a word it doesn't reply succe

[Alexandre Rafalovitch (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Rafalovitch closed SOLR-10345.

Resolution: Information Provided

> I posted 3 documents from post.jar but when i partial update the document 
> means just update one field then then after updating i searched for a word it 
> doesn't reply successfully.means after partial update it lost the contents of 
> the documents.
> 
>
> Key: SOLR-10345
> URL: https://issues.apache.org/jira/browse/SOLR-10345
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.4.2
>Reporter: Waleed Raza
>




--
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-10345) I posted 3 documents from post.jar but when i partial update the document means just update one field then then after updating i searched for a word it doesn't reply su

[Alexandre Rafalovitch (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936940#comment-15936940
 ] 

Alexandre Rafalovitch commented on SOLR-10345:
--

Please ask these questions on the Solr User mailing list first as - most likely 
- it is not a bug in Solr. 

Start from 
https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents

And note that if your field is a destination of copyFields and you use atomic 
updates, you probably don't want to store that target field nor have unique 
values in it. It should *only* be a target for other fields' content.

> I posted 3 documents from post.jar but when i partial update the document 
> means just update one field then then after updating i searched for a word it 
> doesn't reply successfully.means after partial update it lost the contents of 
> the documents.
> 
>
> Key: SOLR-10345
> URL: https://issues.apache.org/jira/browse/SOLR-10345
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.4.2
>Reporter: Waleed Raza
>




--
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 # 3913 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3913/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

5 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([170A46983A75DFA8:BF3CD845A51434F2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1394)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1087)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1057)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:232)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
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 

[jira] [Updated] (SOLR-10346) Clean up static page HTML top nav

[Cassandra Targett (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cassandra Targett updated SOLR-10346:
-
Attachment: SRG-top-nav-20170322.png

> Clean up static page HTML top nav
> -
>
> Key: SOLR-10346
> URL: https://issues.apache.org/jira/browse/SOLR-10346
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
> Attachments: SRG-top-nav-20170322.png
>
>
> For demo purposes, the top navigation bar for the HTML version of the Ref 
> Guide includes some stuff we probably don't want in production. This should 
> be cleaned up and finalized.
> I'll attach a screenshot of the current nav for reference. It currently has 
> these sections:
> * Home link. This should be made dynamic to update automatically for each 
> version the Guide applies to
> * News. Probably don't need this? Today it goes nowhere, but it could go to 
> the News section of the Solr website.
> * Jekyll Resources. Links to stuff about Jekyll. We don't want this.
> * Solr Resources. Links to Javadocs, Source code and Community page of Solr 
> website. Javadoc links should be dynamic.
> * Feedback. Javascript to open local Mail application to send an email. 
> Currently goes to my apache.org address, which I don't want.
> * Search box. This can stay, and we can modify it to do whatever we want it 
> to do when SOLR-10299 is resolved.



--
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-10345) I posted 3 documents from post.jar but when i partial update the document means just update one field then then after updating i searched for a word it doesn't reply su

[Waleed Raza (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936925#comment-15936925
 ] 

Waleed Raza commented on SOLR-10345:


So what is the solution that after partial update it remains same. i also made 
all fields stored=true . text of the file is stored in _text_ field when i 
update any other field then that field is updated but also _text_ field is 
updated as new value which set to other field

> I posted 3 documents from post.jar but when i partial update the document 
> means just update one field then then after updating i searched for a word it 
> doesn't reply successfully.means after partial update it lost the contents of 
> the documents.
> 
>
> Key: SOLR-10345
> URL: https://issues.apache.org/jira/browse/SOLR-10345
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.4.2
>Reporter: Waleed Raza
>




--
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-10346) Clean up static page HTML top nav

[Cassandra Targett (JIRA)]

Cassandra Targett created SOLR-10346:


 Summary: Clean up static page HTML top nav
 Key: SOLR-10346
 URL: https://issues.apache.org/jira/browse/SOLR-10346
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Reporter: Cassandra Targett
 Attachments: SRG-top-nav-20170322.png

For demo purposes, the top navigation bar for the HTML version of the Ref Guide 
includes some stuff we probably don't want in production. This should be 
cleaned up and finalized.

I'll attach a screenshot of the current nav for reference. It currently has 
these sections:

* Home link. This should be made dynamic to update automatically for each 
version the Guide applies to
* News. Probably don't need this? Today it goes nowhere, but it could go to the 
News section of the Solr website.
* Jekyll Resources. Links to stuff about Jekyll. We don't want this.
* Solr Resources. Links to Javadocs, Source code and Community page of Solr 
website. Javadoc links should be dynamic.
* Feedback. Javascript to open local Mail application to send an email. 
Currently goes to my apache.org address, which I don't want.
* Search box. This can stay, and we can modify it to do whatever we want it to 
do when SOLR-10299 is resolved.



--
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-10345) I posted 3 documents from post.jar but when i partial update the document means just update one field then then after updating i searched for a word it doesn't reply succ

[Waleed Raza (JIRA)]

Waleed Raza created SOLR-10345:
--

 Summary: I posted 3 documents from post.jar but when i partial 
update the document means just update one field then then after updating i 
searched for a word it doesn't reply successfully.means after partial update it 
lost the contents of the documents.
 Key: SOLR-10345
 URL: https://issues.apache.org/jira/browse/SOLR-10345
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Affects Versions: 6.4.2
Reporter: Waleed Raza






--
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-10323) SpellingQueryConverter does not remove ":" char when using fielded queries

[Amrit Sarkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936915#comment-15936915
 ] 

Amrit Sarkar edited comment on SOLR-10323 at 3/22/17 6:51 PM:
--

SOLR-10323.patch uploaded which will ignore ":" and "(" throughout the original 
term. This fixes our problem but an overhead comes around as the 
SpellingQueryConverter will break if the original term is like:

foo:bar(random)  ===> [bar, random]
foo:bar:bar ===> [bar, bar], in current code, this happens already

and there is no way to escape it like:
foo:bar\(random)
foo:bar\:bar

But this will work perfectly with other special characters like underscores, 
highen and alphanumerics.

I will add relevant test cases very soon if we have a +1 with the stated 
compromise.


was (Author: sarkaramr...@gmail.com):
SOLR-10323.patch uploaded which will ignore ":" and "(" throughout the original 
term. This fixes our problem but an overhead comes around as the 
SpellingQueryConverter will break if the original term is like:

foo:bar*(*random)  ===> [bar, random]
foo:bar*:*bar ===> [bar, bar], in current code, this happens already

and there is no way to escape it like:
foo:bar*\(*random)
foo:bar*\:*bar

But this will work perfectly with other special characters like underscores, 
highen and alphanumerics.

I will add relevant test cases very soon if we have a +1 with the stated 
compromise.

> SpellingQueryConverter does not remove ":" char when using fielded queries
> --
>
> Key: SOLR-10323
> URL: https://issues.apache.org/jira/browse/SOLR-10323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: Michael Pellegrini
> Attachments: SOLR-10323.patch
>
>
> If you pass a fielded query to {{SpellingQueryConverter.convert}}, it returns 
> a token that is prefixed with a ":" char.
> Example: The query "foo:bar" is converted to ":bar"
> This bug seems to have been introduced by the fix for SOLR-2556. Before this 
> patch, {{SpellingQueryConverter.convert}} returned tokens without the leading 
> colon char.



--
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-10323) SpellingQueryConverter does not remove ":" char when using fielded queries

[Amrit Sarkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amrit Sarkar updated SOLR-10323:

Attachment: SOLR-10323.patch

SOLR-10323.patch uploaded which will ignore ":" and "(" throughout the original 
term. This fixes our problem but an overhead comes around as the 
SpellingQueryConverter will break if the original term is like:

foo:bar*(*random)  ===> [bar, random]
foo:bar*:*bar ===> [bar, bar], in current code, this happens already

and there is no way to escape it like:
foo:bar*\(*random)
foo:bar*\:*bar

But this will work perfectly with other special characters like underscores, 
highen and alphanumerics.

I will add relevant test cases very soon if we have a +1 with the stated 
compromise.

> SpellingQueryConverter does not remove ":" char when using fielded queries
> --
>
> Key: SOLR-10323
> URL: https://issues.apache.org/jira/browse/SOLR-10323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: Michael Pellegrini
> Attachments: SOLR-10323.patch
>
>
> If you pass a fielded query to {{SpellingQueryConverter.convert}}, it returns 
> a token that is prefixed with a ":" char.
> Example: The query "foo:bar" is converted to ":bar"
> This bug seems to have been introduced by the fix for SOLR-2556. Before this 
> patch, {{SpellingQueryConverter.convert}} returned tokens without the leading 
> colon char.



--
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-10264) ManagedSynonymFilterFactory does not parse multi-term synonyms

[Christine Poerschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936906#comment-15936906
 ] 

Christine Poerschke commented on SOLR-10264:


Dug a little further re: the {{sow}} (split-on-whitespace) error encountered as 
per above and found at 
[schema-rest.xml#L623|https://github.com/apache/lucene-solr/blob/master/solr/core/src/test-files/solr/collection1/conf/schema-rest.xml#L623]
 {{text}} which would partly explain 
the consideration of the {{text}} field though not fully since the search is 
asking for the {{managed_en_field}} field, hmm.

> ManagedSynonymFilterFactory does not parse multi-term synonyms
> --
>
> Key: SOLR-10264
> URL: https://issues.apache.org/jira/browse/SOLR-10264
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.4.2
>Reporter: Jörg Rathlev
>Priority: Minor
> Attachments: SOLR-10264.patch, SOLR-10264.patch, SOLR-10264.patch, 
> SOLR-10264-test.patch
>
>
> The parser that the {{ManagedSynonymFilterFactory}} uses to parse the JSON 
> resource into a synonym map does not parse multi-term synonyms in the 
> expected way.
> If the synonym {"foo bar":"baz"} is added to the managed resource, the 
> expected behavior is that the multi-term synonym "foo bar" will be mapped to 
> the synonym "baz".
> In the {{analyze}} method of {{SynonymMap.Parser}}, multiple origin terms are 
> concatenated with a separating {{SynonymMap.WORD_SEPARATOR}}, but the 
> {{analyze}} method is not used by the parser in the 
> {{ManagedSynonymFilterFactory}}.
> As a workaround, multi-term synonyms can be uploaded separated by a null 
> character, i.e., uploading {"foo\ubar":"baz"} works.



--
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-10298) Reduce size of new Ref Guide PDF

[Cassandra Targett (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936904#comment-15936904
 ] 

Cassandra Targett commented on SOLR-10298:
--

Would something like [Ghost4J|http://www.ghost4j.org/] help?

> Reduce size of new Ref Guide PDF
> 
>
> Key: SOLR-10298
> URL: https://issues.apache.org/jira/browse/SOLR-10298
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>
> The new Ref Guide PDF is ~31Mb in size, which is more than 2x the current PDF 
> produced by Confluence (which is 14Mb).
> The asciidoctor-pdf project has a script to optimize the PDF, mostly by 
> scaling down images. When I run this tool on the new PDF, the size is reduced 
> to ~18Mb. (More info on this script: 
> https://github.com/asciidoctor/asciidoctor-pdf#optional-scripts).
> Some of the current image files are very large in size, so I believe that by 
> scaling the images down, we can make the size smaller without adding a step 
> in the build to run the optimize script programmatically (it also has a 
> dependency on GhostScript, so it would be nice to not add another dependency 
> if it can be avoided).
> The new PDF is also about 300 pages longer, but this issue is primarily 
> concerned with file size. However, reducing the number of pages will also 
> make it smaller. A few things that could be tried to reduce the # of pages:
> * Reduce font sizes
> * Increase page margins
> * Review options for when a forced page-break is used and modify if possible



--
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-10343) Update Solr default/example configs to use SynonymGraphFilterFactory

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SOLR-10343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomás Fernández Löbbe updated SOLR-10343:
-
Issue Type: Task  (was: Bug)

> Update Solr default/example configs to use SynonymGraphFilterFactory
> 
>
> Key: SOLR-10343
> URL: https://issues.apache.org/jira/browse/SOLR-10343
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>
> {{SynonymFilterFactory}} was deprecated in LUCENE-6664



--
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-10344) Update Solr default/example configs to use WordDelimiterGraphFilterFactory

[JIRA]

Tomás Fernández Löbbe created SOLR-10344:


 Summary: Update Solr default/example configs to use 
WordDelimiterGraphFilterFactory
 Key: SOLR-10344
 URL: https://issues.apache.org/jira/browse/SOLR-10344
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe


{{WordDelimiterFilterFactory}} was deprecated in LUCENE-7619



--
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-10343) Update Solr default/example configs to use SynonymGraphFilterFactory

[JIRA]

Tomás Fernández Löbbe created SOLR-10343:


 Summary: Update Solr default/example configs to use 
SynonymGraphFilterFactory
 Key: SOLR-10343
 URL: https://issues.apache.org/jira/browse/SOLR-10343
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomás Fernández Löbbe


{{SynonymFilterFactory}} was deprecated in LUCENE-6664



--
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-9986) Implement DatePointField

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936823#comment-15936823
 ] 

Tomás Fernández Löbbe commented on SOLR-9986:
-

Note that the last commit (8a99675 and 9382ddb) is only Javadoc and it didn't 
make it to version 6.5. Sorry if it caused any confusion. 

> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9986.patch, SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
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-7729) Support for string type separator for CustomSeparatorBreakIterator

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936810#comment-15936810
 ] 

David Smiley commented on LUCENE-7729:
--

Nice work Amrit.  Just curious; is this feature driven by a search-app 
requirement or ...

One issue with the implementation I see is that if it starts to find a match 
but ultimately doesn't, then the position is not reset back to the start (plus 
1).  This means hypothetically a string separator of {{ab}} would fail to find 
the substring in the input {{aab}}.  I didn't try with your patch but do you 
concur?  I'm a little concerned about possible overhead for this mode.  Maybe 
subclassing to override advanceForward and advanceBackward would make sense.  
If this were an inner class to do the string, then a factory method instead of 
constructor could be used.  I think CustomSeparatorBreakIterator should 
continue to accept a single char constructor arg; I imagine most uses of this 
would remain to be one character.

nitpick: most Lucene/Solr code is stylistically different than yours.  Please 
always use braces where they are optional in Java.  And please always put 
spaces around keywords, and around squiggly brackets.  If per chance you use 
IntelliJ, then "ant idea" should have the formatting already configured.

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
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-9990) Add PointFields as pField in example/default schemas

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936795#comment-15936795
 ] 

Varun Thacker commented on SOLR-9990:
-

Thanks for the clarification. Should have looked at the new managed-schema more 
closely before commenting.

> Add PointFields as pField in example/default schemas
> 
>
> Key: SOLR-9990
> URL: https://issues.apache.org/jira/browse/SOLR-9990
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9990.patch
>
>
> Followup task of SOLR-8396



--
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-9986) Implement DatePointField

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936796#comment-15936796
 ] 

ASF subversion and git services commented on SOLR-9986:
---

Commit 9382ddb3fa93c53c3a5c62abf465031e2f6c24e1 in lucene-solr's branch 
refs/heads/branch_6x from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9382ddb ]

SOLR-9986: Add javadoc to DatePointField class


> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9986.patch, SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
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-9986) Implement DatePointField

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936789#comment-15936789
 ] 

ASF subversion and git services commented on SOLR-9986:
---

Commit 8a996753920170ac1e6e8960d6b63848ccc1ea44 in lucene-solr's branch 
refs/heads/master from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8a99675 ]

SOLR-9986: Add javadoc to DatePointField class


> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Cao Manh Dat
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9986.patch, SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
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-10323) SpellingQueryConverter does not remove ":" char when using fielded queries

[Amrit Sarkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936766#comment-15936766
 ] 

Amrit Sarkar commented on SOLR-10323:
-

The issue seems to be bigger than that:

In SpellingQueryConverterTest::testNumeric()

{code}
@Test
  public void testNumeric() throws Exception {
SpellingQueryConverter converter = new SpellingQueryConverter();
converter.init(new NamedList());
converter.setAnalyzer(new WhitespaceAnalyzer());
String[] queries = {"12345", "foo:12345", "12345 67890", "foo:(12345 
67890)", "foo:(life 67890)", "12345 life",
"+12345 +life", "-12345 life"};
int[] tokensToExpect = {1, 1, 2, 2, 2, 2, 2, 2};
for (int i = 0; i < queries.length; i++) {
  Collection tokens = converter.convert(queries[i]);
  System.out.println("tkns for "+queries[i]+" >> "+tokens);
  assertTrue("tokens Size: " + tokens.size() + " is not: " + 
tokensToExpect[i], tokens.size() == tokensToExpect[i]);
}
  }
{code}

{code}
tkns for 12345 >> [12345]
tkns for foo:12345 >> [:12345]
tkns for 12345 67890 >> [12345, 67890]
tkns for foo:(12345 67890) >> [(12345, 67890]
tkns for foo:(life 67890) >> [(life, 67890]
tkns for 12345 life >> [12345, life]
tkns for +12345 +life >> [+12345, +life]
tkns for -12345 life >> [-12345, life]
{code}

Observe *(* coming anywhere, braces are not handled too. Test cases are not 
hard enough there.

> SpellingQueryConverter does not remove ":" char when using fielded queries
> --
>
> Key: SOLR-10323
> URL: https://issues.apache.org/jira/browse/SOLR-10323
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Affects Versions: 6.2.1
>Reporter: Michael Pellegrini
>
> If you pass a fielded query to {{SpellingQueryConverter.convert}}, it returns 
> a token that is prefixed with a ":" char.
> Example: The query "foo:bar" is converted to ":bar"
> This bug seems to have been introduced by the fix for SOLR-2556. Before this 
> patch, {{SpellingQueryConverter.convert}} returned tokens without the leading 
> colon char.



--
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

Re: [VOTE] Release Lucene/Solr 6.5.0 RC1

[Tomás Fernández Löbbe]

+1
SUCCESS! [0:39:59.070517]

On Wed, Mar 22, 2017 at 5:27 AM, David Smiley 
wrote:

> +1
>
>
> SUCCESS! [1:02:15.276954]
>
> Thanks for being the RM Jim.
>
> On Tue, Mar 21, 2017 at 5:55 PM jim ferenczi 
> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 6.5.0
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-
>> rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.5.0-RC1-
>> rev4b16c9a10c3c00cafaf1fc92ec3276a7bc7b8c95
>>
>> Here's my +1
>> SUCCESS! [0:49:02.989006]
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

[jira] [Updated] (SOLR-10337) HTMLStripCharFilterFactory does not seem to handle

[NW Brad (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

NW Brad updated SOLR-10337:
---
Description: 
HTMLStripCharFilterFactory does not remove  sections from the  
section of HTML document, but works fine in the  section.
NOTE (03/22/2017):  This is occurring when when using ExtractingRequestHandler 
via a curl command:
e.g curl http://localhost:8983/solr/test_core/update/extract?literal.id=33 -F 
"myfile=@test_data/a_simple_html_page_jira.htm"
It will work correctly in the Analysis tab of the Solr Admin tool for the same 
configuration.


Fails remove