Re: [JENKINS] Lucene » Lucene-Solr-Tests-8.x - Build # 1343 - Still Unstable!

[Munendra S N]

This failure seems to be introduced in
https://issues.apache.org/jira/browse/SOLR-14999


On Sat, Jan 9, 2021 at 7:44 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build:
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1343/
>
> 2 tests failed.
> FAILED:  org.apache.solr.core.TestSolrXml.testCloudConfigRequiresHostPort
>
> Error Message:
>  Expected: (an instance of org.apache.solr.common.SolrException and
> exception with message a string containing "solrcloud section missing
> required entry 'hostPort'")  but: exception with message a string
> containing "solrcloud section missing required entry 'hostPort'" message
> was "Error parsing 'hostPort', value 'null' cannot be parsed as int"
> Stacktrace was: org.apache.solr.common.SolrException: Error parsing
> 'hostPort', value 'null' cannot be parsed as int  at
> org.apache.solr.core.SolrXmlConfig.parseInt(SolrXmlConfig.java:271)  at
> org.apache.solr.core.SolrXmlConfig.fillSolrCloudSection(SolrXmlConfig.java:425)
> at org.apache.solr.core.SolrXmlConfig.fromConfig(SolrXmlConfig.java:118)
> at
> org.apache.solr.core.SolrXmlConfig.fromInputStream(SolrXmlConfig.java:190)
> at org.apache.solr.core.SolrXmlConfig.fromString(SolrXmlConfig.java:175)
> at
> org.apache.solr.core.TestSolrXml.testCloudConfigRequiresHostPort(TestSolrXml.java:328)
> 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:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:258)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)  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 org.junit.rules.RunRules.evaluate(RunRules.java:20)  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:947)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)  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
> 

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

[Munendra S N]

Test failure is fixed now
https://github.com/apache/lucene-solr/commit/514c4b1e491c1c93b7b928731437dcbe932237f9

Thanks,
Munendra S N



On Fri, Jan 8, 2021 at 12:00 AM Munendra S N 
wrote:

> I'm looking into this
>
> Regards,
> Munendra S N
>
>
>
> On Thu, Jan 7, 2021 at 11:54 PM Chris Hostetter 
> wrote:
>
>>
>> : WHen I try your exact repro line (along with the method name), I get:
>> : BUILD FAILED
>> : /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a
>> : single test was executed (a typo in the filter pattern maybe?).
>>
>> your repo is stale Ishan -- it's a test that was committed today...
>>
>> https://issues.apache.org/jira/browse/SOLR-14950
>>
>>
>> : On Thu, Jan 7, 2021 at 11:09 PM Timothy Potter 
>> : wrote:
>> :
>> : > This test seems to fail consistently for me on 8x:
>> : >
>> : >
>> : > org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace
>> : >
>> : >
>> : > NOTE: reproduce with: ant test  -Dtestcase=TestBulkSchemaAPI
>> : > -Dtests.method=testCopyFieldWithReplace -Dtests.seed=7657D4FA16A76DC8
>> : > -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-UY
>> : > -Dtests.timezone=America/Resolute -Dtests.asserts=true
>> : > -Dtests.file.encoding=UTF-8
>> : >
>> : > java.lang.AssertionError: {
>> : >   "responseHeader":{
>> : > "status":400,
>> : > "QTime":6},
>> : >   "error":{
>> : > "metadata":[
>> : >
>>  "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
>> : >
>> : >
>> "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
>> : > "details":[{
>> : > "add-field-type":{
>> : >   "name":"myNewTextField",
>> : >   "class":"solr.TextField",
>> : >   "analyzer":{
>> : > "charFilters":[{
>> : > "name":"patternReplace",
>> : > "replacement":"$1$1",
>> : > "pattern":"([a-zA-Z])1+"}],
>> : > "tokenizer":{"name":"whitespace"},
>> : > "filters":[{"name":"asciiFolding"}]}},
>> : > "errorMessages":["Every charFilter must define a class
>> : > property!\n"]}],
>> : > "msg":"error processing commands",
>> : > "code":400}}
>> : >  expected null, but was:<{metadata=[error-class,
>> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject, root-error-class,
>> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject],
>> : > details=[{add-field-type={name=myNewTextField, class=solr.TextField,
>> : > analyzer={charFilters=[{name=patternReplace, replacement=$1$1,
>> : > pattern=([a-zA-Z])\\1+}], tokenizer={name=whitespace},
>> : > filters=[{name=asciiFolding}]}}, errorMessages=[Every charFilter must
>> : > define a class property!
>> : > ]}], msg=error processing commands, code=400}>
>> : >
>> : > at
>> __randomizedtesting.SeedInfo.seed([7657D4FA16A76DC8:B096864C3F5D3F33]:0)
>> : > at org.junit.Assert.fail(Assert.java:89)
>> : > at org.junit.Assert.failNotNull(Assert.java:756)
>> : > at org.junit.Assert.assertNull(Assert.java:738)
>> : > at
>> : >
>> org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace(TestBulkSchemaAPI.java:734)
>> : > 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)
>> : >
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Failing test on branch_8x: org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace

[Munendra S N]

I'm looking into this

Regards,
Munendra S N



On Thu, Jan 7, 2021 at 11:54 PM Chris Hostetter 
wrote:

>
> : WHen I try your exact repro line (along with the method name), I get:
> : BUILD FAILED
> : /home/ishan/code/lucene-solr/lucene/common-build.xml:1616: Not even a
> : single test was executed (a typo in the filter pattern maybe?).
>
> your repo is stale Ishan -- it's a test that was committed today...
>
> https://issues.apache.org/jira/browse/SOLR-14950
>
>
> : On Thu, Jan 7, 2021 at 11:09 PM Timothy Potter 
> : wrote:
> :
> : > This test seems to fail consistently for me on 8x:
> : >
> : >
> : > org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace
> : >
> : >
> : > NOTE: reproduce with: ant test  -Dtestcase=TestBulkSchemaAPI
> : > -Dtests.method=testCopyFieldWithReplace -Dtests.seed=7657D4FA16A76DC8
> : > -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=es-UY
> : > -Dtests.timezone=America/Resolute -Dtests.asserts=true
> : > -Dtests.file.encoding=UTF-8
> : >
> : > java.lang.AssertionError: {
> : >   "responseHeader":{
> : > "status":400,
> : > "QTime":6},
> : >   "error":{
> : > "metadata":[
> : >
>  "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
> : >
> : >
> "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
> : > "details":[{
> : > "add-field-type":{
> : >   "name":"myNewTextField",
> : >   "class":"solr.TextField",
> : >   "analyzer":{
> : > "charFilters":[{
> : > "name":"patternReplace",
> : > "replacement":"$1$1",
> : > "pattern":"([a-zA-Z])1+"}],
> : > "tokenizer":{"name":"whitespace"},
> : > "filters":[{"name":"asciiFolding"}]}},
> : > "errorMessages":["Every charFilter must define a class
> : > property!\n"]}],
> : > "msg":"error processing commands",
> : > "code":400}}
> : >  expected null, but was:<{metadata=[error-class,
> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject, root-error-class,
> : > org.apache.solr.api.ApiBag$ExceptionWithErrObject],
> : > details=[{add-field-type={name=myNewTextField, class=solr.TextField,
> : > analyzer={charFilters=[{name=patternReplace, replacement=$1$1,
> : > pattern=([a-zA-Z])\\1+}], tokenizer={name=whitespace},
> : > filters=[{name=asciiFolding}]}}, errorMessages=[Every charFilter must
> : > define a class property!
> : > ]}], msg=error processing commands, code=400}>
> : >
> : > at
> __randomizedtesting.SeedInfo.seed([7657D4FA16A76DC8:B096864C3F5D3F33]:0)
> : > at org.junit.Assert.fail(Assert.java:89)
> : > at org.junit.Assert.failNotNull(Assert.java:756)
> : > at org.junit.Assert.assertNull(Assert.java:738)
> : > at
> : >
> org.apache.solr.rest.schema.TestBulkSchemaAPI.testCopyFieldWithReplace(TestBulkSchemaAPI.java:734)
> : > 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)
> : >
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Houston Putman to the PMC

[Munendra S N]

Congratulations and welcome, Houston

On Wed, Dec 2, 2020 at 3:37 AM Timothy Potter  wrote:

> Welcome Houston!
>
> On Tue, Dec 1, 2020 at 2:43 PM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> Welcome Houston!!
>>
>> On Tue, Dec 1, 2020 at 1:28 PM Anshum Gupta 
>> wrote:
>>
>>> Congratulations and welcome, Houston!
>>>
>>> On Tue, Dec 1, 2020 at 1:19 PM Mike Drob  wrote:
>>>
 I am pleased to announce that Houston Putman has accepted the PMC's
 invitation to join.

 Congratulations and welcome, Houston!

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


>>>
>>> --
>>> Anshum Gupta
>>>
>>

Re: Welcome Julie Tibshirani as Lucene/Solr committer

[Munendra S N]

Congratulations and welcome Julie!

On Fri, Nov 20, 2020 at 12:38 AM Mayya Sharipova
 wrote:

> Congratulations and welcome Julie!!!
>
> On Thu, Nov 19, 2020 at 1:51 PM Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
>> Welcome Julie!
>>
>> Christine
>>
>> From: dev@lucene.apache.org At: 11/19/20 02:50:57
>> To: dev@lucene.apache.org
>> Subject: Re: Welcome Julie Tibshirani as Lucene/Solr committer
>>
>> Thank you for the warm welcome! It’s a big honor for me -- I’ve been a
>> Lucene fan since the start of my software career. I’m excited to contribute
>> to such a great project.
>>
>> I’m a developer at Elastic focused on core search features. My
>> professional background is in information retrieval and data systems. I
>> also have an interest in statistical computing and machine learning
>> software. I’m originally from Canada but have lived in the SF Bay Area for
>> many years now. Some of my favorite things…
>> * Color: purple
>> * Album: Siamese Dream
>> * Java keyword: final
>>
>> Julie
>>
>> On Wed, Nov 18, 2020 at 6:33 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Welcome Julie!
>>>
>>> On Thu, 19 Nov, 2020, 12:10 am Erick Erickson, 
>>> wrote:
>>>
 Welcome Julie!

 > On Nov 18, 2020, at 1:21 PM, Alexandre Rafalovitch <
 arafa...@gmail.com> wrote:
 >
 > Juliet from the house of Elasticsearch meets a interesting,
 relevancy-aware  committer from the house of Solr.
 >
 > Such a romantic beginning. Not sure I want to know the end of that
 heroine's journey.
 >
 > :-)
 >
 > On Wed., Nov. 18, 2020, 12:59 p.m. Dawid Weiss, <
 dawid.we...@gmail.com> wrote:
 >
 > Congratulations and welcome, Julie.
 >
 > I think juliet is not a bad nick at all, you just need to who -all |
 grep "romeo"... :)
 >
 > Dawid
 >
 > On Wed, Nov 18, 2020 at 4:08 PM Michael Sokolov 
 wrote:
 > I'm pleased to announce that Julie Tibshirani has accepted the PMC's
 > invitation to become a committer.
 >
 > Julie, the tradition is that new committers introduce themselves with
 > a brief bio.
 >
 > I think we may still be sorting out the details of your Apache account
 > (julie@ may have been taken?), but as soon as that has been sorted
 out
 >  and karma has been granted, you can use your new powers to add
 > yourself to the committers section of the Who We Are page on the
 > website: 
 >
 > Congratulations and welcome!
 >
 > Mike Sokolov
 >
 > -
 > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 > For additional commands, e-mail: dev-h...@lucene.apache.org
 >


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


>>

Re: bin/solr testing surprise with techproducts example

[Munendra S N]

The wiki has steps to build solr with gradle
https://cwiki.apache.org/confluence/display/SOLR/Building+Solr+with+Gradle

./gradlew assemble or ./gradlew dev will create runnable solr instance.


On Wed, Sep 23, 2020, 8:01 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Hello everyone.
>
> So I was trying to locally test the small
> https://issues.apache.org/jira/browse/SOLR-11167 change on master branch
> and encountered two things:
>
> Question: What is the replacement for "cd solr ; ant dist server" usage?
>
> If there is an equivalent -- "./gradlew -p solr assembleDist" perhaps? --
> then I'd be happy to update
> https://github.com/apache/lucene-solr/blob/master/help/ant.txt with the
> info.
>
> Observation: "cd solr ; bin/solr start -e techproducts" on master branch
> (but not branch_8x) gives me an error. Is this a known issue already or if
> not could someone try to reproduce the issue before a JIRA ticket is opened?
>
> ERROR: Error CREATEing SolrCore 'techproducts': Unable to create core
> [techproducts] Caused by: [schema.xml] analyzer/tokenizer: missing
> mandatory attribute 'class'
>
> Thanks,
>
> Christine
>

Re: [VOTE] Lucene logo contest, third time's a charm

[Munendra S N]

A1, D (binding)

Regards,
Munendra S N



On Fri, Sep 4, 2020 at 7:02 PM Michael Sokolov  wrote:

> A1, D, A2 (binding)
>
> On Fri, Sep 4, 2020 at 12:46 AM David Smiley  wrote:
> >
> > (binding)
> > vote: D, A1
> >
> >
> > (thanks Ryan for your thorough vote instructions & preparation)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Atri Sharma to the PMC

[Munendra S N]

Congratulations and welcome, Atri!

On Fri, Aug 21, 2020, 11:13 AM Tomás Fernández Löbbe 
wrote:

> Welcome, Atri!
>
> On Thu, Aug 20, 2020 at 2:50 PM Jitendra soni 
> wrote:
>
>> Welcome Atri!
>>
>> On Fri, Aug 21, 2020 at 3:18 AM Nhat Nguyen
>>  wrote:
>>
>>> Welcome Atri!
>>>
>>> On Thu, Aug 20, 2020 at 5:47 PM Gus Heck  wrote:
>>>
 Welcome! :)

 On Thu, Aug 20, 2020 at 4:44 PM jim ferenczi 
 wrote:

> Welcome Atri!
>
> Le jeu. 20 août 2020 à 22:00, Jan Høydahl  a
> écrit :
>
>> Welcome Atri!
>>
>> Jan
>>
>> 20. aug. 2020 kl. 20:16 skrev Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>:
>>
>> 
>> I am pleased to announce that Atri Sharma has accepted the PMC's
>> invitation to join.
>>
>> Congratulations and welcome, Atri!
>>
>>
>>

 --
 http://www.needhamsoftware.com (work)
 http://www.the111shift.com (play)

>>>
>>
>> --
>> Thanks
>> Jitendra
>>
>

Re: [VOTE] Release Lucene/Solr 8.6.1 RC2

[Munendra S N]

+1
SUCCESS! [1:30:17.973222]

Regards,
Munendra S N



On Wed, Aug 12, 2020 at 2:22 PM Noble Paul  wrote:

> SUCCESS! [1:07:08.626970]
> Ubuntu 20.04.1 LTS
>
> On Wed, Aug 12, 2020 at 4:49 PM Atri Sharma  wrote:
> >
> > +1 (non binding).
> >
> > SUCCESS! [1:03:32.13920]
> >
> > On Wed, Aug 12, 2020 at 3:24 AM Gus Heck  wrote:
> > >
> > > SUCCESS! [0:54:03.106188]
> > >
> > > And installed the tarball as a 4 node cluster, created a collection
> and added a document - success :)
> > >
> > > +1
> > >
> > > On Tue, Aug 11, 2020 at 12:13 PM Timothy Potter 
> wrote:
> > >>
> > >> Thanks Houston.
> > >>
> > >> SUCCESS! [1:34:35.219332]
> > >>
> > >> +1
> > >>
> > >> On Mon, Aug 10, 2020 at 1:02 PM Houston Putman <
> houstonput...@gmail.com> wrote:
> > >>>
> > >>> Please vote for release candidate 2 for Lucene/Solr 8.6.1
> > >>>
> > >>> The artifacts can be downloaded from:
> > >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
> > >>>
> > >>> 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-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
> > >>>
> > >>> The vote will be open for at least 72 hours i.e. until 2020-08-13
> 20:00 UTC.
> > >>>
> > >>> [ ] +1  approve
> > >>> [ ] +0  no opinion
> > >>> [ ] -1  disapprove (and reason why)
> > >>>
> > >>> Here is my +1
> > >
> > >
> > >
> > > --
> > > http://www.needhamsoftware.com (work)
> > > http://www.the111shift.com (play)
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Munendra SN to the PMC

[Munendra S N]

Thank you all

Regards,
Munendra S N



On Wed, Aug 5, 2020 at 8:45 PM Michael McCandless 
wrote:

> Welcome Munendra!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Aug 4, 2020 at 5:09 PM David Smiley  wrote:
>
>> Welcome Munendra!
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Aug 2, 2020 at 7:20 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I am pleased to announce that Munendra SN has accepted the PMC's
>>> invitation to join.
>>>
>>> Congratulations and welcome, Munendra!
>>>
>>

Re: Welcome Namgyu Kim to the PMC

[Munendra S N]

Congratulations Namgyu!

Regards,
Munendra S N



On Wed, Aug 5, 2020 at 8:47 PM Michael McCandless 
wrote:

> Welcome Namgyu!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Aug 4, 2020 at 5:08 PM David Smiley  wrote:
>
>> Welcome Namgyu!
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Aug 2, 2020 at 7:20 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I am pleased to announce that Namgyu Kim has accepted the PMC's
>>> invitation to join.
>>>
>>> Congratulations and welcome, Namgyu!
>>>
>>

Re: Welcome Gus Heck to the PMC

[Munendra S N]

Congratulations Gus!

Regards,
Munendra S N



On Wed, Aug 5, 2020 at 8:46 PM Michael McCandless 
wrote:

> Welcome Gus!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Tue, Aug 4, 2020 at 5:09 PM David Smiley  wrote:
>
>> Welcome Gus!
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Aug 2, 2020 at 7:21 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I am pleased to announce that Gus Heck has accepted the PMC's
>>> invitation to join.
>>>
>>> Congratulations and welcome, Gus!
>>>
>>

Re: Welcome Mike Drob to the PMC

[Munendra S N]

Congratulations Mike!

Regards,
Munendra S N



On Sat, Jul 25, 2020 at 9:52 AM David Smiley  wrote:

> Welcome Mike!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jul 24, 2020 at 11:28 PM Kranti Parisa 
> wrote:
>
>> wow, this is great news. Congratulations Mike!
>>
>> Best,
>> Kranti
>>
>>
>>
>> On Fri, Jul 24, 2020 at 4:04 PM Tomás Fernández Löbbe <
>> tomasflo...@gmail.com> wrote:
>>
>>> Welcome Mike!!
>>>
>>> On Fri, Jul 24, 2020 at 3:51 PM Martin Gainty 
>>> wrote:
>>>
>>>> Congratulation Mike!
>>>> martin
>>>>
>>>> --
>>>> *From:* Erick Erickson 
>>>> *Sent:* Friday, July 24, 2020 4:55 PM
>>>> *To:* dev@lucene.apache.org 
>>>> *Subject:* Re: Welcome Mike Drob to the PMC
>>>>
>>>> Welcome Mike!
>>>>
>>>> > On Jul 24, 2020, at 4:12 PM, Ilan Ginzburg 
>>>> wrote:
>>>> >
>>>> > Congratulations Mike, happy to hear that!
>>>> >
>>>> > Ilan
>>>> >
>>>> > On Fri, Jul 24, 2020 at 9:56 PM Anshum Gupta 
>>>> wrote:
>>>> > I am pleased to announce that Mike Drob has accepted the PMC's
>>>> invitation to join.
>>>> >
>>>> > Congratulations and welcome, Mike!
>>>> >
>>>> > --
>>>> > Anshum Gupta
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>>

Re: Welcome Alessandro Benedetti as a Lucene/Solr committer

[Munendra S N]

Congratulations Alessandro!



On Wed, Mar 18, 2020 at 8:02 PM Houston Putman 
wrote:

> Congrats Alessandro!
>
> On Wed, Mar 18, 2020 at 10:07 AM Tommaso Teofili <
> tommaso.teof...@gmail.com> wrote:
>
>> welcome on board Alessandro, well deserved!
>> I still remember when we were sitting together in the same room having
>> fun with Lucene/Solr a few years ago, keep up the good job !
>>
>> Regards,
>> Tommaso
>>
>> On Wed, 18 Mar 2020 at 14:01, David Smiley 
>> wrote:
>>
>>> Hi all,
>>>
>>> Please join me in welcoming Alessandro Benedetti as the latest
>>> Lucene/Solr committer!
>>>
>>> Alessandro has been contributing to Lucene and Solr in areas such as
>>> More Like This, Synonym boosting, and Suggesters, and other areas for
>>> years.  Furthermore he's been a help to many users on the solr-user mailing
>>> list and has helped others through his blog posts and presentations about
>>> search.  We look forward to his future contributions.
>>>
>>> Congratulations and welcome!  It is a tradition to introduce yourself
>>> with a brief bio, Alessandro.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>

Re: Changes from 6.2.1 to 8.4.1 BaseDistributedSearchTestCase test failure with group.ngroups=true

[Munendra S N]

Hey,

Could you please share the test case which is failing?

Regards,
Munendra S N



On Tue, Mar 3, 2020 at 9:03 AM Sergio Bilello 
wrote:

> Hello!
>
> I am trying to perform an upgrade from solr 6.2.1 to 8.4.1.
>
> I was able to fix 99% of the problems related to deprecated API. The only
> one that I need to figure out is related to BaseDistributedSearchTestCase.
> So I perform a test case where I group the documents with group.ngroups =
> true but I see that the numFound document is not respecting the number of
> records returned. Is there any expected change that could affect my test
> case?
>
> Thanks
>
> Sergio
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.4.1 RC1

[Munendra S N]

+1

SUCCESS! [1:44:01.503865]

Regards,
Munendra S N



On Fri, Jan 10, 2020 at 5:55 PM Gézapeti  wrote:

> I wanted to do this for a while now. Having this smoke tester script is
> neat! :)
>
> SUCCESS! [1:35:44.613132]
>
> +1 (non-binding)
>
> On Fri, Jan 10, 2020 at 10:12 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.4.1
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.1-RC1-rev832bf13dd9187095831caf69783179d41059d013
>>
>> 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-8.4.1-RC1-rev832bf13dd9187095831caf69783179d41059d013
>>
>> The vote will be open for at least 72 hours i.e. until 2020-01-13 10:00
>> UTC.
>>
>> [x] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>> 
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [VOTE] Release Lucene/Solr 8.4.0 RC2

[Munendra S N]

+1

SUCCESS! [1:28:23.323039]



On Fri, Dec 20, 2019 at 3:15 PM Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> +1
>
> SUCCESS! [0:48:58.719194]
>
> On Fri, Dec 20, 2019 at 4:53 AM Adrien Grand  wrote:
>
>> Please vote for release candidate 2 for Lucene/Solr 8.4.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC2-revbc02ab906445fcf4e297f4ef00ab4a54fdd72ca2
>>
>> 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-8.4.0-RC2-revbc02ab906445fcf4e297f4ef00ab4a54fdd72ca2
>>
>> The vote will be open for at least 3 working days, i.e. until 2019-12-28
>> 00:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> --
>> Adrien
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Munendra S N]

