[GitHub] [lucene-solr] dsmiley commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider pluggable in HttpClientUtil

[GitBox]

dsmiley commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider 
pluggable in HttpClientUtil
URL: https://github.com/apache/lucene-solr/pull/1261#issuecomment-604602628
 
 
   We agree connectionSocketFactoryRegistryProvider is a bit much.  I had 
dropped "Provider" as it seems kinda meta and somewhat redundant with the word 
also having a "Factory" (Provider ~ Factory), but I can see it could be there.  
I like your proposal of keeping either one of connection or socket.  I propose 
keep the word socket and drop connection.  Or abbreviate "connection" to "conn" 
which is sufficiently shorter to make me feel better about the fully complete 
word.  Ah naming...
   
   I can see generics may be an issue so yeah keep the class.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14351:
-

Your suggestion is complementary and not a different design but an additional 
design going beyond what I did.

I'm not sure if it's worth the trouble given it's not a big deal when we mess 
this up; not that we don't care but it's not the level of seriousness as 
resource-closing / memory-leaks.  Things are hard-reset for the next request.  
Also, some places, namely HttpSolrCall doesn't balance in a lexical context 
with the clear/reset.  Granted that case could simply be an exception; your 
suggestion doesn't insist on a try-finally always.  Shrug, I dunno.

> Harden MDCLoggingContext.clear depth tracking
> -
>
> Key: SOLR-14351
> URL: https://issues.apache.org/jira/browse/SOLR-14351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MDCLoggingContext tracks recursive calls and only clears when the recursion 
> level is back down to 0.  If a caller forgets to register and ends up calling 
> clear any ways, then this can mess things up.  Additionally I found at least 
> one place this is occurring, which led me to investigate this matter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14302) Solr stops printing stacktraces in log and output due to OmitStackTraceInFastThrow - regression of SOLR-7436

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14302:


Commit 255132fc1c6d4639db3becb6b9501feb7dd6593c in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=255132f ]

SOLR-14302: Ensure Solr always includes the stacktrace for exceptions by using 
'-OmitStackTraceInFastThrow'


> Solr stops printing stacktraces in log and output due to 
> OmitStackTraceInFastThrow - regression of SOLR-7436 
> -
>
> Key: SOLR-14302
> URL: https://issues.apache.org/jira/browse/SOLR-14302
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14302.patch
>
>
> I recently saw a person ask a question about an Exception in their logs that 
> didn't have a stack trace even though it certainly seemed like it should.
> I was immediately suspicious that they may have tweaked their solr options to 
> override the {{-XX:-OmitStackTraceInFastThrow}} that was added to bin/solr by 
> SOLR-7436, but then i discovered it's gone now - removed in SOLR-13394 w/o 
> any discussion/consideration (and possibly unintentionally w/o understanding 
> it's purpose?)
> We should almost certainly restore this by default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (LUCENE-9266) ant nightly-smoke fails due to presence of build.gradle

[Mike Drob (Jira)]

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

Mike Drob commented on LUCENE-9266:
---

Pushed the trivial fix for build.gradle, will leave this open to see if we get 
other failures on Jenkins. Locally I was seeing LUCENE-9170 but I'm not sure 
why it wouldn't be an issue on CI servers as well.

> ant nightly-smoke fails due to presence of build.gradle
> ---
>
> Key: LUCENE-9266
> URL: https://issues.apache.org/jira/browse/LUCENE-9266
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Seen on Jenkins - 
> [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1617/console]
>  
> Reproduced locally.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (LUCENE-8739) ZSTD Compressor support in Lucene

[Michael McCandless (Jira)]

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

Michael McCandless commented on LUCENE-8739:


I think this is worth a deep dive, at least to understand its performance for 
"typical" Lucene use cases ... I've heard (just anecdotally) that ZSTD shows 
impressive speed and compression.  That said, the added complexity in 
implementation is definitely a downside.

> ZSTD Compressor support in Lucene
> -
>
> Key: LUCENE-8739
> URL: https://issues.apache.org/jira/browse/LUCENE-8739
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/codecs
>Reporter: Sean Torres
>Priority: Minor
>  Labels: features
>
> ZStandard has a great speed and compression ratio tradeoff. 
> ZStandard is open source compression from Facebook.
> More about ZSTD
> [https://github.com/facebook/zstd]
> [https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compression-with-zstandard/]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] madrob commented on a change in pull request #1333: LUCENE-9266 Update smoke test for gradle

[GitBox]

madrob commented on a change in pull request #1333: LUCENE-9266 Update smoke 
test for gradle
URL: https://github.com/apache/lucene-solr/pull/1333#discussion_r398809631
 
 

 ##
 File path: lucene/common-build.xml
 ##
 @@ -598,9 +599,13 @@
 
 
 
-  
+  
+
 
 Review comment:
   This was part of LUCENE-9170, I ran into the same problem. Wasn't sure if it 
was related to gradle or not.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #1382: SOLR-12720 Remove autoReplicaFailoverWaitAfterExpiration

[GitBox]

MarcusSorealheis commented on issue #1382: SOLR-12720 Remove 
autoReplicaFailoverWaitAfterExpiration
URL: https://github.com/apache/lucene-solr/pull/1382#issuecomment-604513220
 
 
   @ctargett Thank you for catching that.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-12720) Remove autoReplicaFailoverWaitAfterExpiration in Solr 8.0

[Marcus Eagan (Jira)]

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

Marcus Eagan commented on SOLR-12720:
-

Blow it away: https://github.com/apache/lucene-solr/pull/1382

> Remove autoReplicaFailoverWaitAfterExpiration in Solr 8.0
> -
>
> Key: SOLR-12720
> URL: https://issues.apache.org/jira/browse/SOLR-12720
> Project: Solr
>  Issue Type: Task
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: 8.1, master (9.0)
>
>
> SOLR-12719 deprecated the autoReplicaFailoverWaitAfterExpiration property in 
> solr.xml. We should remove it entirely in Solr 8.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Issue Comment Deleted] (SOLR-12720) Remove autoReplicaFailoverWaitAfterExpiration in Solr 8.0

[Marcus Eagan (Jira)]

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

Marcus Eagan updated SOLR-12720:

Comment: was deleted

(was: Blow it away: https://github.com/apache/lucene-solr/pull/1382)

> Remove autoReplicaFailoverWaitAfterExpiration in Solr 8.0
> -
>
> Key: SOLR-12720
> URL: https://issues.apache.org/jira/browse/SOLR-12720
> Project: Solr
>  Issue Type: Task
>  Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: 8.1, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> SOLR-12719 deprecated the autoReplicaFailoverWaitAfterExpiration property in 
> solr.xml. We should remove it entirely in Solr 8.0



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking

[Mike Drob (Jira)]

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

Mike Drob commented on SOLR-14351:
--

As I was looking through the PR, I had an idea for a slightly different design 
decision...

 

If instead of null, be return an AutoCloseable, then we don't have to have 
developers remember to call clear at the end. And we would get compiler 
warnings where we miss it. Maybe it wouldn't work with the ThreadLocal and 
static context, but it might be worth exploring.

> Harden MDCLoggingContext.clear depth tracking
> -
>
> Key: SOLR-14351
> URL: https://issues.apache.org/jira/browse/SOLR-14351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MDCLoggingContext tracks recursive calls and only clears when the recursion 
> level is back down to 0.  If a caller forgets to register and ends up calling 
> clear any ways, then this can mess things up.  Additionally I found at least 
> one place this is occurring, which led me to investigate this matter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14302) Solr stops printing stacktraces in log and output due to OmitStackTraceInFastThrow - regression of SOLR-7436

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14302:


Commit f760d3cf52c0621dcf8942926410f29f2a8d5c11 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f760d3c ]

