date:20200910



dweiss commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690040203


   > So it turns out that fileMode isn't an option for FileCopyDetails, so it 
was applying it to the whole Copy operation instead. Changing it to setMode 
fixed everything.
   
   Ah. Great catch! This is one of the biggest gotchas in gradle - unscoped 
variables sometimes reach out to unexpected places. Thanks for finding it.



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



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

[GitHub] [lucene-solr] dweiss commented on pull request #1844: SOLR-14847: Create Solr Server TGZ



dweiss commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690040828


   I've added a file permissions block and verified what the distribution 
plugin does. I still have mixed feelings about it but I admit I am conservative 
about using third-party plugins (spent too much time debugging such stuff...).
   
   Let it be though. +1 from me.



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



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

[GitHub] [lucene-solr] uschindler commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



uschindler commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690040410


   > uschindler why are you so grumpy, you have so much to add to this issue, 
why don’t you do it in a positive way?
   
   Sorry for this. It was a bit busy yesterday and after I have seen a 
"workaround" that has security-critical effects (we're taking responsibility 
for access to declared members by JDK), and multiple people hammering: "hey 
there's a bug!", while at the same time this PR was almost merged (@s1monw said 
"LGTM") I had to stop this.
   
   Whenever you intend to use AccessController#doPrivileged, you should really 
only do this, if you are under control of that code and you take responsibility 
- and definitely never as a workaround for a bug. Side note: The bug in the JDK 
annoyed me too much, so I quickly went to "dark side".
   
   After a second thought, I developed the better workaround in #1850 (I had 
this in mind previously, too - but as @dweiss said, the new workaround is not 
as elegant as the subclassing). It can't handle the ByteBuffer case. This will 
come back to us, if we want to use Deflater at more places in Lucene; for now 
both bugfixes are fine.
   
   Maybe before merging #1850: *Could you also test, if making the bugfix class 
"public" helps?* (I don't think it will help, but it's worth a try). The 
problem is: Our class is in different classloader than JDK's Deflater (module 
class loader), so nobody from JDK would be able to see our private 
implementation and therefore JVM refuses to lookup that method (although the 
"old reflection API is not fully correct here; nowadays one should always use 
`MethodHandles.lookup()` in such cases as it clearly emulates and enforces what 
the JLS specifies). Because of this, I would have more expected a "package 
access" security exception. If JDK would have used a Lookup, this won't have 
happened, too.
   
   But as @iverase has a quick reproducer in Elasticsearch, maybe he can try to 
just make the class public. If that does not work, I will merge #1850. 



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



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

[GitHub] [lucene-solr] uschindler commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



uschindler commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690042065


   Nevertheless, I think we should work the new workaround, because I don't 
want JDK to do crazy reflection on every constructor call. It would still be 
interesting to know, if making `BugfixDeflater_JDK8252739` public.



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



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

[GitHub] [lucene-solr] uschindler edited a comment on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



uschindler edited a comment on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690042065


   Nevertheless, I think we should work the new workaround, because I don't 
want JDK to do crazy reflection on every constructor call. It would still be 
interesting to know, if making `BugfixDeflater_JDK8252739` public helps.



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



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

[GitHub] [lucene-solr] dweiss commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



dweiss commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690042351


   Simon is right that language matters. And stays on the Web forever. 
   We all have dark sides. And we're all scared of yours, Uwe! :)
   
   +1 to the new workaround. Adding forbidden-apis should keep it under control.



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



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

[jira] [Created] (LUCENE-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)

Dawid Weiss created LUCENE-9518:
---

 Summary: Add sanity to gradle archiving tasks (predictable order, 
default permissions, fail on duplicates) 
 Key: LUCENE-9518
 URL: https://issues.apache.org/jira/browse/LUCENE-9518
 Project: Lucene - Core
  Issue Type: Task
Reporter: Dawid Weiss
Assignee: Dawid Weiss






--
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] dweiss opened a new pull request #1851: LUCENE-9518: Add sanity to gradle archiving tasks.



dweiss opened a new pull request #1851:
URL: https://github.com/apache/lucene-solr/pull/1851


   



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



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

[GitHub] [lucene-solr] uschindler commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



uschindler commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690055724


   Thanks Dawid! All is fine :-)
   
   One problem that was a bit confusing when @iverase opened the original issue 
was this sentence: "We are running into issues when running Elasticsearch CI 
with java security turned on." This looks like an issue only with CI and the PR 
is just to workaround some bug in the CI system, which should definitely not 
done. I have seen many issues opened by ES people using that terminology. It 
should be different: If Elastic's CI discovers a bug, a person should verify 
and understand it, and after that open an issue with "running tests in our 
Elasticsearch codebase discovered a bug". The terminology that was used is 
confusing as it implies that only CI is not happy.
   
   Actually this bug should be visible to anybody running ES tests? 100% of all 
Tests should fail.



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



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

[jira] [Resolved] (LUCENE-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)

2020-09-10 Thread ASF subversion and git services (Jira)



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

Dawid Weiss resolved LUCENE-9518.
-
Fix Version/s: master (9.0)
   Resolution: Fixed

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

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

Commit a05a055d9d3f5ef10ec092becf9ac74e44f6a953 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a05a055 ]

LUCENE-9518: Add sanity to gradle archiving tasks (predictable order, default 
permissions, fail on duplicates) (#1851)



> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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] iverase commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



iverase commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690067149


   > It would still be interesting to know, if making BugfixDeflater_JDK8252739 
public helps.
   
   I have a go locally and It does not seem to work.
   
   > while at the same time this PR was almost merged  I had to stop this.
   
   I can only ensure you I was not planning in merging the PR until your 
review, that is the reason I added you as the only reviewer :)
   
   > One problem that was a bit confusing when @iverase opened the original 
issue was this sentence: "We are running into issues when running Elasticsearch 
CI with java security turned on." 
   
   That is my bad, I will try to be more precise and assertive in the future.
   
   > Actually this bug should be visible to anybody running ES tests? 100% of 
all Tests should fail.
   
   It only fails in buggy JDK 11 and if you are hitting that bit of code. I 
think by default most of the people run locally using JDK 14 as it is the 
version required to build Elasticsearch.
   
   Final question, I guess it is not possible in forbidden-apis to prevent 
subclassing? e.g prevent subclassing Deflator 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



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

[GitHub] [lucene-solr] uschindler commented on pull request #1849: LUCENE-9517: Add doPrivileged block when creating BugfixDeflater_JDK8252739 objects



uschindler commented on pull request #1849:
URL: https://github.com/apache/lucene-solr/pull/1849#issuecomment-690102497


   > I have a go locally and It does not seem to work.
   
   Tht's what I expected. If they would have used `MethodHandles.lookup()` it 
would have worked better without `AccessController`. Thanks!!!
   
   > Final question, I guess it is not possible in forbidden-apis to prevent 
subclassing? e.g prevent subclassing Deflator class.
   
   No, you can't. There are some way to do this for abstract classes, if you 
put the constructor on forbiddenapis (as it's called by subclasses). For the 
use case here it won't work, as we have to call ctor to create the instance.
   
   Thanks for the response to all other comments. Sorry for the issue, I was a 
bit harsh! 
   
   I will now merge the other PR.



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



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

[GitHub] [lucene-solr] uschindler merged pull request #1850: LUCENE-9517: Don't subclass Deflater and instead create a patch for setDictionary() using a functional interface

2020-09-10 Thread ASF subversion and git services (Jira)



uschindler merged pull request #1850:
URL: https://github.com/apache/lucene-solr/pull/1850


   



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



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

[jira] [Commented] (LUCENE-9517) BugfixDeflater_JDK8252739 causes Java security issues in JDK 11



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

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

Commit 8debc9d0c2ee7c507d5ed7a4b738ec083151fb6d in lucene-solr's branch 
refs/heads/master from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8debc9d ]

LUCENE-9517: Don't subclass Deflater and instead create a patch for 
setDictionary() using a functional interface (#1850)



> BugfixDeflater_JDK8252739 causes Java security issues in JDK 11
> ---
>
> Key: LUCENE-9517
> URL: https://issues.apache.org/jira/browse/LUCENE-9517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.x, master (9.0)
>Reporter: Ignacio Vera
>Assignee: Uwe Schindler
>Priority: Major
>  Labels: Java10, Java11
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> We are running into issues when running Elasticsearch CI with java security 
> turned on and using JDK11 (only for the ones that contains the jdk bug ).   
> The errors look like:
>  
>  
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessDeclaredMembers") {code}
>  
> The issue seems to be here:
> [http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l989]
> As we now have a subclass that wants to run this code. Note that this code 
> has been removed in JDK12 and above.
> We might need to wrap the creation of this object in a doPriviledged Block or 
> find a different solution that does not need to subclass the Deflater class.
>  
> cc: [~uschindler]
>  
>  
>  



--
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] dweiss merged pull request #1851: LUCENE-9518: Add sanity to gradle archiving tasks.

2020-09-10 Thread ASF subversion and git services (Jira)



dweiss merged pull request #1851:
URL: https://github.com/apache/lucene-solr/pull/1851


   



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



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

[jira] [Commented] (LUCENE-9517) BugfixDeflater_JDK8252739 causes Java security issues in JDK 11



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

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

Commit b313618cc1d104ae8994aad9aa71565562407ee1 in lucene-solr's branch 
refs/heads/branch_8x from Uwe Schindler
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b313618 ]

LUCENE-9517: Don't subclass Deflater and instead create a patch for 
setDictionary() using a functional interface (#1850)
(backport: forbiddenApis/base.txt changed for Java 8, private static method in 
interface changed)


> BugfixDeflater_JDK8252739 causes Java security issues in JDK 11
> ---
>
> Key: LUCENE-9517
> URL: https://issues.apache.org/jira/browse/LUCENE-9517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.x, master (9.0)
>Reporter: Ignacio Vera
>Assignee: Uwe Schindler
>Priority: Major
>  Labels: Java10, Java11
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> We are running into issues when running Elasticsearch CI with java security 
> turned on and using JDK11 (only for the ones that contains the jdk bug ).   
> The errors look like:
>  
>  
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessDeclaredMembers") {code}
>  
> The issue seems to be here:
> [http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l989]
> As we now have a subclass that wants to run this code. Note that this code 
> has been removed in JDK12 and above.
> We might need to wrap the creation of this object in a doPriviledged Block or 
> find a different solution that does not need to subclass the Deflater class.
>  
> cc: [~uschindler]
>  
>  
>  



--
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] (LUCENE-9517) BugfixDeflater_JDK8252739 causes Java security issues in JDK 11