+1

SUCCESS! [1:30:13.695296]



On Wed, Dec 18, 2019 at 2:01 PM Andrzej Białecki  wrote:

> +1
>
> SUCCESS! [1:34:39.788377]
>
> On 17 Dec 2019, at 21:13, Anshum Gupta  wrote:
>
> +1
>
> SUCCESS! [1:21:44.176149]
>
> On Tue, Dec 17, 2019 at 10:23 AM Adrien Grand  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> 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-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> The vote will be open for at least 3 working days, i.e. until 2019-12-20
>> 19:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> --
>> Adrien
>>
>
>
> --
> Anshum Gupta
>
>
>

Re: [VOTE] Release Lucene/Solr 8.3.1 RC2

[MUNENDRA S N]

+1

SUCCESS! [1:28:14.138771]



On Fri, Nov 29, 2019 at 8:12 PM Jan Høydahl  wrote:

> +1
>
> SUCCESS! [1:52:34.599842]
>
> I still think https://issues.apache.org/jira/browse/SOLR-13977 is
> important and should be mentioned in release email.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 29. nov. 2019 kl. 10:07 skrev Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
>
> Please vote for release candidate 2 for Lucene/Solr 8.3.1
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> 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-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>
> The vote will be open for at least 72 hours from now.
>
> [x] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

Re: Welcome Houston Putman as Lucene/Solr committer

[MUNENDRA S N]

Congrats and welcome Houston!

Regards,
Munendra S N



On Thu, Nov 14, 2019 at 6:51 PM Karl Wright  wrote:

> Welcome!
> Karl
>
> On Thu, Nov 14, 2019 at 8:17 AM Michael Sokolov 
> wrote:
>
>> Hi Houston, welcome!
>>
>> On Thu, Nov 14, 2019 at 7:23 AM Erick Erickson 
>> wrote:
>> >
>> > Welcome!
>> >
>> > > On Nov 14, 2019, at 5:19 AM, Jan Høydahl 
>> wrote:
>> > >
>> > > Congrats and welcome Houston!
>> > >
>> > > --
>> > > Jan Høydahl, search solution architect
>> > > Cominvent AS - www.cominvent.com
>> > >
>> > >> 14. nov. 2019 kl. 09:57 skrev Anshum Gupta :
>> > >>
>> > >> Hi all,
>> > >>
>> > >> Please join me in welcoming Houston Putman as the latest Lucene/Solr
>> committer!
>> > >>
>> > >> Houston has been involved with the community since 2013, when he
>> first contributed the Analytics contrib module. Since then he has been
>> involved with the community, participated in conferences and spoken about
>> his work with Lucene/Solr. In the recent past, he has been involved with
>> getting Solr to scale on Kubernetes.
>> > >>
>> > >> Looking forward to your commits to the Apache Lucene/Solr project :)
>> > >>
>> > >> Congratulations and welcome, Houston! It's a tradition to introduce
>> yourself with a brief bio.
>> > >>
>> > >> --
>> > >> Anshum Gupta
>> > >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Welcome Atri Sharma as Lucene/Solr committer

[MUNENDRA S N]

Congratulations and welcome, Atri


On Wed, Sep 18, 2019 at 2:12 PM Mikhail Khludnev  wrote:

> Welcome, Atri.
>
> On Wed, Sep 18, 2019 at 10:12 AM Adrien Grand  wrote:
>
>> Hi all,
>>
>> Please join me in welcoming Atri Sharma as Lucene/ Solr committer!
>>
>> If you are following activity on Lucene, this name will likely sound
>> familiar to you: Atri has been very busy trying to improve Lucene over
>> the past months. In particular, Atri recently started improving our
>> top-hits optimizations like early termination on sorted indexes and
>> WAND, when indexes are searched using multiple threads.
>>
>> Congratulations and welcome! It is a tradition to introduce yourself
>> with a brief bio.
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

[jira] [Commented] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-12393:
-

Thanks again. I will make the suggested changes