SOLR-14302: Ensure Solr always includes the stacktrace for exceptions by using 
'-OmitStackTraceInFastThrow'

(cherry picked from commit 255132fc1c6d4639db3becb6b9501feb7dd6593c)


> Solr stops printing stacktraces in log and output due to 
> OmitStackTraceInFastThrow - regression of SOLR-7436 
> -
>
> Key: SOLR-14302
> URL: https://issues.apache.org/jira/browse/SOLR-14302
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-14302.patch
>
>
> I recently saw a person ask a question about an Exception in their logs that 
> didn't have a stack trace even though it certainly seemed like it should.
> I was immediately suspicious that they may have tweaked their solr options to 
> override the {{-XX:-OmitStackTraceInFastThrow}} that was added to bin/solr by 
> SOLR-7436, but then i discovered it's gone now - removed in SOLR-13394 w/o 
> any discussion/consideration (and possibly unintentionally w/o understanding 
> it's purpose?)
> We should almost certainly restore this by default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-14302) Solr stops printing stacktraces in log and output due to OmitStackTraceInFastThrow - regression of SOLR-7436

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter resolved SOLR-14302.
---
Fix Version/s: 8.6
   master (9.0)
   Resolution: Fixed

> Solr stops printing stacktraces in log and output due to 
> OmitStackTraceInFastThrow - regression of SOLR-7436 
> -
>
> Key: SOLR-14302
> URL: https://issues.apache.org/jira/browse/SOLR-14302
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.1
>Reporter: Chris M. Hostetter
>Assignee: Chris M. Hostetter
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Attachments: SOLR-14302.patch
>
>
> I recently saw a person ask a question about an Exception in their logs that 
> didn't have a stack trace even though it certainly seemed like it should.
> I was immediately suspicious that they may have tweaked their solr options to 
> override the {{-XX:-OmitStackTraceInFastThrow}} that was added to bin/solr by 
> SOLR-7436, but then i discovered it's gone now - removed in SOLR-13394 w/o 
> any discussion/consideration (and possibly unintentionally w/o understanding 
> it's purpose?)
> We should almost certainly restore this by default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] athrog commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider pluggable in HttpClientUtil

[GitBox]

athrog commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider 
pluggable in HttpClientUtil
URL: https://github.com/apache/lucene-solr/pull/1261#issuecomment-604588248
 
 
   Hi David, thank you for the feedback and my apologies in the delayed 
response. I agree, 'schema' is an overloaded word in Solr that we could avoid. 
Your suggestion of `connectionSocketFactoryRegistry` is better, but there's 
still a Provider on top of that, and having a 
`connectionSocketFactoryRegistryProvider` sounds like too much Java word-salad 
to me. Maybe just drop the "connection" (since it's implied by a socket)? Or 
`connectionSocketFactoriesProvider`?
   
   As to using a Supplier, we could use 
`Supplier>`, but that would be a dodgy cast 
(at HttpClientUtil.java:161) due to the generics so I think I'll keep it a 
concrete class for now.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-9266) ant nightly-smoke fails due to presence of build.gradle

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on LUCENE-9266:
-

Commit cd9375a6f9ce7d22d1e542314aed6ee2e33fae5b in lucene-solr's branch 
refs/heads/master from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cd9375a ]

LUCENE-9266 Update smoke test for gradle


> ant nightly-smoke fails due to presence of build.gradle
> ---
>
> Key: LUCENE-9266
> URL: https://issues.apache.org/jira/browse/LUCENE-9266
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Seen on Jenkins - 
> [https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1617/console]
>  
> Reproduced locally.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] madrob closed pull request #1333: LUCENE-9266 Update smoke test for gradle

[GitBox]

madrob closed pull request #1333: LUCENE-9266 Update smoke test for gradle
URL: https://github.com/apache/lucene-solr/pull/1333
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Updated] (LUCENE-9170) wagon-ssh Maven HTTPS issue

[Mike Drob (Jira)]

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

Mike Drob updated LUCENE-9170:
--
Fix Version/s: master (9.0)

> wagon-ssh Maven HTTPS issue
> ---
>
> Key: LUCENE-9170
> URL: https://issues.apache.org/jira/browse/LUCENE-9170
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Attachments: LUCENE-9170.patch, LUCENE-9170.patch
>
>
> When I do, from lucene/ in branch_8_4:
> ant -Dversion=8.4.2 generate-maven-artifacts 
> I see that wagon-ssh is being resolved from http://repo1.maven.org/maven2 
> instead of https equivalent. This is surprising to me, since I can't find the 
> http URL anywhere.
> Here's my log:
> https://paste.centos.org/view/be2d3f3f
> This is a critical issue since releases won't work without this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent

[Chris M. Hostetter (Jira)]

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

Chris M. Hostetter commented on SOLR-14322:
---

At a glance everything currently in the PR looks sane to me.

In theory, since thse are public/protected methods in a public class in the 
test-framework we should be concerned about back compat for users that are 
subclassing it to write their own tests, and these method signature changes 
should be a No-No  BUT ... this class & these methods are such a 
cluster-f*ck already, that if we cause a compilation failure for anyone 
actaully trying to call these methods in existing code, we'll probably be doing 
them a favor -- so i'm certainly not going to complain.

> AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
> --
>
> Key: SOLR-14322
> URL: https://issues.apache.org/jira/browse/SOLR-14322
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are many strange things going on with this method - 
> 1. It accepts a value in seconds, but many callers pass millis
> 2. The method will only retry on the last shard being inconsistent, not any 
> other shard
> 3. Catching Throwable is dubious.
> 4. There's a conditional wait mixed with an unconditional sleep. (this might 
> be ok?)
> 5. There's a bunch of System.out and System.err
> 6. If we never get to the "level out state" we still simply return instead of 
> somehow indicating the error condition



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent

[Mike Drob (Jira)]

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

Mike Drob commented on SOLR-14322:
--

I'll add a note in CHANGES

> AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
> --
>
> Key: SOLR-14322
> URL: https://issues.apache.org/jira/browse/SOLR-14322
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are many strange things going on with this method - 
> 1. It accepts a value in seconds, but many callers pass millis
> 2. The method will only retry on the last shard being inconsistent, not any 
> other shard
> 3. Catching Throwable is dubious.
> 4. There's a conditional wait mixed with an unconditional sleep. (this might 
> be ok?)
> 5. There's a bunch of System.out and System.err
> 6. If we never get to the "level out state" we still simply return instead of 
> somehow indicating the error condition



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13659) Refactor Cache config to lazily load the the class

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13659:


Commit ea864b43a321b6e02a32fd043ea646adcb614351 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ea864b4 ]

SOLR-13659: Remove unused SolrCacheHolder
accidental leftover from reverted plugin work


> Refactor Cache config to lazily load the the class 
> ---
>
> Key: SOLR-13659
> URL: https://issues.apache.org/jira/browse/SOLR-13659
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Cache implementation class is currently loaded from the SolrConfig 
> classloader 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14351:
-

I pushed that as a commit to the PR. Lets review there.

> Harden MDCLoggingContext.clear depth tracking
> -
>
> Key: SOLR-14351
> URL: https://issues.apache.org/jira/browse/SOLR-14351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MDCLoggingContext tracks recursive calls and only clears when the recursion 
> level is back down to 0.  If a caller forgets to register and ends up calling 
> clear any ways, then this can mess things up.  Additionally I found at least 
> one place this is occurring, which led me to investigate this matter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] msokolov commented on issue #1351: LUCENE-9280: Collectors to skip noncompetitive documents

[GitBox]

msokolov commented on issue #1351: LUCENE-9280: Collectors to skip 
noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#issuecomment-604683807
 
 
   That 3x speedup is very nice! My experience with these benchmarks is they 