2020-09-10 Thread Uwe Schindler (Jira)



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

Uwe Schindler resolved LUCENE-9517.
---
Resolution: Fixed

I merged the PR and backported the changes to 8.x:
- forbiddenapis adaption (removal of ByteBuffer)
- change of access flags on interface method (in Java 8, "private static" 
methods are not allowed)

> BugfixDeflater_JDK8252739 causes Java security issues in JDK 11
> ---
>
> Key: LUCENE-9517
> URL: https://issues.apache.org/jira/browse/LUCENE-9517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.x, master (9.0)
>Reporter: Ignacio Vera
>Assignee: Uwe Schindler
>Priority: Major
>  Labels: Java10, Java11
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> We are running into issues when running Elasticsearch CI with java security 
> turned on and using JDK11 (only for the ones that contains the jdk bug ).   
> The errors look like:
>  
>  
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessDeclaredMembers") {code}
>  
> The issue seems to be here:
> [http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l989]
> As we now have a subclass that wants to run this code. Note that this code 
> has been removed in JDK12 and above.
> We might need to wrap the creation of this object in a doPriviledged Block or 
> find a different solution that does not need to subclass the Deflater class.
>  
> cc: [~uschindler]
>  
>  
>  



--
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-9517) BugfixDeflater_JDK8252739 causes Java security issues in JDK 11

2020-09-10 Thread Uwe Schindler (Jira)



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

Uwe Schindler commented on LUCENE-9517:
---

Sorry for beeing a bit harsh, see PR for more information. I hope all is fine!

> BugfixDeflater_JDK8252739 causes Java security issues in JDK 11
> ---
>
> Key: LUCENE-9517
> URL: https://issues.apache.org/jira/browse/LUCENE-9517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.x, master (9.0)
>Reporter: Ignacio Vera
>Assignee: Uwe Schindler
>Priority: Major
>  Labels: Java10, Java11
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> We are running into issues when running Elasticsearch CI with java security 
> turned on and using JDK11 (only for the ones that contains the jdk bug ).   
> The errors look like:
>  
>  
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessDeclaredMembers") {code}
>  
> The issue seems to be here:
> [http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l989]
> As we now have a subclass that wants to run this code. Note that this code 
> has been removed in JDK12 and above.
> We might need to wrap the creation of this object in a doPriviledged Block or 
> find a different solution that does not need to subclass the Deflater class.
>  
> cc: [~uschindler]
>  
>  
>  



--
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-9517) BugfixDeflater_JDK8252739 causes Java security issues in JDK 11

2020-09-10 Thread Ignacio Vera (Jira)



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

Ignacio Vera commented on LUCENE-9517:
--

Absolutely! I realise the issue did come in a moment you were pretty busy 
working on there stuff! And then saw you thinking about the issue and I learn a 
ton :) 

 

Thank you! ( and everybody else that contributed)

> BugfixDeflater_JDK8252739 causes Java security issues in JDK 11
> ---
>
> Key: LUCENE-9517
> URL: https://issues.apache.org/jira/browse/LUCENE-9517
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 8.x, master (9.0)
>Reporter: Ignacio Vera
>Assignee: Uwe Schindler
>Priority: Major
>  Labels: Java10, Java11
> Fix For: 8.x, master (9.0)
>
>  Time Spent: 4h 50m
>  Remaining Estimate: 0h
>
> We are running into issues when running Elasticsearch CI with java security 
> turned on and using JDK11 (only for the ones that contains the jdk bug ).   
> The errors look like:
>  
>  
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessDeclaredMembers") {code}
>  
> The issue seems to be here:
> [http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/java.base/share/classes/java/util/zip/Deflater.java#l989]
> As we now have a subclass that wants to run this code. Note that this code 
> has been removed in JDK12 and above.
> We might need to wrap the creation of this object in a doPriviledged Block or 
> find a different solution that does not need to subclass the Deflater class.
>  
> cc: [~uschindler]
>  
>  
>  



--
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-14823) Allow Rule Based Replica Assignment Policy



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

Noble Paul resolved SOLR-14823.
---
Resolution: Invalid

> Allow Rule Based Replica Assignment Policy
> --
>
> Key: SOLR-14823
> URL: https://issues.apache.org/jira/browse/SOLR-14823
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Priority: Major
>
> When I disabled the slow replica placement, at the time I also just skipped 
> the rule based policy - this should be allowed and those tests reenabled.



--
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-14817) Handle security in the node forwarding / proxy / remoteQuery feature that HttpSolrCall has



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

Noble Paul reassigned SOLR-14817:
-

Assignee: Noble Paul

> Handle security in the node forwarding / proxy / remoteQuery feature that 
> HttpSolrCall has 
> ---
>
> Key: SOLR-14817
> URL: https://issues.apache.org/jira/browse/SOLR-14817
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Assignee: Noble Paul
>Priority: Major
>




--
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-14816) Bring back shard whitelisting feature



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

Noble Paul reassigned SOLR-14816:
-

Assignee: Noble Paul

> Bring back shard whitelisting feature
> -
>
> Key: SOLR-14816
> URL: https://issues.apache.org/jira/browse/SOLR-14816
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Assignee: Noble Paul
>Priority: Major
>




--
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-14823) Allow Rule Based Replica Assignment Policy



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

Noble Paul commented on SOLR-14823:
---

Autoscaling policy framework is removed from master.

> Allow Rule Based Replica Assignment Policy
> --
>
> Key: SOLR-14823
> URL: https://issues.apache.org/jira/browse/SOLR-14823
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Robert Miller
>Priority: Major
>
> When I disabled the slow replica placement, at the time I also just skipped 
> the rule based policy - this should be allowed and those tests reenabled.



--
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] dweiss merged pull request #1820: LUCENE-9464: Add high(er)-level hit highlighter example that demonstrates and uses low-level components



dweiss merged pull request #1820:
URL: https://github.com/apache/lucene-solr/pull/1820


   



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



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

[GitHub] [lucene-solr] dweiss commented on pull request #1820: LUCENE-9464: Add high(er)-level hit highlighter example that demonstrates and uses low-level components



dweiss commented on pull request #1820:
URL: https://github.com/apache/lucene-solr/pull/1820#issuecomment-690175885


   I've merged this in. If we decide to change it or improve the API, let it be 
another issue.



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



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

[jira] [Resolved] (LUCENE-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components

2020-09-10 Thread ASF subversion and git services (Jira)



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

Dawid Weiss resolved LUCENE-9464.
-
Fix Version/s: master (9.0)
   Resolution: Fixed

> Add high(er)-level hit highlighter example that demonstrates and uses 
> low-level components
> --
>
> Key: LUCENE-9464
> URL: https://issues.apache.org/jira/browse/LUCENE-9464
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>




--
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-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components



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

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

Commit e2f3f626ee4c7f2d2df1e09a31b971c81e95be44 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2f3f62 ]

LUCENE-9464: Add high(er)-level hit highlighter example that demonstrates and 
uses low-level components (#1820)



> Add high(er)-level hit highlighter example that demonstrates and uses 
> low-level components
> --
>
> Key: LUCENE-9464
> URL: https://issues.apache.org/jira/browse/LUCENE-9464
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




--
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] noblepaul opened a new pull request #1852: propegate() to propagate()



noblepaul opened a new pull request #1852:
URL: https://github.com/apache/lucene-solr/pull/1852


   



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



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

[jira] [Commented] (SOLR-14701) Deprecate Schemaless Mode (Discussion)

2020-09-10 Thread Alexandre Rafalovitch (Jira)



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

Alexandre Rafalovitch commented on SOLR-14701:
--

Shoot. We are all missing something. The chain has to be there and always 
enabled. Because we are not just guessing schema (however correctly). We are 
also actively modifying incoming values in the ways just field mapping does not.

Specifically:
 # We are generating IDs
 # We are removing blank values
 # We are renaming fields with spaces
 # We are parsing dates in custom formats

So, when we disable our URPChain (as per current instructions), we also lose 
all of those functions and Solr suddenly starts complaining about all those 
things. Also, if you run a different chain (such as dedupe), it will not be 
doing the above things.

I just checked it with `bin/post -c schemaless -type text/csv -d 
$'date1\n2020-08-01'` . It works out of the box and fails in two different ways 
once we give our switch off command.

Which means, either we promote this to always on with flag on guessing URP, not 
whole chain. But then we will have bugs when using other chains.

Or we really demote it to example schema and explain how it works so people 
manually include those processes in their own design.

Or? Thoughts please!

> Deprecate Schemaless Mode (Discussion)
> --
>
> Key: SOLR-14701
> URL: https://issues.apache.org/jira/browse/SOLR-14701
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Marcus Eagan
>Priority: Major
> Attachments: image-2020-08-04-01-35-03-075.png
>
>
> I know this won't be the most popular ticket out there, but I am growing more 
> and more sympathetic to the idea that we should rip many of the freedoms out 
> that cause users more harm than not. One of the freedoms I saw time and time 
> again to cause issues was schemaless mode. It doesn't work as named or 
> documented, so I think it should be deprecated. 
> If you use it in production reliably and in a way that cannot be accomplished 
> another way, I am happy to hear from more knowledgeable folks as to why 
> deprecation is a bad idea. 



--
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] (LUCENE-9519) Correct behavior for highlights that cross multi-value boundaries

Dawid Weiss created LUCENE-9519:
---

 Summary: Correct behavior for highlights that cross multi-value 
boundaries
 Key: LUCENE-9519
 URL: https://issues.apache.org/jira/browse/LUCENE-9519
 Project: Lucene - Core
  Issue Type: Sub-task
Reporter: Dawid Weiss
Assignee: Dawid Weiss






--
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] (LUCENE-9520) (build) strange "/generated" folders show up out of nowhere

Dawid Weiss created LUCENE-9520:
---

 Summary: (build) strange "/generated" folders show up out of 
nowhere
 Key: LUCENE-9520
 URL: https://issues.apache.org/jira/browse/LUCENE-9520
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Dawid Weiss


Precommit has been failing for me recently with odd exceptions like this:

{code}
* What went wrong:
Execution failed for task ':checkWorkingCopyClean'.
> Working copy is not a clean git checkout (skip with 
> -Pvalidation.git.failOnModified=false), offending files:
- lucene/analysis/common/src/java/generated (untracked)
- lucene/codecs/src/java/generated (untracked)
- lucene/core/src/java/generated (untracked)
- lucene/highlighter/src/java/generated (untracked)
- lucene/highlighter/src/test/generated_tests (untracked)
- lucene/memory/src/java/generated (untracked)
- lucene/queries/src/java/generated (untracked)
- lucene/queryparser/src/java/generated (untracked)
- lucene/sandbox/src/java/generated (untracked)
- lucene/test-framework/src/java/generated (untracked)
{code}