> ExpandComponent only calculates the score of expanded docs when sorted by 
> score
> ---
>
> Key: SOLR-12393
> URL: https://issues.apache.org/jira/browse/SOLR-12393
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch
>
>
> If you use the ExpandComponent to show expanded docs and if you want the 
> score back (specified in "fl"), it will be NaN if the expanded docs are 
> sorted by anything other than the default score descending.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (SOLR-9802) Cannot group by a datefield in SolrCloud

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-9802:


[~erickerickson]
I would need some suggestions here. There is similar issue in terms component 
too - SOLR-13403. In both cases, main problem is {{Data.toString()}} being 
called.
I have attached patches for both issues which resolves issues but not in the 
best possible way

Initial thoughts was to implement {{toString()}} in {{MutableDateValue}} but as 
{{MutableDateValue}} is just wrapper for {{Date}}, current implementation looks 
good to me. 
I went through usage of {{mutableValue}} across codebase, except in distributed 
grouping and terms component(for point field only), there is an additional 
wrapper for {{mutableValues}} in Solr. So, similarly we could have new wrapper 
class for each {{mutableValue}}



> Cannot group by a datefield in SolrCloud
> 
>
> Key: SOLR-9802
> URL: https://issues.apache.org/jira/browse/SOLR-9802
> Project: Solr
>  Issue Type: Bug
>Reporter: Erick Erickson
>Priority: Major
> Attachments: SOLR-9802.patch
>
>
> While working on SOLR-5260 I ran across this. It is easily reproducible by 
> indexing techproducts to a two-shard collection and then
> =true=manufacturedate_dt
> This works fine stand-alone.
> When 5260 gets checked in look in DocValuesNotIndexedTest.java for a 
> reference to this JIRA and take out the special processing that avoids this 
> bug for a unit test.
> Stack trace:
>   80770 ERROR (qtp845642178-32) [n:127.0.0.1:50799_solr c:dv_coll s:shard1 
> r:core_node2 x:dv_coll_shard1_replica1] o.a.s.h.RequestHandlerBase 
> org.apache.solr.common.SolrException: 
> Invalid Date String:'Mon Feb 02 13:40:21 MSK 239906837'
> 
>   at org.apache.solr.util.DateMathParser.parseMath(DateMathParser.java:234)
>   at org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:530)
>   at 
> org.apache.solr.search.grouping.distributed.command.GroupConverter.fromMutable(GroupConverter.java:59)
>   at 
> org.apache.solr.search.grouping.distributed.command.SearchGroupsFieldCommand.result(SearchGroupsFieldCommand.java:124)
>   at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:57)
>   at 
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:36)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-12393:
-

Thanks David. I removed exception handling changes and moved it to SOLR-13704. 
Approach still remains the same.


> ExpandComponent only calculates the score of expanded docs when sorted by 
> score
> ---
>
> Key: SOLR-12393
> URL: https://issues.apache.org/jira/browse/SOLR-12393
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch
>
>
> If you use the ExpandComponent to show expanded docs and if you want the 
> score back (specified in "fl"), it will be NaN if the expanded docs are 
> sorted by anything other than the default score descending.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-12393) ExpandComponent only calculates the score of expanded docs when sorted by score

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-12393:

Attachment: SOLR-12393.patch

> ExpandComponent only calculates the score of expanded docs when sorted by 
> score
> ---
>
> Key: SOLR-12393
> URL: https://issues.apache.org/jira/browse/SOLR-12393
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12393.patch, SOLR-12393.patch, SOLR-12393.patch
>
>
> If you use the ExpandComponent to show expanded docs and if you want the 
> score back (specified in "fl"), it will be NaN if the expanded docs are 
> sorted by anything other than the default score descending.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-13704:

Fix Version/s: 8.3
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> Return Correct Error code in ExpandComponent for Error cases 
> -
>
> Key: SOLR-13704
> URL: https://issues.apache.org/jira/browse/SOLR-13704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
> Attachments: SOLR-13704.patch, SOLR-13704.patch
>
>
> This is spin-off from SOLR-12393
> In some error cases, wrong error code is returned like
> * expand field is not specified
> * parsing expand query or expand filters fails
> In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-13704:

Status: Patch Available  (was: Open)

> Return Correct Error code in ExpandComponent for Error cases 
> -
>
> Key: SOLR-13704
> URL: https://issues.apache.org/jira/browse/SOLR-13704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13704.patch, SOLR-13704.patch
>
>
> This is spin-off from SOLR-12393
> In some error cases, wrong error code is returned like
> * expand field is not specified
> * parsing expand query or expand filters fails
> In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-13704:
-

 [^SOLR-13704.patch] 
Correct status code when
* expand field is not specified
* parsing expand query or expand filters fails
* invalid fieldtype is specified.

Some of the existing checks in expand assumes that expand is combination with 
collapsing which may not be the case.
Also, when expand.field is date field request fails with status 500

> Return Correct Error code in ExpandComponent for Error cases 
> -
>
> Key: SOLR-13704
> URL: https://issues.apache.org/jira/browse/SOLR-13704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13704.patch
>
>
> This is spin-off from SOLR-12393
> In some error cases, wrong error code is returned like
> * expand field is not specified
> * parsing expand query or expand filters fails
> In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-13704:

Attachment: SOLR-13704.patch

> Return Correct Error code in ExpandComponent for Error cases 
> -
>
> Key: SOLR-13704
> URL: https://issues.apache.org/jira/browse/SOLR-13704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13704.patch, SOLR-13704.patch
>
>
> This is spin-off from SOLR-12393
> In some error cases, wrong error code is returned like
> * expand field is not specified
> * parsing expand query or expand filters fails
> In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-13704:

Attachment: SOLR-13704.patch

> Return Correct Error code in ExpandComponent for Error cases 
> -
>
> Key: SOLR-13704
> URL: https://issues.apache.org/jira/browse/SOLR-13704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13704.patch
>
>
> This is spin-off from SOLR-12393
> In some error cases, wrong error code is returned like
> * expand field is not specified
> * parsing expand query or expand filters fails
> In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Created] (SOLR-13704) Return Correct Error code in ExpandComponent for Error cases

[Munendra S N (Jira)]

Munendra S N created SOLR-13704:
---

 Summary: Return Correct Error code in ExpandComponent for Error 
cases 
 Key: SOLR-13704
 URL: https://issues.apache.org/jira/browse/SOLR-13704
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SearchComponents - other
Reporter: Munendra S N
Assignee: Munendra S N


This is spin-off from SOLR-12393
In some error cases, wrong error code is returned like
* expand field is not specified
* parsing expand query or expand filters fails

In these cases, error code should 400 instead of 500



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (SOLR-13209) NullPointerException from call in org.apache.solr.search.SolrIndexSearcher.getDocSet

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-13209:
-

Similar to SOLR-8319. NPE is because query which is the key is null. 

> NullPointerException from call in 
> org.apache.solr.search.SolrIndexSearcher.getDocSet
> 
>
> Key: SOLR-13209
> URL: https://issues.apache.org/jira/browse/SOLR-13209
> Project: Solr
>  Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s 
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise 
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from 
> the [Solr 
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' > 
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no 
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field": 
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}' 
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary 
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}' 
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will 
> allow you to reproduce the issue reported.
>Reporter: Cesar Rodriguez
>Priority: Minor
>  Labels: diffblue, newdev
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?group=true
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
>  java.lang.NullPointerException
>   at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
>   at 
> org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:124)
>   at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:163)
>   at 
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:792)
>   at 
> org.apache.solr.search.Grouping$CommandQuery.createFirstPassCollector(Grouping.java:860)
>   at org.apache.solr.search.Grouping.execute(Grouping.java:327)
>   at 
> org.apache.solr.handler.component.QueryComponent.doProcessGroupedSearch(QueryComponent.java:1408)
>   at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:365)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2559)
> [...]
> {noformat}
> Method {{org.apache.solr.search.SolrIndexSearcher.getDocSet()}}, at line 792 
> calls {{filterCache.get(absQ)}} where {{absQ}} is a null pointer. I think 
> this null pointer comes in fact from the caller, but I don't fully follow the 
> logic of the code.
> To set up an environment to reproduce this bug, follow the description in the 
> ‘Environment’ field.
> We automatically found this issue and ~70 more like this using [Diffblue 
> Microservices Testing|https://www.diffblue.com/labs/?utm_source=solr-br]. 
> Find more information on this [fuzz testing 
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results?utm_source=solr-br].



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Updated] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-6328:
---
Fix Version/s: 8.3
 Assignee: Munendra S N
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>    Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
> Attachments: SOLR-6328.patch, SOLR-6328.patch, SOLR-6328.patch, 
> SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

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

[jira] [Commented] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-6328:


 [^SOLR-6328.patch] 
Fixes testRandomFaceting

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch, SOLR-6328.patch, 
> SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-6328:
---
Attachment: SOLR-6328.patch

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch, SOLR-6328.patch, 
> SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-9622) ExplainAugmenterFactory does not work on grouped queries

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-9622:


For [explain] to work, {{query}} obj has to be accessible/available, code 
[link|https://github.com/apache/lucene-solr/blob/54ab07718a016c888e69ff4a8070c24cf34d3a51/solr/core/src/java/org/apache/solr/response/transform/ExplainAugmenterFactory.java#L107]
This happens when writing {{doclist}} in response Writer - 
[link|https://github.com/apache/lucene-solr/blob/54ab07718a016c888e69ff4a8070c24cf34d3a51/solr/core/src/java/org/apache/solr/response/TextResponseWriter.java#L139].
 In case of grouping, doclist is produced.

[explain] works with grouping when {{distrib=true}}, as execution flow is 
entirely different. In single node setup, [explain] works when 
{{group.main=true}} due to 
[this|https://github.com/apache/lucene-solr/blob/54ab07718a016c888e69ff4a8070c24cf34d3a51/solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java#L1468]

There could be multiple ways to fix 
* handle other group formats similar to {{group.main=true}}, so that 
{{ResultContext}} is produced from grouping.
* Make query available to response writer(either via rb or directly)
but I don't think either approach is proper or straight-forward


> ExplainAugmenterFactory does not work on grouped queries
> 
>
> Key: SOLR-9622
> URL: https://issues.apache.org/jira/browse/SOLR-9622
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Reporter: Henrik
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-6328:


 [^SOLR-6328.patch] 
Retrigger build

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-6328:
---
Attachment: SOLR-6328.patch

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-6328:
---
Attachment: SOLR-6328.patch

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-6328:
---
Status: Patch Available  (was: Open)

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-6328) facet.limit=0 returns no counts, even if facet.missing=true

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-6328:


 [^SOLR-6328.patch] 
With additional tests

> facet.limit=0 returns no counts, even if facet.missing=true
> ---
>
> Key: SOLR-6328
> URL: https://issues.apache.org/jira/browse/SOLR-6328
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Reporter: Hoss Man
>Priority: Minor
> Attachments: SOLR-6328.patch, SOLR-6328.patch
>
>
> facet.limit constraints the number of term values returned for a field when 
> using facet.field or facet.pivot, but that limit is (suppose) to be 
> independent of facet.missing, which adds an additional count beyond the 
> facet.limit for docs that are "missing" that field.
> This works fine for facet.limit >= 1, but if you use 
> {{facet.limit=0=true}} (ie: you are only interested in the 
> missing count) you get no counts at all -- not even for the missing count.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-9894) Tokenizer work randomly

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-9894 at 8/10/19 1:59 PM:
-

Thanks [~nppoly]

Closing this as not a problem.


was (Author: munendrasn):
Thanks [~nppoly]

Closing this not a problem.

> Tokenizer work randomly
> ---
>
> Key: SOLR-9894
> URL: https://issues.apache.org/jira/browse/SOLR-9894
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 6.2.1
> Environment: solrcloud 6.2.1(3 solr nodes)
> OS:linux
> RAM:8G
>Reporter: 王海涛
>Priority: Critical
>  Labels: patch
> Attachments: step1.png, step2.png, step3.png, step4.png
>
>
> my schema.xml has a fieldType as folow:
> 
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="false"/>
>class="org.wltea.pinyin.solr5.PinyinTokenFilterFactory" pinyinAll="true" 
> minTermLength="2"/> 
>   
>   
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="true"/>
>  
>   
>   
> Attention:
>   index tokenzier useSmart is false
>   query tokenzier useSmart is true
> But when I send query request with parameter q ,
> the query tokenziner sometimes useSmart equals true
> sometimes useSmart equal false.
> That is so terrible!
> I guess the problem may be caught by tokenizer cache.
> when I query ,the tokenizer should use true as the useSmart's value,
> but it had cache the wrong tokenizer result which created by indexWriter who 
> use false as useSmart's value.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-9894) Tokenizer work randomly

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-9894.

Resolution: Not A Problem

Thanks [~nppoly]

Closing this not a problem.

> Tokenizer work randomly
> ---
>
> Key: SOLR-9894
> URL: https://issues.apache.org/jira/browse/SOLR-9894
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 6.2.1
> Environment: solrcloud 6.2.1(3 solr nodes)
> OS:linux
> RAM:8G
>Reporter: 王海涛
>Priority: Critical
>  Labels: patch
> Attachments: step1.png, step2.png, step3.png, step4.png
>
>
> my schema.xml has a fieldType as folow:
> 
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="false"/>
>class="org.wltea.pinyin.solr5.PinyinTokenFilterFactory" pinyinAll="true" 
> minTermLength="2"/> 
>   
>   
>   
>class="org.wltea.analyzer.lucene.IKTokenizerFactory" useSmart="true"/>
>  
>   
>   
> Attention:
>   index tokenzier useSmart is false
>   query tokenzier useSmart is true
> But when I send query request with parameter q ,
> the query tokenziner sometimes useSmart equals true
> sometimes useSmart equal false.
> That is so terrible!
> I guess the problem may be caught by tokenizer cache.
> when I query ,the tokenizer should use true as the useSmart's value,
> but it had cache the wrong tokenizer result which created by indexWriter who 
> use false as useSmart's value.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-11961) group.query and sort with function getting error in solrcloud

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-11961.
-
Resolution: Duplicate

Keeping SOLR-6203 and closing this as duplicate

> group.query and sort with function getting error in solrcloud
> -
>
> Key: SOLR-11961
> URL: https://issues.apache.org/jira/browse/SOLR-11961
> Project: Solr
>  Issue Type: Bug
>  Components: search, SolrCloud
>Affects Versions: 6.4, 6.4.2
>Reporter: adeppa
>Priority: Major
> Attachments: Screen Shot 2018-02-13 at 11.41.45 AM.png
>
>
> while querying combination of group.query and sort function is not working 
>  getting below error 
>  
> Environment : 
>  Solr 6.4.2 and solr cloud mode with two shards and replication factor 2 
>  AWS  with ubuntu 
> query :/solr/qa/select?fq=((level:*.RL AND 
>  im_field_destination_category:7845 AND im_field_geography:6937 AND 
>  im_field_legacy_category:(7875 OR 12949 OR 7902 OR 12954) AND 
>  im_field_report_research_type:7854) OR (im_field_destination_category:7845 
>  AND im_field_geography:6937 AND im_field_legacy_category:(7875 OR 12949 OR 
>  7902 OR 12954) AND im_field_report_research_type:7855 AND 
>  ${sku}))= im_field_deliverable_type:(12941)= 
>  
> im_field_deliverable_type:(12941)=true=on=*:*=sm_field_sku:(manpq7416
>  
>  OR TTPMUS0005A OR TTPXSI1015US OR TTPMUS0004B OR 
>  TTPDPRUS0215)=product(if(exists(query(\{!v="${sku}"})),1,0),2) 
>  desc=json 
> if run same query in sudo node will working ,please help me on this 
> Error: 
> { 
>    "responseHeader":{ 
>      "zkConnected":true, 
>      "status":500, 
>      "QTime":8, 
>      "params":{ 
>        "q":"*:*", 
>        "indent":"on", 
>        "fq":"((level:*.RL AND im_field_destination_category:7845 AND 
>  im_field_geography:6937 AND im_field_legacy_category:(7875 OR 12949 OR 7902 
>  OR 12954) AND im_field_report_research_type:7854) OR 
>  (im_field_destination_category:7845 AND im_field_geography:6937 AND 
>  im_field_legacy_category:(7875 OR 12949 OR 7902 OR 12954) AND 
>  im_field_report_research_type:7855 AND ${sku}))", 
>        "sort":"product(if(exists(query(\{!v=\"${sku}\"})),1,0),2) desc", 
>        "group.query":[" im_field_deliverable_type:(12941)", 
>          " im_field_deliverable_type:(12941)"], 
>        "sku":"sm_field_sku:(manpq7416 OR TTPMUS0005A OR TTPXSI1015US OR 
>  TTPMUS0004B OR TTPDPRUS0215)", 
>        "wt":"json", 
>        "_":"1518098081571", 
>        "group":"true"}}, 
>    "error":{ 
>      "metadata":[ 
>        "error-class","org.apache.solr.common.SolrException", 
>        
>  
> "root-error-class","org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException"],
>  
>      "msg":"org.apache.solr.client.solrj.SolrServerException: No live 
>  SolrServers available to handle this 
>  request:[[http://172.22.0.231:8983/solr/qa_shard1_replica2], 
>  [http://172.22.0.231:8983/solr/qa_shard2_replica2], 
>  [http://172.22.1.249:8983/solr/qa_shard1_replica3]]", 
>      "trace":"org.apache.solr.common.SolrException: 
>  org.apache.solr.client.solrj.SolrServerException: No live SolrServers 
>  available to handle this 
>  request:[[http://172.22.0.231:8983/solr/qa_shard1_replica2], 
>  [http://172.22.0.231:8983/solr/qa_shard2_replica2], 
>  [http://172.22.1.249:8983/solr/qa_shard1_replica3]]\n\tat 
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:415)\n\tat
>  
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)\n\tat
>  
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)\n\tat 
>  org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)\n\tat 
>  org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat 
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)\n\tat
>  
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)\n\tat
>  
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)\n\tat
>  
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>  
>  
&

[jira] [Commented] (SOLR-9815) Verbose Garbage Collection logging is on by default

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-9815:


[~janhoy]

Could this be closed?

> Verbose Garbage Collection logging is on by default
> ---
>
> Key: SOLR-9815
> URL: https://issues.apache.org/jira/browse/SOLR-9815
> Project: Solr
>  Issue Type: Wish
>  Components: logging
>Affects Versions: 6.3
>Reporter: Gethin James
>Priority: Minor
> Attachments: class-log4j-log vs garbage-free-log4j.png
>
>
> There have been some excellent logging fixes in 6.3 
> (http://www.cominvent.com/2016/11/07/solr-logging-just-got-better/).  However 
> now, by default, Solr is logging a great deal of garbage collection 
> information.
> It seems that this logging is excessive, can we make the default logging to 
> not be verbose?
> For linux/mac setting GC_LOG_OPTS="" in solr.in.sh seems to work around the 
> issue, but looking at solr.cmd I don't think that will work for windows.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-11760) Accept Header is not honored / Errors returned in XML instead of JSON

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-11760.
-
Resolution: Duplicate

Keeping SOLR-10998 and closing this as duplicate

> Accept Header is not honored / Errors returned in XML instead of JSON
> -
>
> Key: SOLR-11760
> URL: https://issues.apache.org/jira/browse/SOLR-11760
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 6.6
>Reporter: Chantal Ackermann
>Priority: Minor
>
> We generally request JSON from SOLR, via HTTP with {{wt=json}} (without using 
> a client impl).
> In case of fundamental errors, however, no JSON is returned but XML (either 
> because {{wt=json}} is not transmitted correctly or the request handler that 
> understands this parameter is not executed). It would be nice if in this case 
> the `Accept:application/json` header could be honored.
> {code}
> $ http http://localhost:8983/solr/offers_gb/select q==*:* wt=json rows=1 
> Accept:"application/json" -v
> POST /solr/offers_gb/select?q=%2A%3A%2A HTTP/1.1
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Content-Length: 27
> Content-Type: application/json
> Host: localhost:8983
> User-Agent: HTTPie/0.9.4
> {
> "rows": "1",
> "wt": "json"
> }
> HTTP/1.1 400 Bad Request
> Content-Length: 525
> Content-Type: application/xml; charset=UTF-8
> 
> 
> 400 name="QTime">0*:* name="json">{"wt": "json", "rows": "1"} name="error"> name="error-class">org.apache.solr.common.SolrException name="root-error-class">org.apache.solr.common.SolrException name="msg">Unknown top-level key in JSON request : wt name="code">400
> 
> {code}
> As opposed to:
> {code}
> $ http http://localhost:8983/solr/offers_gb/select q==bla:* wt==json rows==1 
> Accept:"application/json" -v
> GET /solr/offers_gb/select?q=bla%3A%2A=json=1 HTTP/1.1
> Accept: application/json
> Accept-Encoding: gzip, deflate
> Connection: keep-alive
> Host: localhost:8983
> User-Agent: HTTPie/0.9.4
> HTTP/1.1 400 Bad Request
> Cache-Control: no-cache, no-store
> Content-Length: 282
> Content-Type: application/json; charset=UTF-8
> ETag: "1605105208b"
> Expires: Sat, 01 Jan 2000 01:00:00 GMT
> Last-Modified: Wed, 13 Dec 2017 17:56:18 GMT
> Pragma: no-cache
> {
> "error": {
> "code": 400,
> "metadata": [
> "error-class",
> "org.apache.solr.common.SolrException",
> "root-error-class",
> "org.apache.solr.common.SolrException"
> ],
> "msg": "undefined field bla"
> },
> "responseHeader": {
> "QTime": 0,
> "params": {
> "q": "bla:*",
> "rows": "1",
> "wt": "json"
> },
> "status": 400,
> "zkConnected": true
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-8032) unhandled exceptions

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-8032.

Resolution: Not A Problem

Based on above comment resolving this

> unhandled exceptions
> 
>
> Key: SOLR-8032
> URL: https://issues.apache.org/jira/browse/SOLR-8032
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0, 5.1
>Reporter: songwanging
>Priority: Minor
>
> In method close() of class RecoveryStrategy 
> (solr\core\src\java\org\apache\solr\cloud\RecoveryStrategy.java)
> The catch block catch (NullPointerException e) performs no actions to handle 
> its expected exception, which makes itself useless. 
> To fix this bug, we should add more code into the catch block to handle this 
> exception.
> public void close() {
> close = true;
> try {
>   prevSendPreRecoveryHttpUriRequest.abort();
> } catch (NullPointerException e) {
>   // okay
> }
>...
>   }
> ==
> In method startLeaderInitiatedRecoveryOnReplicas() of class ElectionContext 
> (\solr\core\src\java\org\apache\solr\cloud\ElectionContext.java)
> The catch block catch (NoNodeException e) performs no actions to handle its 
> expected exception, which makes itself useless. 
> To fix this bug, we should add more code into the catch block to handle this 
> exception.
>  try {
> replicas = zkClient.getChildren(znodePath, null, false);
>   } catch (NoNodeException nne) {
> // this can be ignored
>   }



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-8102) solr fails connecting to zookeeper on osx jdk 1.8 ipv6

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-8102.

Resolution: Cannot Reproduce

Not able to reproduce. Hence, closing this. Please reopen if you are able to 
reproduce with steps to reproduce the issue

> solr fails connecting to zookeeper on osx jdk 1.8 ipv6
> --
>
> Key: SOLR-8102
> URL: https://issues.apache.org/jira/browse/SOLR-8102
> Project: Solr
>  Issue Type: Bug
>Reporter: Matteo Grolla
>Priority: Major
>
> on my macbook pro I see solr trying connecting to zookeeper, both on 
> localhost, using an ipv6 address.
> This fails because of timeout so my solution has been to add
> -Djava.net.preferIPv4Stack=true
> to java options and everything seems ok now
> hope this helps



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13680:

Resolution: Done
Status: Resolved  (was: Patch Available)

Thanks [~kamaci]

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch, SOLR-13680.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13680:

Issue Type: Improvement  (was: Bug)

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch, SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13680:
-

[^SOLR-13680.patch] 
 Tests were failing due to change in {{ManagedSchema}} so, I have removed them. 
Stream closing is already handled 
[here|https://github.com/apache/lucene-solr/blob/2e5c554fea0aea1dfeecb22f03f18fb78cd4/solr/core/src/java/org/apache/solr/schema/ManagedIndexSchema.java#L142].

If the stream is closed early, managed-schema won't be persisted locally which 
causes test failures

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch, SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13680:

Attachment: SOLR-13680.patch

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch, SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13680:
-

[~kamaci]
Tests are failing, could you please look into it?

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13680:
-

 [^SOLR-13680.patch] 
Attaching the patch generated using Github PR. Not sure why preCommit test 
build didn't trigger.

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13680:

Attachment: SOLR-13680.patch

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13680.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13680:
-

Changes LGTM. Once precommit test build passes, I will commit this

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

Re: [JENKINS] Lucene-Solr-Tests-master - Build # 3499 - Failure

[MUNENDRA S N]

Caused due to SOLR-11866

Regards,
Munendra S N


On Mon, Aug 5, 2019 at 3:47 PM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3499/
>
> All tests passed
>
> Build Log:
> [...truncated 6182 lines...]
> [javac] Compiling 74 source files to
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/highlighter/classes/java
> [javac]
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/highlighter/src/java/org/apache/lucene/search/uhighlight/UnifiedHighlighter.java:104:
> error: cannot find symbol
> [javac]   IndexReader emptyReader = new MultiReader();
> [javac] ^
> [javac]   symbol:   class MultiReader
> [javac]   location: class UnifiedHighlighter
> [javac] 1 error
>
> BUILD FAILED
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:634:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:578:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:59:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build.xml:481:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2181:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/module-build.xml:552:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:519:
> The following error occurred while executing this line:
> /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:1973:
> Compile failed; see the compiler error output for details.
>
> Total time: 29 minutes 54 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> Recording test results
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11866) Support efficient subset matching in query elevation rules

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-11866:
-

This caused compilation error. 
[~dsmiley]
I think by mistake, {{import org.apache.lucene.index.MultiReader}} is removed 
from {{UnifiedHighlighter}}

> Support efficient subset matching in query elevation rules
> --
>
> Key: SOLR-11866
> URL: https://issues.apache.org/jira/browse/SOLR-11866
> Project: Solr
>  Issue Type: Improvement
>  Components: SearchComponents - other
>Affects Versions: 8.0
>Reporter: Bruno Roustant
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.3
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Leverages the SOLR-11865 refactoring by introducing a 
> SubsetMatchElevationProvider in QueryElevationComponent. This provider calls 
> a new util class TrieSubsetMatcher to efficiently match all query elevation 
> rules which subset is contained by the current query list of terms.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13679:

   Resolution: Fixed
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-12555:

Resolution: Done
Status: Resolved  (was: Patch Available)

As  all the try-fail-catch are replaced with expectThrows(), closing this

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, 
> SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-13676.
-
   Resolution: Done
Fix Version/s: 8.3

> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Diego Ceccarelli
>    Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with 
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack 
> trace is printed out in the logs. This small patch avoid the stack trace by 
> using {{ignoreException}}.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13680:

Status: Patch Available  (was: Open)

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (SOLR-13680) Close Resources Properly

[Munendra S N (JIRA)]

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

Munendra S N reassigned SOLR-13680:
---

Assignee: Munendra S N

> Close Resources Properly
> 
>
> Key: SOLR-13680
> URL: https://issues.apache.org/jira/browse/SOLR-13680
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.2
>Reporter: Furkan KAMACI
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Files, streams or connections which implements Closeable or AutoCloseable 
> interface should be closed after use.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13679:
-

 [^SOLR-13679.patch] 
Change the default Style to {{text}} the value used in case of docTransformer 
registered in {{defaultFactories}}

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13679:

Attachment: SOLR-13679.patch

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N reassigned SOLR-13679:
---

Assignee: Munendra S N

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13679:
-

 [^SOLR-13679.patch] 
Default Style for ExplainAugumenter is set to {{nl}}. This could have backward 
compatibility issues. So, will be pushing only to master

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13679:

Status: Patch Available  (was: Open)

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13679:

Attachment: SOLR-13679.patch

> Different default Style for [explain] doctransformer registered in 
> solrconfig.xml 
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>    Reporter: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
>  class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this 
> without adding it in solrconfig.xml but when used this way, default style 
> used is {{text}}
> Default style should be same in both cases. This behavior is same to 
> registering ResponseWriters in solrconfig, if content-type is not overridden 
> then, default content-type will used



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Assigned] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException

[Munendra S N (JIRA)]

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

Munendra S N reassigned SOLR-13676:
---

Assignee: Munendra S N

> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Diego Ceccarelli
>    Assignee: Munendra S N
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with 
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack 
> trace is printed out in the logs. This small patch avoid the stack trace by 
> using {{ignoreException}}.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml

[Munendra S N (JIRA)]

Munendra S N created SOLR-13679:
---

 Summary: Different default Style for [explain] doctransformer 
registered in solrconfig.xml 
 Key: SOLR-13679
 URL: https://issues.apache.org/jira/browse/SOLR-13679
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Munendra S N


Adding explain docTransformer via solrconfig.xml
{code:java}

{code}
Here, no style is specified. So, default style is used which is {{nl}}.

ExplainDocTransformer is part of defaultFactories. So, user can use this 
without adding it in solrconfig.xml but when used this way, default style used 
is {{text}}

Default style should be same in both cases. This behavior is same to 
registering ResponseWriters in solrconfig, if content-type is not overridden 
then, default content-type will used





--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-10913) Incosistent function query results inside conditional

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-10913.
-
Resolution: Fixed

This is fixed in SOLR-11758

> Incosistent function query results inside conditional
> -
>
> Key: SOLR-10913
> URL: https://issues.apache.org/jira/browse/SOLR-10913
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.4.1
>Reporter: Mykhailo Kozik
>Priority: Major
>
> Hey, I was trying to simulate gt function on old version of solr (5.5.0) 
> using sub and max
> (afaik, gt is not available on 5.5.0)
> I found strange inconsistency for function queries (reproducible on 6.4.1 as 
> well)
> For simplest usecase, have at least 1 doc in solr collection and provide 
> addition fl parameter:
> fl=*,max(0, 0.9), if(0, 1, 0), if(0.9, 1, 0), if(max(0, 0.9), 1, 0), 
> if(max(0, 1.1), 1, 0)
> The output is following:
> "max(0, 0.9)":0.9,
> "if(0, 1, 0)":0,
> "if(0.9, 1, 0)":1,
> "if(max(0, 0.9), 1, 0)":0,
> "if(max(0, 1.1), 1, 0)":1
> 4th usecase seems strange to me and inconsistent to previous expressions as 
> well.
> Could you clarify if it's a bug or I am doing something wrong.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-11266) V2 API returning wrong content-type

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-11266:

   Resolution: Done
 Assignee: Munendra S N
Fix Version/s: master (9.0)
   Status: Resolved  (was: Patch Available)

> V2 API returning wrong content-type
> ---
>
> Key: SOLR-11266
> URL: https://issues.apache.org/jira/browse/SOLR-11266
> Project: Solr
>  Issue Type: Improvement
>  Components: v2 API
>Reporter: Ishan Chattopadhyaya
>    Assignee: Munendra S N
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-11266.patch, SOLR-11266.patch
>
>
> The content-type of the returned value is wrong in many places. It should 
> return "application/json", but instead returns "application/text-plan".
> Here's an example:
> {code}
> [ishan@t430 ~] $ curl -v 
> "http://localhost:8983/api/collections/products/select?q=*:*=0;
> *   Trying 127.0.0.1...
> * TCP_NODELAY set
> * Connected to localhost (127.0.0.1) port 8983 (#0)
> > GET /api/collections/products/select?q=*:*=0 HTTP/1.1
> > Host: localhost:8983
> > User-Agent: curl/7.51.0
> > Accept: */*
> > 
> < HTTP/1.1 200 OK
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 184
> < 
> {
>   "responseHeader":{
> "zkConnected":true,
> "status":0,
> "QTime":1,
> "params":{
>   "q":"*:*",
>   "rows":"0"}},
>   "response":{"numFound":260,"start":0,"docs":[]
>   }}
> * Curl_http_done: called premature == 0
> * Connection #0 to host localhost left intact
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-12555:
-

 [^SOLR-12555.patch] 
Patch with only solr changes. I'm planning to commit this module by module if 
there are many changes.

[~gerlowskija] any suggestions here?? 

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, 
> SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-12555:

Attachment: SOLR-12555.patch

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, 
> SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated LUCENE-8938:
-
   Resolution: Fixed
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

> Replace try-fail-catch test patterns
> 
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
>  Issue Type: Test
>        Reporter: Munendra S N
>        Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 
> This is spawned from SOLR-12555



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Resolved] (SOLR-13657) Fix TestXPathRecordReader.testUnsupported_Xpaths

[Munendra S N (JIRA)]

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

Munendra S N resolved SOLR-13657.
-
   Resolution: Fixed
Fix Version/s: 8.3

> Fix TestXPathRecordReader.testUnsupported_Xpaths
> 
>
> Key: SOLR-13657
> URL: https://issues.apache.org/jira/browse/SOLR-13657
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.3
>
>
> {{tTestXPathRecordReader.testUnsupported_Xpaths}} covers some negative cases 
> for xpath
> While working on SOLR-12555, found that, here NPE thrown as rr is never set 
> not the expected exception
> {code:java}
>  try {
>   rr.addField("bold"  ,"b",false);
>   fail("A RuntimeException was expected: 'b' xpaths must begin with 
> '/'.");
>   }
> catch (RuntimeException ex) {  }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N commented on LUCENE-8938:
--

 [^LUCENE-8938.patch] 
I have used {{expectThrowsAnyof}} when multiple exceptions can be thrown

> Replace try-fail-catch test patterns
> 
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
>  Issue Type: Test
>        Reporter: Munendra S N
>        Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 
> This is spawned from SOLR-12555



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated LUCENE-8938:
-
Attachment: LUCENE-8938.patch

> Replace try-fail-catch test patterns
> 
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
>  Issue Type: Test
>        Reporter: Munendra S N
>        Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 
> This is spawned from SOLR-12555



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated LUCENE-8938:
-
Status: Patch Available  (was: Open)

> Replace try-fail-catch test patterns
> 
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
>  Issue Type: Test
>        Reporter: Munendra S N
>        Assignee: Munendra S N
>Priority: Major
> Attachments: LUCENE-8938.patch
>
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 
> This is spawned from SOLR-12555



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated LUCENE-8938:
-
Description: Replace try-fail-catch test patterns with {{expectThrows}} 
wherever possible. This is spawned from SOLR-12555  (was: Replace 
try-fail-catch test patterns with {{expectThrows}} wherever possible. )

> Replace try-fail-catch test patterns
> 
>
> Key: LUCENE-8938
> URL: https://issues.apache.org/jira/browse/LUCENE-8938
> Project: Lucene - Core
>  Issue Type: Test
>        Reporter: Munendra S N
>        Assignee: Munendra S N
>Priority: Major
>
> Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 
> This is spawned from SOLR-12555



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-12555:
-

I have created separate lucene issue - LUCENE-8938

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (LUCENE-8938) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

Munendra S N created LUCENE-8938:


 Summary: Replace try-fail-catch test patterns
 Key: LUCENE-8938
 URL: https://issues.apache.org/jira/browse/LUCENE-8938
 Project: Lucene - Core
  Issue Type: Test
Reporter: Munendra S N
Assignee: Munendra S N


Replace try-fail-catch test patterns with {{expectThrows}} wherever possible. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13643) ResponseBuilder should provide accessors/setters for analytics response handling

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13643:
-

{quote}I'm planning make these member variable private in master(9.0){quote}
This is not done. Probably, I will handle it in different jira

> ResponseBuilder should provide accessors/setters for analytics response 
> handling
> 
>
> Key: SOLR-13643
> URL: https://issues.apache.org/jira/browse/SOLR-13643
> Project: Solr
>  Issue Type: Task
>  Components: Response Writers
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>Assignee: Munendra S N
>Priority: Trivial
> Fix For: 8.3
>
> Attachments: 
> SOLR-13643-Create-accessors-setters-in-ResponseBuild.patch, 
> SOLR-13643-Create-accessors-setters-in-ResponseBuild.patch, SOLR-13643.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Right now inside o.a.s.h.c.AnalyticsComponent.java, fields inside 
> ResponseBuilder are accessed directly.  Since they're in the same package, 
> this is OK at compile tie.  But when the Solr core and Analytics jars are 
> loaded at runtime by Solr, they are done by different classloaders, which 
> causes an IllegalAccessError during request handling.  There must be soething 
> different about y setup which is why I am running into this, but it seems 
> like a good idea to abstract away the fields behinds setters/getters anyway.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13633:

   Resolution: Fixed
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

Thanks [~nealsidhwaney]

> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Fix For: 8.3
>
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13643) ResponseBuilder should provide accessors/setters for analytics response handling

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13643:

   Resolution: Done
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

Thanks [~nealsidhwaney]


> ResponseBuilder should provide accessors/setters for analytics response 
> handling
> 
>
> Key: SOLR-13643
> URL: https://issues.apache.org/jira/browse/SOLR-13643
> Project: Solr
>  Issue Type: Task
>  Components: Response Writers
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>Assignee: Munendra S N
>Priority: Trivial
> Fix For: 8.3
>
> Attachments: 
> SOLR-13643-Create-accessors-setters-in-ResponseBuild.patch, 
> SOLR-13643-Create-accessors-setters-in-ResponseBuild.patch, SOLR-13643.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Right now inside o.a.s.h.c.AnalyticsComponent.java, fields inside 
> ResponseBuilder are accessed directly.  Since they're in the same package, 
> this is OK at compile tie.  But when the Solr core and Analytics jars are 
> loaded at runtime by Solr, they are done by different classloaders, which 
> causes an IllegalAccessError during request handling.  There must be soething 
> different about y setup which is why I am running into this, but it seems 
> like a good idea to abstract away the fields behinds setters/getters anyway.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13656:

   Resolution: Fixed
Fix Version/s: 8.3
   Status: Resolved  (was: Patch Available)

> Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
> --
>
> Key: SOLR-13656
> URL: https://issues.apache.org/jira/browse/SOLR-13656
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13656.patch, SOLR-13656.patch
>
>
> {{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test 
> bad solrconfig containing MergePolicyFactory without any public constructors.
> While working on SOLR-12555, found that above test fails while loading 
> solrconfig instead while creating mergepolicy



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13633:
-

Thanks for explanation, Neal. I will commit this and SOLR-13643 either today or 
tomorrow

> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-13633 at 7/28/19 10:40 AM:
---

Thanks for explanation, Neal. I will commit this with {{--data-binary}} changes 
and SOLR-13643 either today or tomorrow


was (Author: munendrasn):
Thanks for explanation, Neal. I will commit this and SOLR-13643 either today or 
tomorrow

> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Comment Edited] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N edited comment on SOLR-13633 at 7/28/19 10:21 AM:
---

your explanation is correct but the doc provides a sample request which is one 
of the way to pass expressions. 

{quote}curl -H POST --data-binary @/Users/nealsid/testanalytics.json 
http://localhost:8983/solr/testcoll/select?q=Vehicle_Make:TOYOT{quote}
This is another way to send expressions. Both formats are specific to cURL 
rather than solr. So, I would like to keep the current format. Once you confirm 
I will the commit the changes



was (Author: munendrasn):
your explanation is correct but the doc provides a sample request which is one 
of the way to pass expressions. 

{quote}curl -H POST --data-binary @/Users/nealsid/testanalytics.json 
http://localhost:8983/solr/testcoll/select?q=Vehicle_Make:TOYOT{quote}
This is another way send expressions. Both formats are specific to cURL rather 
than solr. So, I would like to keep the current format. Once you confirm I will 
the commit the changes


> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13657) Fix TestXPathRecordReader.testUnsupported_Xpaths

[Munendra S N (JIRA)]

Munendra S N created SOLR-13657:
---

 Summary: Fix TestXPathRecordReader.testUnsupported_Xpaths
 Key: SOLR-13657
 URL: https://issues.apache.org/jira/browse/SOLR-13657
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Munendra S N
Assignee: Munendra S N


{{tTestXPathRecordReader.testUnsupported_Xpaths}} covers some negative cases 
for xpath

While working on SOLR-12555, found that, here NPE thrown as rr is never set not 
the expected exception
{code:java}
 try {
  rr.addField("bold"  ,"b",false);
  fail("A RuntimeException was expected: 'b' xpaths must begin with '/'.");
  }
catch (RuntimeException ex) {  }
{code}




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13633:
-

your explanation is correct but the doc provides a sample request which is one 
of the way to pass expressions. 

{quote}curl -H POST --data-binary @/Users/nealsid/testanalytics.json 
http://localhost:8983/solr/testcoll/select?q=Vehicle_Make:TOYOT{quote}
This is another way send expressions. Both formats are specific to cURL rather 
than solr. So, I would like to keep the current format. Once you confirm I will 
the commit the changes


> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13656:

Attachment: SOLR-13656.patch

> Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
> --
>
> Key: SOLR-13656
> URL: https://issues.apache.org/jira/browse/SOLR-13656
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13656.patch, SOLR-13656.patch
>
>
> {{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test 
> bad solrconfig containing MergePolicyFactory without any public constructors.
> While working on SOLR-12555, found that above test fails while loading 
> solrconfig instead while creating mergepolicy



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13656:

Status: Patch Available  (was: Open)

> Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
> --
>
> Key: SOLR-13656
> URL: https://issues.apache.org/jira/browse/SOLR-13656
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13656.patch
>
>
> {{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test 
> bad solrconfig containing MergePolicyFactory without any public constructors.
> While working on SOLR-12555, found that above test fails while loading 
> solrconfig instead while creating mergepolicy



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13656:
-

 [^SOLR-13656.patch] 

* Fixes the test 
* use expectThrows to verify
* remove DummyMergePolicy. This was added for tests and not used anywhere

> Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
> --
>
> Key: SOLR-13656
> URL: https://issues.apache.org/jira/browse/SOLR-13656
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13656.patch
>
>
> {{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test 
> bad solrconfig containing MergePolicyFactory without any public constructors.
> While working on SOLR-12555, found that above test fails while loading 
> solrconfig instead while creating mergepolicy



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-13656:

Attachment: SOLR-13656.patch

> Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
> --
>
> Key: SOLR-13656
> URL: https://issues.apache.org/jira/browse/SOLR-13656
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>    Reporter: Munendra S N
>    Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-13656.patch
>
>
> {{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test 
> bad solrconfig containing MergePolicyFactory without any public constructors.
> While working on SOLR-12555, found that above test fails while loading 
> solrconfig instead while creating mergepolicy



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Created] (SOLR-13656) Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation

[Munendra S N (JIRA)]

Munendra S N created SOLR-13656:
---

 Summary: Fix SolrIndexConfigTest.testFailingSolrIndexConfigCreation
 Key: SOLR-13656
 URL: https://issues.apache.org/jira/browse/SOLR-13656
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Munendra S N
Assignee: Munendra S N


{{SolrIndexConfigTest.testFailingSolrIndexConfigCreation}} is added to test bad 
solrconfig containing MergePolicyFactory without any public constructors.

While working on SOLR-12555, found that above test fails while loading 
solrconfig instead while creating mergepolicy





--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Updated] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N updated SOLR-12555:

Attachment: SOLR-12555.patch

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-12555) Replace try-fail-catch test patterns

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-12555:
-

 [^SOLR-12555.patch] 
Fixed the failing test in {{ChangedSchemaMergeTest}}

> Replace try-fail-catch test patterns
> 
>
> Key: SOLR-12555
> URL: https://issues.apache.org/jira/browse/SOLR-12555
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Affects Versions: 8.0
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-12555-sorted-by-package.txt, SOLR-12555.patch, 
> SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.patch, SOLR-12555.txt
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> I recently added some test code through SOLR-12427 which used the following 
> test anti-pattern:
> {code}
> try {
> actionExpectedToThrowException();
> fail("I expected this to throw an exception, but it didn't");
> catch (Exception e) {
> assertOnThrownException(e);
> }
> {code}
> Hoss (rightfully) objected that this should instead be written using the 
> formulation below, which is clearer and more concise.
> {code}
> SolrException e = expectThrows(() -> {...});
> {code}
> We should remove many of these older formulations where it makes sense.  Many 
> of them were written before {{expectThrows}} was introduced, and having the 
> old style assertions around makes it easier for them to continue creeping in.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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

[jira] [Commented] (SOLR-13633) Small types in analytics documentation

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13633:
-

[~nealsidhwaney]

{code:java}
curl --data-urlencode 'analytics={
{code}
https://ec.haxx.se/http-post.html
This is correct and works. {{analytics}} is sent as request parameter. Why this 
needs to be changed?

> Small types in analytics documentation
> --
>
> Key: SOLR-13633
> URL: https://issues.apache.org/jira/browse/SOLR-13633
> Project: Solr
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>    Assignee: Munendra S N
>Priority: Trivial
> Attachments: SOLR-13633.patch
>
>
> There are a couple typos in the analytics documentation commands that might 
> make someone just getting started scratch their head a bit. Upcoming 2 line 
> patch fixes them.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

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