can be pretty noisy, maybe accounting for the regressions? I tend to increase 
comp.taskRepeatCount = 500. I'd also be interested to see how this optimization 
fares for higher values of topN - I think the default is 10, but you can edit 
in benchUtil.py. You did not sort the index right (eg: 
comp.newIndex('baseline', sourceData, facets=facets, 
indexSort='lastModNDV:long', addDVFields=True)? It would be interesting to see 
if this has the same impact for sorted index, large N, especially running with 
an executor (.competitor(...concurrentSearchers = True ). 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1368: SOLR-14351: Fix/improve MDCLoggingContext usage

[GitBox]

dsmiley commented on a change in pull request #1368: SOLR-14351: Fix/improve 
MDCLoggingContext usage
URL: https://github.com/apache/lucene-solr/pull/1368#discussion_r398887911
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java
 ##
 @@ -615,7 +614,7 @@ public Action call() throws IOException {
   }
   return RETURN;
 } finally {
-  MDCLoggingContext.clear();
+  MDCLoggingContext.clear(); // admittedly setCore might not have been 
called but that's okay.
 
 Review comment:
   This probably isn't needed anymore either


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Resolved] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent

[Mike Drob (Jira)]

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

Mike Drob resolved SOLR-14322.
--
Fix Version/s: master (9.0)
 Assignee: Mike Drob
   Resolution: Fixed

> AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
> --
>
> Key: SOLR-14322
> URL: https://issues.apache.org/jira/browse/SOLR-14322
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are many strange things going on with this method - 
> 1. It accepts a value in seconds, but many callers pass millis
> 2. The method will only retry on the last shard being inconsistent, not any 
> other shard
> 3. Catching Throwable is dubious.
> 4. There's a conditional wait mixed with an unconditional sleep. (this might 
> be ok?)
> 5. There's a bunch of System.out and System.err
> 6. If we never get to the "level out state" we still simply return instead of 
> somehow indicating the error condition



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14322) AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14322:


Commit a31ecd2eb8c2f1b8b24d0afb7242e71c622378cc in lucene-solr's branch 
refs/heads/master from Mike Drob
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a31ecd2 ]

SOLR-14322 Improve AbstractFullDistribZkTestBase.waitForThingsToLevelOut


> AbstractFullDistribZkTestBase.waitForThingsToLevelOut is very inconsistent
> --
>
> Key: SOLR-14322
> URL: https://issues.apache.org/jira/browse/SOLR-14322
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are many strange things going on with this method - 
> 1. It accepts a value in seconds, but many callers pass millis
> 2. The method will only retry on the last shard being inconsistent, not any 
> other shard
> 3. Catching Throwable is dubious.
> 4. There's a conditional wait mixed with an unconditional sleep. (this might 
> be ok?)
> 5. There's a bunch of System.out and System.err
> 6. If we never get to the "level out state" we still simply return instead of 
> somehow indicating the error condition



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] janhoy commented on issue #1372: SOLR-14358 Document how to use Processor in JavaDocs

[GitBox]

janhoy commented on issue #1372: SOLR-14358 Document how to use Processor in 
JavaDocs
URL: https://github.com/apache/lucene-solr/pull/1372#issuecomment-604724110
 
 
   Yes, please use single valued int fields for url_length , url_levels , 
url_toplevel and url_landingpage
   Else, it looks good!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] madrob closed pull request #1306: SOLR-14299: IndexFetcher doesnt' reset count to 0 after the last packet is received

[GitBox]

madrob closed pull request #1306: SOLR-14299: IndexFetcher doesnt' reset count 
to 0 after the last packet is received
URL: https://github.com/apache/lucene-solr/pull/1306
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] epugh commented on issue #1372: SOLR-14358 Document how to use Processor in JavaDocs

[GitBox]

epugh commented on issue #1372: SOLR-14358 Document how to use Processor in 
JavaDocs
URL: https://github.com/apache/lucene-solr/pull/1372#issuecomment-604678922
 
 
   So @janhoy and @HoustonPutman is there something you want me to change?  
Should I tackle the `url_xxx` naming?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-11775) json.facet can use inconsistent Long/Integer for "count" depending on shard count

[Lucene/Solr QA (Jira)]

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

Lucene/Solr QA commented on SOLR-11775:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 8 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
19s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m  7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m  7s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 48m 
39s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
16s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 44s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11775 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12997914/SOLR-11775.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 
10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / cd9375a6f9c |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/727/testReport/ |
| modules | C: solr/core solr/test-framework U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/727/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> json.facet can use inconsistent Long/Integer for "count" depending on shard 
> count
> -
>
> Key: SOLR-11775
> URL: https://issues.apache.org/jira/browse/SOLR-11775
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-11775.patch, SOLR-11775.patch
>
>
> (NOTE: I noticed this while working on a test for {{type: range}} but it's 
> possible other facet types may be affected as well)
> When dealing with a single core request -- either standalone or a collection 
> with only one shard -- json.facet seems to use "Integer" objects to return 
> the "count" of facet buckets, however if the shard count is increased then 
> the end client gets a "Long" object for the "count"
> (This isn't noticable when using {{wt=json}} but can be very problematic when 
> trying to write client code using {{wt=xml}} or SolrJ



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] dsmiley commented on issue #1368: SOLR-14351: Fix/improve MDCLoggingContext usage

[GitBox]

dsmiley commented on issue #1368: SOLR-14351: Fix/improve MDCLoggingContext 
usage
URL: https://github.com/apache/lucene-solr/pull/1368#issuecomment-604680265
 
 
   I was thinking that maybe there is a way to reduce the number of places we 
even have to think about set/clear of the MDC.  In the last commit here I 
explore that idea.  SolrCore.open (called whenever a core is retrieved from 
CoreContainer) now calls set on the MDC, and close (it's ref-counted) clears 
it.  I was then able to remove a bunch of callers, and perhaps in the process 
enhanced the scope of this context to some callers' callers that made sense.  
On the down side, it might be argued this is surprising side-effect behavior 
that doesn't _belong_ on the open/close of getting a core reference; I dunno.  
I think I like it though I'm slightly worried I missed something since this 
sort of thing isn't really tested well so I'm relying on all of us to notice 
and report missing or wrong MDC info.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] madrob commented on issue #1306: SOLR-14299: IndexFetcher doesnt' reset count to 0 after the last packet is received

[GitBox]

madrob commented on issue #1306: SOLR-14299: IndexFetcher doesnt' reset count 
to 0 after the last packet is received
URL: https://github.com/apache/lucene-solr/pull/1306#issuecomment-604724539
 
 
   This was committed to 8.5 and master


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] athrog commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider pluggable in HttpClientUtil

[GitBox]

athrog commented on issue #1261: SOLR-14260: Make SchemaRegistryProvider 
pluggable in HttpClientUtil
URL: https://github.com/apache/lucene-solr/pull/1261#issuecomment-604724994
 
 
   Fixed the obsolete comments, just did a grep for old instances and found a 
few more that needed changing


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-11775) json.facet can use inconsistent Long/Integer for "count" depending on shard count

[Munendra S N (Jira)]

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

Munendra S N commented on SOLR-11775:
-

 [^SOLR-11775.patch] 
* Test failure fixes and handling Classical faceting which delegates  to Json 
faceting

> json.facet can use inconsistent Long/Integer for "count" depending on shard 
> count
> -
>
> Key: SOLR-11775
> URL: https://issues.apache.org/jira/browse/SOLR-11775
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-11775.patch, SOLR-11775.patch
>
>
> (NOTE: I noticed this while working on a test for {{type: range}} but it's 
> possible other facet types may be affected as well)
> When dealing with a single core request -- either standalone or a collection 
> with only one shard -- json.facet seems to use "Integer" objects to return 
> the "count" of facet buckets, however if the shard count is increased then 
> the end client gets a "Long" object for the "count"
> (This isn't noticable when using {{wt=json}} but can be very problematic when 
> trying to write client code using {{wt=xml}} or SolrJ



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-11775) json.facet can use inconsistent Long/Integer for "count" depending on shard count

