[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 19396 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19396/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([D8249B31D24347D4:17BAFE085DB22F8B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11881 lines...]
   [junit4] Suite: org.apache

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Trey Grainger]

Thanks for the great feedback, everyone.

Since the update handler currently already smart-defaults the response type
like Yonik is describing based on the incoming content type (whether you
specify the content-type header or not), it seems that we won't need to
make any changes there.

I just summarized everyone's feedback into action items and submitted a
JIRA (SOLR-10494 ) for
further tracking. If you have further comments or if I missed anything,
feel free to reply there.

Thanks,

Trey Grainger
Co-author, Solr in Action
SVP of Engineering @ Lucidworks

On Fri, Apr 14, 2017 at 11:35 PM, David Smiley 
wrote:

> It's a neat idea to have the response format smart-defaulted based on the
> POST content-type.  +1 to that!
>
> On Fri, Apr 14, 2017 at 11:24 PM Yonik Seeley  wrote:
>
>> Just a reminder that we have had indented JSON query responses by
>> default at the "/query" endpoint for years. That doesn't cover other
>> handlers though.
>> Readability/aesthetics of our docs/examples is where the biggest
>> deficiency lies - lots of XML examples that could have been JSON for a
>> long time now.  Hopefully this change would prevent new docs from
>> being written that use XML output format.
>>
>> Other thoughts:
>> - The /query endpoint should remain, no need to break everyone who has
>> been using it
>> - I assume sending XML to the existing update handler should perhaps
>> continue to return an XML response?
>> - I assume that it's desirable to have indentation by default... but
>> this is also a slight back compat change/break for people that
>> currently specify JSON and expect it un-indented (for some response
>> types, the difference could be large, like 2x).  If we go this way, we
>> need to add that to the CHANGES as well.
>>
>> -Yonik
>>
>>
>> On Fri, Apr 14, 2017 at 2:53 PM, Trey Grainger 
>> wrote:
>> > Just wanted to throw this out there for discussion. Solr's default query
>> > response format is still XML, despite the fact that Solr has supported
>> the
>> > JSON response format for over a decade, developer mindshare has clearly
>> > shifted toward JSON over the years, and most modern/competing systems
>> also
>> > use JSON format now by default.
>> >
>> > In fact, Solr's admin UI even explicitly adds wt=json to the request (by
>> > default in the UI) to override the default of wt=xml, so Solr's Admin UI
>> > effectively has a different default than the API.
>> >
>> > We have now introduced things like the JSON faceting API, and the new
>> more
>> > modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
>> > we're moving in the direction of JSON anyway.
>> >
>> > I'd like propose that we switch the default response writer to JSON
>> > (wt=json) instead of XML for Solr 7.0, as this seems to me like the
>> right
>> > direction and a good time to make this change with the next major
>> version.
>> >
>> > Before I create a JIRA and submit a patch, though, I wanted to check
>> here
>> > make sure there were no strong objections to changing the default.
>> >
>> > -Trey Grainger
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
> solrenterprisesearchserver.com
>

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

And I suppose to hit the leader we would have to hit the actual leader jetty 
port. I assume that is still possible? Have not looked into it.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Trey Grainger (JIRA)]

Trey Grainger created SOLR-10494:


 Summary: Switch Solr's Default Response Type from XML to JSON
 Key: SOLR-10494
 URL: https://issues.apache.org/jira/browse/SOLR-10494
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (7.0)
Reporter: Trey Grainger
Priority: Minor
 Fix For: master (7.0)


Solr's default response format is still XML, despite the fact that Solr has 
supported the JSON response format for over a decade, developer mindshare has 
clearly shifted toward JSON over the years, and most modern/competing systems 
also use JSON format now by default.

In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
default in the UI) to override the default of wt=xml, so Solr's Admin UI 
effectively has a different default than the API.

We have now introduced things like the JSON faceting API, and the new more 
modern /V2 apis assume JSON for the areas of Solr they cover, so clearly we're 
moving in the direction of JSON anyway.

I'd like propose that we switch the default response writer to JSON (wt=json) 
instead of XML for Solr 7.0, as this seems to me like the right direction and a 
good time to make this change with the next major version.

Based upon feedback from the Lucene Dev's mailing list, we want to:
1) Change the default response writer type to "wt=json" and also change to 
"indent=on" by default
2) Make no changes on the update handler side; it already works as desired (it 
returns the response in the same content-type as the request unless the "wt" is 
passed in explicitly).
3) Keep the /query request handler around since people have already used it for 
years to do JSON queries
4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
on how to change (back) the response format.

The default format change, plus the addition of "indent=on" are back compat 
changes, so we need to make sure we doc those clearly in the CHANGES.txt. There 
will also need to be significant adjustments to the Solr Ref Guide, Tutorial, 
etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

We would probably also have to be sure and index directly to the leader if that 
is not the current behavior.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[David Smiley]

It's a neat idea to have the response format smart-defaulted based on the
POST content-type.  +1 to that!

On Fri, Apr 14, 2017 at 11:24 PM Yonik Seeley  wrote:

> Just a reminder that we have had indented JSON query responses by
> default at the "/query" endpoint for years. That doesn't cover other
> handlers though.
> Readability/aesthetics of our docs/examples is where the biggest
> deficiency lies - lots of XML examples that could have been JSON for a
> long time now.  Hopefully this change would prevent new docs from
> being written that use XML output format.
>
> Other thoughts:
> - The /query endpoint should remain, no need to break everyone who has
> been using it
> - I assume sending XML to the existing update handler should perhaps
> continue to return an XML response?
> - I assume that it's desirable to have indentation by default... but
> this is also a slight back compat change/break for people that
> currently specify JSON and expect it un-indented (for some response
> types, the difference could be large, like 2x).  If we go this way, we
> need to add that to the CHANGES as well.
>
> -Yonik
>
>
> On Fri, Apr 14, 2017 at 2:53 PM, Trey Grainger  wrote:
> > Just wanted to throw this out there for discussion. Solr's default query
> > response format is still XML, despite the fact that Solr has supported
> the
> > JSON response format for over a decade, developer mindshare has clearly
> > shifted toward JSON over the years, and most modern/competing systems
> also
> > use JSON format now by default.
> >
> > In fact, Solr's admin UI even explicitly adds wt=json to the request (by
> > default in the UI) to override the default of wt=xml, so Solr's Admin UI
> > effectively has a different default than the API.
> >
> > We have now introduced things like the JSON faceting API, and the new
> more
> > modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
> > we're moving in the direction of JSON anyway.
> >
> > I'd like propose that we switch the default response writer to JSON
> > (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
> > direction and a good time to make this change with the next major
> version.
> >
> > Before I create a JIRA and submit a patch, though, I wanted to check here
> > make sure there were no strong objections to changing the default.
> >
> > -Trey Grainger
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Yonik Seeley]

Just a reminder that we have had indented JSON query responses by
default at the "/query" endpoint for years. That doesn't cover other
handlers though.
Readability/aesthetics of our docs/examples is where the biggest
deficiency lies - lots of XML examples that could have been JSON for a
long time now.  Hopefully this change would prevent new docs from
being written that use XML output format.

Other thoughts:
- The /query endpoint should remain, no need to break everyone who has
been using it
- I assume sending XML to the existing update handler should perhaps
continue to return an XML response?
- I assume that it's desirable to have indentation by default... but
this is also a slight back compat change/break for people that
currently specify JSON and expect it un-indented (for some response
types, the difference could be large, like 2x).  If we go this way, we
need to add that to the CHANGES as well.

-Yonik


On Fri, Apr 14, 2017 at 2:53 PM, Trey Grainger  wrote:
> Just wanted to throw this out there for discussion. Solr's default query
> response format is still XML, despite the fact that Solr has supported the
> JSON response format for over a decade, developer mindshare has clearly
> shifted toward JSON over the years, and most modern/competing systems also
> use JSON format now by default.
>
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by
> default in the UI) to override the default of wt=xml, so Solr's Admin UI
> effectively has a different default than the API.
>
> We have now introduced things like the JSON faceting API, and the new more
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
> we're moving in the direction of JSON anyway.
>
> I'd like propose that we switch the default response writer to JSON
> (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
> direction and a good time to make this change with the next major version.
>
> Before I create a JIRA and submit a patch, though, I wanted to check here
> make sure there were no strong objections to changing the default.
>
> -Trey Grainger

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

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Walter Underwood]

I like that.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Apr 14, 2017, at 7:47 PM, Alexandre Rafalovitch  wrote:
> 
> We could put commented out wt=xml in the solrconfig.xml as a secondary 
> reminder.
> 
> Regards,
>Alex
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
> 
> 
> On 15 April 2017 at 03:53, Doug Turnbull
>  wrote:
>> Sounds great. I agree!
>> 
>> I can imagine there might be really old client libraries/integrations that
>> assume XML without sending a wt, but I think it's ok to break those sorts of
>> things in a major release. And those folks can learn to send wt=xml
>> 
>> -Doug
>> 
>> On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  wrote:
>>> 
>>> Just wanted to throw this out there for discussion. Solr's default query
>>> response format is still XML, despite the fact that Solr has supported the
>>> JSON response format for over a decade, developer mindshare has clearly
>>> shifted toward JSON over the years, and most modern/competing systems also
>>> use JSON format now by default.
>>> 
>>> In fact, Solr's admin UI even explicitly adds wt=json to the request (by
>>> default in the UI) to override the default of wt=xml, so Solr's Admin UI
>>> effectively has a different default than the API.
>>> 
>>> We have now introduced things like the JSON faceting API, and the new more
>>> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
>>> we're moving in the direction of JSON anyway.
>>> 
>>> I'd like propose that we switch the default response writer to JSON
>>> (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
>>> direction and a good time to make this change with the next major version.
>>> 
>>> Before I create a JIRA and submit a patch, though, I wanted to check here
>>> make sure there were no strong objections to changing the default.
>>> 
>>> -Trey Grainger
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([4E159F36D0898C31:818BFA0F5F78E46E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12783 lines...]
   [junit4] Suite: org.apache.solr.handle

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Alexandre Rafalovitch]

We could put commented out wt=xml in the solrconfig.xml as a secondary reminder.

Regards,
Alex

http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 15 April 2017 at 03:53, Doug Turnbull
 wrote:
> Sounds great. I agree!
>
> I can imagine there might be really old client libraries/integrations that
> assume XML without sending a wt, but I think it's ok to break those sorts of
> things in a major release. And those folks can learn to send wt=xml
>
> -Doug
>
> On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  wrote:
>>
>> Just wanted to throw this out there for discussion. Solr's default query
>> response format is still XML, despite the fact that Solr has supported the
>> JSON response format for over a decade, developer mindshare has clearly
>> shifted toward JSON over the years, and most modern/competing systems also
>> use JSON format now by default.
>>
>> In fact, Solr's admin UI even explicitly adds wt=json to the request (by
>> default in the UI) to override the default of wt=xml, so Solr's Admin UI
>> effectively has a different default than the API.
>>
>> We have now introduced things like the JSON faceting API, and the new more
>> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
>> we're moving in the direction of JSON anyway.
>>
>> I'd like propose that we switch the default response writer to JSON
>> (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
>> direction and a good time to make this change with the next major version.
>>
>> Before I create a JIRA and submit a patch, though, I wanted to check here
>> make sure there were no strong objections to changing the default.
>>
>> -Trey Grainger

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

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Walter Underwood]

This is guaranteed to break stuff, but I support it. Even though I put the 
first XML support into a search engine and worked for an XML database company.

Also, if someone even proposes a PDF response writer, I will hunt them down.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


> On Apr 14, 2017, at 5:53 PM, Doug Turnbull 
>  wrote:
> 
> Sounds great. I agree!
> 
> I can imagine there might be really old client libraries/integrations that 
> assume XML without sending a wt, but I think it's ok to break those sorts of 
> things in a major release. And those folks can learn to send wt=xml
> 
> -Doug
> 
> On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  > wrote:
> Just wanted to throw this out there for discussion. Solr's default query 
> response format is still XML, despite the fact that Solr has supported the 
> JSON response format for over a decade, developer mindshare has clearly 
> shifted toward JSON over the years, and most modern/competing systems also 
> use JSON format now by default.
> 
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> 
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> 
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> 
> Before I create a JIRA and submit a patch, though, I wanted to check here 
> make sure there were no strong objections to changing the default.
> 
> -Trey Grainger

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Doug Turnbull]

Sounds great. I agree!

I can imagine there might be really old client libraries/integrations that
assume XML without sending a wt, but I think it's ok to break those sorts
of things in a major release. And those folks can learn to send wt=xml

-Doug

On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  wrote:

> Just wanted to throw this out there for discussion. Solr's default query
> response format is still XML, despite the fact that Solr has supported the
> JSON response format for over a decade, developer mindshare has clearly
> shifted toward JSON over the years, and most modern/competing systems also
> use JSON format now by default.
>
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by
> default in the UI) to override the default of wt=xml, so Solr's Admin UI
> effectively has a different default than the API.
>
> We have now introduced things like the JSON faceting API, and the new more
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
> we're moving in the direction of JSON anyway.
>
> I'd like propose that we switch the default response writer to JSON
> (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
> direction and a good time to make this change with the next major version.
>
> Before I create a JIRA and submit a patch, though, I wanted to check here
> make sure there were no strong objections to changing the default.
>
> -Trey Grainger
>

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+164) - Build # 3281 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3281/
Java: 32bit/jdk-9-ea+164 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([A96FC1456866B6:8B8EBC10046ECD32]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:865)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAf

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on LUCENE-7785:
--

Interesting.  I could have sworn I had read that LGPL was OK for binary 
dependencies, but I can see it right there on the legal page that it isn't.  
Learn something new every day.


> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1773 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1773/

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([540C1D27E1CD13A2:9B92781E6E3C7BFD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11150 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.StatsReloadRaceTest
   [junit

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7785:


+1, LGTM

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10493) Investigate SolrCloudExampleTest failures.

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-10493:
-

 Summary: Investigate SolrCloudExampleTest failures.
 Key: SOLR-10493
 URL: https://issues.apache.org/jira/browse/SOLR-10493
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson
Assignee: Erick Erickson


May be related to my recent check-in for SOLR-10007. This test _does_ fail 
prior to that (Steve Rowe beasted and checked with 10007 rolled back and sent 
me error logs), but the failures he reports are significantly different than I 
was seeing with 10007. Since I was certainly in the core reload code and the 
reports with SOLR-10007 mention core reloading but the ones without SOLR-10007 
do NOT mention core reloading it's suspicious enough to spend some time on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10489) StatsReloadRaceTest.testParallelReloadAndStats failures

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10489:
---

SOLR-10007 doesn't appear to be the culprit. Steve Rowe generously ran 1,000 
iterations on his beefy machine with SOLR-10007 rolled back and we're seeing 
the same errors. Actually, Steve reports two different ones. The one Andrzej 
reported above and:

{code}
 [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=StatsReloadRaceTest 
-Dtests.method=testParallelReloadAndStats -Dtests.seed=76D37F1574FC0FE3 
-Dtests.slow=true -Dtests.locale=es-HN 
-Dtests.timezone=America/Indiana/Indianapolis -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   3.20s | StatsReloadRaceTest.testParallelReloadAndStats <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([76D37F1574FC0FE3:B94D1A2CFB0D67BC]:0)
   [junit4]>at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:120)
   [junit4]>at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
{code}


[~ab] I'll try to assign it back to you. I doubt that there's a single 
underlying cause so I'll raise a separate JIRA for SolrCloudExampleTest as the 
failures Steve had are significantly different than mine. Unlike the failures 
for this JIRA, the ones for SolrCloudExample test look more likely to be 
related to 10007.

> StatsReloadRaceTest.testParallelReloadAndStats failures
> ---
>
> Key: SOLR-10489
> URL: https://issues.apache.org/jira/browse/SOLR-10489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>
> This test has been failing a lot after the changes in SOLR-9959, for unclear 
> reasons. The failure is always in the same place:
> {code}
> java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
> registry solr.core.collection1
>   at 
> __randomizedtesting.SeedInfo.seed([28B54D77FD0E3DF1:E72B284E72FF55AE]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10489) StatsReloadRaceTest.testParallelReloadAndStats failures

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-10489:
-

Assignee: Andrzej Bialecki   (was: Erick Erickson)

> StatsReloadRaceTest.testParallelReloadAndStats failures
> ---
>
> Key: SOLR-10489
> URL: https://issues.apache.org/jira/browse/SOLR-10489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>
> This test has been failing a lot after the changes in SOLR-9959, for unclear 
> reasons. The failure is always in the same place:
> {code}
> java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
> registry solr.core.collection1
>   at 
> __randomizedtesting.SeedInfo.seed([28B54D77FD0E3DF1:E72B284E72FF55AE]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Shawn Heisey]

On 4/14/2017 12:53 PM, Trey Grainger wrote:
> Just wanted to throw this out there for discussion. Solr's default
> query response format is still XML, despite the fact that Solr has
> supported the JSON response format for over a decade, developer
> mindshare has clearly shifted toward JSON over the years, and most
> modern/competing systems also use JSON format now by default.

+1

Sounds good to me, as long as it's master only, which is what the
message subject proposes.

Various docs will need to make this clear so when somebody upgrades,
finds their simple homegrown client no longer works, and goes looking
for the reason, it's easy to find.  With any luck, they will notice the
new default *before* they upgrade and encounter a problem.

Thanks,
Shawn


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

[jira] [Commented] (SOLR-9120) o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] -- NoSuchFileException

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9120:


This issue seems to have fallen out of notice.  I suspect that something 
changed in Lucene so that Solr is looking at outdated information, and Solr 
just needs to be updated so it looks in a new place for data, or so that it 
keeps a previous commit point around for a moment while it gathers information. 
 If somebody has any idea what I can look for, I am willing to put time into 
finding a fix, but I have no idea where to begin right now.

The message can be eliminated from the logs by setting the log level for 
LukeRequestHandler (full class name 
org.apache.solr.handler.admin.LukeRequestHandler) to ERROR, which can be done 
either in the Logging UI or in log4j.properties.


> o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_NNN] -- 
> NoSuchFileException
> 
>
> Key: SOLR-9120
> URL: https://issues.apache.org/jira/browse/SOLR-9120
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>
> On Solr 6.0, we frequently see the following errors popping up:
> {code}
> java.nio.file.NoSuchFileException: 
> /var/lib/solr/logs_shard2_replica1/data/index/segments_2c5
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
>   at 
> sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
>   at 
> sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
>   at java.nio.file.Files.readAttributes(Files.java:1737)
>   at java.nio.file.Files.size(Files.java:2332)
>   at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:243)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:131)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:597)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:585)
>   at 
> org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.u

Re: Strange Solr JIRA versions

[Mark Miller]

Something to look into. That might actually. E something we can configure
correctly rather than also giving admin.
On Fri, Apr 14, 2017 at 3:25 PM Tomás Fernández Löbbe 
wrote:

> Isn't the PMC group required to see issues with security level "private"?
>
> On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett  > wrote:
>
>> I'm also +1 to removing PMC group - I checked and every permission PMC
>> group has, administrators also have so consolidating those 2 groups
>> should have no impact on people.
>>
>> I'd be happy to have admin access, and I will help keep my eyes out
>> for problems like this in the future.
>>
>> On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson 
>> wrote:
>> > bq: my proposal would be to get rid of that PMC group (which is like
>> > more admins), clear the admin group, and seed it with anyone that
>> > calls out wanting access
>> >
>> > +1
>> >
>> > On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller 
>> wrote:
>> >> bq. Personally I'm fine with not being an administrator as long as I
>> can
>> >> assign JIRAs to myself and resolve them.
>> >>
>> >> I think that is 80-90% of us. The only time I ever use admin is to fix
>> >> version stuff like this or do a release. I think Jenkins access might
>> work
>> >> this way, you have to request it. It would also be great if like the
>> >> committer role could manage versions, but I couldn't seem to find that
>> >> feature.
>> >>
>> >> But anyway, my proposal would be to get rid of that PMC group (which
>> is like
>> >> more admins), clear the admin group, and seed it with anyone that
>> calls out
>> >> wanting access, and then give access as requested from there out, extra
>> >> points for a warning about this 'feature' and managing versions
>> consistently
>> >> with the past unless there is discussion.
>> >>
>> >> - Mark
>> >>
>> >> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <
>> erickerick...@gmail.com>
>> >> wrote:
>> >>>
>> >>> I agree with all your points and would _much_ rather be unable to
>> >>> screw up even if it meant jumping through another hoop on those rare
>> >>> occasions when I needed more authority.
>> >>>
>> >>> Personally I'm fine with not being an administrator as long as I can
>> >>> assign JIRAs to myself and resolve them.
>> >>>
>> >>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
>> >>> wrote:
>> >>> > The problem is not so much notifying people, because no one is
>> closely
>> >>> > monitoring this stuff. By the time we ever notice it and attempt to
>> fix
>> >>> > it,
>> >>> > there are 40-200 issues involved. You are not the only one. And I
>> would
>> >>> > be
>> >>> > angry at you! If not for the fact that it's a terrible JIRA issue
>> that
>> >>> > did
>> >>> > not used to be a problem. But, ok, you have learned this JIRA
>> 'feature'
>> >>> > is a
>> >>> > problem. What about those not reading this, what about future
>> >>> > committers,
>> >>> > what about you go away for a year and come back having forgotten.
>> The
>> >>> > JIRA
>> >>> > issue to fix this in JIRA has tons of votes, but it's also old, so
>> no
>> >>> > help
>> >>> > from Atlassian likely any time soon. You can read the comments on
>> the
>> >>> > bug
>> >>> > report and lots of people have this problem and hate it. The devs
>> doing
>> >>> > it
>> >>> > here are not special, that's obvious.
>> >>> >
>> >>> > I'm not sure why we have so many admins though. Sure, if you do a
>> >>> > release,
>> >>> > you want to be able to manage the versions, but a huge number of
>> >>> > committers
>> >>> > have not done a release and could request admin when needed. Then we
>> >>> > could
>> >>> > grant it, and be like, by the way, careful with your god like
>> powers to
>> >>> > create stuff out of thin air without realizing.
>> >>> >
>> >>> > Perhaps the other reason most might use admin power is to add
>> someone,
>> >>> > but I
>> >>> > think only a subset of people do that as well currently.
>> >>> >
>> >>> > - Mark
>> >>> >
>> >>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> >>> >> versions" as "trunk", which is also incorrect.
>> >>> >>
>> >>> >> Well, now I know.
>> >>> >>
>> >>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > If you look at the "history" tab on the JIRA you can see who set
>> what
>> >>> >> > values when. I checked 4-5 of the JIRAS and the person who set
>> those
>> >>> >> > has a long record of being very conscientious about changes so
>> I'm
>> >>> >> > certain it's just an awareness issue, at least for that person.
>> I'll
>> >>> >> > ping
>> >>> >> >
>> >>> >> > Which suggests a way to raise awareness going forward: check the
>> >>> >> > history and send a message.
>> >>> >> >
>> >>> >> > If that doesn't cure it we can consider harsher measures,
>> although I
>> >>> >> > don't think forbidding arbitrary labels is "harsh", it's just
>> too bad
>> >>> >> > we can't.
>>

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Erik Hatcher]

While we’re at it, let’s also get rid of all the “experimental” in the 
responses too?


> On Apr 14, 2017, at 2:53 PM, Trey Grainger  wrote:
> 
> Just wanted to throw this out there for discussion. Solr's default query 
> response format is still XML, despite the fact that Solr has supported the 
> JSON response format for over a decade, developer mindshare has clearly 
> shifted toward JSON over the years, and most modern/competing systems also 
> use JSON format now by default.
> 
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> 
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> 
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> 
> Before I create a JIRA and submit a patch, though, I wanted to check here 
> make sure there were no strong objections to changing the default.
> 
> -Trey Grainger


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

Re: Strange Solr JIRA versions

[Tomás Fernández Löbbe]

Isn't the PMC group required to see issues with security level "private"?

On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett 
wrote:

> I'm also +1 to removing PMC group - I checked and every permission PMC
> group has, administrators also have so consolidating those 2 groups
> should have no impact on people.
>
> I'd be happy to have admin access, and I will help keep my eyes out
> for problems like this in the future.
>
> On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson 
> wrote:
> > bq: my proposal would be to get rid of that PMC group (which is like
> > more admins), clear the admin group, and seed it with anyone that
> > calls out wanting access
> >
> > +1
> >
> > On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller 
> wrote:
> >> bq. Personally I'm fine with not being an administrator as long as I can
> >> assign JIRAs to myself and resolve them.
> >>
> >> I think that is 80-90% of us. The only time I ever use admin is to fix
> >> version stuff like this or do a release. I think Jenkins access might
> work
> >> this way, you have to request it. It would also be great if like the
> >> committer role could manage versions, but I couldn't seem to find that
> >> feature.
> >>
> >> But anyway, my proposal would be to get rid of that PMC group (which is
> like
> >> more admins), clear the admin group, and seed it with anyone that calls
> out
> >> wanting access, and then give access as requested from there out, extra
> >> points for a warning about this 'feature' and managing versions
> consistently
> >> with the past unless there is discussion.
> >>
> >> - Mark
> >>
> >> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson  >
> >> wrote:
> >>>
> >>> I agree with all your points and would _much_ rather be unable to
> >>> screw up even if it meant jumping through another hoop on those rare
> >>> occasions when I needed more authority.
> >>>
> >>> Personally I'm fine with not being an administrator as long as I can
> >>> assign JIRAs to myself and resolve them.
> >>>
> >>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
> >>> wrote:
> >>> > The problem is not so much notifying people, because no one is
> closely
> >>> > monitoring this stuff. By the time we ever notice it and attempt to
> fix
> >>> > it,
> >>> > there are 40-200 issues involved. You are not the only one. And I
> would
> >>> > be
> >>> > angry at you! If not for the fact that it's a terrible JIRA issue
> that
> >>> > did
> >>> > not used to be a problem. But, ok, you have learned this JIRA
> 'feature'
> >>> > is a
> >>> > problem. What about those not reading this, what about future
> >>> > committers,
> >>> > what about you go away for a year and come back having forgotten. The
> >>> > JIRA
> >>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
> >>> > help
> >>> > from Atlassian likely any time soon. You can read the comments on the
> >>> > bug
> >>> > report and lots of people have this problem and hate it. The devs
> doing
> >>> > it
> >>> > here are not special, that's obvious.
> >>> >
> >>> > I'm not sure why we have so many admins though. Sure, if you do a
> >>> > release,
> >>> > you want to be able to manage the versions, but a huge number of
> >>> > committers
> >>> > have not done a release and could request admin when needed. Then we
> >>> > could
> >>> > grant it, and be like, by the way, careful with your god like powers
> to
> >>> > create stuff out of thin air without realizing.
> >>> >
> >>> > Perhaps the other reason most might use admin power is to add
> someone,
> >>> > but I
> >>> > think only a subset of people do that as well currently.
> >>> >
> >>> > - Mark
> >>> >
> >>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
> >>> >> versions" as "trunk", which is also incorrect.
> >>> >>
> >>> >> Well, now I know.
> >>> >>
> >>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
> >>> >> 
> >>> >> wrote:
> >>> >> > If you look at the "history" tab on the JIRA you can see who set
> what
> >>> >> > values when. I checked 4-5 of the JIRAS and the person who set
> those
> >>> >> > has a long record of being very conscientious about changes so I'm
> >>> >> > certain it's just an awareness issue, at least for that person.
> I'll
> >>> >> > ping
> >>> >> >
> >>> >> > Which suggests a way to raise awareness going forward: check the
> >>> >> > history and send a message.
> >>> >> >
> >>> >> > If that doesn't cure it we can consider harsher measures,
> although I
> >>> >> > don't think forbidding arbitrary labels is "harsh", it's just too
> bad
> >>> >> > we can't.
> >>> >> >
> >>> >> > Erick
> >>> >> >
> >>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <
> markrmil...@gmail.com>
> >>> >> > wrote:
> >>> >> >> I wish hossman was still more active in this type of thing. He
> would
> >>> >> >> have
> >>> >> >> sworn more and fixed it more meticulously and probably earlier.
> Or
> >>> >> >> maybe he
> >>> >> >>

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+164) - Build # 3279 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3279/
Java: 32bit/jdk-9-ea+164 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([3E826E88A3DC4F83:B5A5BD59E2DAE407]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:865)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnore

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7785:
--