Don't know where the "generated" folder comes from. IntellIJ is the primary 
suspect but I'm not 100% sure.



--
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-9520) (build) strange "/generated" folders show up out of nowhere



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

Dawid Weiss commented on LUCENE-9520:
-

Another question is why jgit reports these because they're empty folders (so 
shouldn't be reported). git status definitely doesn't show them.

> (build) strange "/generated" folders show up out of nowhere
> ---
>
> Key: LUCENE-9520
> URL: https://issues.apache.org/jira/browse/LUCENE-9520
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Priority: Major
>
> Precommit has been failing for me recently with odd exceptions like this:
> {code}
> * What went wrong:
> Execution failed for task ':checkWorkingCopyClean'.
> > Working copy is not a clean git checkout (skip with 
> > -Pvalidation.git.failOnModified=false), offending files:
> - lucene/analysis/common/src/java/generated (untracked)
> - lucene/codecs/src/java/generated (untracked)
> - lucene/core/src/java/generated (untracked)
> - lucene/highlighter/src/java/generated (untracked)
> - lucene/highlighter/src/test/generated_tests (untracked)
> - lucene/memory/src/java/generated (untracked)
> - lucene/queries/src/java/generated (untracked)
> - lucene/queryparser/src/java/generated (untracked)
> - lucene/sandbox/src/java/generated (untracked)
> - lucene/test-framework/src/java/generated (untracked)
> {code}
> Don't know where the "generated" folder comes from. IntellIJ is the primary 
> suspect but I'm not 100% sure.



--
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-14417) Gradle build sometimes fails RE BlockPoolSlice



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

Dawid Weiss commented on SOLR-14417:


It's not classpath ordering. The referencing class and the referenced class are 
both in the 'test' sources. I don't know what this code does or why it tries to 
shadow Hadoop classes but it's really fishy.

I am tempted to change at least change the hard reference in this in the 
problematic test to a dynamic lookup - then it wouldn't try to reference those 
classes during compilation (and would verify they're shadowed at runtime).

> Gradle build sometimes fails RE BlockPoolSlice
> --
>
> Key: SOLR-14417
> URL: https://issues.apache.org/jira/browse/SOLR-14417
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Minor
>
> There seems to be some package visibility hacks around our Hdfs integration:
> {{/Users/dsmiley/SearchDev/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:125:
>  error: BlockPoolSlice is not public in 
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed 
> from outside package}}
> {{List> modifiedHadoopClasses = Arrays.asList(BlockPoolSlice.class, 
> DiskChecker.class,}}
> This happens on my Gradle build when running {{gradlew testClasses}} (i.e. to 
> compile tests) but Ant proceeded without issue.  The work-around is to run 
> {{gradlew clean}} first but really I want our build to be smarter here.
> CC [~krisden]



--
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] dweiss opened a new pull request #1853: LUCENE-9519: Correct behavior for highlights that cross multi-value boundary



dweiss opened a new pull request #1853:
URL: https://github.com/apache/lucene-solr/pull/1853


   



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



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

[jira] [Commented] (LUCENE-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

Mike Drob commented on LUCENE-9518:
---

Hi Dawid - can you give a little more detail on what issue this hacks around?

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

Dawid Weiss commented on LUCENE-9518:
-

Google for predictable archives order; this affects caches and makes builds 
reproducible. The rest is generally to make builds consistent across OSs and 
machines.

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

Dawid Weiss commented on LUCENE-9518:
-

Duplicate entries in archives are typically an error (a ZIP archive can have 
multiple files with the same path - one shadowing another).

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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] HoustonPutman commented on pull request #1844: SOLR-14847: Create Solr Server TGZ



HoustonPutman commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690313852


   I might be using it wrong, but I don't think the distTar task overwrites 
previously generated tars. I've tried changing the executable bit paths, and 
the tar that already exists is unnaffected.
   
   If this is the case, we might want to switch back to the manual task. Though 
this seems like I'm doing something wrong, because this surely can't be the 
default behavior of the plugin.



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



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

[GitHub] [lucene-solr] dweiss commented on pull request #1844: SOLR-14847: Create Solr Server TGZ

2020-09-10 Thread ASF subversion and git services (Jira)



dweiss commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690316717


   I think those bits are not part of the task's inputs so it's not re-run. Try 
--rerun-tasks or cleanDistTar



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



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

[jira] [Commented] (LUCENE-9519) Correct behavior for highlights that cross multi-value boundaries



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

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

Commit 59d83428bcbe5d722c2245cf5b42839e6c02e637 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=59d8342 ]

LUCENE-9519: Correct behavior for highlights that cross multi-value boundaries 
(#1853)



> Correct behavior for highlights that cross multi-value boundaries
> -
>
> Key: LUCENE-9519
> URL: https://issues.apache.org/jira/browse/LUCENE-9519
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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] (LUCENE-9519) Correct behavior for highlights that cross multi-value boundaries



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

Dawid Weiss resolved LUCENE-9519.
-
Fix Version/s: master (9.0)
   Resolution: Fixed

> Correct behavior for highlights that cross multi-value boundaries
> -
>
> Key: LUCENE-9519
> URL: https://issues.apache.org/jira/browse/LUCENE-9519
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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] HoustonPutman commented on pull request #1844: SOLR-14847: Create Solr Server TGZ



HoustonPutman commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690320665


   Ahh ok, thank for clearing that up. Whenever I cleaned it up beforehand, the 
task worked fine. I've also tested changing actual files and the task 
unsurprisingly works correctly.
   
   Since we won't be adding executables in weird places too often, I think this 
should be good to go. +1



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



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

[GitHub] [lucene-solr] dweiss opened a new pull request #1854: SOLR-14417: Gradle build sometimes fails RE BlockPoolSlice



dweiss opened a new pull request #1854:
URL: https://github.com/apache/lucene-solr/pull/1854


   Workaround. This is test-change only, shouldn't affect anything else.



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



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

[GitHub] [lucene-solr] dweiss commented on pull request #1844: SOLR-14847: Create Solr Server TGZ



dweiss commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690322403


   I think the timestamps/ execution bits are not part of inputs on purpose
   (to allow distributed artifact caches). This is on the border of my gradle
   foo knowledge, you'd have to dig in yourself if you want to know more.
   
   Dawid
   
   
   On Thu, Sep 10, 2020 at 4:19 PM Houston Putman 
   wrote:
   
   > Ahh ok, thank for clearing that up. Whenever I cleaned it up beforehand,
   > the task worked fine. I've also tested changing actual files and the task
   > unsurprisingly works correctly.
   >
   > Since we won't be adding executables in weird places too often, I think
   > this should be good to go. +1
   >
   > —
   > You are receiving this because your review was requested.
   > Reply to this email directly, view it on GitHub
   > ,
   > or unsubscribe
   > 

   > .
   >
   



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



-
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 pull request #1844: SOLR-14847: Create Solr Server TGZ



madrob commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690323468


   Does this need a CHANGES entry? We haven't been doing that for other gradle 
build things, but wanted to confirm.



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



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

[jira] [Commented] (SOLR-13807) Caching for term facet counts

2020-09-10 Thread Michael Gibney (Jira)



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

Michael Gibney commented on SOLR-13807:
---

As a side-effect of [PR #1357|https://github.com/apache/lucene-solr/pull/1357] 
on this issue, SOLR-9724 is also incidentally fixed.

> Caching for term facet counts
> -
>
> Key: SOLR-13807
> URL: https://issues.apache.org/jira/browse/SOLR-13807
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Affects Versions: master (9.0), 8.2
>Reporter: Michael Gibney
>Priority: Minor
> Attachments: SOLR-13807-benchmarks.tgz, 
> SOLR-13807__SOLR-13132_test_stub.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Solr does not have a facet count cache; so for _every_ request, term facets 
> are recalculated for _every_ (facet) field, by iterating over _every_ field 
> value for _every_ doc in the result domain, and incrementing the associated 
> count.
> As a result, subsequent requests end up redoing a lot of the same work, 
> including all associated object allocation, GC, etc. This situation could 
> benefit from integrated caching.
> Because of the domain-based, serial/iterative nature of term facet 
> calculation, latency is proportional to the size of the result domain. 
> Consequently, one common/clear manifestation of this issue is high latency 
> for faceting over an unrestricted domain (e.g., {{\*:\*}}), as might be 
> observed on a top-level landing page that exposes facets. This type of 
> "static" case is often mitigated by external (to Solr) caching, either with a 
> caching layer between Solr and a front-end application, or within a front-end 
> application, or even with a caching layer between the end user and a 
> front-end application.
> But in addition to the overhead of handling this caching elsewhere in the 
> stack (or, for a new user, even being aware of this as a potential issue to 
> mitigate), any external caching mitigation is really only appropriate for 
> relatively static cases like the "landing page" example described above. A 
> Solr-internal facet count cache (analogous to the {{filterCache}}) would 
> provide the following additional benefits:
>  # ease of use/out-of-the-box configuration to address a common performance 
> concern
>  # compact (specifically caching count arrays, without the extra baggage that 
> accompanies a naive external caching approach)
>  # NRT-friendly (could be implemented to be segment-aware)
>  # modular, capable of reusing the same cached values in conjunction with 
> variant requests over the same result domain (this would support common use 
> cases like paging, but also potentially more interesting direct uses of 
> facets). 
>  # could be used for distributed refinement (i.e., if facet counts over a 
> given domain are cached, a refinement request could simply look up the 
> ordinal value for each enumerated term and directly grab the count out of the 
> count array that was cached during the first phase of facet calculation)
>  # composable (e.g., in aggregate functions that calculate values based on 
> facet counts across different domains, like SKG/relatedness – see SOLR-13132)



--
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-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

Mike Drob commented on LUCENE-9518:
---

I found 
[https://docs.gradle.org/6.4/userguide/working_with_files.html#sec:reproducible_archives]
 which also mentions {{preserveFileTimestamps = false}}, do we have any build 
steps that expect the timestamps in our archives to be accurate or should we 
consider setting that as well? I'm not sure what it actually does - sets them 
all to zero I imagine?

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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-14851) Http2SolrClient doesn't handle keystore type correctly