[Munendra S N (Jira)]

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

Munendra S N updated SOLR-11775:

Attachment: SOLR-11775.patch

> json.facet can use inconsistent Long/Integer for "count" depending on shard 
> count
> -
>
> Key: SOLR-11775
> URL: https://issues.apache.org/jira/browse/SOLR-11775
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Reporter: Chris M. Hostetter
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-11775.patch, SOLR-11775.patch
>
>
> (NOTE: I noticed this while working on a test for {{type: range}} but it's 
> possible other facet types may be affected as well)
> When dealing with a single core request -- either standalone or a collection 
> with only one shard -- json.facet seems to use "Integer" objects to return 
> the "count" of facet buckets, however if the shard count is increased then 
> the end client gets a "Long" object for the "count"
> (This isn't noticable when using {{wt=json}} but can be very problematic when 
> trying to write client code using {{wt=xml}} or SolrJ



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] mayya-sharipova edited a comment on issue #1351: LUCENE-9280: Collectors to skip noncompetitive documents

[GitBox]

mayya-sharipova edited a comment on issue #1351: LUCENE-9280: Collectors to 
skip noncompetitive documents
URL: https://github.com/apache/lucene-solr/pull/1351#issuecomment-604173071
 
 
   I have run some benchmarking using `luceneutil`.
   As the new sort optimization uses a new `LongDocValuesPointSortField` that 
is not present in `luceneutil`, I had to hack `luceneutil` as follows:
   
   1. I added a  sort task on a long field `TermDateTimeSort`  to 
`wikimedium.1M.nostopwords.tasks` . This task was present in 
`wikinightly.tasks` , but was not able for wikimedium 1M and 10M tasks
   2. I indexed the corresponding field `lastModNDV` as `LongPoint` as well. It 
was only indexed as `NumericDocValuesField` before, but for the sort 
optimization we need long values to be indexed both as docValues and as points.
   3. I modified `SearchTask.java` to have `TopFieldCollector` with 
`totalHitsThreshold` set to `topK`: `final TopFieldCollector c = 
TopFieldCollector.create(s, topN, null, topN);`   Sort optimization only works 
when we set total hits threshold.
   4. For the patch version , I modified sort in `TaskParser.java`. Instead of 
`lastModNDVSort = new Sort(new SortField("lastModNDV", SortField.Type.LONG));`  
I useed the optimized sort: `lastModNDVSort = new Sort(new 
LongDocValuesPointSortField("lastModNDV"));`
   
   Here the main point of comparison is `TermDTSort` as it is the only sort on 
long field. Other sorts are presented to demonstrate a possible regression or 
absence on them.
   
   ---
   wikimedium1m
   | TaskQPS   | baseline QPS | StdDevQPS | my_modified_version QPS 
| StdDevQPS |
   | - | ---: | : | --: 
| : |
   | **TermDTSort**|   507.20 |   (11.2%) |  550.02 
|   (16.1%) |
   | HighTermMonthSort |   550.06 |   (10.4%) |  443.69 
|   (16.1%) |
   | HighTermDayOfYearSort |   105.62 |   (24.9%) |   91.93 
|   (22.1%) |
   ---
   wikimedium10m
   | TaskQPS   | baseline QPS | StdDevQPS | my_modified_version QPS 
| StdDevQPS |
   | - | ---: | : | --: 
| : |
   | **TermDTSort**|   147.64 |   (11.5%) |  547.80 
|(6.6%) |
   | HighTermMonthSort |   147.85 |   (12.2%) |  239.28 
|(7.3%) |
   | HighTermDayOfYearSort |74.44 |(7.7%) |   42.56 
|   (12.1%) |
   
   For wikimedium1m  TermDTSort using `LongDocValuesPointSortField` doesn't 
seem to have much effect. As probably in this index segments are smaller, and 
probably optimization was completely skipped on those segments.
   For wikimedium10m TermDTSort using `LongDocValuesPointSortField`  instead of 
usual `SortField.Type.LONG` **brings about 3x speedups**.
   There is some regression/speedups for the sort tasks of HighTermMonthSort 
and HighTermDayOfYearSort, which I don't know the reason why, as they should 
not be effected. 
   
   
   
   
   
   
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] mbwaheed commented on a change in pull request #1369: SOLR-14213: Allow enabling shared store to be scriptable

[GitBox]

mbwaheed commented on a change in pull request #1369: SOLR-14213: Allow 
enabling shared store to be scriptable
URL: https://github.com/apache/lucene-solr/pull/1369#discussion_r398892436
 
 

 ##
 File path: solr/bin/solr
 ##
 @@ -1975,6 +1975,10 @@ if [ "$SOLR_MODE" == 'solrcloud' ]; then
 
 CLOUD_MODE_OPTS+=('-DzkRun')
   fi
+  
+  if [ -n "$SHARE_STORE_ENABLED" ]; then
 
 Review comment:
   Why not SHARE**D**_STORE_ENABLED?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13659) Refactor Cache config to lazily load the the class

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-13659:


Commit 64d17daad597f45e750b44d4f67a798ff59d2211 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64d17da ]

SOLR-13659: Remove unused SolrCacheHolder
accidental leftover from reverted plugin work

(cherry picked from commit ea864b43a321b6e02a32fd043ea646adcb614351)


> Refactor Cache config to lazily load the the class 
> ---
>
> Key: SOLR-13659
> URL: https://issues.apache.org/jira/browse/SOLR-13659
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Cache implementation class is currently loaded from the SolrConfig 
> classloader 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] gerlowskija commented on issue #1379: SOLR-14363: Separate /get requests into their own type designation

[GitBox]

gerlowskija commented on issue #1379: SOLR-14363: Separate /get requests into 
their own type designation
URL: https://github.com/apache/lucene-solr/pull/1379#issuecomment-604650801
 
 
   > Can we instead dynamically pull out the request handler path no matter 
what it is?
   We do this already - it gets indexed into a field called `path_s`.  That 
happens regardless of this PR.  Changing the tokenization on `path_s` sounds 
reasonable, but is probably a separate PR since it's not entirely connected.
   
   This PR is mostly about the `type_s` field. `type_s` gets populated with a 
few enum-like values that aim to represent broad classes/types of requests: 
"update", "query", "commit", etc.  The idea is that admins can get a sense at a 
glance as to what sort of traffic is hitting cross sections of their cluster 
without getting as granular as `path_s` provides.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1379: SOLR-14363: Separate /get requests into their own type designation

[GitBox]

gerlowskija edited a comment on issue #1379: SOLR-14363: Separate /get requests 
into their own type designation
URL: https://github.com/apache/lucene-solr/pull/1379#issuecomment-604650801
 
 
   > Can we instead dynamically pull out the request handler path no matter 
what it is?
   
   We do this already - it gets indexed into a field called `path_s`.  That 
happens regardless of this PR.  Changing the tokenization on `path_s` sounds 
reasonable, but is probably a separate PR since it's not entirely connected.
   
   This PR is mostly about the `type_s` field. `type_s` gets populated with a 
few enum-like values that aim to represent broad classes/types of requests: 
"update", "query", "commit", etc.  The idea is that admins can get a sense at a 
glance as to what sort of traffic is hitting cross sections of their cluster 
without getting as granular as `path_s` provides.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking

[David Smiley (Jira)]

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

David Smiley commented on SOLR-14351:
-

I played with this idea a bit locally.  Two issues:
* a try-with-resources demands you declare a local variable to store the 
AutoCloseable thing.  That means we need to declare an instance of something 
that's AutoCloseable and give it a name.
* AutoCloseable.close declares it throws Exception.  To avoid the caller seeing 
this, we'd want to perhaps have MDCLoggingContext implement AutoCloseable and 
declare close but not throw an exception.