`ant precommit` is happy now

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[Andrzej Białecki]

I like it, too, +1.

> On 14 Apr 2017, at 20:56, David Smiley  wrote:
> 
> +1 makes sense to me.
> 
> On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  > wrote:
> Just wanted to throw this out there for discussion. Solr's default query 
> response format is still XML, despite the fact that Solr has supported the 
> JSON response format for over a decade, developer mindshare has clearly 
> shifted toward JSON over the years, and most modern/competing systems also 
> use JSON format now by default.
> 
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> 
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> 
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> 
> Before I create a JIRA and submit a patch, though, I wanted to check here 
> make sure there were no strong objections to changing the default.
> 
> -Trey Grainger
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7785:
--

Ahh, I see what you mean, I'll push the fix for the order once my `ant 
precommit` succeeds.

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7785:


I think the error message is okay - it's hard to be precise about the cause of 
out-of-order problems.  The out-of-order checker can only tell that there is a 
problem *after* seeing the key following your new one.  Here's your patch in 
context:

{noformat}
 +ua.net.nlp.morfologik-ukrainian-search.version = 3.7.5
 +/ua.net.nlp/morfologik-ukrainian-search = 
${ua.net.nlp.morfologik-ukrainian-search.version}
 +
  /org.ccil.cowan.tagsoup/tagsoup = 1.2.1
{noformat}

FYI, we work pretty hard to make sure that {{ant precommit}} works properly all 
the time, so if you see a failure, it's very likely due to your changes.

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7785:
--

Here's what I get:
check-lib-versions:
 [echo] Lib versions check under: 
/home/master/work/ukr/spelling/lucene-workspace/lucene-solr/lucene/..
[libversions] :: loading settings :: file = 
/home/master/work/ukr/spelling/lucene-workspace/lucene-solr/lucene/top-level-ivy-settings.xml
[libversions] OUT-OF-ORDER coordinate key '/org.ccil.cowan.tagsoup/tagsoup' in 
ivy-versions.properties
[libversions] Checked that ivy-versions.properties and 
ivy-ignore-conflicts.properties have lexically sorted '/org/name' keys and no 
duplicates or orphans.
[libversions] Scanned 46 ivy.xml files for rev="${/org/name}" format.
[libversions] Found 0 indirect dependency version conflicts.
[libversions] Completed in 1.24s., 1 error(s).


> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.5 - Build # 12 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.5/12/

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.hdfs.HdfsBasicDistributedZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [NRTCachingDirectory] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.NRTCachingDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:352)  at 
org.apache.solr.core.SolrCore.cleanupOldIndexDirectories(SolrCore.java:2996)  
at org.apache.solr.core.SolrCore.close(SolrCore.java:1538)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:957)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:831)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)  at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.NRTCachingDirectory
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:352)
at 
org.apache.solr.core.SolrCore.cleanupOldIndexDirectories(SolrCore.java:2996)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1538)
at org.apache.solr.core.SolrCore.(SolrCore.java:957)
at org.apache.solr.core.SolrCore.(SolrCore.java:831)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)
at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([82A2D71F8B77F8BC]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:301)
at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequire

Re: Change Default Response Format (wt) to JSON in Solr 7.0?

[David Smiley]

+1 makes sense to me.

On Fri, Apr 14, 2017 at 2:53 PM Trey Grainger  wrote:

> Just wanted to throw this out there for discussion. Solr's default query
> response format is still XML, despite the fact that Solr has supported the
> JSON response format for over a decade, developer mindshare has clearly
> shifted toward JSON over the years, and most modern/competing systems also
> use JSON format now by default.
>
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by
> default in the UI) to override the default of wt=xml, so Solr's Admin UI
> effectively has a different default than the API.
>
> We have now introduced things like the JSON faceting API, and the new more
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
> we're moving in the direction of JSON anyway.
>
> I'd like propose that we switch the default response writer to JSON
> (wt=json) instead of XML for Solr 7.0, as this seems to me like the right
> direction and a good time to make this change with the next major version.
>
> Before I create a JIRA and submit a patch, though, I wanted to check here
> make sure there were no strong objections to changing the default.
>
> -Trey Grainger
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Change Default Response Format (wt) to JSON in Solr 7.0?

[Trey Grainger]

Just wanted to throw this out there for discussion. Solr's default query
response format is still XML, despite the fact that Solr has supported the
JSON response format for over a decade, developer mindshare has clearly
shifted toward JSON over the years, and most modern/competing systems also
use JSON format now by default.

In fact, Solr's admin UI even explicitly adds wt=json to the request (by
default in the UI) to override the default of wt=xml, so Solr's Admin UI
effectively has a different default than the API.

We have now introduced things like the JSON faceting API, and the new more
modern /V2 apis assume JSON for the areas of Solr they cover, so clearly
we're moving in the direction of JSON anyway.

I'd like propose that we switch the default response writer to JSON
(wt=json) instead of XML for Solr 7.0, as this seems to me like the right
direction and a good time to make this change with the next major version.

Before I create a JIRA and submit a patch, though, I wanted to check here
make sure there were no strong objections to changing the default.

-Trey Grainger

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7785:


bq. It still fails for me but dues to some issue with 
`/org.ccil.cowan.tagsoup/tagsoup`, hopefully files related to this issue are 
good now.

Looking at your changes to {{ivy-versions.properties}}, I think the new 
dependency is in the wrong order (as the comment at the top of the file says, 
the {{/org/name}} keys must be lexically ordered) - likely the error you're 
seeing is telling you that.  If I'm right, perhaps the error message should be 
fixed.  Please post it here.

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Cassandra Targett]

I'm also +1 to removing PMC group - I checked and every permission PMC
group has, administrators also have so consolidating those 2 groups
should have no impact on people.

I'd be happy to have admin access, and I will help keep my eyes out
for problems like this in the future.

On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson  wrote:
> bq: my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that
> calls out wanting access
>
> +1
>
> On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller  wrote:
>> bq. Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> I think that is 80-90% of us. The only time I ever use admin is to fix
>> version stuff like this or do a release. I think Jenkins access might work
>> this way, you have to request it. It would also be great if like the
>> committer role could manage versions, but I couldn't seem to find that
>> feature.
>>
>> But anyway, my proposal would be to get rid of that PMC group (which is like
>> more admins), clear the admin group, and seed it with anyone that calls out
>> wanting access, and then give access as requested from there out, extra
>> points for a warning about this 'feature' and managing versions consistently
>> with the past unless there is discussion.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson 
>> wrote:
>>>
>>> I agree with all your points and would _much_ rather be unable to
>>> screw up even if it meant jumping through another hoop on those rare
>>> occasions when I needed more authority.
>>>
>>> Personally I'm fine with not being an administrator as long as I can
>>> assign JIRAs to myself and resolve them.
>>>
>>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
>>> wrote:
>>> > The problem is not so much notifying people, because no one is closely
>>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>>> > it,
>>> > there are 40-200 issues involved. You are not the only one. And I would
>>> > be
>>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>>> > did
>>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>>> > is a
>>> > problem. What about those not reading this, what about future
>>> > committers,
>>> > what about you go away for a year and come back having forgotten. The
>>> > JIRA
>>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>>> > help
>>> > from Atlassian likely any time soon. You can read the comments on the
>>> > bug
>>> > report and lots of people have this problem and hate it. The devs doing
>>> > it
>>> > here are not special, that's obvious.
>>> >
>>> > I'm not sure why we have so many admins though. Sure, if you do a
>>> > release,
>>> > you want to be able to manage the versions, but a huge number of
>>> > committers
>>> > have not done a release and could request admin when needed. Then we
>>> > could
>>> > grant it, and be like, by the way, careful with your god like powers to
>>> > create stuff out of thin air without realizing.
>>> >
>>> > Perhaps the other reason most might use admin power is to add someone,
>>> > but I
>>> > think only a subset of people do that as well currently.
>>> >
>>> > - Mark
>>> >
>>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>>> > 
>>> > wrote:
>>> >>
>>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>>> >> versions" as "trunk", which is also incorrect.
>>> >>
>>> >> Well, now I know.
>>> >>
>>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>>> >> 
>>> >> wrote:
>>> >> > If you look at the "history" tab on the JIRA you can see who set what
>>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>>> >> > has a long record of being very conscientious about changes so I'm
>>> >> > certain it's just an awareness issue, at least for that person. I'll
>>> >> > ping
>>> >> >
>>> >> > Which suggests a way to raise awareness going forward: check the
>>> >> > history and send a message.
>>> >> >
>>> >> > If that doesn't cure it we can consider harsher measures, although I
>>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>>> >> > we can't.
>>> >> >
>>> >> > Erick
>>> >> >
>>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
>>> >> > wrote:
>>> >> >> I wish hossman was still more active in this type of thing. He would
>>> >> >> have
>>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>>> >> >> maybe he
>>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>>> >> >> the
>>> >> >> proper versions I could, and it's clean again for now.
>>> >> >>
>>> >> >> I'm halfway serious about the admin thing given you can easily auto
>>> >> >> create
>>> >> >> components and versions by accident. Maybe instead of giving it to
>>> >> >> everyone
>>> >> >> by default, we should be doing it by request.
>>> >> >>
>>> >> >> - Mark

Re: Strange Solr JIRA versions

[Cassandra Targett]

On Fri, Apr 14, 2017 at 9:56 AM, Mark Miller  wrote:
> I wish hossman was still more active in this type of thing. He would have
> sworn more

Heh. This is why I was going to send a mail about it before he got
back from vacation ;)

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

Re: Strange Solr JIRA versions

[Erick Erickson]

bq: my proposal would be to get rid of that PMC group (which is like
more admins), clear the admin group, and seed it with anyone that
calls out wanting access

+1

On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller  wrote:
> bq. Personally I'm fine with not being an administrator as long as I can
> assign JIRAs to myself and resolve them.
>
> I think that is 80-90% of us. The only time I ever use admin is to fix
> version stuff like this or do a release. I think Jenkins access might work
> this way, you have to request it. It would also be great if like the
> committer role could manage versions, but I couldn't seem to find that
> feature.
>
> But anyway, my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that calls out
> wanting access, and then give access as requested from there out, extra
> points for a warning about this 'feature' and managing versions consistently
> with the past unless there is discussion.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson 
> wrote:
>>
>> I agree with all your points and would _much_ rather be unable to
>> screw up even if it meant jumping through another hoop on those rare
>> occasions when I needed more authority.
>>
>> Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
>> wrote:
>> > The problem is not so much notifying people, because no one is closely
>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>> > it,
>> > there are 40-200 issues involved. You are not the only one. And I would
>> > be
>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>> > did
>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>> > is a
>> > problem. What about those not reading this, what about future
>> > committers,
>> > what about you go away for a year and come back having forgotten. The
>> > JIRA
>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>> > help
>> > from Atlassian likely any time soon. You can read the comments on the
>> > bug
>> > report and lots of people have this problem and hate it. The devs doing
>> > it
>> > here are not special, that's obvious.
>> >
>> > I'm not sure why we have so many admins though. Sure, if you do a
>> > release,
>> > you want to be able to manage the versions, but a huge number of
>> > committers
>> > have not done a release and could request admin when needed. Then we
>> > could
>> > grant it, and be like, by the way, careful with your god like powers to
>> > create stuff out of thin air without realizing.
>> >
>> > Perhaps the other reason most might use admin power is to add someone,
>> > but I
>> > think only a subset of people do that as well currently.
>> >
>> > - Mark
>> >
>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>> > 
>> > wrote:
>> >>
>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> >> versions" as "trunk", which is also incorrect.
>> >>
>> >> Well, now I know.
>> >>
>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>> >> 
>> >> wrote:
>> >> > If you look at the "history" tab on the JIRA you can see who set what
>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>> >> > has a long record of being very conscientious about changes so I'm
>> >> > certain it's just an awareness issue, at least for that person. I'll
>> >> > ping
>> >> >
>> >> > Which suggests a way to raise awareness going forward: check the
>> >> > history and send a message.
>> >> >
>> >> > If that doesn't cure it we can consider harsher measures, although I
>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> >> > we can't.
>> >> >
>> >> > Erick
>> >> >
>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
>> >> > wrote:
>> >> >> I wish hossman was still more active in this type of thing. He would
>> >> >> have
>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> >> maybe he
>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> >> the
>> >> >> proper versions I could, and it's clean again for now.
>> >> >>
>> >> >> I'm halfway serious about the admin thing given you can easily auto
>> >> >> create
>> >> >> components and versions by accident. Maybe instead of giving it to
>> >> >> everyone
>> >> >> by default, we should be doing it by request.
>> >> >>
>> >> >> - Mark
>> >> >>
>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller 
>> >> >> wrote:
>> >> >>>
>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>> >> >>> add
>> >> >>> new
>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>> >> >>>
>> >> >>> - Mark
>> >> >>>
>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>> >> >>> 
>> >> >>> wrote:
>> >> 
>> >>  Bummer, seems we can't lock this down :(
>> >>  

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7785:
--

Ok, thanks for the suggestions, I was able to run `ant precommit` and I've 
added/adjusted the files to make it happier.
It still fails for me but dues to some issue with 
`/org.ccil.cowan.tagsoup/tagsoup`, hopefully files related to this issue are 
good now.

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([EC9E13270669C8A6:2300761E8998A0F9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12550 lines...]
   [junit4] Suite: org.apache.solr.handle

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

Instead we would do:

{code}
// ok, now introduce a network partition between the leader and both 
replicas
log.info("Closing proxies for the non-leader replicas...");
for (SocketProxy proxy : nonLeaderProxies)
  proxy.close();

JettySolrRunner leaderJetty = getJettyOnPort(getReplicaPort(leader));
getProxyForReplica(leader).close();

// indexing during a partition
log.info("Sending a doc during the network partition...");
sendDoc(2);

// Wait a little
Thread.sleep(2000);

// Kill the leader
log.info("Killing leader for shard1 of " + collectionName + " on node " + 
leader.getNodeName() + "");
leaderJetty.stop();
{code}

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

more precisely, if the issue is as stated, it would seem the problem is that we 
stop the replicas from being able to receive requests, then we index 2 docs, 
then we kill the leader and close it's proxy. That is where there seems to be 
room for a replica to recover from the leader. If we do 
getProxyForReplica(leader).close() when we close the replica proxies, that 
should prevent any replica from being able to recover from it even before we 
kill the leader jetty. Doesn't seem like it would have any negative 
consequences either on first look. It's not like the test expects a replica to 
still be able to talk to the leader during this point, right?

{code}
// ok, now introduce a network partition between the leader and both 
replicas
log.info("Closing proxies for the non-leader replicas...");
for (SocketProxy proxy : nonLeaderProxies)
  proxy.close();

// indexing during a partition
log.info("Sending a doc during the network partition...");
sendDoc(2);

// Wait a little
Thread.sleep(2000);

// Kill the leader
log.info("Killing leader for shard1 of " + collectionName + " on node " + 
leader.getNodeName() + "");
JettySolrRunner leaderJetty = getJettyOnPort(getReplicaPort(leader));
getProxyForReplica(leader).close();
leaderJetty.stop();
{code}

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Mark Miller]

bq. committer role could manage versions, but I couldn't seem to find that
feature.

Although I suppose if it could, it would probably also get god like auto
create powers anyway.

On Fri, Apr 14, 2017 at 1:45 PM Mark Miller  wrote:

> bq. Personally I'm fine with not being an administrator as long as I can 
> assign
> JIRAs to myself and resolve them.
>
> I think that is 80-90% of us. The only time I ever use admin is to fix
> version stuff like this or do a release. I think Jenkins access might work
> this way, you have to request it. It would also be great if like the
> committer role could manage versions, but I couldn't seem to find that
> feature.
>
> But anyway, my proposal would be to get rid of that PMC group (which is
> like more admins), clear the admin group, and seed it with anyone that
> calls out wanting access, and then give access as requested from there out,
> extra points for a warning about this 'feature' and managing versions
> consistently with the past unless there is discussion.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson 
> wrote:
>
>> I agree with all your points and would _much_ rather be unable to
>> screw up even if it meant jumping through another hoop on those rare
>> occasions when I needed more authority.
>>
>> Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
>> wrote:
>> > The problem is not so much notifying people, because no one is closely
>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>> it,
>> > there are 40-200 issues involved. You are not the only one. And I would
>> be
>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>> did
>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>> is a
>> > problem. What about those not reading this, what about future
>> committers,
>> > what about you go away for a year and come back having forgotten. The
>> JIRA
>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>> help
>> > from Atlassian likely any time soon. You can read the comments on the
>> bug
>> > report and lots of people have this problem and hate it. The devs doing
>> it
>> > here are not special, that's obvious.
>> >
>> > I'm not sure why we have so many admins though. Sure, if you do a
>> release,
>> > you want to be able to manage the versions, but a huge number of
>> committers
>> > have not done a release and could request admin when needed. Then we
>> could
>> > grant it, and be like, by the way, careful with your god like powers to
>> > create stuff out of thin air without realizing.
>> >
>> > Perhaps the other reason most might use admin power is to add someone,
>> but I
>> > think only a subset of people do that as well currently.
>> >
>> > - Mark
>> >
>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson <
>> erickerick...@gmail.com>
>> > wrote:
>> >>
>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> >> versions" as "trunk", which is also incorrect.
>> >>
>> >> Well, now I know.
>> >>
>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <
>> erickerick...@gmail.com>
>> >> wrote:
>> >> > If you look at the "history" tab on the JIRA you can see who set what
>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>> >> > has a long record of being very conscientious about changes so I'm
>> >> > certain it's just an awareness issue, at least for that person. I'll
>> >> > ping
>> >> >
>> >> > Which suggests a way to raise awareness going forward: check the
>> >> > history and send a message.
>> >> >
>> >> > If that doesn't cure it we can consider harsher measures, although I
>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> >> > we can't.
>> >> >
>> >> > Erick
>> >> >
>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
>> >> > wrote:
>> >> >> I wish hossman was still more active in this type of thing. He would
>> >> >> have
>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> >> maybe he
>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> >> the
>> >> >> proper versions I could, and it's clean again for now.
>> >> >>
>> >> >> I'm halfway serious about the admin thing given you can easily auto
>> >> >> create
>> >> >> components and versions by accident. Maybe instead of giving it to
>> >> >> everyone
>> >> >> by default, we should be doing it by request.
>> >> >>
>> >> >> - Mark
>> >> >>
>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>> add
>> >> >>> new
>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>> >> >>>
>> >> >>> - Mark
>> >> >>>
>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <
>> markrmil...@gmail.com>
>> >> >>> wrote:
>> >> 
>> >>  B

Re: Strange Solr JIRA versions

[Mark Miller]

bq. Personally I'm fine with not being an administrator as long as I can assign
JIRAs to myself and resolve them.

I think that is 80-90% of us. The only time I ever use admin is to fix
version stuff like this or do a release. I think Jenkins access might work
this way, you have to request it. It would also be great if like the
committer role could manage versions, but I couldn't seem to find that
feature.

But anyway, my proposal would be to get rid of that PMC group (which is
like more admins), clear the admin group, and seed it with anyone that
calls out wanting access, and then give access as requested from there out,
extra points for a warning about this 'feature' and managing versions
consistently with the past unless there is discussion.

- Mark

On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson 
wrote:

> I agree with all your points and would _much_ rather be unable to
> screw up even if it meant jumping through another hoop on those rare
> occasions when I needed more authority.
>
> Personally I'm fine with not being an administrator as long as I can
> assign JIRAs to myself and resolve them.
>
> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller 
> wrote:
> > The problem is not so much notifying people, because no one is closely
> > monitoring this stuff. By the time we ever notice it and attempt to fix
> it,
> > there are 40-200 issues involved. You are not the only one. And I would
> be
> > angry at you! If not for the fact that it's a terrible JIRA issue that
> did
> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
> is a
> > problem. What about those not reading this, what about future committers,
> > what about you go away for a year and come back having forgotten. The
> JIRA
> > issue to fix this in JIRA has tons of votes, but it's also old, so no
> help
> > from Atlassian likely any time soon. You can read the comments on the bug
> > report and lots of people have this problem and hate it. The devs doing
> it
> > here are not special, that's obvious.
> >
> > I'm not sure why we have so many admins though. Sure, if you do a
> release,
> > you want to be able to manage the versions, but a huge number of
> committers
> > have not done a release and could request admin when needed. Then we
> could
> > grant it, and be like, by the way, careful with your god like powers to
> > create stuff out of thin air without realizing.
> >
> > Perhaps the other reason most might use admin power is to add someone,
> but I
> > think only a subset of people do that as well currently.
> >
> > - Mark
> >
> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson  >
> > wrote:
> >>
> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
> >> versions" as "trunk", which is also incorrect.
> >>
> >> Well, now I know.
> >>
> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <
> erickerick...@gmail.com>
> >> wrote:
> >> > If you look at the "history" tab on the JIRA you can see who set what
> >> > values when. I checked 4-5 of the JIRAS and the person who set those
> >> > has a long record of being very conscientious about changes so I'm
> >> > certain it's just an awareness issue, at least for that person. I'll
> >> > ping
> >> >
> >> > Which suggests a way to raise awareness going forward: check the
> >> > history and send a message.
> >> >
> >> > If that doesn't cure it we can consider harsher measures, although I
> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
> >> > we can't.
> >> >
> >> > Erick
> >> >
> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
> >> > wrote:
> >> >> I wish hossman was still more active in this type of thing. He would
> >> >> have
> >> >> sworn more and fixed it more meticulously and probably earlier. Or
> >> >> maybe he
> >> >> is sick of it after last time. Anyway, I did what I could, preserved
> >> >> the
> >> >> proper versions I could, and it's clean again for now.
> >> >>
> >> >> I'm halfway serious about the admin thing given you can easily auto
> >> >> create
> >> >> components and versions by accident. Maybe instead of giving it to
> >> >> everyone
> >> >> by default, we should be doing it by request.
> >> >>
> >> >> - Mark
> >> >>
> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller 
> >> >> wrote:
> >> >>>
> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
> add
> >> >>> new
> >> >>> bad versions in the future ;) This is no fun to cleanup.
> >> >>>
> >> >>> - Mark
> >> >>>
> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller  >
> >> >>> wrote:
> >> 
> >>  Bummer, seems we can't lock this down :(
> >>  https://jira.atlassian.com/browse/JRASERVER-42068
> >> 
> >>  On Fri, Apr 14, 2017 at 9:42 AM Mark Miller  >
> >>  wrote:
> >> >
> >> > On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
> >> >  wrote:
> >> >>
> >> >> I noticed these the other day also, and had an email half-wrote
> >> >> that I
> >> >> intended to finish up today.
> >> >>

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7785:


I see that the POM for {{ua.net.nlp:morfologik-ukrainian-search:3.7.5}} adds 
the v2 Apache license.  I hereby remove my -1.

bq. Please let me know if something is still wrong.

I'm pretty sure the current patch won't pass {{ant precommit}} - have you tried 
running that yet Andriy?  There are missing files in {{lucene/licenses/}} for 
the new dependency: a checksum file ({{\*.sha1}}), a LICENSE file and a NOTICE 
file.  You can generate the checksum file using {{ant jar-checksums}}, but 
you'll need to manually create the other two.  You can create 
{{morfologik-ukrainian-search.LICENSE-ASL.txt}} by copying from another file in 
that directory that contains a clean ALv2 license, e.g. 
{{commons-codec-LICENSE-ASL.txt}}.  I'm fuzzy on the requirements for the 
NOTICE file, but look at the other NOTICE files in that dir to get an idea of 
the range of things they contain.  Some info here: 
[http://www.apache.org/dev/licensing-howto.html#overview-of-files] and here: 
[http://www.apache.org/licenses/LICENSE-2.0.html#redistribution].

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Erick Erickson]

I agree with all your points and would _much_ rather be unable to
screw up even if it meant jumping through another hoop on those rare
occasions when I needed more authority.

Personally I'm fine with not being an administrator as long as I can
assign JIRAs to myself and resolve them.

On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller  wrote:
> The problem is not so much notifying people, because no one is closely
> monitoring this stuff. By the time we ever notice it and attempt to fix it,
> there are 40-200 issues involved. You are not the only one. And I would be
> angry at you! If not for the fact that it's a terrible JIRA issue that did
> not used to be a problem. But, ok, you have learned this JIRA 'feature' is a
> problem. What about those not reading this, what about future committers,
> what about you go away for a year and come back having forgotten. The JIRA
> issue to fix this in JIRA has tons of votes, but it's also old, so no help
> from Atlassian likely any time soon. You can read the comments on the bug
> report and lots of people have this problem and hate it. The devs doing it
> here are not special, that's obvious.
>
> I'm not sure why we have so many admins though. Sure, if you do a release,
> you want to be able to manage the versions, but a huge number of committers
> have not done a release and could request admin when needed. Then we could
> grant it, and be like, by the way, careful with your god like powers to
> create stuff out of thin air without realizing.
>
> Perhaps the other reason most might use admin power is to add someone, but I
> think only a subset of people do that as well currently.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson 
> wrote:
>>
>> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> versions" as "trunk", which is also incorrect.
>>
>> Well, now I know.
>>
>> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson 
>> wrote:
>> > If you look at the "history" tab on the JIRA you can see who set what
>> > values when. I checked 4-5 of the JIRAS and the person who set those
>> > has a long record of being very conscientious about changes so I'm
>> > certain it's just an awareness issue, at least for that person. I'll
>> > ping
>> >
>> > Which suggests a way to raise awareness going forward: check the
>> > history and send a message.
>> >
>> > If that doesn't cure it we can consider harsher measures, although I
>> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> > we can't.
>> >
>> > Erick
>> >
>> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
>> > wrote:
>> >> I wish hossman was still more active in this type of thing. He would
>> >> have
>> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> maybe he
>> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> the
>> >> proper versions I could, and it's clean again for now.
>> >>
>> >> I'm halfway serious about the admin thing given you can easily auto
>> >> create
>> >> components and versions by accident. Maybe instead of giving it to
>> >> everyone
>> >> by default, we should be doing it by request.
>> >>
>> >> - Mark
>> >>
>> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller 
>> >> wrote:
>> >>>
>> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add
>> >>> new
>> >>> bad versions in the future ;) This is no fun to cleanup.
>> >>>
>> >>> - Mark
>> >>>
>> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller 
>> >>> wrote:
>> 
>>  Bummer, seems we can't lock this down :(
>>  https://jira.atlassian.com/browse/JRASERVER-42068
>> 
>>  On Fri, Apr 14, 2017 at 9:42 AM Mark Miller 
>>  wrote:
>> >
>> > On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>> >  wrote:
>> >>
>> >> I noticed these the other day also, and had an email half-wrote
>> >> that I
>> >> intended to finish up today.
>> >>
>> >> To start, JIRA unfortunately makes this really easy to make a mess
>> >> of
>> >> - if you can create or edit an issue, you can just pop in a new
>> >> value
>> >> that gets added to the list of open versions. Editing an issue is
>> >> open
>> >> to lots of folks - committers, contributors, the reporter of an
>> >> issue.
>> >> So, we have high potential for this to be an ongoing problem.
>> >
>> >
>> > Ah, that makes this a lot less baffling I guess.
>> >
>> >>
>> >>
>> >> But, since only committers can commit patches and are thus the
>> >> usual
>> >> resolvers of an issue, committers either aren't paying enough
>> >> attention to that field when they resolve an issue or there is
>> >> confusion/difference of understanding about what that field is
>> >> supposed to mean.
>> >>
>> >> There are currently 49 issues for Solr that have these
>> >> "non-standard"
>> >> versions [1]. Some date back before the most recent 6.5.0 release,
>> >> which means th

[GitHub] lucene-solr issue #187: LUCENE-7785: Move dictionary for Ukrainan analyzer t...

[arysin]

Github user arysin commented on the issue:

https://github.com/apache/lucene-solr/pull/187
  
Thanks for the prompt feedback guys, I think I've addressed all the issues 
with the latest commits but please let me know if something is still wrong.
Once we're good with master branch I'll prepare the 6x changes.


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

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7785:


Github user arysin commented on the issue:

https://github.com/apache/lucene-solr/pull/187
  
Thanks for the prompt feedback guys, I think I've addressed all the issues 
with the latest commits but please let me know if something is still wrong.
Once we're good with master branch I'll prepare the 6x changes.


> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-10471:
--

Assignee: Mark Miller

> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2.1, master (7.0)
>Reporter: Michael Braun
>Assignee: Mark Miller
>Priority: Minor
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This 
> was changed in the solr.xml example but it was not changed in the solr 
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
>   fi
> {code}
> And for solr.cmd:
> {code}
>  IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it 
> will be overridden to 15,000. I'd think this should be raised to 30,000 or 
> removed entirely to fall back on the solr.xml's behavior.  
> [~markrmil...@gmail.com] is this correct?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Mark Miller]

The problem is not so much notifying people, because no one is closely
monitoring this stuff. By the time we ever notice it and attempt to fix it,
there are 40-200 issues involved. You are not the only one. And I would be
angry at you! If not for the fact that it's a terrible JIRA issue that did
not used to be a problem. But, ok, you have learned this JIRA 'feature' is
a problem. What about those not reading this, what about future committers,
what about you go away for a year and come back having forgotten. The JIRA
issue to fix this in JIRA has tons of votes, but it's also old, so no help
from Atlassian likely any time soon. You can read the comments on the bug
report and lots of people have this problem and hate it. The devs doing it
here are not special, that's obvious.

I'm not sure why we have so many admins though. Sure, if you do a release,
you want to be able to manage the versions, but a huge number of committers
have not done a release and could request admin when needed. Then we could
grant it, and be like, by the way, careful with your god like powers to
create stuff out of thin air without realizing.

Perhaps the other reason most might use admin power is to add someone, but
I think only a subset of people do that as well currently.

- Mark

On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson 
wrote:

> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
> versions" as "trunk", which is also incorrect.
>
> Well, now I know.
>
> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson 
> wrote:
> > If you look at the "history" tab on the JIRA you can see who set what
> > values when. I checked 4-5 of the JIRAS and the person who set those
> > has a long record of being very conscientious about changes so I'm
> > certain it's just an awareness issue, at least for that person. I'll
> > ping
> >
> > Which suggests a way to raise awareness going forward: check the
> > history and send a message.
> >
> > If that doesn't cure it we can consider harsher measures, although I
> > don't think forbidding arbitrary labels is "harsh", it's just too bad
> > we can't.
> >
> > Erick
> >
> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller 
> wrote:
> >> I wish hossman was still more active in this type of thing. He would
> have
> >> sworn more and fixed it more meticulously and probably earlier. Or
> maybe he
> >> is sick of it after last time. Anyway, I did what I could, preserved the
> >> proper versions I could, and it's clean again for now.
> >>
> >> I'm halfway serious about the admin thing given you can easily auto
> create
> >> components and versions by accident. Maybe instead of giving it to
> everyone
> >> by default, we should be doing it by request.
> >>
> >> - Mark
> >>
> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller 
> wrote:
> >>>
> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add
> new
> >>> bad versions in the future ;) This is no fun to cleanup.
> >>>
> >>> - Mark
> >>>
> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller 
> >>> wrote:
> 
>  Bummer, seems we can't lock this down :(
>  https://jira.atlassian.com/browse/JRASERVER-42068
> 
>  On Fri, Apr 14, 2017 at 9:42 AM Mark Miller 
>  wrote:
> >
> > On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
> >  wrote:
> >>
> >> I noticed these the other day also, and had an email half-wrote
> that I
> >> intended to finish up today.
> >>
> >> To start, JIRA unfortunately makes this really easy to make a mess
> of
> >> - if you can create or edit an issue, you can just pop in a new
> value
> >> that gets added to the list of open versions. Editing an issue is
> open
> >> to lots of folks - committers, contributors, the reporter of an
> issue.
> >> So, we have high potential for this to be an ongoing problem.
> >
> >
> > Ah, that makes this a lot less baffling I guess.
> >
> >>
> >>
> >> But, since only committers can commit patches and are thus the usual
> >> resolvers of an issue, committers either aren't paying enough
> >> attention to that field when they resolve an issue or there is
> >> confusion/difference of understanding about what that field is
> >> supposed to mean.
> >>
> >> There are currently 49 issues for Solr that have these
> "non-standard"
> >> versions [1]. Some date back before the most recent 6.5.0 release,
> >> which means there are issues fixed in 6.4 and 6.5 (at least) which
> >> don't say so in JIRA.
> >>
> >> This could be really problematic going forward. We need to agree
> that
> >> when issues are resolved, the fixVersion field is reliable and means
> >> the same thing to everyone.
> >
> >
> > +1!
> >
> >>
> >>
> >> IMO we should always use the *next* version that makes sense at that
> >> time. So, an issue resolved today would be "6.6" and "master (7.0)".
> >> Others may have different points of view on how 

Re: Strange Solr JIRA versions

[Erick Erickson]

Hmmm, and come to think of it I'm pretty sure I resolved some "fix
versions" as "trunk", which is also incorrect.

Well, now I know.

On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson  wrote:
> If you look at the "history" tab on the JIRA you can see who set what
> values when. I checked 4-5 of the JIRAS and the person who set those
> has a long record of being very conscientious about changes so I'm
> certain it's just an awareness issue, at least for that person. I'll
> ping
>
> Which suggests a way to raise awareness going forward: check the
> history and send a message.
>
> If that doesn't cure it we can consider harsher measures, although I
> don't think forbidding arbitrary labels is "harsh", it's just too bad
> we can't.
>
> Erick
>
> On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller  wrote:
>> I wish hossman was still more active in this type of thing. He would have
>> sworn more and fixed it more meticulously and probably earlier. Or maybe he
>> is sick of it after last time. Anyway, I did what I could, preserved the
>> proper versions I could, and it's clean again for now.
>>
>> I'm halfway serious about the admin thing given you can easily auto create
>> components and versions by accident. Maybe instead of giving it to everyone
>> by default, we should be doing it by request.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller  wrote:
>>>
>>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>>> bad versions in the future ;) This is no fun to cleanup.
>>>
>>> - Mark
>>>
>>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller 
>>> wrote:

 Bummer, seems we can't lock this down :(
 https://jira.atlassian.com/browse/JRASERVER-42068

 On Fri, Apr 14, 2017 at 9:42 AM Mark Miller 
 wrote:
>
> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>  wrote:
>>
>> I noticed these the other day also, and had an email half-wrote that I
>> intended to finish up today.
>>
>> To start, JIRA unfortunately makes this really easy to make a mess of
>> - if you can create or edit an issue, you can just pop in a new value
>> that gets added to the list of open versions. Editing an issue is open
>> to lots of folks - committers, contributors, the reporter of an issue.
>> So, we have high potential for this to be an ongoing problem.
>
>
> Ah, that makes this a lot less baffling I guess.
>
>>
>>
>> But, since only committers can commit patches and are thus the usual
>> resolvers of an issue, committers either aren't paying enough
>> attention to that field when they resolve an issue or there is
>> confusion/difference of understanding about what that field is
>> supposed to mean.
>>
>> There are currently 49 issues for Solr that have these "non-standard"
>> versions [1]. Some date back before the most recent 6.5.0 release,
>> which means there are issues fixed in 6.4 and 6.5 (at least) which
>> don't say so in JIRA.
>>
>> This could be really problematic going forward. We need to agree that
>> when issues are resolved, the fixVersion field is reliable and means
>> the same thing to everyone.
>
>
> +1!
>
>>
>>
>> IMO we should always use the *next* version that makes sense at that
>> time. So, an issue resolved today would be "6.6" and "master (7.0)".
>> Others may have different points of view on how we should do this, but
>> I think traditionally it's been the way I suggest, so if there is
>> change desired there, we should discuss it.
>
>
> I agree.
>
>>
>>
>> Side note: I know there is some doubt today that 6.6 will ever exist.
>> However, it will be a lot easier to go through JIRA to remove "6.6"
>> from issues that aren't in 6.x than it will be to review
>> issue-by-issue everything that says "6x" or "6.x" or "branch_6x",
>> etc., and figure out when it was actually released.
>
>
> +1. It also matches how we handle CHANGES afaict.
>
> I wish we could disable the auto creating of versions entirely somehow,
> but I guess the next best thing is to raise awareness. It's great to have
> the correct versions and in the correct ordering.
>
> - Mark
>
>>
>>
>> Cassandra
>>
>> [1] Query for JIRA issues:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x)
>>
>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller 
>> wrote:
>> > Who keeps adding strange JIRA release versions? I've cleaned up
>> > strange ones
>> > in the past and they keep coming back.
>> >
>> > Why do we have branch6x, 6x and 6.x and trunk?
>> >
>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I
>> > don't
>> > think we do, who keeps adding these duplic

Re: Strange Solr JIRA versions

[Erick Erickson]

If you look at the "history" tab on the JIRA you can see who set what
values when. I checked 4-5 of the JIRAS and the person who set those
has a long record of being very conscientious about changes so I'm
certain it's just an awareness issue, at least for that person. I'll
ping

Which suggests a way to raise awareness going forward: check the
history and send a message.

If that doesn't cure it we can consider harsher measures, although I
don't think forbidding arbitrary labels is "harsh", it's just too bad
we can't.

Erick

On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller  wrote:
> I wish hossman was still more active in this type of thing. He would have
> sworn more and fixed it more meticulously and probably earlier. Or maybe he
> is sick of it after last time. Anyway, I did what I could, preserved the
> proper versions I could, and it's clean again for now.
>
> I'm halfway serious about the admin thing given you can easily auto create
> components and versions by accident. Maybe instead of giving it to everyone
> by default, we should be doing it by request.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller  wrote:
>>
>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>> bad versions in the future ;) This is no fun to cleanup.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller 
>> wrote:
>>>
>>> Bummer, seems we can't lock this down :(
>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>
>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller 
>>> wrote:

 On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
  wrote:
>
> I noticed these the other day also, and had an email half-wrote that I
> intended to finish up today.
>
> To start, JIRA unfortunately makes this really easy to make a mess of
> - if you can create or edit an issue, you can just pop in a new value
> that gets added to the list of open versions. Editing an issue is open
> to lots of folks - committers, contributors, the reporter of an issue.
> So, we have high potential for this to be an ongoing problem.


 Ah, that makes this a lot less baffling I guess.

>
>
> But, since only committers can commit patches and are thus the usual
> resolvers of an issue, committers either aren't paying enough
> attention to that field when they resolve an issue or there is
> confusion/difference of understanding about what that field is
> supposed to mean.
>
> There are currently 49 issues for Solr that have these "non-standard"
> versions [1]. Some date back before the most recent 6.5.0 release,
> which means there are issues fixed in 6.4 and 6.5 (at least) which
> don't say so in JIRA.
>
> This could be really problematic going forward. We need to agree that
> when issues are resolved, the fixVersion field is reliable and means
> the same thing to everyone.


 +1!

>
>
> IMO we should always use the *next* version that makes sense at that
> time. So, an issue resolved today would be "6.6" and "master (7.0)".
> Others may have different points of view on how we should do this, but
> I think traditionally it's been the way I suggest, so if there is
> change desired there, we should discuss it.


 I agree.

>
>
> Side note: I know there is some doubt today that 6.6 will ever exist.
> However, it will be a lot easier to go through JIRA to remove "6.6"
> from issues that aren't in 6.x than it will be to review
> issue-by-issue everything that says "6x" or "6.x" or "branch_6x",
> etc., and figure out when it was actually released.


 +1. It also matches how we handle CHANGES afaict.

 I wish we could disable the auto creating of versions entirely somehow,
 but I guess the next best thing is to raise awareness. It's great to have
 the correct versions and in the correct ordering.

 - Mark

>
>
> Cassandra
>
> [1] Query for JIRA issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x)
>
> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller 
> wrote:
> > Who keeps adding strange JIRA release versions? I've cleaned up
> > strange ones
> > in the past and they keep coming back.
> >
> > Why do we have branch6x, 6x and 6.x and trunk?
> >
> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I
> > don't
> > think we do, who keeps adding these duplicates? Let's come to some
> > sanity
> > here.
> >
> > - Mark
> > --
> > - Mark
> > about.me/markrmiller
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@l

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7785:


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

https://github.com/apache/lucene-solr/pull/187#discussion_r111596732
  
--- Diff: 
lucene/analysis/morfologik/src/java/org/apache/lucene/analysis/uk/UkrainianMorfologikAnalyzer.java
 ---
@@ -145,7 +152,7 @@ protected TokenStreamComponents createComponents(String 
fieldName) {
 
   private static Dictionary getDictionary() {
 try {
-  return 
Dictionary.read(UkrainianMorfologikAnalyzer.class.getResource("ukrainian.dict"));
+  return 
Dictionary.read(UkrainianMorfologikAnalyzer.class.getResource("/ua/net/nlp/ukrainian.dict"));
--- End diff --

I am a bit confused on why for class loader getResource() we need relative 
path (surprisingly the full one starting with "/" does not work for me), but 
otherwise it makes sense so I'll push the fix shortly.


> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #187: LUCENE-7785: Move dictionary for Ukrainan ana...

[arysin]

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

https://github.com/apache/lucene-solr/pull/187#discussion_r111596732
  
--- Diff: 
lucene/analysis/morfologik/src/java/org/apache/lucene/analysis/uk/UkrainianMorfologikAnalyzer.java
 ---
@@ -145,7 +152,7 @@ protected TokenStreamComponents createComponents(String 
fieldName) {
 
   private static Dictionary getDictionary() {
 try {
-  return 
Dictionary.read(UkrainianMorfologikAnalyzer.class.getResource("ukrainian.dict"));
+  return 
Dictionary.read(UkrainianMorfologikAnalyzer.class.getResource("/ua/net/nlp/ukrainian.dict"));
--- End diff --

I am a bit confused on why for class loader getResource() we need relative 
path (surprisingly the full one starting with "/" does not work for me), but 
otherwise it makes sense so I'll push the fix shortly.


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

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

Maybe we can just close the leader proxy before we index the docs.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-7785:


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

https://github.com/apache/lucene-solr/pull/187#discussion_r111595706
  
--- Diff: 
lucene/analysis/morfologik/src/java/org/apache/lucene/analysis/uk/UkrainianMorfologikAnalyzer.java
 ---
@@ -107,11 +107,18 @@ public UkrainianMorfologikAnalyzer(CharArraySet 
stopwords, CharArraySet stemExcl
   @Override
   protected Reader initReader(String fieldName, Reader reader) {
 NormalizeCharMap.Builder builder = new NormalizeCharMap.Builder();
+// different apostrophes
 builder.add("\u2019", "'");
+builder.add("\u0218", "'");
 builder.add("\u02BC", "'");
+builder.add("`", "'");
+builder.add("´", "'");
+// ignored characters
 builder.add("\u0301", "");