2020-09-10 Thread Andras Salamon (Jira)

Andras Salamon created SOLR-14851:
-

 Summary: Http2SolrClient doesn't handle keystore type correctly
 Key: SOLR-14851
 URL: https://issues.apache.org/jira/browse/SOLR-14851
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andras Salamon


I wanted to use Solr SSL using bcfks keystore type. Even after specifying the 
following JVM properties, Solr was not able to start: 
{{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks 
-Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}

The error message in the log:

{noformat}2020-09-07 14:42:29.429 ERROR (main) [   ] o.a.s.c.SolrCore 
null:org.apache.solr.common.SolrException: Error instantiating 
shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException: 
Invalid keystore format
at 
org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
at 
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
at 
org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
at 
org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
at 
java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at 
java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
at 
java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
at 
org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
at 
org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
at 
org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
at 
org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
at 
org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
at org.eclipse.jetty.server.Server.start(Server.java:407)
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
at org.eclipse.jetty.server.Server.doStart(Server.java:371)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
at 
org.eclipse.jetty.xml.XmlConfiguration.lambda$main$0(XmlConfiguration.java:1888)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1837)
at sun.reflect.NativeMethodAccessorIm

[jira] [Updated] (SOLR-14851) Http2SolrClient doesn't handle keystore type correctly

2020-09-10 Thread Andras Salamon (Jira)



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

Andras Salamon updated SOLR-14851:
--
Status: Patch Available  (was: Open)

> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andras Salamon
>Priority: Major
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the 
> following JVM properties, Solr was not able to start: 
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks 
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [   ] o.a.s.c.SolrCore 
> null:org.apache.solr.common.SolrException: Error instantiating 
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException: 
> Invalid keystore format
> at 
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at 
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at 
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at 
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
>

[jira] [Updated] (SOLR-14851) Http2SolrClient doesn't handle keystore type correctly

2020-09-10 Thread Andras Salamon (Jira)



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

Andras Salamon updated SOLR-14851:
--
Attachment: SOLR-14851-01.patch

> Http2SolrClient doesn't handle keystore type correctly
> --
>
> Key: SOLR-14851
> URL: https://issues.apache.org/jira/browse/SOLR-14851
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andras Salamon
>Priority: Major
> Attachments: SOLR-14851-01.patch
>
>
> I wanted to use Solr SSL using bcfks keystore type. Even after specifying the 
> following JVM properties, Solr was not able to start: 
> {{-Djavax.net.ssl.keyStoreType=bcfks -Djavax.net.ssl.trustStoreType=bcfks 
> -Dsolr.jetty.truststore.type=bcfks -Dsolr.jetty.keystore.type=bcfks}}
> The error message in the log:
> {noformat}2020-09-07 14:42:29.429 ERROR (main) [   ] o.a.s.c.SolrCore 
> null:org.apache.solr.common.SolrException: Error instantiating 
> shardHandlerFactory class [HttpShardHandlerFactory]: java.io.IOException: 
> Invalid keystore format
> at 
> org.apache.solr.handler.component.ShardHandlerFactory.newInstance(ShardHandlerFactory.java:56)
> at org.apache.solr.core.CoreContainer.load(CoreContainer.java:660)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:262)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:182)
> at 
> org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:134)
> at 
> org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:751)
> at 
> java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at 
> java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:742)
> at 
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:744)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:360)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1445)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1409)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:822)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:275)
> at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:46)
> at 
> org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:188)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:513)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:154)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:173)
> at 
> org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:447)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:66)
> at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:784)
> at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:753)
> at org.eclipse.jetty.util.Scanner.scan(Scanner.java:641)
> at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:540)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:146)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:599)
> at 
> org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:249)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:72)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169)
> at org.eclipse.jetty.server.Server.start(Server.java:407)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117)
> at 
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97)
> at or

[jira] [Commented] (LUCENE-9518) Add sanity to gradle archiving tasks (predictable order, default permissions, fail on duplicates)



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

Dawid Weiss commented on LUCENE-9518:
-

I don't know what happens to these. I never had the need to use that setting 
(as opposed to those I added).

> Add sanity to gradle archiving tasks (predictable order, default permissions, 
> fail on duplicates) 
> --
>
> Key: LUCENE-9518
> URL: https://issues.apache.org/jira/browse/LUCENE-9518
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
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] dweiss commented on pull request #1844: SOLR-14847: Create Solr Server TGZ



dweiss commented on pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844#issuecomment-690364133


   I don't know. It's on master only and pretty much everything falls under 
"gradle build" umbrella. Feel free to add it if you like though!



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



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

[GitHub] [lucene-solr] dweiss merged pull request #1853: LUCENE-9519: Correct behavior for highlights that cross multi-value boundary



dweiss merged pull request #1853:
URL: https://github.com/apache/lucene-solr/pull/1853


   



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



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

[jira] [Commented] (SOLR-14820) Create replica is broken

2020-09-10 Thread Christine Poerschke (Jira)



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

Christine Poerschke commented on SOLR-14820:


Thanks for sharing that Solr and ZooKeeper are separate processes and that the 
setup uses the official docker containers!

I haven't yet myself used Solr via Docker but the following might be worth 
trying out if not already tried (irrespective of the docker use):
* Have only one Solr instance, only one instance in the entire setup that is. 
It's not how the setup would run eventually but for investigative purposes it 
would place the overseer etc. all in the same JVM process.
* The {{node}} parameter of the {{ADDREPLICA}} is documented as optional, does 
supplying or not supplying it make a difference to the success/fail outcome? 
* If logging verbosity on the sole Solr instance is increased, might there be 
something interesting to see in the logs?
* If the sole Solr instance was to not use an external ZooKeeper ensemble but 
an embedded ZooKeeper instance, does that make a difference?

> Create replica is broken
> 
>
> Key: SOLR-14820
> URL: https://issues.apache.org/jira/browse/SOLR-14820
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java), Server
>Affects Versions: 8.6, 8.5.1, 8.5.2, 8.6.1, 8.6.2
>Reporter: Thomas Wöckinger
>Priority: Critical
>
> Creating an additional replica for a collection fails because live nodes are 
> not valid



--
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] [Reopened] (SOLR-14151) Make schema components load from packages

2020-09-10 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe reopened SOLR-14151:
--

This test also started failing since the last commit in this Jira issue: 
{{FAILED:  org.apache.solr.pkg.TestPackages.classMethod}}. [Here is the first 
failure|http://example.com|https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/426/]

> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Labels: packagemanager
> Fix For: 8.7
>
>  Time Spent: 12h 40m
>  Remaining Estimate: 0h
>
> Example:
> {code:xml}
>  
> 
>   
>generateNumberParts="0" catenateWords="0"
>   catenateNumbers="0" catenateAll="0"/>
>   
>   
> 
>   
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed, 
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components 
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API



--
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] tballison opened a new pull request #1855: SOLR-14439 -- upgrade to Tika 1.24.1



tballison opened a new pull request #1855:
URL: https://github.com/apache/lucene-solr/pull/1855


   
   * https://issues.apache.org/jira/projects/SOLR/issues/SOLR-14439
   
   * SOLR-14439: Upgrade to Tika 1.24.1
   
   
   
   # Description
   
   Upgrade to Tika 1.24.1.
   
   # Solution
   
   See description.
   
   # Tests
   
   Existing unit tests pass, and I confirmed via integration tests with DIH and 
the ExtractingRequesthandler on Tika's ~700 unit test files that there are no 
surprises.  Manual integration test code is available here: 
https://github.com/tballison/tika-addons/tree/main/solr-tika-integration
   
   
   # Checklist
   This patch is against branch_8x.  Mercifully, Tika has been removed from 
master.  `ant precommit` is successful as is `ant test`.
   



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



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

[jira] [Comment Edited] (SOLR-14847) Solr packaging needs to produce server tgz for release



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

Mike Drob edited comment on SOLR-14847 at 9/10/20, 3:56 PM:


Thanks for the help on this Dawid and Houston!


was (Author: mdrob):
Thanks for the help on this David and Houston!

> Solr packaging needs to produce server tgz for release
> --
>
> Key: SOLR-14847
> URL: https://issues.apache.org/jira/browse/SOLR-14847
> 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: 4h 20m
>  Remaining Estimate: 0h
>
> We currently have a solr/packaging assemble target that creates a directory 
> of all the server contents, but we don't have any targets that would generate 
> a tgz like for releases.



--
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-14847) Solr packaging needs to produce server tgz for release

2020-09-10 Thread ASF subversion and git services (Jira)



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

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

Thanks for the help on this David and Houston!

> Solr packaging needs to produce server tgz for release
> --
>
> Key: SOLR-14847
> URL: https://issues.apache.org/jira/browse/SOLR-14847
> 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: 4h 20m
>  Remaining Estimate: 0h
>
> We currently have a solr/packaging assemble target that creates a directory 
> of all the server contents, but we don't have any targets that would generate 
> a tgz like for releases.



--
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-14847) Solr packaging needs to produce server tgz for release



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

ASF subversion and git services commented on SOLR-14847:


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

SOLR-14847: Create Solr Server TGZ (#1844)

Create new targets for building solr binary release artifacts:

gradlew -p solr/packaging distTar distZip

Co-authored-by: Houston Putman 
Co-authored-by: Dawid Weiss 
Co-authored-by: Mike Drob 

> Solr packaging needs to produce server tgz for release
> --
>
> Key: SOLR-14847
> URL: https://issues.apache.org/jira/browse/SOLR-14847
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mike Drob
>Priority: Major
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> We currently have a solr/packaging assemble target that creates a directory 
> of all the server contents, but we don't have any targets that would generate 
> a tgz like for releases.



--
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-14439) Upgrade to Tika 1.24.1

2020-09-10 Thread Tim Allison (Jira)



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

Tim Allison commented on SOLR-14439:


I'll merge the PR tomorrow (Friday ET) against {{branch_8x}} if there aren't 
any objections.

> Upgrade to Tika 1.24.1
> --
>
> Key: SOLR-14439
> URL: https://issues.apache.org/jira/browse/SOLR-14439
> Project: Solr
>  Issue Type: Task
>  Components: contrib - DataImportHandler
>Reporter: Tim Allison
>Assignee: Tim Allison
>Priority: Major
> Attachments: SOLR-14339.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We recently released 1.24.1 with several fixes for DoS vulnerabilities we 
> found via fuzzing: CVE-2020-9489 https://seclists.org/oss-sec/2020/q2/69



--
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] [Comment Edited] (LUCENE-9444) Need an API to easily fetch facet labels for a field in a document