I wonder if CoreContainer.getCore ought to bump the logging context? since it's 
ref-counted and thus could clear on close.   H

> Harden MDCLoggingContext.clear depth tracking
> -
>
> Key: SOLR-14351
> URL: https://issues.apache.org/jira/browse/SOLR-14351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MDCLoggingContext tracks recursive calls and only clears when the recursion 
> level is back down to 0.  If a caller forgets to register and ends up calling 
> clear any ways, then this can mess things up.  Additionally I found at least 
> one place this is occurring, which led me to investigate this matter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] madrob closed pull request #1347: SOLR-14322 Improve AbstractFullDistribZkTestBase.waitForThingsToLevelOut

[GitBox]

madrob closed pull request #1347: SOLR-14322 Improve 
AbstractFullDistribZkTestBase.waitForThingsToLevelOut
URL: https://github.com/apache/lucene-solr/pull/1347
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] madrob commented on issue #1347: SOLR-14322 Improve AbstractFullDistribZkTestBase.waitForThingsToLevelOut

[GitBox]

madrob commented on issue #1347: SOLR-14322 Improve 
AbstractFullDistribZkTestBase.waitForThingsToLevelOut
URL: https://github.com/apache/lucene-solr/pull/1347#issuecomment-604723693
 
 
   Committed a31ecd2


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-14365) CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values

[Cao Manh Dat (Jira)]

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

Cao Manh Dat commented on SOLR-14365:
-

Hi [~jbernste] [~shalin] should we adding another method or just implicitly 
change the default implementation?

> CollapsingQParser - Avoiding always allocate int[] and float[] with size 
> equals to number of unique values
> --
>
> Key: SOLR-14365
> URL: https://issues.apache.org/jira/browse/SOLR-14365
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.4.1
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Since Collapsing is a PostFilter, documents reach Collapsing must match with 
> all filters and queries, so the number of documents Collapsing need to 
> collect/compute score is a small fraction of the total number documents in 
> the index. So why do we need to always consume the memory (for int[] and 
> float[] array) for all unique values of the collapsed field? If the number of 
> unique values of the collapsed field found in the documents that match 
> queries and filters is 300 then we only need int[] and float[] array with 
> size of 300 and not 1.2 million in size. However, we don't know which value 
> of the collapsed field will show up in the results so we cannot use a smaller 
> array.
> The easy fix for this problem is using as much as we need by using IntIntMap 
> and IntFloatMap that hold primitives and are much more space efficient than 
> the Java HashMap. These maps can be slower (10x or 20x) than plain int[] and 
> float[] if matched documents is large (almost all documents matched queries 
> and other filters). But our belief is that does not happen that frequently 
> (how frequently do we run collapsing on the entire index?).
> For this issue I propose adding 2 methods for collapsing which is
> * array : which is current implementation
> * hash : which is new approach and will be default method
> later we can add another method {{smart}} which is automatically pick method 
> based on comparision between {{number of docs matched queries and filters}} 
> and {{number of unique values of the field}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Assigned] (SOLR-14260) Make SchemaRegistryProvider pluggable in HttpClientUtil

[David Smiley (Jira)]

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

David Smiley reassigned SOLR-14260:
---

Fix Version/s: 8.6
 Assignee: David Smiley
  Description: 
HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
implementation of this abstract class (outside of test cases). Currently, it is 
not override-able at runtime.

This PR adds the ability to override the registry provider at runtime, using 
the class name value provided by 
"solr.httpclient.socketFactory.registry.provider", similar to how this class 
allows for choosing the HttpClientBuilderFactory at runtime.  And 
SchemaRegistryProvider is renamed to SocketFactoryRegistryProvider.

We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
context). This change helps us more easily configure Solr in a modular way, 
since we've implemented a custom SocketFactoryRegistryProvider that configures 
Apache clients to use our SSL context.

  was:
HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
implementation of this abstract class (outside of test cases). Currently, it is 
not override-able at runtime.

This PR adds the ability to override the registry provider at runtime, using 
the class name value provided by "solr.schema.registry.provider", similar to 
how this class allows for choosing the HttpClientBuilderFactory at runtime.

We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
context). This change helps us more easily configure Solr in a modular way, 
since we've implemented a custom SchemaRegistryProvider that configures Apache 
clients to use our SSL context.


> Make SchemaRegistryProvider pluggable in HttpClientUtil
> ---
>
> Key: SOLR-14260
> URL: https://issues.apache.org/jira/browse/SOLR-14260
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Andy Throgmorton
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
> mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
> implementation of this abstract class (outside of test cases). Currently, it 
> is not override-able at runtime.
> This PR adds the ability to override the registry provider at runtime, using 
> the class name value provided by 
> "solr.httpclient.socketFactory.registry.provider", similar to how this class 
> allows for choosing the HttpClientBuilderFactory at runtime.  And 
> SchemaRegistryProvider is renamed to SocketFactoryRegistryProvider.
> We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
> context). This change helps us more easily configure Solr in a modular way, 
> since we've implemented a custom SocketFactoryRegistryProvider that 
> configures Apache clients to use our SSL context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Created] (SOLR-14365) CollapsingQParser - Avoiding always allocate int[] and float[] with size equals to number of unique values

[Cao Manh Dat (Jira)]

Cao Manh Dat created SOLR-14365:
---

 Summary: CollapsingQParser - Avoiding always allocate int[] and 
float[] with size equals to number of unique values
 Key: SOLR-14365
 URL: https://issues.apache.org/jira/browse/SOLR-14365
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.4.1
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat


Since Collapsing is a PostFilter, documents reach Collapsing must match with 
all filters and queries, so the number of documents Collapsing need to 
collect/compute score is a small fraction of the total number documents in the 
index. So why do we need to always consume the memory (for int[] and float[] 
array) for all unique values of the collapsed field? If the number of unique 
values of the collapsed field found in the documents that match queries and 
filters is 300 then we only need int[] and float[] array with size of 300 and 
not 1.2 million in size. However, we don't know which value of the collapsed 
field will show up in the results so we cannot use a smaller array.

The easy fix for this problem is using as much as we need by using IntIntMap 
and IntFloatMap that hold primitives and are much more space efficient than the 
Java HashMap. These maps can be slower (10x or 20x) than plain int[] and 
float[] if matched documents is large (almost all documents matched queries and 
other filters). But our belief is that does not happen that frequently (how 
frequently do we run collapsing on the entire index?).

For this issue I propose adding 2 methods for collapsing which is
* array : which is current implementation
* hash : which is new approach and will be default method
later we can add another method {{smart}} which is automatically pick method 
based on comparision between {{number of docs matched queries and filters}} and 
{{number of unique values of the field}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14049) Disable Config APIs by default

[Marcus Eagan (Jira)]

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

Marcus Eagan commented on SOLR-14049:
-

I would like to see this change happen.

In an ideal state, not only should config APIs be disabled by default, they 
should only work if auth is enabled. Cannot rely on firewalls alone. The 
problem there is that then this change becomes an ease-of-use impediment that 
we do not want to introduce. Hmmm... Security vs Usability.



> Disable Config APIs by default
> --
>
> Key: SOLR-14049
> URL: https://issues.apache.org/jira/browse/SOLR-14049
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>
> Spin off from SOLR-13978. This is not my proposal (I support this only 
> conditionally), I'm just opening the JIRA.
> Proposal is to do this by 8.4. Reason is that Config APIs have been used in 
> the past to invoke RCE vulnerabilities in some components of Solr.
> The discussion has happened in SOLR-13978. I am willing to do the work once 
> we have agreement on this.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] dsmiley closed pull request #1261: SOLR-14260: Make SchemaRegistryProvider pluggable in HttpClientUtil