-NormalizeCharMap normMap = builder.build();
+builder.add("\u00AD", "");
+builder.add("\uFEFF", "");
--- End diff --

That was from the note [Wikimedia guys 
suggested](https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Ukrainian_Morfologik_Analysis#Recommendations_.26_Plan),
 but agree it does not make sense here, I'll remove it


> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[GitHub] lucene-solr pull request #187: LUCENE-7785: Move dictionary for Ukrainan ana...

[arysin]

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

https://github.com/apache/lucene-solr/pull/187#discussion_r111595706
  
--- Diff: 
lucene/analysis/morfologik/src/java/org/apache/lucene/analysis/uk/UkrainianMorfologikAnalyzer.java
 ---
@@ -107,11 +107,18 @@ public UkrainianMorfologikAnalyzer(CharArraySet 
stopwords, CharArraySet stemExcl
   @Override
   protected Reader initReader(String fieldName, Reader reader) {
 NormalizeCharMap.Builder builder = new NormalizeCharMap.Builder();
+// different apostrophes
 builder.add("\u2019", "'");
+builder.add("\u0218", "'");
 builder.add("\u02BC", "'");
+builder.add("`", "'");
+builder.add("´", "'");
+// ignored characters
 builder.add("\u0301", "");
-NormalizeCharMap normMap = builder.build();
+builder.add("\u00AD", "");
+builder.add("\uFEFF", "");
--- End diff --

That was from the note [Wikimedia guys 
suggested](https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Ukrainian_Morfologik_Analysis#Recommendations_.26_Plan),
 but agree it does not make sense here, I'll remove it


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

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

I suppose that depends on if it's the same as removing force leader test 
coverage. We want to maintain it if we can - whether that means using the 
proxy, changing we use it, or changing the test. 

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10475) DIH JdbcDataSource SqlEntityProcessor - Support Child-free parents after all children has been consumed

[Pavel Vasilyev (JIRA)]

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

Pavel Vasilyev resolved SOLR-10475.
---
   Resolution: Cannot Reproduce
Fix Version/s: 6.4.2

With Solr 6.4.2 the DIH is working as expected without any side effects. 
Additional case with &maxRows limit is also working fine.

> DIH JdbcDataSource SqlEntityProcessor - Support Child-free parents after all 
> children has been consumed
> ---
>
> Key: SOLR-10475
> URL: https://issues.apache.org/jira/browse/SOLR-10475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 5.5.1
> Environment: Solr on Linux machine
> Oracle Data base (11g)
>Reporter: Pavel Vasilyev
> Fix For: 6.4.2
>
> Attachments: SOLR-10475.patch
>
>
> Assume DIH's feature of zipping {{parents}} and {{children}} is used. Here is 
> sample {{dih-config.xml}}:
> {code:xml}
> 
>   
>query="SELECT * FROM PARENT ORDER BY id">  
>  where="parent_id=parent.id" query="SELECT * 
> FROM CHILD_1 ORDER BY parent_id" join="zipper" >
>  
>   
>   
> 
> {code}
> One might come up with the issue when:
> - Oracle Database is used;
> - at some point of joining there are no more children documents; thus the 
> child's {{ResultSet}} is closed;
> - parent documents are not finished; thus {{ResultSet}} is still in process;
> - attempting to find child for the next parent is failing due to closed 
> {{ResultSet}}
> Here is stacktrace:
> {code}
> org.apache.solr.handler.dataimport.DataImportHandlerException: 
> java.sql.SQLRecoverableException: Closed Resultset: next
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:61)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:434)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(JdbcDataSource.java:350)
> at 
> com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1216)
> at org.apache.solr.handler.dataimport.Zipper.supplyNextChild(Zipper.java:65)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:127)
> at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
> at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
> at 
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461)
> Caused by: java.sql.SQLRecoverableException: Closed Resultset: next
> at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:238)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:426)
> ... 14 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10475) DIH JdbcDataSource SqlEntityProcessor - Support Child-free parents after all children has been consumed