2020-09-10 Thread Ankur (Jira)



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

Ankur edited comment on LUCENE-9444 at 9/10/20, 5:06 PM:
-

Thanks [~mikemccand]. I uploaded a new patch that incorporates the code review 
feed. The patch
 * Makes {{FacetLabelReader}} public as suggested.
 * Adds javadoc explaining why {{FacetLabelReader}} is not thread-safe.
 * Eliminates {{Iterator}} and replaces {{lookupLabels()}} methods with 
{{nextFacetLabel()}} methods that just return {{null}} if no more FacetLabels 
exist for input docId.
 * Adds {{@lucene.experimental}} to class level javadocs.
 * Enhances {{TestTaxonomyLabels.testBasic()}} method to check that fetching 
FacetLabels in decreasing docId order throws {{AssertionError.}}


was (Author: goankur):
Thanks [~mikemccand]. I uploaded a new patch that incorporates the code review 
feed. The patch
 * Makes {{FacetLabelReader}} public as suggested.
 * Adds javadoc to explaining that {{FacetLabelReader}} is not thread-safe.
 * Eliminates {{Iterator}} and replaces {{lookupLabels()}} methods with 
{{nextFacetLabel()}} methods that just return {{null}} if no more FacetLabels 
exist for input docId.
 * Adds {{@lucene.experimental}} to class level javadocs.
 * Enhances {{TestTaxonomyLabels.testBasic()}} method to check that fetching 
FacetLabels in decreasing docId order throws {{AssertionError.}}

> Need an API to easily fetch facet labels for a field in a document
> --
>
> Key: LUCENE-9444
> URL: https://issues.apache.org/jira/browse/LUCENE-9444
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Major
>  Labels: facet
> Attachments: LUCENE-9444.patch, LUCENE-9444.v2.patch
>
>
> A facet field may be included in the list of fields whose values are to be 
> returned for each hit.
> In order to get the facet labels for each hit we need to
>  # Create an instance of _DocValuesOrdinalsReader_ and invoke 
> _getReader(LeafReaderContext context)_ method to obtain an instance of 
> _OrdinalsSegmentReader()_
>  # _OrdinalsSegmentReader.get(int docID, IntsRef ordinals)_ method is then 
> used to fetch and decode the binary payload in the document's BinaryDocValues 
> field. This provides the ordinals that refer to facet labels in the 
> taxonomy.**
>  # Lastly TaxonomyReader.getPath(ord) is used to fetch the labels to be 
> returned.
>  
> Ideally there should be a simple API - *String[] getLabels(docId)* that hides 
> all the above details and gives us the string labels. This can be part of 
> *TaxonomyFacets* but that's just one idea.
> I am opening this issue to get community feedback and suggestions.
>  



--
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-9449) Skip non-competitive documents when sort by _doc with search after

2020-09-10 Thread Tomas Eduardo Fernandez Lobbe (Jira)



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

Tomas Eduardo Fernandez Lobbe commented on LUCENE-9449:
---

I didn't look at this change in detail, but there are some failures in Jenkins 
that nay be related to this commit:
{noformat}
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/27938/
Java: 64bit/jdk-11.0.6 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.testSameHitsAsPointRangeQuery

Error Message:
java.lang.AssertionError

Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([1BAE2B7423173E7C:20AD3790C6015356]:0)
at 
org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:195)
at 
org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:240)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:254)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:211)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:71)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:741)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:72)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:528)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:657)
at 
org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:638)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:559)
at 
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.assertSameHits(TestIndexSortSortedNumericDocValuesRangeQuery.java:87)
at 
org.apache.lucene.search.TestIndexSortSortedNumericDocValuesRangeQuery.testSameHitsAsPointRangeQuery(TestIndexSortSortedNumericDocValuesRangeQuery.java:76)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomized

[jira] [Commented] (SOLR-14510) Remove deprecations added with the BlockMax WAND support

2020-09-10 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-14510:


Commit 02509788692909b2e1efc24218714bef76423b43 in lucene-solr's branch 
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0250978 ]

SOLR-14510: Remove deprecations added with BlockMax WAND support (#1823)



> Remove deprecations added with the BlockMax WAND support
> 
>
> Key: SOLR-14510
> URL: https://issues.apache.org/jira/browse/SOLR-14510
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'd like to remove some of the deprecations added by the work in SOLR-132899. 



--
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] tflobbe merged pull request #1823: SOLR-14510: Remove deprecations added with BlockMax WAND support



tflobbe merged pull request #1823:
URL: https://github.com/apache/lucene-solr/pull/1823


   



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



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

[jira] [Commented] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after



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

Mayya Sharipova commented on LUCENE-9449:
-

[~tflobbe]

Thanks for informing me about this, and sorry for the trouble.

I am working on fixing these test failures.

> Skip non-competitive documents when sort by _doc with search after
> --
>
> Key: LUCENE-9449
> URL: https://issues.apache.org/jira/browse/LUCENE-9449
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> Enhance DocComparator to provide an iterator over competitive documents when 
> search ing with "after" FieldDoc.
> This iterator can quickly position on the desired "after" document, and skip 
> all documents or even segments that contain documents before "after"
> This is especially efficient when "after" is high.
>  
> Related to LUCENE-9280



--
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 a change in pull request #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture



dsmiley commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r486536304



##
File path: solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java
##
@@ -260,18 +260,13 @@ public final T process(SolrClient client) throws 
SolrServerException, IOExceptio
   public final CompletableFuture processAsynchronously(SolrClient client, 
String collection) {
 final long startNanos = System.nanoTime();
 final CompletableFuture> internalFuture = 
client.requestAsync(this, collection);
-final CompletableFuture apiFuture = new CompletableFuture<>();
-
-internalFuture.whenComplete((result, error) -> {
-  if (!internalFuture.isCompletedExceptionally()) {
-T res = createResponse(client);
-res.setResponse(result);
-long endNanos = System.nanoTime();
-res.setElapsedTime(TimeUnit.NANOSECONDS.toMillis(endNanos - 
startNanos));
-apiFuture.complete(res);
-  } else {
-apiFuture.completeExceptionally(error);
-  }
+
+final CompletableFuture apiFuture = internalFuture.thenApply((result) 
-> {

Review comment:
   What if internalFuture completes exceptionally?





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



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

[jira] [Commented] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after



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

Mayya Sharipova commented on LUCENE-9449:
-

The test failure would be fixed by this PR: 
https://github.com/apache/lucene-solr/pull/1833

> Skip non-competitive documents when sort by _doc with search after
> --
>
> Key: LUCENE-9449
> URL: https://issues.apache.org/jira/browse/LUCENE-9449
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> Enhance DocComparator to provide an iterator over competitive documents when 
> search ing with "after" FieldDoc.
> This iterator can quickly position on the desired "after" document, and skip 
> all documents or even segments that contain documents before "after"
> This is especially efficient when "after" is high.
>  
> Related to LUCENE-9280



--
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] [Comment Edited] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after



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

Mayya Sharipova edited comment on LUCENE-9449 at 9/10/20, 6:42 PM:
---

The test failure would be fixed by this PR: 
[https://github.com/apache/lucene-solr/pull/1833]

once it is merged.


was (Author: mayyas):
The test failure would be fixed by this PR: 
https://github.com/apache/lucene-solr/pull/1833

> Skip non-competitive documents when sort by _doc with search after
> --
>
> Key: LUCENE-9449
> URL: https://issues.apache.org/jira/browse/LUCENE-9449
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 4h 40m
>  Remaining Estimate: 0h
>
> Enhance DocComparator to provide an iterator over competitive documents when 
> search ing with "after" FieldDoc.
> This iterator can quickly position on the desired "after" document, and skip 
> all documents or even segments that contain documents before "after"
> This is especially efficient when "after" is high.
>  
> Related to LUCENE-9280



--
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] thelabdude commented on pull request #1845: SOLR-14613: Autoscaling replacement using placement plugins



thelabdude commented on pull request #1845:
URL: https://github.com/apache/lucene-solr/pull/1845#issuecomment-690613460


   Building on @noblepaul 's concern, I do think we need to reconcile the newly 
added interfaces in the `org.apache.solr.cluster.api` package (under solrj) 
with the very similar interfaces in the `org.apache.solr.cluster.placement` 
package added in this PR. I do realize the `org.apache.solr.cluster.api` 
package was introduced while the work on this PR was already underway. My 
intent here is to move forward with a plan we’re all comfortable with and not 
rehash the past.
   
   To recap my understanding from the previous PR comments, the intent of 
having the Node, SolrCollection, Shard, Replica interfaces in 
`org.apache.solr.cluster.placement` is to avoid exposing SolrCloud internals to 
the plugin writer.
   
   While I agree that is a laudable goal in general esp. for plugins, this 
particular framework actually needs to have access to internal information 
about the cluster. In other words, placing replicas is a very internal (and 
core) concern. The fact we're exposing this as a pluggable implementation is 
really for operational convenience. 
   
   Moreover, I do believe implementing a placement strategy requires most of 
the metadata present in collections, shards, replicas, and nodes, so I don’t 
know if the cost of having two representations of the same domain objects in 
two different places is worth the benefit it provides? I think the community 
needs to decide this is how we want to move forward.
   
   So referring back to Ilan's stated goals:
   1. placement plugin writing is easy, 
   2. implementation for this placement API is efficient, and 
   3. plugins do not break when Solr is refactored
   
   I’d actually argue that goal #1 is subjective and hard to measure. For 
instance, do we consider the SamplePluginAffinityReplicaPlacement impl easy to 
write? It seems to require a fair amount of knowledge of how Solr’s various 
objects interact.
   
   I believe @murblanc  has done a great job with goal #2 in this PR.
   
   For goal #3, my sense is that any refactoring probably cannot break the 
interfaces defined in `org.apache.solr.cluster.api` without fundamentally 
changing the architecture of SolrCloud, which would likely break assumptions 
made in the `org.apache.solr.cluster.placement` as well.
   
   Lastly, from our slack conversation, I was only suggesting that instead of 
the plugin impl introducing the `AzWithNodes` that we simply formalize this as 
a `DataCenter` in the API, which basically does what `AzWithNodes` is doing in 
the code, not a big deal though ...
   



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



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

[GitHub] [lucene-solr] madrob merged pull request #1844: SOLR-14847: Create Solr Server TGZ

2020-09-10 Thread ASF subversion and git services (Jira)



madrob merged pull request #1844:
URL: https://github.com/apache/lucene-solr/pull/1844


   



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



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

[jira] [Commented] (LUCENE-9501) IndexSortSortedNumericDocValuesRangeQuery violates iterator invariant.



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

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

Commit 37e4dbef6d11af96e08d7c1bfe8157c2049dcc6b in lucene-solr's branch 
refs/heads/master from Julie Tibshirani
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=37e4dbe ]

LUCENE-9501: Fix invariant violation in 
IndexSortSortedNumericDocValuesRangeQuery. (#1833)

Previously the DocIdSetIterator returned an old value for docID advance
returned NO_MORE_DOCS. This violates the DocIdSetIterator contract and made it
possiblefor the iterator's advance method to be called even after it was
already exhausted.

> IndexSortSortedNumericDocValuesRangeQuery violates iterator invariant.
> --
>
> Key: LUCENE-9501
> URL: https://issues.apache.org/jira/browse/LUCENE-9501
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In LUCENE-7714 we added a new query to sandbox called 
> IndexSortSortedNumericDocValuesRangeQuery that optimizes range calculations 
> when the field is sorted. The query has a bad bug: its DocIdSetIterator can 
> return an old value for docID() even after advance has returned NO_MORE_DOCS. 
> This violates the DocIdSetIterator contract and means that it's possible for 
> DocIdSetIterator#advance to be called when it's already been exhausted (which 
> can result in invalid reads).
> We would have expected this issue to be caught in tests, especially because 
> classes like AssertingIndexSearcher check for these invariants. As part of 
> this fix I'll look into improvements to the Asserting* wrapper framework.



--
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 merged pull request #1833: LUCENE-9501: Fix invariant violation in IndexSortSortedNumericDocValuesRangeQuery.



mayya-sharipova merged pull request #1833:
URL: https://github.com/apache/lucene-solr/pull/1833


   



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



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

[GitHub] [lucene-solr] mayya-sharipova opened a new pull request #1856: LUCENE-9449 Skip docs with _doc sort and "after" (#1725)



mayya-sharipova opened a new pull request #1856:
URL: https://github.com/apache/lucene-solr/pull/1856


   - Enhance DocComparator to provide an iterator over competitive
   documents when searching with "after". This iterator can quickly position
   on the desired "after" document skipping all documents and segments before
   "after".
   
   - Redesign numeric comparators to provide skipping functionality
   by default.
   
   Backport for #LUCENE-9449



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



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

[GitHub] [lucene-solr] mayya-sharipova commented on pull request #1856: LUCENE-9449 Skip docs with _doc sort and "after" (#1725)



mayya-sharipova commented on pull request #1856:
URL: https://github.com/apache/lucene-solr/pull/1856#issuecomment-690635209


   @jimczi  This is a backport for 
https://github.com/apache/lucene-solr/pull/1725. Not sure if you would like to 
review it, or I can just merge it.



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



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

[jira] [Commented] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after



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

Mayya Sharipova commented on LUCENE-9449:
-

[https://github.com/apache/lucene-solr/pull/1833] has been merged, and the test 
doesn't fail anymore

> Skip non-competitive documents when sort by _doc with search after
> --
>
> Key: LUCENE-9449
> URL: https://issues.apache.org/jira/browse/LUCENE-9449
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> Enhance DocComparator to provide an iterator over competitive documents when 
> search ing with "after" FieldDoc.
> This iterator can quickly position on the desired "after" document, and skip 
> all documents or even segments that contain documents before "after"
> This is especially efficient when "after" is high.
>  
> Related to LUCENE-9280



--
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] (LUCENE-9449) Skip non-competitive documents when sort by _doc with search after



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

Mayya Sharipova resolved LUCENE-9449.
-
Resolution: Fixed

> Skip non-competitive documents when sort by _doc with search after
> --
>
> Key: LUCENE-9449
> URL: https://issues.apache.org/jira/browse/LUCENE-9449
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mayya Sharipova
>Priority: Minor
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> Enhance DocComparator to provide an iterator over competitive documents when 
> search ing with "after" FieldDoc.
> This iterator can quickly position on the desired "after" document, and skip 
> all documents or even segments that contain documents before "after"
> This is especially efficient when "after" is high.
>  
> Related to LUCENE-9280



--
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-14847) Solr packaging needs to produce server tgz for release

2020-09-10 Thread ASF subversion and git services (Jira)



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

Dawid Weiss commented on SOLR-14847:


You're very welcome. Thank you for being patient with my build neoclassicism... 
David ~= Dawid (although [~dsmiley] may object) - Polish doesn't have the 'v' 
letter (we have diacritics; yes, it is complicated).

> Solr packaging needs to produce server tgz for release
> --
>
> Key: SOLR-14847
> URL: https://issues.apache.org/jira/browse/SOLR-14847
> 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: 4.5h
>  Remaining Estimate: 0h
>
> We currently have a solr/packaging assemble target that creates a directory 
> of all the server contents, but we don't have any targets that would generate 
> a tgz like for releases.



--
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-9501) IndexSortSortedNumericDocValuesRangeQuery violates iterator invariant.



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

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

Commit a1d460b27c525a526ff0928cb2454571c1fbf91f in lucene-solr's branch 
refs/heads/branch_8x from Julie Tibshirani
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a1d460b ]