[GitBox]

dsmiley closed pull request #1261: SOLR-14260: Make SchemaRegistryProvider 
pluggable in HttpClientUtil
URL: https://github.com/apache/lucene-solr/pull/1261
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-7871) Platform independent config file instead of solr.in.sh and solr.in.cmd

[Marcus Eagan (Jira)]

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

Marcus Eagan commented on SOLR-7871:


Is this still of interest [~janhoy] and [~gerlowskija]?

> Platform independent config file instead of solr.in.sh and solr.in.cmd
> --
>
> Key: SOLR-7871
> URL: https://issues.apache.org/jira/browse/SOLR-7871
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: bin/solr
> Attachments: SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, 
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, 
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, 
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch
>
>
> Spinoff from SOLR-7043
> The config files {{solr.in.sh}} and {{solr.in.cmd}} are currently executable 
> batch files, but all they do is to set environment variables for the start 
> scripts on the format {{key=value}}
> Suggest to instead have one central platform independent config file e.g. 
> {{bin/solr.yml}} or {{bin/solrstart.properties}} which is parsed by 
> {{SolrCLI.java}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14260) Make SchemaRegistryProvider pluggable in HttpClientUtil

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14260:


Commit d1601f6fdf20230abfec50cc587ca1af879d4ea5 in lucene-solr's branch 
refs/heads/master from Andy Throgmorton
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d1601f6 ]

SOLR-14260: SolrJ pluggable ConnectionSocketFactory in HttpClientUtil
see SocketFactoryRegistryProvider
Fixes #1261


> Make SchemaRegistryProvider pluggable in HttpClientUtil
> ---
>
> Key: SOLR-14260
> URL: https://issues.apache.org/jira/browse/SOLR-14260
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Andy Throgmorton
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
> mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
> implementation of this abstract class (outside of test cases). Currently, it 
> is not override-able at runtime.
> This PR adds the ability to override the registry provider at runtime, using 
> the class name value provided by 
> "solr.httpclient.socketFactory.registry.provider", similar to how this class 
> allows for choosing the HttpClientBuilderFactory at runtime.  And 
> SchemaRegistryProvider is renamed to SocketFactoryRegistryProvider.
> We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
> context). This change helps us more easily configure Solr in a modular way, 
> since we've implemented a custom SocketFactoryRegistryProvider that 
> configures Apache clients to use our SSL context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-14260) Make SchemaRegistryProvider pluggable in HttpClientUtil

[David Smiley (Jira)]

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

David Smiley resolved SOLR-14260.
-
Resolution: Fixed

Thanks for contributing Andy!

> Make SchemaRegistryProvider pluggable in HttpClientUtil
> ---
>
> Key: SOLR-14260
> URL: https://issues.apache.org/jira/browse/SOLR-14260
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Andy Throgmorton
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
> mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
> implementation of this abstract class (outside of test cases). Currently, it 
> is not override-able at runtime.
> This PR adds the ability to override the registry provider at runtime, using 
> the class name value provided by 
> "solr.httpclient.socketFactory.registry.provider", similar to how this class 
> allows for choosing the HttpClientBuilderFactory at runtime.  And 
> SchemaRegistryProvider is renamed to SocketFactoryRegistryProvider.
> We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
> context). This change helps us more easily configure Solr in a modular way, 
> since we've implemented a custom SocketFactoryRegistryProvider that 
> configures Apache clients to use our SSL context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14357) solrj: using insecure namedCurves

[Marcus Eagan (Jira)]

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

Marcus Eagan commented on SOLR-14357:
-

Can you share a more complete stack trace for the the exception you observed? 
There have been some fixes to easily disable all the weak EC implementations in 
later Javas but it hasn't made it to [Java 8 or 
11|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8235540], the 
recommended versions for Solr. However, before I sink my teeth into the rabbit 
at the bottom of this hole, I want to understand where the exception originated 
from. We may be able to safely disable all the weak algorithms by default, but 
without knowing where it lives, I don't know what that action will break. 

> solrj: using insecure namedCurves
> -
>
> Key: SOLR-14357
> URL: https://issues.apache.org/jira/browse/SOLR-14357
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Bernd Wahlen
>Priority: Major
>
> i tried to run our our backend with solrj 8.4.1 on jdk14 and get the 
> following error:
> Caused by: java.lang.IllegalArgumentException: Error in security property. 
> Constraint unknown: c2tnb191v1
> after i removed all the X9.62 algoriths from the property 
> jdk.disabled.namedCurves in
> /usr/lib/jvm/java-14-openjdk-14.0.0.36-1.rolling.el7.x86_64/conf/security/java.security
> everything is running.
> This does not happend on staging (i think because of only 1 solr node - not 
> using lb client).
> We do not set or change any ssl settings in solr.in.sh.
> I don't know how to fix that (default config?, apache client settings?), but 
> i think using insecure algorithms may be  a security risk and not only a 
> jdk14 issue.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] dsmiley closed pull request #1366: SOLR-14342: Optimize core loading order in SolrCloud.

[GitBox]

dsmiley closed pull request #1366: SOLR-14342: Optimize core loading order in 
SolrCloud.
URL: https://github.com/apache/lucene-solr/pull/1366
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-14342) CoreSorter is partially broken, thus core loading order is sub-optimal

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14342:


Commit a0b0c710b550ad6475740af52cec2eb4a4522d46 in lucene-solr's branch 
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a0b0c71 ]

SOLR-14342: Improve core loading order in SolrCloud.
Makes collections available sooner and reduces leaderVoteWait timeouts in large 
SolrCloud clusters.
This fixes a previous attempt to do this.
Fixes #1366


> CoreSorter is partially broken, thus core loading order is sub-optimal
> --
>
> Key: SOLR-14342
> URL: https://issues.apache.org/jira/browse/SOLR-14342
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In SOLR-7280, it Solr was supposedly improved to load cores in a more optimal 
> order in SolrCloud, considering the state of collections across the cluster.  
> The CoreContainer uses CoreSorter for this.  Unfortunately, CoreSorter's 
> attempts to gather statistics early on in CoreSorter.init() operate on an 
> empty list and do nothing (i.e. dead code). The root cause is that 
> getCloudDescriptors() works by looking at cc.getCores however at this stage 
> _there are no cores_ ! (We haven't sorted them so they certainly haven't been 
> loaded yet.   I have a fix.
> This might be classified as a bug fix but the core load order is more about 
> optimization, so a fix to a wrong/incomplete optimization isn't really a bug 
> from a user's point of view.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14260) Make SchemaRegistryProvider pluggable in HttpClientUtil

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14260:


Commit 167cbeae022a3056e224ea9b661e956343e4c315 in lucene-solr's branch 
refs/heads/branch_8x from Andy Throgmorton
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=167cbea ]

SOLR-14260: SolrJ pluggable ConnectionSocketFactory in HttpClientUtil
see SocketFactoryRegistryProvider
Fixes #1261

(cherry picked from commit d1601f6fdf20230abfec50cc587ca1af879d4ea5)


> Make SchemaRegistryProvider pluggable in HttpClientUtil
> ---
>
> Key: SOLR-14260
> URL: https://issues.apache.org/jira/browse/SOLR-14260
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Andy Throgmorton
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> HttpClientUtil.java defines and uses an abstract SchemaRegistryProvider for 
> mapping a protocol to an Apache ConnectionSocketFactory. There is only one 
> implementation of this abstract class (outside of test cases). Currently, it 
> is not override-able at runtime.
> This PR adds the ability to override the registry provider at runtime, using 
> the class name value provided by 
> "solr.httpclient.socketFactory.registry.provider", similar to how this class 
> allows for choosing the HttpClientBuilderFactory at runtime.  And 
> SchemaRegistryProvider is renamed to SocketFactoryRegistryProvider.
> We've implemented a custom mTLS solution in Solr (which uses a custom SSL 
> context). This change helps us more easily configure Solr in a modular way, 
> since we've implemented a custom SocketFactoryRegistryProvider that 
> configures Apache clients to use our SSL context.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (SOLR-14342) CoreSorter is partially broken, thus core loading order is sub-optimal