[Pavel Vasilyev (JIRA)]

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

Pavel Vasilyev commented on SOLR-10475:
---

Andrey, thank you for your valuable input.

Looks like the issue was related to Oracle jdbc in particular. Nevertheless, 
the issue is not reproducible on Solr 6.4.2.
IMO we can close the issue as Non Reproducible (at least on latest builds).

Thank you,

> DIH JdbcDataSource SqlEntityProcessor - Support Child-free parents after all 
> children has been consumed
> ---
>
> Key: SOLR-10475
> URL: https://issues.apache.org/jira/browse/SOLR-10475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 5.5.1
> Environment: Solr on Linux machine
> Oracle Data base (11g)
>Reporter: Pavel Vasilyev
> Attachments: SOLR-10475.patch
>
>
> Assume DIH's feature of zipping {{parents}} and {{children}} is used. Here is 
> sample {{dih-config.xml}}:
> {code:xml}
> 
>   
>query="SELECT * FROM PARENT ORDER BY id">  
>  where="parent_id=parent.id" query="SELECT * 
> FROM CHILD_1 ORDER BY parent_id" join="zipper" >
>  
>   
>   
> 
> {code}
> One might come up with the issue when:
> - Oracle Database is used;
> - at some point of joining there are no more children documents; thus the 
> child's {{ResultSet}} is closed;
> - parent documents are not finished; thus {{ResultSet}} is still in process;
> - attempting to find child for the next parent is failing due to closed 
> {{ResultSet}}
> Here is stacktrace:
> {code}
> org.apache.solr.handler.dataimport.DataImportHandlerException: 
> java.sql.SQLRecoverableException: Closed Resultset: next
> at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:61)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:434)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(JdbcDataSource.java:350)
> at 
> com.google.common.collect.Iterators$PeekingImpl.hasNext(Iterators.java:1216)
> at org.apache.solr.handler.dataimport.Zipper.supplyNextChild(Zipper.java:65)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:127)
> at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
> at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:244)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
> at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
> at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
> at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
> at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
> at 
> org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461)
> Caused by: java.sql.SQLRecoverableException: Closed Resultset: next
> at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:238)
> at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:426)
> ... 14 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7785) Move dictionary for Ukrainian analyzer to external dependency

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7785:
-