LUCENE-9501: Fix invariant violation in 
IndexSortSortedNumericDocValuesRangeQuery. (#1833)

Previously the DocIdSetIterator returned an old value for docID advance
returned NO_MORE_DOCS. This violates the DocIdSetIterator contract and made it
possiblefor the iterator's advance method to be called even after it was
already exhausted.

> IndexSortSortedNumericDocValuesRangeQuery violates iterator invariant.
> --
>
> Key: LUCENE-9501
> URL: https://issues.apache.org/jira/browse/LUCENE-9501
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In LUCENE-7714 we added a new query to sandbox called 
> IndexSortSortedNumericDocValuesRangeQuery that optimizes range calculations 
> when the field is sorted. The query has a bad bug: its DocIdSetIterator can 
> return an old value for docID() even after advance has returned NO_MORE_DOCS. 
> This violates the DocIdSetIterator contract and means that it's possible for 
> DocIdSetIterator#advance to be called when it's already been exhausted (which 
> can result in invalid reads).
> We would have expected this issue to be caught in tests, especially because 
> classes like AssertingIndexSearcher check for these invariants. As part of 
> this fix I'll look into improvements to the Asserting* wrapper framework.



--
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-14417) Gradle build sometimes fails RE BlockPoolSlice

2020-09-10 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-14417:


Commit ed930f4b29f473dd3e7e72d099d086a9c81f71d7 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed930f4 ]

SOLR-14417: Gradle build sometimes fails RE BlockPoolSlice (#1854)

* SOLR-14417: workaround the compiler scope problem.

* Make the list modifiable.

> Gradle build sometimes fails RE BlockPoolSlice
> --
>
> Key: SOLR-14417
> URL: https://issues.apache.org/jira/browse/SOLR-14417
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There seems to be some package visibility hacks around our Hdfs integration:
> {{/Users/dsmiley/SearchDev/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:125:
>  error: BlockPoolSlice is not public in 
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed 
> from outside package}}
> {{List> modifiedHadoopClasses = Arrays.asList(BlockPoolSlice.class, 
> DiskChecker.class,}}
> This happens on my Gradle build when running {{gradlew testClasses}} (i.e. to 
> compile tests) but Ant proceeded without issue.  The work-around is to run 
> {{gradlew clean}} first but really I want our build to be smarter here.
> CC [~krisden]



--
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-14417) Gradle build sometimes fails RE BlockPoolSlice

2020-09-10 Thread ASF subversion and git services (Jira)



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

ASF subversion and git services commented on SOLR-14417:


Commit ed930f4b29f473dd3e7e72d099d086a9c81f71d7 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed930f4 ]

SOLR-14417: Gradle build sometimes fails RE BlockPoolSlice (#1854)

* SOLR-14417: workaround the compiler scope problem.

* Make the list modifiable.

> Gradle build sometimes fails RE BlockPoolSlice
> --
>
> Key: SOLR-14417
> URL: https://issues.apache.org/jira/browse/SOLR-14417
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There seems to be some package visibility hacks around our Hdfs integration:
> {{/Users/dsmiley/SearchDev/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:125:
>  error: BlockPoolSlice is not public in 
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed 
> from outside package}}
> {{List> modifiedHadoopClasses = Arrays.asList(BlockPoolSlice.class, 
> DiskChecker.class,}}
> This happens on my Gradle build when running {{gradlew testClasses}} (i.e. to 
> compile tests) but Ant proceeded without issue.  The work-around is to run 
> {{gradlew clean}} first but really I want our build to be smarter here.
> CC [~krisden]



--
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-14417) Gradle build sometimes fails RE BlockPoolSlice



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

Dawid Weiss resolved SOLR-14417.

Fix Version/s: master (9.0)
 Assignee: Dawid Weiss
   Resolution: Fixed

> Gradle build sometimes fails RE BlockPoolSlice
> --
>
> Key: SOLR-14417
> URL: https://issues.apache.org/jira/browse/SOLR-14417
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There seems to be some package visibility hacks around our Hdfs integration:
> {{/Users/dsmiley/SearchDev/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:125:
>  error: BlockPoolSlice is not public in 
> org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed 
> from outside package}}
> {{List> modifiedHadoopClasses = Arrays.asList(BlockPoolSlice.class, 
> DiskChecker.class,}}
> This happens on my Gradle build when running {{gradlew testClasses}} (i.e. to 
> compile tests) but Ant proceeded without issue.  The work-around is to run 
> {{gradlew clean}} first but really I want our build to be smarter here.
> CC [~krisden]



--
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] moisheschwartz opened a new pull request #1857: Update json-faceting-domain-changes.adoc



moisheschwartz opened a new pull request #1857:
URL: https://github.com/apache/lucene-solr/pull/1857


   Added missing word
   
   
   
   
   # Description
   
   Added a missing word.
   
   # Solution
   
   Added the word.
   
   # Tests
   
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] 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)
   - [x] I have developed this patch against the `master` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] 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



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

[jira] [Created] (SOLR-14852) SolrZkResourceLoader.openResource should not throw an NPE for empty znodes

2020-09-10 Thread Erick Erickson (Jira)

Erick Erickson created SOLR-14852:
-

 Summary: SolrZkResourceLoader.openResource should not throw an NPE 
for empty znodes
 Key: SOLR-14852
 URL: https://issues.apache.org/jira/browse/SOLR-14852
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Erick Erickson


I'm looking at why TestBulkSchemaConcurrent fails so often lately and ran 
across this.