[David Smiley (Jira)]

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

David Smiley updated SOLR-14342:

Labels: scaling  (was: )

> CoreSorter is partially broken, thus core loading order is sub-optimal
> --
>
> Key: SOLR-14342
> URL: https://issues.apache.org/jira/browse/SOLR-14342
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Labels: scaling
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In SOLR-7280, it Solr was supposedly improved to load cores in a more optimal 
> order in SolrCloud, considering the state of collections across the cluster.  
> The CoreContainer uses CoreSorter for this.  Unfortunately, CoreSorter's 
> attempts to gather statistics early on in CoreSorter.init() operate on an 
> empty list and do nothing (i.e. dead code). The root cause is that 
> getCloudDescriptors() works by looking at cc.getCores however at this stage 
> _there are no cores_ ! (We haven't sorted them so they certainly haven't been 
> loaded yet.   I have a fix.
> This might be classified as a bug fix but the core load order is more about 
> optimization, so a fix to a wrong/incomplete optimization isn't really a bug 
> from a user's point of view.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Resolved] (SOLR-14342) CoreSorter is partially broken, thus core loading order is sub-optimal

[David Smiley (Jira)]

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

David Smiley resolved SOLR-14342.
-
Fix Version/s: 8.6
   Resolution: Fixed

> CoreSorter is partially broken, thus core loading order is sub-optimal
> --
>
> Key: SOLR-14342
> URL: https://issues.apache.org/jira/browse/SOLR-14342
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Labels: scaling
> Fix For: 8.6
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In SOLR-7280, it Solr was supposedly improved to load cores in a more optimal 
> order in SolrCloud, considering the state of collections across the cluster.  
> The CoreContainer uses CoreSorter for this.  Unfortunately, CoreSorter's 
> attempts to gather statistics early on in CoreSorter.init() operate on an 
> empty list and do nothing (i.e. dead code). The root cause is that 
> getCloudDescriptors() works by looking at cc.getCores however at this stage 
> _there are no cores_ ! (We haven't sorted them so they certainly haven't been 
> loaded yet.   I have a fix.
> This might be classified as a bug fix but the core load order is more about 
> optimization, so a fix to a wrong/incomplete optimization isn't really a bug 
> from a user's point of view.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14342) CoreSorter is partially broken, thus core loading order is sub-optimal

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14342:


Commit 2ba905741bc65146c99e3e4d74c75084709beeb2 in lucene-solr's branch 
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2ba9057 ]

SOLR-14342: Improve core loading order in SolrCloud.
Makes collections available sooner and reduces leaderVoteWait timeouts in large 
SolrCloud clusters.
This fixes a previous attempt to do this.
Fixes #1366

(cherry picked from commit a0b0c710b550ad6475740af52cec2eb4a4522d46)


> CoreSorter is partially broken, thus core loading order is sub-optimal
> --
>
> Key: SOLR-14342
> URL: https://issues.apache.org/jira/browse/SOLR-14342
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In SOLR-7280, it Solr was supposedly improved to load cores in a more optimal 
> order in SolrCloud, considering the state of collections across the cluster.  
> The CoreContainer uses CoreSorter for this.  Unfortunately, CoreSorter's 
> attempts to gather statistics early on in CoreSorter.init() operate on an 
> empty list and do nothing (i.e. dead code). The root cause is that 
> getCloudDescriptors() works by looking at cc.getCores however at this stage 
> _there are no cores_ ! (We haven't sorted them so they certainly haven't been 
> loaded yet.   I have a fix.
> This might be classified as a bug fix but the core load order is more about 
> optimization, so a fix to a wrong/incomplete optimization isn't really a bug 
> from a user's point of view.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14351) Harden MDCLoggingContext.clear depth tracking

[Mike Drob (Jira)]

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

Mike Drob commented on SOLR-14351:
--

Leave a comment, file a JIRA, move on with other things?

> Harden MDCLoggingContext.clear depth tracking
> -
>
> Key: SOLR-14351
> URL: https://issues.apache.org/jira/browse/SOLR-14351
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MDCLoggingContext tracks recursive calls and only clears when the recursion 
> level is back down to 0.  If a caller forgets to register and ends up calling 
> clear any ways, then this can mess things up.  Additionally I found at least 
> one place this is occurring, which led me to investigate this matter.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[GitHub] [lucene-solr] gerlowskija edited a comment on issue #1379: SOLR-14363: Separate /get requests into their own type designation

[GitBox]

gerlowskija edited a comment on issue #1379: SOLR-14363: Separate /get requests 
into their own type designation
URL: https://github.com/apache/lucene-solr/pull/1379#issuecomment-604650801
 
 
   > Can we instead dynamically pull out the request handler path no matter 
what it is?
   
   We do - it gets indexed into a field called `path_s`.  That happens 
regardless of this PR.  Changing the tokenization on `path_s` sounds 
reasonable, but is probably a separate PR since it's not entirely connected.
   
   This PR is mostly about the `type_s` field. `type_s` gets populated with a 
few enum-like values that aim to represent broad classes/types of requests: 
"update", "query", "commit", etc.  The idea is that admins can get a sense at a 
glance as to what sort of traffic is hitting cross sections of their cluster 
without getting as granular as `path_s` provides.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] mbwaheed commented on a change in pull request #1369: SOLR-14213: Allow enabling shared store to be scriptable

[GitBox]

mbwaheed commented on a change in pull request #1369: SOLR-14213: Allow 
enabling shared store to be scriptable
URL: https://github.com/apache/lucene-solr/pull/1369#discussion_r398893770
 
 

 ##
 File path: solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java
 ##
 @@ -568,4 +568,17 @@ private static PluginInfo 
getTracerPluginInfo(XmlConfigFile config) {
 Node node = config.getNode("solr/tracerConfig", false);
 return (node == null) ? null : new PluginInfo(node, "tracerConfig", false, 
true);
   }
+  
+  private static SharedStoreConfig loadSharedStoreConfig(NamedList nl) 
{
+if (nl == null) {
+  // shared store is not configured
+  return null;
+} 
+boolean enabled = Boolean.parseBoolean(
+required("sharedStore", "sharedStoreEnabled", removeValue(nl, 
"sharedStoreEnabled")));
+if (enabled) {
+  return new SharedStoreConfig();
+}
 
 Review comment:
   Maybe it works for now, but later we might want to properly add an enabled 
property to SharedStoreConfig and create SharedStoreConfig even enabled is 
false. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] MarcusSorealheis opened a new pull request #1382: Remove auto rep solr 12720

[GitBox]

MarcusSorealheis opened a new pull request #1382: Remove auto rep solr 12720
URL: https://github.com/apache/lucene-solr/pull/1382
 
 
   
   
   
   # Description
   There is something problematic that was deprecated a while ago that is no 
gone.
   
   # Solution
   
   I removed the the deprecated object and its associated artifacts and added 
how users could still leverage the API for trigger configuration if they so 
choose. 
   
   # Tests
   
   No change to any test.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [ ] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [ ] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [ ] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [ ] I have developed this patch against the `master` branch.
   - [ ] I have run `ant precommit` and the appropriate test suite.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Ref 
Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) 
(for Solr changes only).
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Updated] (SOLR-14128) SystemCollectionCompatTest times out waiting for Overseer to do compatibility checks

[Andrzej Bialecki (Jira)]

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