Steven is right -- we can't accept these licenses, Andriy. 

> Move dictionary for Ukrainian analyzer to external dependency
> -
>
> Key: LUCENE-7785
> URL: https://issues.apache.org/jira/browse/LUCENE-7785
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andriy Rysin
>Assignee: Dawid Weiss
>
> Currently the dictionary for Ukrainian analyzer is a blob in the source tree. 
> We should move it out to external dependency, this allows:
> * to have less binaries in the source
> * easier to update the dictionary and track updates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9555:
-

I guess I was unclear. I meant to rip the proxy stuff out _from this test_. I'm 
sure it's fine (and necessary) elsewhere.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

My first thought would be to guess that ForceLeaderTest is just using the proxy 
stuff incorrectly. Turning off the proxy for a jetty cuts off communication to 
that jetty (to the port that jetty is listening on), not also 'from' that jetty 
was my understanding.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9555:
---

bq. I think this is big problem for our jetty proxy stuff, right?

I guess it depends on the test. [~timporter], any thoughts on this comment?

I'm not sure we want to rip the proxy stuff out just yet, but we do want to 
look into [~caomanhdat]'s comment and perhaps see if we can improve things if 
we need to.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-9555 at 4/14/17 3:17 PM:


bq. I think this is big problem for our jetty proxy stuff, right?

I guess it depends on the test. [~thelabdude]], any thoughts on this comment?

I'm not sure we want to rip the proxy stuff out just yet, but we do want to 
look into [~caomanhdat]'s comment and perhaps see if we can improve things if 
we need to.


was (Author: markrmil...@gmail.com):
bq. I think this is big problem for our jetty proxy stuff, right?

I guess it depends on the test. [~timporter], any thoughts on this comment?

I'm not sure we want to rip the proxy stuff out just yet, but we do want to 
look into [~caomanhdat]'s comment and perhaps see if we can improve things if 
we need to.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10489) StatsReloadRaceTest.testParallelReloadAndStats failures

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-10489:
-

Assignee: Erick Erickson  (was: Andrzej Bialecki )

> StatsReloadRaceTest.testParallelReloadAndStats failures
> ---
>
> Key: SOLR-10489
> URL: https://issues.apache.org/jira/browse/SOLR-10489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Erick Erickson
>
> This test has been failing a lot after the changes in SOLR-9959, for unclear 
> reasons. The failure is always in the same place:
> {code}
> java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
> registry solr.core.collection1
>   at 
> __randomizedtesting.SeedInfo.seed([28B54D77FD0E3DF1:E72B284E72FF55AE]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10489) StatsReloadRaceTest.testParallelReloadAndStats failures

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10489:
---

I’m getting about a 1% failure rate on this test _and_ one of the ones that 
gave me grief when working on SOLR-10007. I’ve backed my local version out to 
the commit just before SOLR-10007 but including SOLR-9959 and I'm beasting it 
now. My guess is that these two tests won’t fail, but it’ll take pretty much 
all day for me to be certain.

Meanwhile I'll grab this JIRA since I strongly suspect SOLR-10007. [~ab] feel 
free to take it back, at this point it looks like something I introduced though.

This is the other test that fails for me.
SolrCloudExampleTest



> StatsReloadRaceTest.testParallelReloadAndStats failures
> ---
>
> Key: SOLR-10489
> URL: https://issues.apache.org/jira/browse/SOLR-10489
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>
> This test has been failing a lot after the changes in SOLR-9959, for unclear 
> reasons. The failure is always in the same place:
> {code}
> java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
> registry solr.core.collection1
>   at 
> __randomizedtesting.SeedInfo.seed([28B54D77FD0E3DF1:E72B284E72FF55AE]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
>   at 
> org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9555:
-

[~caomanhdat] - yea, ForceLeaderTest was one of the ones that was failing for 
me. A node still able to recover when it shouldn't would make sense, but I 
don't really understand how the proxy stuff works enough to debug it or know 
how to fix it. Is the right path to rip the proxy stuff out and kill nodes some 
other way?

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Mark Miller]

I wish hossman was still more active in this type of thing. He would have
sworn more and fixed it more meticulously and probably earlier. Or maybe he
is sick of it after last time. Anyway, I did what I could, preserved the
proper versions I could, and it's clean again for now.

I'm halfway serious about the admin thing given you can easily auto create
components and versions by accident. Maybe instead of giving it to everyone
by default, we should be doing it by request.

- Mark

On Fri, Apr 14, 2017 at 10:29 AM Mark Miller  wrote:

> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
> bad versions in the future ;) This is no fun to cleanup.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller 
> wrote:
>
>> Bummer, seems we can't lock this down :(
>> https://jira.atlassian.com/browse/JRASERVER-42068
>>
>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller 
>> wrote:
>>
>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett 
>>> wrote:
>>>
 I noticed these the other day also, and had an email half-wrote that I
 intended to finish up today.

 To start, JIRA unfortunately makes this really easy to make a mess of
 - if you can create or edit an issue, you can just pop in a new value
 that gets added to the list of open versions. Editing an issue is open
 to lots of folks - committers, contributors, the reporter of an issue.
 So, we have high potential for this to be an ongoing problem.

>>>
>>> Ah, that makes this a lot less baffling I guess.
>>>
>>>

 But, since only committers can commit patches and are thus the usual
 resolvers of an issue, committers either aren't paying enough
 attention to that field when they resolve an issue or there is
 confusion/difference of understanding about what that field is
 supposed to mean.

 There are currently 49 issues for Solr that have these "non-standard"
 versions [1]. Some date back before the most recent 6.5.0 release,
 which means there are issues fixed in 6.4 and 6.5 (at least) which
 don't say so in JIRA.

 This could be really problematic going forward. We need to agree that
 when issues are resolved, the fixVersion field is reliable and means
 the same thing to everyone.

>>>
>>> +1!
>>>
>>>

 IMO we should always use the *next* version that makes sense at that
 time. So, an issue resolved today would be "6.6" and "master (7.0)".
 Others may have different points of view on how we should do this, but
 I think traditionally it's been the way I suggest, so if there is
 change desired there, we should discuss it.

>>>
>>> I agree.
>>>
>>>

 Side note: I know there is some doubt today that 6.6 will ever exist.
 However, it will be a lot easier to go through JIRA to remove "6.6"
 from issues that aren't in 6.x than it will be to review
 issue-by-issue everything that says "6x" or "6.x" or "branch_6x",
 etc., and figure out when it was actually released.