SolrZkResourceLoader.openResource has this code:
{code:java}
  try {
if (zkController.pathExists(file)) {
  Stat stat = new Stat();
  byte[] bytes = zkController.getZkClient().getData(file, null, stat, 
true);
  return new ZkByteArrayInputStream(bytes, stat);
{code}
new ZkByteArrayInputStream eventually winds up at:
{code:java}
public ByteArrayInputStream(byte buf[]) {
this.buf = buf;
this.pos = 0;
this.count = buf.length; // throws an NPE
}
{code}
I don't think this is the root cause of the test failure at all since this is 
caught like this:
{code:java}
  protected NamedList loadConfigSetFlags(CoreDescriptor cd, SolrResourceLoader 
loader) {
try {
  return ConfigSetProperties.readFromResourceLoader(loader, ".");
} catch (Exception ex) {
  log.debug("No configSet flags", ex);
  return null;
}
  }
{code}
That said, it seems wrong to count on an obscure constructor to generate an 
NPE, then catch all exceptions and return null...



--
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-13645) Add analytics function to format/extract components from dates

2020-09-10 Thread Houston Putman (Jira)



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

Houston Putman commented on SOLR-13645:
---

Hey [~nealsidhwaney], thank you for the contribution! I'm so sorry that this 
hasn't been acknowledged or reviewed yet. I'll take a look a deeper look at it 
and get back to you.

My initial thoughts are that it is very clean and fits nicely in with the rest 
of the contrib. The addition of the tests and docs is great too.

> Add analytics function to format/extract components from dates
> --
>
> Key: SOLR-13645
> URL: https://issues.apache.org/jira/browse/SOLR-13645
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>Priority: Minor
> Attachments: SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch
>
>
> It's helpful when running analytics to be able to do manipulation on dates 
> such as extracting month/day/year, converting to th week of year, etc, and 
> other formatting as many existing libraries provide.  I have a patch going 
> through final testing that will add this to the analytcs library.
> One thing I'm sort of amibvialent about is that it exposes that we use Java 
> date parsing in the analytics function, because the syntax is the same format 
> string that SimpleDateFormat accepts.  Ideally there would be an abstraction 
> between the analytics language and what's used on the backend to implement 
> it.  On the other hand, implementing a syntax for time/date formatting is 
> something that's been done many many times before, and this is not the only 
> place where Java date particulars show through.  It would be good to revisit 
> this at a later time.
>  
>  
>  



--
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] thelabdude edited a comment on pull request #1845: SOLR-14613: Autoscaling replacement using placement plugins



thelabdude edited a comment on pull request #1845:
URL: https://github.com/apache/lucene-solr/pull/1845#issuecomment-690613460


   Building on @noblepaul 's concern, I do think we need to reconcile the newly 
added interfaces in the `org.apache.solr.cluster.api` package (under solrj) 
with the very similar interfaces in the `org.apache.solr.cluster.placement` 
package added in this PR. I do realize the `org.apache.solr.cluster.api` 
package was introduced while the work on this PR was already underway. My 
intent here is to move forward with a plan we’re all comfortable with and not 
rehash the past.
   
   To recap my understanding from the previous PR comments, the intent of 
having the Node, SolrCollection, Shard, Replica interfaces in 
`org.apache.solr.cluster.placement` is to avoid exposing SolrCloud internals to 
the plugin writer.
   
   While I agree that is a laudable goal in general esp. for plugins, this 
particular framework actually needs to have access to internal information 
about the cluster. In other words, placing replicas is a very internal (and 
core) concern. The fact we're exposing this as a pluggable implementation is 
really for operational convenience. 
   
   Moreover, I do believe implementing a placement strategy requires most of 
the metadata present in collections, shards, replicas, and nodes, so I don’t 
know if the cost of having two representations of the same domain objects in 
two different places is worth the benefit it provides? I think the community 
needs to decide this is how we want to move forward.
   
   So referring back to Ilan's stated goals:
   1. placement plugin writing is easy, 
   2. implementation for this placement API is efficient, and 
   3. plugins do not break when Solr is refactored
   
   I’d actually argue that goal `#1` is subjective and hard to measure. For 
instance, do we consider the SamplePluginAffinityReplicaPlacement impl easy to 
write? It seems to require a fair amount of knowledge of how Solr’s various 
objects interact.
   
   I believe @murblanc  has done a great job with goal `#2` in this PR.
   
   For goal `#3`, my sense is that any refactoring probably cannot break the 
interfaces defined in `org.apache.solr.cluster.api` without fundamentally 
changing the architecture of SolrCloud, which would likely break assumptions 
made in the `org.apache.solr.cluster.placement` as well.
   
   Lastly, from our slack conversation, I was only suggesting that instead of 
the plugin impl introducing the `AzWithNodes` that we simply formalize this as 
a `DataCenter` in the API, which basically does what `AzWithNodes` is doing in 
the code, not a big deal though ...
   



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



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

[GitHub] [lucene-solr] murblanc commented on pull request #1845: SOLR-14613: Autoscaling replacement using placement plugins



murblanc commented on pull request #1845:
URL: https://github.com/apache/lucene-solr/pull/1845#issuecomment-690736516


   Thanks @thelabdude  for your long and useful comment. Let me try to give my 
take on this.
   
   By saying writing plugins should be easy in point 1, I meant the boilerplate 
code should not get in the way and force more code lines than really necessary. 
It's the ability to write for example things such as `for (Replica replica : 
shard.replicas())`, `Collections.shuffle(nodes, new Random())` and 
`replica.getShard().getState()`. Such compact statements do not require any 
explanation and are natural for any Java programmer.
   
   My thinking is that once the interfaces in 
`org.apache.solr.cluster.placement` are understood, given an understanding of 
the corresponding _concepts_ in Solr, writing a placement plugin is relatively 
accessible. If you look at `SamplePluginAffinityReplicaPlacement`, most of the 
complexity is not Solr related but for implementing the _business logic_ of the 
placement decisions (sorting, filtering etc).
   
   For point 2 I didn't want the API to get in the way of efficiency. The 
current implementation of the API is definitely not optimized (no 
multithreading etc) but this can be changed without impact on the API or on 
existing plugins. I believe we reached a good place. I too prefer how the 
attribute fetching looks now (@noblepaul's contribution) than what I initially 
proposed.
   
   Point 3 is very important. Any internal Solr interface is relatively easy to 
change, we have the code using it and adapt it as the interface is modified. 
Once we start handing these interfaces to external code (external to the 
lucene-solr github repo really), then changing (or not changing) them is a lot 
more complex and painful.
   
   My assumption here is that placement code might be implemented by outside 
users to suit their specific needs, and that code might not be contributed back 
to the project (as opposed to the plugin I wrote and that will be the default 
one and a possible starting point for custom ones). Therefore, we want to be 
able to maintain these interfaces unchanged even if internal implementation 
changes. Of course if internal _concepts_ change then the interfaces will 
likely have to change. For example if the notion of shard leader goes away 
(imagine...) then of course that part of the API (be it defined on the 
`Replica` or on the `Shard`) doesn't really make sense anymore.
   
   Take as example the ongoing discussions about configuration. The plugin 
writer should not have to change the code based on how and where we decide 
placement plugin configuration should live.
   
   Last, the cluster abstractions for the placement plugins do not necessarily 
represent the existing cluster! In the initial (current) proposal they do (see 
`SimpleClusterAbstractionsImpl`), but soon we'll want to provide a forward view 
of how the cluster will (likely) look after known past assignment decisions are 
applied (these things are quite slow to happen due to the structure of 
`Overseer`). We had a similar separate mechanism in Autoscaling in 8x (the 
notion of `Session`), here we can keep the plugin writer completely agnostic of 
that fact, and placement decisions will simply become better (esp. under high 
load) once we change the internal implementation. This is to say the interfaces 
should really focus on the _concepts_ at play and not the current internal 
implementation of these concepts, as the implementations of these interfaces 
will drift away from their internal counterparts quite soon.
   If we want to recreate a simulation environment, focusing on concepts rather 
than implementation simplifies things a lot as well. I guess everybody agrees 
on the last points made though.
   
   All this being said, it would be better to unify cluster abstractions (and 
possibly other abstractions) that are to be used by external code and have a 
single set of abstractions (interfaces). External uses of such interfaces 
include placement code (this PR), event processing (see 
[SOLR-14749](https://issues.apache.org/jira/browse/SOLR-14749)) and possibly 
other external code that needs to interact with the cluster. The interfaces 
defined here were used to write the plugin, and were changed in the process to 
simplify the plugin code. I believe if we make them evolve to adapt to event 
processing we'll have a pretty good coverage of potential uses.



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



-
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 #1769: SOLR-14789: Absorb the docker-solr repo.



madrob commented on a change in pull request #1769:
URL: https://github.com/apache/lucene-solr/pull/1769#discussion_r486650047



##
File path: solr/docker/build.gradle
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+plugins {
+  id "base"
+  id "com.palantir.docker" version "0.25.0"

Review comment:
   I think our convention is to declare the plugin version in 
`build.gradle` with `apply false`

##
File path: solr/docker/package/Dockerfile.local-package
##
@@ -0,0 +1,5 @@
+ARG BASE_IMAGE=alpine:3.12

Review comment:
   I'm confused why we need this as an intermediate docker image containing 
just the tgz? Also, why make this configurable and why not `FROM scratch`?





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



-
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 pull request #1769: SOLR-14789: Absorb the docker-solr repo.



madrob commented on pull request #1769:
URL: https://github.com/apache/lucene-solr/pull/1769#issuecomment-690751069


   Overall looks good, just a pair of minor questions/comments.



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



-
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 #1769: SOLR-14789: Absorb the docker-solr repo.



madrob commented on a change in pull request #1769:
URL: https://github.com/apache/lucene-solr/pull/1769#discussion_r486650047



##
File path: solr/docker/build.gradle
##
@@ -0,0 +1,94 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+plugins {
+  id "base"
+  id "com.palantir.docker" version "0.25.0"

Review comment:
   I think our convention is to declare the plugin version in root 
`build.gradle` with `apply 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



-
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 #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture



dsmiley commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r486657172



##
File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -862,15 +1011,32 @@ public RouteException(ErrorCode errorCode, 
NamedList throwables, Map<
 }
 List inputCollections =
 collection == null ? Collections.emptyList() : 