Andrzej Bialecki updated SOLR-14128:

Fix Version/s: 8.6

> SystemCollectionCompatTest times out waiting for Overseer to do compatibility 
> checks
> 
>
> Key: SOLR-14128
> URL: https://issues.apache.org/jira/browse/SOLR-14128
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
> Attachments: fail.txt, nodeset.patch, pass.txt, 
> thetaphi_Lucene-Solr-master-Linux_25161.log.txt
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-14128) SystemCollectionCompatTest times out waiting for Overseer to do compatibility checks

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on SOLR-14128:


Commit 5bcbde9599003ed8b423bb68d3a16cfab4375efe in lucene-solr's branch 
refs/heads/branch_8x from Andrzej Bialecki
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5bcbde9 ]

SOLR-14128: Improve distributed locking around managed schema upgrade process.


> SystemCollectionCompatTest times out waiting for Overseer to do compatibility 
> checks
> 
>
> Key: SOLR-14128
> URL: https://issues.apache.org/jira/browse/SOLR-14128
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Chris M. Hostetter
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: fail.txt, nodeset.patch, pass.txt, 
> thetaphi_Lucene-Solr-master-Linux_25161.log.txt
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (SOLR-13659) Refactor Cache config to lazily load the the class

[Noble Paul (Jira)]

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

Noble Paul commented on SOLR-13659:
---

Yes, that must go

> Refactor Cache config to lazily load the the class 
> ---
>
> Key: SOLR-13659
> URL: https://issues.apache.org/jira/browse/SOLR-13659
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Cache implementation class is currently loaded from the SolrConfig 
> classloader 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Updated] (LUCENE-9077) Gradle build

[Erick Erickson (Jira)]

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

Erick Erickson updated LUCENE-9077:
---
Description: 
This task focuses on providing gradle-based build equivalent for Lucene and 
Solr (on master branch). See notes below on why this respin is needed.

The code lives on *gradle-master* branch. It is kept with sync with *master*. 
Try running the following to see an overview of helper guides concerning 
typical workflow, testing and ant-migration helpers:

gradlew :help

A list of items that needs to be added or requires work. If you'd like to work 
on any of these, please add your name to the list. Once you have a patch/ pull 
request let me (dweiss) know - I'll try to coordinate the merges.
 * (/) Apply forbiddenAPIs
 * (/) Generate hardware-aware gradle defaults for parallelism (count of 
workers and test JVMs).
 * (/) Fail the build if --tests filter is applied and no tests execute during 
the entire build (this allows for an empty set of filtered tests at single 
project level).
 * (/) Port other settings and randomizations from common-build.xml
 * (/) Configure security policy/ sandboxing for tests.
 * (/) test's console output on -Ptests.verbose=true
 * (/) add a :helpDeps explanation to how the dependency system works (palantir 
plugin, lockfile) and how to retrieve structured information about current 
dependencies of a given module (in a tree-like output).
 * (/) jar checksums, jar checksum computation and validation. This should be 
done without intermediate folders (directly on dependency sets).
 * (/) verify min. JVM version and exact gradle version on build startup to 
minimize odd build side-effects
 * (/) Repro-line for failed tests/ runs.
 * (/) add a top-level README note about building with gradle (and the required 
JVM).
 * (/) add an equivalent of 'validate-source-patterns' 
(check-source-patterns.groovy) to precommit.
 * (/) add an equivalent of 'rat-sources' to precommit.
 * (/) add an equivalent of 'check-example-lucene-match-version' (solr only) to 
precommit.
 * (/) javadoc compilation

Hard-to-implement stuff already investigated:
 * (/) (done)  -*Printing console output of failed tests.* There doesn't seem 
to be any way to do this in a reasonably efficient way. There are onOutput 
listeners but they're slow to operate and solr tests emit *tons* of output so 
it's an overkill.-
 * (!) (LUCENE-9120) *Tests working with security-debug logs or other JVM-early 
log output*. Gradle's test runner works by redirecting Java's stdout/ syserr so 
this just won't work. Perhaps we can spin the ant-based test runner for such 
corner-cases.

Of lesser importance:
 * Add an equivalent of 'documentation-lint" to precommit.
 * (/) Do not require files to be committed before running precommit. (staged 
files are fine).
 * (/) add rendering of javadocs (gradlew javadoc)
 * Attach javadocs to maven publications.
 * Add test 'beasting' (rerunning the same suite multiple times). I'm afraid 
it'll be difficult to run it sensibly because gradle doesn't offer cwd 
separation for the forked test runners.
 * if you diff solr packaged distribution against ant-created distribution 
there are minor differences in library versions and some JARs are excluded/ 
moved around. I didn't try to force these as everything seems to work (tests, 
etc.) – perhaps these differences should  be fixed in the ant build instead.
 * (/) identify and port various "regenerate" tasks from ant builds (javacc, 
precompiled automata, etc.)
 * Fill in POM details in gradle/defaults-maven.gradle so that they reflect the 
previous content better (dependencies aside).
 * Add any IDE integration layers that should be added (I use IntelliJ and it 
imports the project out of the box, without the need for any special tuning).
 ** Remove idea task and just import from the gradle model? One less thing to 
maintain.
 * Add Solr packaging for docs/* (see TODO in packaging/build.gradle; currently 
XSLT...)
 * I didn't bother adding Solr dist/test-framework to packaging (who'd use it 
from a binary distribution? 
 * There is some python execution in check-broken-links and 
check-missing-javadocs, not sure if it's been ported
 * Nightly-smoke also has some python execution, not sure of the status.
 * (/) Precommit doesn't catch unused imports

 

*{color:#ff}Note:{color}* this builds on the work done by Mark Miller and 
Cao Mạnh Đạt but also applies lessons learned from those two efforts:
 * *Do not try to do too many things at once*. If we deviate too far from 
master, the branch will be hard to merge.
 * *Do everything in baby-steps* and add small, independent build fragments 
replacing the old ant infrastructure.
 * *Try to engage people to run, test and contribute early*. It can't be a 
one-man effort. The more people understand and can contribute to the build, the 
more healthy it will be.

 

  was:
This task focuses on 

[GitHub] [lucene-solr] ctargett edited a comment on issue #1382: Remove auto rep solr 12720

[GitBox]

ctargett edited a comment on issue #1382: Remove auto rep solr 12720
URL: https://github.com/apache/lucene-solr/pull/1382#issuecomment-604413217
 
 
   @MarcusSorealheis What's the associated Jira issue for this? I think you 
meant SOLR-12720? The format to use so the PR and the Jira are properly linked 
is to use the full form in the PR title, as in `SOLR-12720`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] ctargett commented on issue #1382: Remove auto rep solr 12720

[GitBox]

ctargett commented on issue #1382: Remove auto rep solr 12720
URL: https://github.com/apache/lucene-solr/pull/1382#issuecomment-604413217
 
 
   @MarcusSorealheis What's the associated Jira issue for this? I think you 
meant SOLR-12720? The format to use so the PR and the Jira are properly linked 
is to use the full form, as in `SOLR-12720`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] MarcusSorealheis commented on issue #1382: Remove auto rep solr 12720

[GitBox]

MarcusSorealheis commented on issue #1382: Remove auto rep solr 12720
URL: https://github.com/apache/lucene-solr/pull/1382#issuecomment-604491233
 
 
   I’m sorry. It should be there. I opened it sleepily. I’ll fix.
   
   On Thu, Mar 26, 2020 at 05:51 Cassandra Targett 
   wrote:
   
   > @MarcusSorealheis  What's the
   > associated Jira issue for this? I think you meant SOLR-12720? The format to
   > use so the PR and the Jira are properly linked is to use the full form, as
   > in SOLR-12720.
   >
   > —
   > You are receiving this because you were mentioned.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   -- 
   Marcus Eagan
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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