>>>
>>> +1. It also matches how we handle CHANGES afaict.
>>>
>>> I wish we could disable the auto creating of versions entirely somehow,
>>> but I guess the next best thing is to raise awareness. It's great to have
>>> the correct versions and in the correct ordering.
>>>
>>> - Mark
>>>
>>>

 Cassandra

 [1] Query for JIRA issues:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x)

 On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller 
 wrote:
 > Who keeps adding strange JIRA release versions? I've cleaned up
 strange ones
 > in the past and they keep coming back.
 >
 > Why do we have branch6x, 6x and 6.x and trunk?
 >
 > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I
 don't
 > think we do, who keeps adding these duplicates? Let's come to some
 sanity
 > here.
 >
 > - Mark
 > --
 > - Mark
 > about.me/markrmiller

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

 --
>>> - Mark
>>> about.me/markrmiller
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

[jira] [Updated] (SOLR-9726) DocValuesFacets: move 'contains' check after 'min' check

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9726:
--
Fix Version/s: (was: 6.x)
   6.4

> DocValuesFacets: move 'contains' check after 'min' check
> 
>
> Key: SOLR-9726
> URL: https://issues.apache.org/jira/browse/SOLR-9726
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-9726.patch
>
>
> If a query requests facets with a 'contains' check, DocValuesFacets converts 
> each term's ordinal to a BytesRef, does the string match and then checks 
> whether it has a high enough count to go in the priority queue.
> This patch moves the lookup after the min check so that we don't do it for 
> all terms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9353) factor out ReRankQParserPlugin.ReRankQueryRescorer private class

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9353:
--
Fix Version/s: (was: 6.x)
   6.2

> factor out ReRankQParserPlugin.ReRankQueryRescorer private class
> 
>
> Key: SOLR-9353
> URL: https://issues.apache.org/jira/browse/SOLR-9353
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9353.patch
>
>
> To reduce the number of rescorer objects potentially created and also towards 
> (more) code sharing with SOLR-8542.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9574) factor out AbstractReRankQuery class

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9574:
--
Fix Version/s: (was: 6.x)
   6.3

> factor out AbstractReRankQuery class
> 
>
> Key: SOLR-9574
> URL: https://issues.apache.org/jira/browse/SOLR-9574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9574.patch
>
>
> Motivation is to avoid unnecessary code duplication between 
> ReRankQParserPlugin and the SOLR-8542 plugin.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9543) reduce code duplication in ReRankQParserPlugin.ReRankCollector.topDocs

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9543:
--
Fix Version/s: (was: 6.x)
   6.3

> reduce code duplication in ReRankQParserPlugin.ReRankCollector.topDocs
> --
>
> Key: SOLR-9543
> URL: https://issues.apache.org/jira/browse/SOLR-9543
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9543-reduce-part1.patch, 
> SOLR-9543-reduce-part2.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9758) refactor preferLocalShards implementation

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9758:
--
Fix Version/s: (was: 6.x)
   6.4

> refactor preferLocalShards implementation
> -
>
> Key: SOLR-9758
> URL: https://issues.apache.org/jira/browse/SOLR-9758
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-9758.patch
>
>
> This ticket proposes to refactor the existing preferLocalShards 
> implementation (from SOLR-6832 and SOLR-8298) based upon the recent (in 
> SOLR-8332) ReplicaListTransformer addition.
> The intention of the refactor is to encapsulate the local shard url selection 
> logic within the HttpShardHandlerFactory.getReplicaListTransformer method (it 
> is currently spread across the public HttpShardHandler.prepDistributed and 
> the private HttpShardHandler.getURLs method) and to thus remove the 
> ResponseBuilder.preferredHostAddress field.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9412) Update Macro Expander for replacement logic

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9412:
--
Fix Version/s: (was: 6.x)
   6.3

> Update Macro Expander for replacement logic
> ---
>
> Key: SOLR-9412
> URL: https://issues.apache.org/jira/browse/SOLR-9412
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jon Dorando
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9412.patch
>
>
> MacroExpander class was updated to allow to return null when replacement 
> parameters are missing. Right now it defaults to a blank space and it isn't 
> easily verifiable that a parameter was missing. Additionally, unit tests were 
> added for this case and the original use cases of Macro Expander.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9391) LBHttpSolrClient.request can return incorrect Rsp.server string

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9391:
--
Fix Version/s: (was: 6.x)
   6.2

> LBHttpSolrClient.request can return incorrect Rsp.server string
> ---
>
> Key: SOLR-9391
> URL: https://issues.apache.org/jira/browse/SOLR-9391
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9391.patch
>
>
> Problem:
> * 
> [LBHttpSolrClient.request|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java#L361-L366]
>  assigns to {{rsp.server}} at line 361 and then at line 366 makes a 
> {{doRequest(client, req, rsp, isUpdate, false, null);}} method call.
> * If the original {{doRequest}} call(s) did not succeed then later at [line 
> 382|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java#L382]
>  additional {{doRequest}} calls may happen. These calls could use a different 
> server but currently {{rsp.server}} remains unchanged and thus 
> [LBHttpSolrClient.request|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java#L331]
>  could return an incorrect {{Rsp.server}} string value.
> Proposed fix: 
> * Change the [doRequest 
> method|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java#L409-L413]
>  so that it assigns {{Rsp.server}} alongside the existing {{Rsp.rsp}} 
> assignment.
> * Note that since the [HttpSolrClient 
> constructor|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java#L190-L199]
>  trims of any trailing {{/}} from the {{baseUrl}} then the proposed fix 
> potentially minutely changes the {{Rsp.getServer()}} return value.
> ** {{Rsp.getServer()}} is called by 
> [HttpShardHandler.submit|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java#L200]
>  as {{srsp.setShardAddress(rsp.getServer());}}
> ** I have not fully checked where/how {{getShardAddress()}} is then 
> subsequently used but would very much hope that the removal of a trailing 
> {{/}} would not cause any issues.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9912) SimpleFacets - support facet.excludeTerms parameter

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9912:
--
Fix Version/s: (was: 6.x)
   6.5

> SimpleFacets - support facet.excludeTerms parameter
> ---
>
> Key: SOLR-9912
> URL: https://issues.apache.org/jira/browse/SOLR-9912
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9912.patch, SOLR-9912.patch, SOLR-9912.patch, 
> SOLR-9912.patch
>
>
> This ticket is for supporting a new facet.excludeTerms parameter for removing 
> specific terms from the facet counts, without having to exclude the terms 
> from the index itself.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9660) in GroupingSpecification factor [group](sort|offset|limit) into [group](sortSpec)

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9660:
--
Fix Version/s: (was: 6.x)
   6.4

> in GroupingSpecification factor [group](sort|offset|limit) into 
> [group](sortSpec)
> -
>
> Key: SOLR-9660
> URL: https://issues.apache.org/jira/browse/SOLR-9660
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-9660.patch, SOLR-9660.patch, SOLR-9660.patch, 
> SOLR-9660.patch
>
>
> This is split out and adapted from and towards the SOLR-6203 changes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9932) add TestSolrCoreParser class

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9932:
--
Fix Version/s: (was: 6.x)
   6.5

> add TestSolrCoreParser class
> 
>
> Key: SOLR-9932
> URL: https://issues.apache.org/jira/browse/SOLR-9932
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9932.patch
>
>
> The new TestSolrCoreParser class directly instantiates a SolrCoreParser and 
> initialises it with custom query builders, the tests then check that custom 
> xml parses correctly _and_ that the resulting Query object is an instance of 
> the correct class.
> In comparison, the existing TestXmlQParserPlugin test indirectly instantiates 
> and initialises a SolrCoreParser via the solrconfig-testxmlparser.xml and 
> then executes the custom xml queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10077) TestManagedFeatureStore extends LuceneTestCase, but has no tests and just hosts a static method.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-10077:
---
Fix Version/s: (was: 6.x)
   6.5

> TestManagedFeatureStore extends LuceneTestCase, but has no tests and just 
> hosts a static method.
> 
>
> Key: SOLR-10077
> URL: https://issues.apache.org/jira/browse/SOLR-10077
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-10077.patch
>
>
> We should probably just put this static method somewhere else?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9783) remove no-longer-needed sortWithinGroup null checks in (Search|Top)Group[s]ShardResponseProcessor

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9783:
--
Fix Version/s: (was: 6.x)
   6.4

> remove no-longer-needed sortWithinGroup null checks in 
> (Search|Top)Group[s]ShardResponseProcessor
> -
>
> Key: SOLR-9783
> URL: https://issues.apache.org/jira/browse/SOLR-9783
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-9783.patch
>
>
> Why this, why now? I was looking some more at SOLR-6203 and what the next 
> sub-step after the SOLR-9660 sub-step might be. Revisiting [~Judith]'s 
> SOLR-6203 README file, the step (1) is included in SOLR-9660 and step (2) 
> mentions passing around SortSpecs rather than plain Sorts, with Search and 
> TopGroups ShardResponseProcessor amongst the files affected. In principle the 
> change for those two files should be straightforward i.e.
> {code}
>   ...
> - Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
> + SortSpec sortSpecWithinGroup = 
> rb.getGroupingSpec().getSortSpecWithinGroup();
>   ...
> {code}
> except that both starting points are
> {code}
>   Sort sortWithinGroup = rb.getGroupingSpec().getSortWithinGroup();
>   if (sortWithinGroup == null) { // TODO prevent it from being null in the 
> first place
> sortWithinGroup = Sort.RELEVANCE;
>   }
> {code}
> and so this ticket here aims to get rid of the two 'TODO' statements. The 
> statements were added as part of LUCENE-6900's 
> https://svn.apache.org/viewvc?view=revision&revision=1716569 in November 2015 
> and Judith's original SOLR-6203.patch is from October 2015 i.e. slightly 
> before then.
> [~dsmiley] - do you recall anything re: when/how {{sortWithinGroup}} could be 
> null back then? From my reading of the current (master) code the 
> sortWithinGroup would never be null now. {{solr/core}} tests pass when the if 
> statements are removed (will attach patch and also run the non-core solr 
> tests) but that could of course just be due to lacking test coverage.
> And unrelated but noticed whilst in the code area, the patch includes a
> {code}
> + ... || sort == Sort.RELEVANCE) {
> - ... || sort.equals(Sort.RELEVANCE)) {
> {code}
> tweak to QueryCommand.java also.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9890) factor out ShardResultTransformerUtils.[un]marshSortValue methods

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9890:
--
Fix Version/s: (was: 6.x)
   6.5

> factor out ShardResultTransformerUtils.[un]marshSortValue methods
> -
>
> Key: SOLR-9890
> URL: https://issues.apache.org/jira/browse/SOLR-9890
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9890.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9551) Add constructor to JSONWriter which takes wrapperFunction and namedListStyle

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9551:
--
Fix Version/s: (was: 6.x)
   6.3

> Add constructor to JSONWriter which takes wrapperFunction and namedListStyle
> 
>
> Key: SOLR-9551
> URL: https://issues.apache.org/jira/browse/SOLR-9551
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9551.patch, SOLR-9551.patch
>
>
> Currently JSONWriter's constructor extracts the wrapperFunction and 
> namedListStyle from the request.
> This patch adds a new constructor where these are passed in from 
> JSONResponseWriter. This will allow us to decide in JSONResponseWriter which 
> writer to construct based on the named list style.
> There is precedent here - GeoJSONResponseWriter extracts geofield from the 
> request and passes it to GeoJSONWriter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9800) FacetComponent - move construction of SimpleFacets to a protected method

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9800:
--
Fix Version/s: (was: 6.x)
   6.5

> FacetComponent - move construction of SimpleFacets to a protected method
> 
>
> Key: SOLR-9800
> URL: https://issues.apache.org/jira/browse/SOLR-9800
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9800.patch
>
>
> This patch moves the construction of SimpleFacets from inside process() to a 
> new protected method, allowing contrib modules to reuse FacetComponent with a 
> different SimpleFacets implementation.
> For example:
> {code}
> class MyFacetComponent extends FacetComponent {
>   @Override
>   protected SimpleFacets newSimpleFacets(SolrQueryRequest req, DocSet docSet, 
> SolrParams params, ResponseBuilder rb) {
> return new SimpleFacets(req, docSet, params, rb) {
>   @Override
>   protected Predicate newBytesRefFilter(String field, 
> SolrParams params) {
> ...
> return new MyBytesRefFilter (...);
>   }
> };
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats

Error Message:
Key SEARCHER.searcher.indexVersion not found in registry solr.core.collection1

Stack Trace:
java.lang.AssertionError: Key SEARCHER.searcher.indexVersion not found in 
registry solr.core.collection1
at 
__randomizedtesting.SeedInfo.seed([D8B7E38ABD685F1E:172986B332993741]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.requestMetrics(StatsReloadRaceTest.java:132)
at 
org.apache.solr.handler.admin.StatsReloadRaceTest.testParallelReloadAndStats(StatsReloadRaceTest.java:70)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:563)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults

[jira] [Updated] (SOLR-9436) remove no longer used acceptsDocsOutOfOrder methods

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9436:
--
Fix Version/s: (was: 6.x)
   6.3

> remove no longer used acceptsDocsOutOfOrder methods
> ---
>
> Key: SOLR-9436
> URL: https://issues.apache.org/jira/browse/SOLR-9436
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9436.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9535) SolrClients should have protected constructors

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9535:
--
Fix Version/s: (was: 6.x)

> SolrClients should have protected constructors
> --
>
> Key: SOLR-9535
> URL: https://issues.apache.org/jira/browse/SOLR-9535
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.x
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-9535.patch
>
>
> Recent SolrJ changes (SOLR-8097) resulted in {{SolrClient}} ending up with 
> {{protected}} ctors.  This achieved the purpose at the time, and steered 
> consumers towards using the *Builder types.  However the change was overly 
> restrictive, as this visibility prevents consumers from extending 
> {{SolrClient}} in any meaningful way.
> This issue involves changing the visibility of the SolrClient "kitchen sink" 
> ctors to better support extension.
> (See recent discussion on SOLR-8097 for more discussion on this topic.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9567) factor out ReRankCollector from ReRankQParserPlugin

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9567:
--
Fix Version/s: (was: 6.x)
   6.3

> factor out ReRankCollector from ReRankQParserPlugin
> ---
>
> Key: SOLR-9567
> URL: https://issues.apache.org/jira/browse/SOLR-9567
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9567.patch, SOLR-9567.patch
>
>
> Factor out the collector used by ReRankQParserPlugin so that similar 
> reranking queries (e.g. SOLR-8542) can use the same collector.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9415) graph search filter edge

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9415:
--
Fix Version/s: (was: 6.x)