StrUtils.splitSmart(collection, ",", true);
-return requestWithRetryOnStaleState(request, 0, inputCollections);
+
+CompletableFuture> apiFuture = new CompletableFuture<>();
+final AtomicReference>> currentFuture 
= new AtomicReference<>();
+apiFuture.exceptionally((error) -> {
+  if (apiFuture.isCancelled()) {
+currentFuture.get().cancel(true);
+  }
+  return null;
+});
+
+requestWithRetryOnStaleState(request, 0, inputCollections, isAsyncRequest, 
apiFuture, currentFuture);
+
+return apiFuture;
   }
 
   /**
* As this class doesn't watch external collections on the client side,
* there's a chance that the request will fail due to cached stale state,
* which means the state must be refreshed from ZK and retried.
*/
-  protected NamedList 
requestWithRetryOnStaleState(@SuppressWarnings({"rawtypes"})SolrRequest 
request, int retryCount, List inputCollections)
+  protected void requestWithRetryOnStaleState(SolrRequest request,

Review comment:
   This method signature has become too hard to understand.  Taking both a 
CompletableFuture "apiFuture" and AtomicReference to a CF "currentFuture" is 
too complicated.  Can you please devise some other scheme?  Just one 
CompletableFuture, or perhaps return the CF if that's sensible.  I'm sure you 
had your reasons, but the complexity factor for me is just too high.
   
   You might also consider changing the retry approach to switch from 
recursion, to a special exception with a retryCount so the caller can do the 
retry.  I'm just throwing this out there as an idea that _might_ make the 
overall code easier to understand -- not sure.

##
File path: 
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -926,136 +1092,191 @@ public RouteException(ErrorCode errorCode, 
NamedList throwables, Map<
   }
 } // else: ??? how to set this ???
 
-NamedList resp = null;
-try {
-  resp = sendRequest(request, inputCollections);
-  //to avoid an O(n) operation we always add STATE_VERSION to the last and 
try to read it from there
-  Object o = resp == null || resp.size() == 0 ? null : 
resp.get(STATE_VERSION, resp.size() - 1);
-  if(o != null && o instanceof Map) {
-//remove this because no one else needs this and tests would fail if 
they are comparing responses
-resp.remove(resp.size()-1);
-@SuppressWarnings({"rawtypes"})
-Map invalidStates = (Map) o;
-for (Object invalidEntries : invalidStates.entrySet()) {
-  @SuppressWarnings({"rawtypes"})
-  Map.Entry e = (Map.Entry) invalidEntries;
-  getDocCollection((String) e.getKey(), (Integer) e.getValue());
-}
+requestWithRetryOnStaleStateHelper(request, retryCount, inputCollections, 
requestedCollections, isAdmin,
+isAsyncRequest, apiFuture, currentFuture);
+  }
 
+  private void requestWithRetryOnStaleStateHelper(final SolrRequest request,

Review comment:
   it's not clear to me what is gained by refactoring out this method.





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



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

[jira] [Commented] (SOLR-13645) Add analytics function to format/extract components from dates

2020-09-10 Thread Neal Sidhwaney (Jira)



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

Neal Sidhwaney commented on SOLR-13645:
---

Thanks Houston, I appreciate the kind comments and review.  I think before you 
spend any more time on this, it's probably worth it to also look at 
https://issues.apache.org/jira/browse/SOLR-13931, which I found after I pinged 
this issue.  Since that points to a deprecation of analytics, I'd rather not 
use yours and the projects time if it ends up being removed! It's not a big 
deal to me either way.  Thanks again.

 

Neal

> Add analytics function to format/extract components from dates
> --
>
> Key: SOLR-13645
> URL: https://issues.apache.org/jira/browse/SOLR-13645
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 8.1.1
>Reporter: Neal Sidhwaney
>Priority: Minor
> Attachments: SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch, 
> SOLR-13645-Analytics-function-for-date-components.patch
>
>
> It's helpful when running analytics to be able to do manipulation on dates 
> such as extracting month/day/year, converting to th week of year, etc, and 
> other formatting as many existing libraries provide.  I have a patch going 
> through final testing that will add this to the analytcs library.
> One thing I'm sort of amibvialent about is that it exposes that we use Java 
> date parsing in the analytics function, because the syntax is the same format 
> string that SimpleDateFormat accepts.  Ideally there would be an abstraction 
> between the analytics language and what's used on the backend to implement 
> it.  On the other hand, implementing a syntax for time/date formatting is 
> something that's been done many many times before, and this is not the only 
> place where Java date particulars show through.  It would be good to revisit 
> this at a later time.
>  
>  
>  



--
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] dweiss merged pull request #1854: SOLR-14417: Gradle build sometimes fails RE BlockPoolSlice



dweiss merged pull request #1854:
URL: https://github.com/apache/lucene-solr/pull/1854


   



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



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

[jira] [Commented] (SOLR-14776) Precompute the fingerprint during PeerSync

2020-09-10 Thread Cao Manh Dat (Jira)



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

Cao Manh Dat commented on SOLR-14776:
-

> Is there a chance that the core is changing between subsequent calls and so 
> it is not safe to use the same, maybe from incoming updates?

During leader election there shouldn't be any updates coming from the old 
leader (we are not doing anything to prevent that), if there are the current 
fingerprint strategy's here is also fail

>  It looks like there is already caching on SolrCore.getIndexFingerprint, is 
>that broken or insufficient in some way?

Yeah, but we only compute fingerprint during leader election. Therefore after a 
very heavy indexing, then the leader goes away the first call to fingerprint 
gonna takes awhile then slowdown the leader election

>  Thinking about this more, is the big win that we compute our own fingerprint 
>during the time that would normally be spent waiting, and we decrease latency 
>that way?

This can be a way to do that, another solution here is on commit the segment we 
already compute fingerprint for that segment, but I think it is worth to do in 
another issue.

> Precompute the fingerprint during PeerSync
> --
>
> Key: SOLR-14776
> URL: https://issues.apache.org/jira/browse/SOLR-14776
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Computing fingerprint can very costly and take time. But the current 
> implementation will send requests for getting fingerprint for multiple 
> replicas, then on the first response it will then compute its own fingerprint 
> for comparison. A very simple but effective improvement here is compute its 
> own fingerprint right after send requests to other replicas.



--
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-13931) Decommission Analytics component/handler

2020-09-10 Thread David Smiley (Jira)



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

David Smiley commented on SOLR-13931:
-

I asked about this on the dev list recently before knowing about this issue.  
It was suggested we better understand if it's being used at all, say besides 
one user/company any way.  So I asked on the users list:
https://lists.apache.org/thread.html/r96b1ea3b7f50fe1850e3cbb82503542dd4fa63be50faa5cf129832b5%40%3Csolr-user.lucene.apache.org%3E
Not sure how long to wait.  I'll write a dev list post about trying to improve 
how we go about ascertaining who uses our features.

> Decommission Analytics component/handler
> 
>
> Key: SOLR-13931
> URL: https://issues.apache.org/jira/browse/SOLR-13931
> Project: Solr
>  Issue Type: Improvement
>  Components: SearchComponents - other
>Reporter: Mikhail Khludnev
>Priority: Major
>
> Spin off from SOLR-13904 discussion. 
> let's:
> # Deprecate the analytics component
> # Make a migration path to JSON Facets
> # Make sure that JSON Facets has all of the necessary functionality (median, 
> unique, percentile, etc.)
> # Have analytics queries be converted to json facets, and computed that way.
> # Remove the Analytics Component backend
> # Down the road stop supporting analytics component requests all together 
> (Make users switch to json facets themselves)



--
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-14853) Make enableRemoteStreaming option global; not configSet

2020-09-10 Thread David Smiley (Jira)

David Smiley created SOLR-14853:
---

 Summary: Make enableRemoteStreaming option global; not configSet
 Key: SOLR-14853
 URL: https://issues.apache.org/jira/browse/SOLR-14853
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley


The {{enableRemoteStreaming}} option is a security risk, and so it's off by 
default.
https://lucene.apache.org/solr/guide/8_6/content-streams.html
It seems strange that an option like this is declared in solrconfig.xml (a part 
of the configSet) instead of being a global option.  For example 
{{enable.dih.dataConfigParam}} is a System property.  I think it's a bit of a 
stretch to want only some configSets to use this but not others.



--
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-14701) Deprecate Schemaless Mode (Discussion)

2020-09-10 Thread David Smiley (Jira)



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

David Smiley commented on SOLR-14701:
-

bq. Or we really demote it to example schema and explain how it works so people 
manually include those processes in their own design.

+1.  Each URP can be used as the user needs/wants.  Use them all in a POC using 
the example schema, perhaps.

> Deprecate Schemaless Mode (Discussion)
> --
>
> Key: SOLR-14701
> URL: https://issues.apache.org/jira/browse/SOLR-14701
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Marcus Eagan
>Priority: Major
> Attachments: image-2020-08-04-01-35-03-075.png
>
>
> I know this won't be the most popular ticket out there, but I am growing more 
> and more sympathetic to the idea that we should rip many of the freedoms out 
> that cause users more harm than not. One of the freedoms I saw time and time 
> again to cause issues was schemaless mode. It doesn't work as named or 
> documented, so I think it should be deprecated. 
> If you use it in production reliably and in a way that cannot be accomplished 
> another way, I am happy to hear from more knowledgeable folks as to why 
> deprecation is a bad idea. 



--
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] PuneethBikkumanla opened a new pull request #1858: LUCENE-6744: initial fix to few files untested

PuneethBikkumanla opened a new pull request #1858:
URL: https://github.com/apache/lucene-solr/pull/1858

# Description

Hey everyone! This is my first PR.

In this PR, I am addressing the concern of the original ticket that the
equals method is asymmetrically comparing two objects. I currently changed some
of the files requested in the ticket but will go ahead and change the rest once
I know I'm on the right path.

Also, am currently figuring out how/where to add documentation changes to
the Ref Guide regarding this PR.

# Solution

Instead of using `instanceOf` I used `getClass` in the `equals` method as
described in the original Jira ticket

# Tests

Please describe the tests you've developed or run to confirm this patch
implements the feature or solves the problem.

Currently I have not added any tests to verify this change as the existing
tests that I found for these classes do not make it easy to test this. I just
wanted to open up a PR to check whether I'm on the right track and for some
help on figuring out where/how I could test these changes.

# Checklist

Please review the following and check all that apply:

- [x] 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.
- [x] 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)
- [x] I have developed this patch against the `master` branch.
- [x] I have run `./gradlew check`.
- [ ] 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

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

[GitHub] [lucene-solr] noblepaul merged pull request #1852: propegate() to propagate()