> graph search filter edge
> 
>
> Key: SOLR-9415
> URL: https://issues.apache.org/jira/browse/SOLR-9415
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
>Reporter: cmd
>
> currently solr graph hasn't edge concept! for example:
> name1(node),name2(node),relationtype,time,other edge attr.
> tom,alice,College_school_classmate,2016-10-01 
> tom,alice,High_school_classmate,2013-10-01
> tom,alice,middle_school_classmate,2009-10-01
> tom,alice,Primary_school_classmate,2005-10-01 
> tom,Smith,College_school_classmate,2016-10-01 
> tom,Smith,High_school_classmate,2013-10-01
> tom,Smith,middle_school_classmate,2009-10-01
> tom,Smith,Primary_school_classmate,2005-10-01 
> node
> tom  age:23 sex:male addr:
> Smith age:25 sex...
> alice   .
> i want to filter: tom time:[2009 to 2013]  and addr: and  
> relationtype=College is who?
> refer: http://graphml.graphdrawing.org/primer/graphml-primer.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9538) Relocate {JSON,Smile}WriterTest and TestBinaryResponseWriter to org.apache.solr.response

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9538:
--
Fix Version/s: (was: 6.x)
   6.3

> Relocate {JSON,Smile}WriterTest and TestBinaryResponseWriter to 
> org.apache.solr.response
> 
>
> Key: SOLR-9538
> URL: https://issues.apache.org/jira/browse/SOLR-9538
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9538.patch
>
>
> JSONWriterTest, SmileWriterTest and TestBinaryResponseWriter are currently in 
> the org.apache.solr.request package but the classes they test 
> (JSONResponseWriter, SmileWriter, BinaryResponseWriter) are in the 
> org.apache.solr.response package. 
> This patch moves the tests to the response package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9627) add QParser.getSortSpec, deprecate misleadingly named QParser.getSort

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9627:
--
Fix Version/s: (was: 6.x)
   6.3

> add QParser.getSortSpec, deprecate misleadingly named QParser.getSort
> -
>
> Key: SOLR-9627
> URL: https://issues.apache.org/jira/browse/SOLR-9627
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9627.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9413) String.replace Function result is ignored in lucene/analysis/kuromoji CSVUtil.quoteEscape

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9413:
--
Fix Version/s: (was: 6.x)
   6.2

> String.replace Function result is ignored in lucene/analysis/kuromoji 
> CSVUtil.quoteEscape
> -
>
> Key: SOLR-9413
> URL: https://issues.apache.org/jira/browse/SOLR-9413
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.1
>Reporter: AppChecker
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9413.patch
>
>
> Hello!
> Code in the method [CSVUtil. 
> quoteEscape|https://github.com/apache/lucene-solr/blob/633a89c0376e3db5b8c7efe325cdc3a409e250e5/lucene/analysis/kuromoji/src/java/org/apache/lucene/analysis/ja/util/CSVUtil.java#L104]
> {code:title=CSVUtil.java|borderStyle=solid}
> if (result.indexOf('\"') >= 0) {
>   result.replace("\"", ESCAPED_QUOTE);
> }
> {code}
> ignores the return value of the String.replace method.
> Probably, is should be:
> {code:title=CSVUtil.java|borderStyle=solid}
> if (result.indexOf('\"') >= 0) {
>   result = result.replace("\"", ESCAPED_QUOTE);
> }
> {code}
> This possible defect found by [static code analyzer 
> AppChecker|http://cnpo.ru/en/solutions/appchecker.php]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9385) add QParser.getParser(String,SolrQueryRequest) variant

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9385:
--
Fix Version/s: (was: 6.x)
   6.2

> add QParser.getParser(String,SolrQueryRequest) variant
> --
>
> Key: SOLR-9385
> URL: https://issues.apache.org/jira/browse/SOLR-9385
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9385.patch, SOLR-9385.patch
>
>
> For a relative majority (~32) of callers this variant will eliminate the 
> "What do i pass in for the default (since i do not have one)?" question, 
> compared to a relative minority (~19) of callers that pass in a default other 
> than the default.
> (Noticed as part of SOLR-8542 work.)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9820) PerSegmentSingleValuedFaceting - mark "contains" and "ignoreCase" fields private

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9820:
--
Fix Version/s: (was: 6.x)
   6.5

> PerSegmentSingleValuedFaceting - mark "contains" and "ignoreCase" fields 
> private
> 
>
> Key: SOLR-9820
> URL: https://issues.apache.org/jira/browse/SOLR-9820
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9820.patch
>
>
> This patch marks the "contains" and "ignoreCase" fields in 
> PerSegmentSingleValuedFaceting private (they are currently public). 
> A separate patch will follow where I propose to replace them with a 
> customizable variant.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9625) Add HelloWorldSolrCloudTestCase class

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9625:
--
Fix Version/s: (was: 6.x)
   6.3

> Add HelloWorldSolrCloudTestCase class
> -
>
> Key: SOLR-9625
> URL: https://issues.apache.org/jira/browse/SOLR-9625
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9625.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9893) EasyMock/Mockito no longer works with Java 9 b148+

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9893:
--
Affects Version/s: (was: 6.x)
Fix Version/s: (was: 6.x)

> EasyMock/Mockito no longer works with Java 9 b148+
> --
>
> Key: SOLR-9893
> URL: https://issues.apache.org/jira/browse/SOLR-9893
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (7.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-9893.patch, SOLR-9893.patch
>
>
> EasyMock does not work anymore with latest Java 9, because it uses cglib 
> behind that is trying to access a protected method inside the runtime using 
> setAccessible. This is no longer allowed by Java 9.
> Actually this is really stupid. Instead of forcefully making the protected 
> defineClass method available to the outside, it is much more correct to just 
> subclass ClassLoader (like the Lucene expressions module does).
> I tried updating to easymock/mockito, but all that does not work, approx 25 
> tests fail. The only way is to disable all Mocking tests in Java 9. The 
> underlying issue in cglib is still not solved, master's code is here: 
> https://github.com/cglib/cglib/blob/master/cglib/src/main/java/net/sf/cglib/core/ReflectUtils.java#L44-L62
> As we use an old stone-aged version of mockito (1.x), a fix is not expected 
> to happen, although cglib might fix this!
> What should we do? This stupid issue prevents us from testing Java 9 with 
> Solr completely! 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9870) Typos in SolrCore

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9870:
--
Fix Version/s: (was: 6.x)
   6.5

> Typos in SolrCore
> -
>
> Key: SOLR-9870
> URL: https://issues.apache.org/jira/browse/SOLR-9870
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Mike Drob
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9870.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Strange Solr JIRA versions

[Mark Miller]

Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
bad versions in the future ;) This is no fun to cleanup.

- Mark

On Fri, Apr 14, 2017 at 10:23 AM Mark Miller  wrote:

> Bummer, seems we can't lock this down :(
> https://jira.atlassian.com/browse/JRASERVER-42068
>
> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller  wrote:
>
>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett 
>> wrote:
>>
>>> I noticed these the other day also, and had an email half-wrote that I
>>> intended to finish up today.
>>>
>>> To start, JIRA unfortunately makes this really easy to make a mess of
>>> - if you can create or edit an issue, you can just pop in a new value
>>> that gets added to the list of open versions. Editing an issue is open
>>> to lots of folks - committers, contributors, the reporter of an issue.
>>> So, we have high potential for this to be an ongoing problem.
>>>
>>
>> Ah, that makes this a lot less baffling I guess.
>>
>>
>>>
>>> But, since only committers can commit patches and are thus the usual
>>> resolvers of an issue, committers either aren't paying enough
>>> attention to that field when they resolve an issue or there is
>>> confusion/difference of understanding about what that field is
>>> supposed to mean.
>>>
>>> There are currently 49 issues for Solr that have these "non-standard"
>>> versions [1]. Some date back before the most recent 6.5.0 release,
>>> which means there are issues fixed in 6.4 and 6.5 (at least) which
>>> don't say so in JIRA.
>>>
>>> This could be really problematic going forward. We need to agree that
>>> when issues are resolved, the fixVersion field is reliable and means
>>> the same thing to everyone.
>>>
>>
>> +1!
>>
>>
>>>
>>> IMO we should always use the *next* version that makes sense at that
>>> time. So, an issue resolved today would be "6.6" and "master (7.0)".
>>> Others may have different points of view on how we should do this, but
>>> I think traditionally it's been the way I suggest, so if there is
>>> change desired there, we should discuss it.
>>>
>>
>> I agree.
>>
>>
>>>
>>> Side note: I know there is some doubt today that 6.6 will ever exist.
>>> However, it will be a lot easier to go through JIRA to remove "6.6"
>>> from issues that aren't in 6.x than it will be to review
>>> issue-by-issue everything that says "6x" or "6.x" or "branch_6x",
>>> etc., and figure out when it was actually released.
>>>
>>
>> +1. It also matches how we handle CHANGES afaict.
>>
>> I wish we could disable the auto creating of versions entirely somehow,
>> but I guess the next best thing is to raise awareness. It's great to have
>> the correct versions and in the correct ordering.
>>
>> - Mark
>>
>>
>>>
>>> Cassandra
>>>
>>> [1] Query for JIRA issues:
>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x)
>>>
>>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller 
>>> wrote:
>>> > Who keeps adding strange JIRA release versions? I've cleaned up
>>> strange ones
>>> > in the past and they keep coming back.
>>> >
>>> > Why do we have branch6x, 6x and 6.x and trunk?
>>> >
>>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I
>>> don't
>>> > think we do, who keeps adding these duplicates? Let's come to some
>>> sanity
>>> > here.
>>> >
>>> > - Mark
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> - Mark
> about.me/markrmiller
>
-- 
- Mark
about.me/markrmiller

[jira] [Updated] (SOLR-9331) Can we remove ReRankQuery's length constructor argument?

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9331:
--
Fix Version/s: (was: 6.x)
   6.2

> Can we remove ReRankQuery's length constructor argument?
> 
>
> Key: SOLR-9331
> URL: https://issues.apache.org/jira/browse/SOLR-9331
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9331.patch, SOLR-9331.patch
>
>
> Can we remove ReRankQuery's length constructor argument? It is a 
> ReRankQParserPlugin private class.
> proposed patch summary:
> * change ReRankQuery.getTopDocsCollector to use its len argument (instead of 
> the length member)
> * remove ReRankQuery's length member and constructor argument
> * remove ReRankQParser.parse's use of the rows and start parameters
> motivation: towards ReRankQParserPlugin and LTRQParserPlugin (SOLR-8542) 
> sharing (more) code



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8332) factor HttpShardHandler[Factory]'s url shuffling out into a ReplicaListTransformer class

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8332:
--
Fix Version/s: (was: 6.x)
   6.4

> factor HttpShardHandler[Factory]'s url shuffling out into a 
> ReplicaListTransformer class
> 
>
> Key: SOLR-8332
> URL: https://issues.apache.org/jira/browse/SOLR-8332
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.4, master (7.0)
>
> Attachments: SOLR-8332.patch, SOLR-8332.patch, SOLR-8332.patch, 
> SOLR-8332.patch
>
>
> Proposed patch against trunk to follow. No change in behaviour intended. This 
> would be as a step towards SOLR-6730.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9114) NPE using TermVectorComponent, MoreLikeThisComponent in combination with ExactStatsCache

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-9114:
--
Fix Version/s: (was: 6.x)
   6.5

> NPE using TermVectorComponent, MoreLikeThisComponent in combination with 
> ExactStatsCache
> 
>
> Key: SOLR-9114
> URL: https://issues.apache.org/jira/browse/SOLR-9114
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 6.0, 6.1, 6.2, 6.3, 6.4
>Reporter: Andreas Daffner
>Assignee: Cao Manh Dat
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9114.patch, SOLR-9914.patch
>
>
> Hello,
> I am getting a NPE when using the TermVectorComponent in combinition with 
> ExactStatsCache.
> I am using SOLR 6.0.0 with 4 shards in total.
> This Bug is a duplicate of SOLR-8459
> It was already fixed in SOLR-8459 for SOLR 5.x but it is still open in the 
> new SOLR 6.0.0
> Can you please fix it for the nes SOLR 6.0.0 as well? I already tried the 
> patch of the 5.x bugfix on the SOLR 6.0.0 but the bug is still present.
> I set up my solrconfig.xml as described in these 2 links:
> TermVectorComponent:
> https://cwiki.apache.org/confluence/display/solr/The+Term+Vector+Component
> ExactStatsCache:
> https://cwiki.apache.org/confluence/display/solr/Distributed+Requests#Configuring+statsCache+implementation
> My snippets from solrconfig.xml:
> {code}
> ...
>   
>   
>   
>class="org.apache.solr.handler.component.TermVectorComponent"/>
>class="org.apache.solr.handler.component.SearchHandler">
> 
>   true
> 
> 
>   tvComponent
> 
>   
> ...
> {code}
> Unfortunately a request to SOLR like 
> "http://host/solr/corename/tvrh?q=site_url_id:74"; ends up with this NPE:
> {code}
> 69730 ERROR (qtp110456297-14) [c:SingleDomainSite_28 s:shard1 r:core_node1 
> x:SingleDomainSite_28_shard1_replica1] o.a.s.s.HttpSolrCall 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.TermVectorComponent.finishStage(TermVectorComponent.java:451)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:426)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2033)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:229)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:184)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654