[jira] [Commented] (SOLR-14347) Autoscaling placement wrong when concurrent replica placements are calculated

2020-03-24 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14347:


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

SOLR-14347: Autoscaling placement wrong when concurrent replica placements are 
calculated.


> Autoscaling placement wrong when concurrent replica placements are calculated
> -
>
> Key: SOLR-14347
> URL: https://issues.apache.org/jira/browse/SOLR-14347
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 8.5
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-14347.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Steps to reproduce:
>  * create a cluster of a few nodes (tested with 7 nodes)
>  * define per-collection policies that distribute replicas exclusively on 
> different nodes per policy
>  * concurrently create a few collections, each using a different policy
>  * resulting replica placement will be seriously wrong, causing many policy 
> violations
> Running the same scenario but instead creating collections sequentially 
> results in no violations.
> I suspect this is caused by incorrect locking level for all collection 
> operations (as defined in {{CollectionParams.CollectionAction}}) that create 
> new replica placements - i.e. CREATE, ADDREPLICA, MOVEREPLICA, DELETENODE, 
> REPLACENODE, SPLITSHARD, RESTORE, REINDEXCOLLECTION. All of these operations 
> use the policy engine to create new replica placements, and as a result they 
> change the cluster state. However, currently these operations are locked (in 
> {{OverseerCollectionMessageHandler.lockTask}} ) using 
> {{LockLevel.COLLECTION}}. In practice this means that the lock is held only 
> for the particular collection that is being modified.
> A straightforward fix for this issue is to change the locking level to 
> CLUSTER (and I confirm this fixes the scenario described above). However, 
> this effectively serializes all collection operations listed above, which 
> will result in general slow-down of all collection operations.



--
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-13884) Concurrent collection creation leads to multiple replicas placed on same node

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki reassigned SOLR-13884:
---

Assignee: Andrzej Bialecki

> Concurrent collection creation leads to multiple replicas placed on same node
> -
>
> Key: SOLR-13884
> URL: https://issues.apache.org/jira/browse/SOLR-13884
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Andrzej Bialecki
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When multiple collection creations are done concurrently with a 
> collection-level policy, multiple replicas of a single shard can end up on 
> the same node, violating the specified policy.
> This was observed on both 8.2 and master.



--
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-14347) Autoscaling placement wrong when concurrent replica placements are calculated

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki resolved SOLR-14347.
-
Fix Version/s: 8.6
   Resolution: Fixed

> Autoscaling placement wrong when concurrent replica placements are calculated
> -
>
> Key: SOLR-14347
> URL: https://issues.apache.org/jira/browse/SOLR-14347
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 8.5
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
> Attachments: SOLR-14347.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Steps to reproduce:
>  * create a cluster of a few nodes (tested with 7 nodes)
>  * define per-collection policies that distribute replicas exclusively on 
> different nodes per policy
>  * concurrently create a few collections, each using a different policy
>  * resulting replica placement will be seriously wrong, causing many policy 
> violations
> Running the same scenario but instead creating collections sequentially 
> results in no violations.
> I suspect this is caused by incorrect locking level for all collection 
> operations (as defined in {{CollectionParams.CollectionAction}}) that create 
> new replica placements - i.e. CREATE, ADDREPLICA, MOVEREPLICA, DELETENODE, 
> REPLACENODE, SPLITSHARD, RESTORE, REINDEXCOLLECTION. All of these operations 
> use the policy engine to create new replica placements, and as a result they 
> change the cluster state. However, currently these operations are locked (in 
> {{OverseerCollectionMessageHandler.lockTask}} ) using 
> {{LockLevel.COLLECTION}}. In practice this means that the lock is held only 
> for the particular collection that is being modified.
> A straightforward fix for this issue is to change the locking level to 
> CLUSTER (and I confirm this fixes the scenario described above). However, 
> this effectively serializes all collection operations listed above, which 
> will result in general slow-down of all collection operations.



--
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-13884) Concurrent collection creation leads to multiple replicas placed on same node

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki resolved SOLR-13884.
-
Fix Version/s: 8.6
   Resolution: Fixed

SOLR-14347 fixes also this issue.

> Concurrent collection creation leads to multiple replicas placed on same node
> -
>
> Key: SOLR-13884
> URL: https://issues.apache.org/jira/browse/SOLR-13884
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When multiple collection creations are done concurrently with a 
> collection-level policy, multiple replicas of a single shard can end up on 
> the same node, violating the specified policy.
> This was observed on both 8.2 and master.



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

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



[jira] [Updated] (SOLR-14360) Speed up Levenshtein distance calculation when we don't need the exact distance

2020-03-24 Thread Andras Salamon (Jira)


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

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

> Speed up Levenshtein distance calculation when we don't need the exact 
> distance
> ---
>
> Key: SOLR-14360
> URL: https://issues.apache.org/jira/browse/SOLR-14360
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14360-01.patch
>
>
> Sometimes when we calculate the Levenshtein distance we don't need the exact 
> distance, we only want to know if the strings are similar enough.
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/spelling/SolrSpellChecker.java#L113-L114]
> {noformat}
> sug.score = sd.getDistance(original, sug.string);
> if (sug.score < min) continue; {noformat}
> If we use this threshold in the distance calculation, we can speed it up, we 
> can stop the calculation when we already know that the the the distance will 
> be lower than the threshold.



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

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



[jira] [Updated] (SOLR-14360) Speed up Levenshtein distance calculation when we don't need the exact distance

2020-03-24 Thread Andras Salamon (Jira)


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

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

> Speed up Levenshtein distance calculation when we don't need the exact 
> distance
> ---
>
> Key: SOLR-14360
> URL: https://issues.apache.org/jira/browse/SOLR-14360
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14360-01.patch
>
>
> Sometimes when we calculate the Levenshtein distance we don't need the exact 
> distance, we only want to know if the strings are similar enough.
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/spelling/SolrSpellChecker.java#L113-L114]
> {noformat}
> sug.score = sd.getDistance(original, sug.string);
> if (sug.score < min) continue; {noformat}
> If we use this threshold in the distance calculation, we can speed it up, we 
> can stop the calculation when we already know that the the the distance will 
> be lower than the threshold.



--
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-14360) Speed up Levenshtein distance calculation when we don't need the exact distance

2020-03-24 Thread Andras Salamon (Jira)
Andras Salamon created SOLR-14360:
-

 Summary: Speed up Levenshtein distance calculation when we don't 
need the exact distance
 Key: SOLR-14360
 URL: https://issues.apache.org/jira/browse/SOLR-14360
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Andras Salamon
 Attachments: SOLR-14360-01.patch

Sometimes when we calculate the Levenshtein distance we don't need the exact 
distance, we only want to know if the strings are similar enough.

[https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/spelling/SolrSpellChecker.java#L113-L114]
{noformat}
sug.score = sd.getDistance(original, sug.string);
if (sug.score < min) continue; {noformat}
If we use this threshold in the distance calculation, we can speed it up, we 
can stop the calculation when we already know that the the the distance will be 
lower than the threshold.



--
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] (LUCENE-9198) Remove news section from TLP website

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler reopened LUCENE-9198:
---

I would like to reopen this:
I just checked the commits when [~romseygeek] did the release and I noticed 
that he still created the top-level news, although we don't have them anymore 
on the main web page.

Although this issue removed the news from homepage and replaced them by the 
two-column layout, the TLP news are still there, so there is still additional 
work for the release manager to copypaste news.

Actually there is still one reference and it is also created as a page: 
https://lucene.apache.org/news.html (which is only referred somewhere on the 
right).

IMHO, we should remove the whole folder: content/main_news.
The news.html on root level may possibly also removed, or we may just change 
them to load all news from all 3 subprojects and sort them by date? 

Any opinions? I tend to remove the TLP news page completely.

> Remove news section from TLP website
> 
>
> Key: LUCENE-9198
> URL: https://issues.apache.org/jira/browse/LUCENE-9198
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: new-tlp-conditional-news.png, 
> new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the front page [https://lucene.apache.org|https://lucene.apache.org/] we 
> today show a list of TLP news.
> For every release we author one news article for Solr, one news article for 
> LuceneCore, and one news article for TLP site, combining the two.
> In all these years we have never published a news item to TLP that is not a 
> release announcement, except in 2014 when we announced that OpenRelevance sub 
> project closed.
> I thus propose to remove this news section, and replace it with two widgets 
> that automatically display the last 5 news headings from LuceneCore, Solr and 
> PyLucene sub projects.
> If we have an important TLP announcement to make at some point, that can be 
> done right there on the front page, not?



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

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



[jira] [Updated] (SOLR-14182) Move metric reporters config from solr.xml to ZK cluster properties

2020-03-24 Thread Alan Woodward (Jira)


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

Alan Woodward updated SOLR-14182:
-
Fix Version/s: (was: 8.5)
   8.6

> Move metric reporters config from solr.xml to ZK cluster properties
> ---
>
> Key: SOLR-14182
> URL: https://issues.apache.org/jira/browse/SOLR-14182
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 8.4
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.6
>
>
> Metric reporters are currently configured statically in solr.xml, which makes 
> it difficult to change dynamically or in a containerized environment.
> We should move this section to ZK /cluster.properties and add a back-compat 
> migration shim.



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

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



[jira] [Updated] (SOLR-14170) Tag package feature as experimental

2020-03-24 Thread Alan Woodward (Jira)


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

Alan Woodward updated SOLR-14170:
-
Fix Version/s: (was: 8.5)
   8.6

> Tag package feature as experimental
> ---
>
> Key: SOLR-14170
> URL: https://issues.apache.org/jira/browse/SOLR-14170
> Project: Solr
>  Issue Type: Test
>  Components: documentation
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.6
>
>
> The new package store and package installation feature introduced in 8.4 was 
> supposed to be tagged as lucene.experimental with a clear warning in 
> ref-guide "Not yet recommended for production use"
> Let's add that for 8.5 so there is no doubt that if you use the feature you 
> know the risks. Once the APIs have stabilized and there are a number of 
> packages available "in the wild", we can decide to release it as a "GA" 
> feature, but not yet!



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

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



[jira] [Updated] (SOLR-14273) Autoscaling "cores" tag should support "strict : false"

2020-03-24 Thread Alan Woodward (Jira)


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

Alan Woodward updated SOLR-14273:
-
Fix Version/s: (was: 8.5)
   8.6

> Autoscaling "cores" tag should support "strict : false"
> ---
>
> Key: SOLR-14273
> URL: https://issues.apache.org/jira/browse/SOLR-14273
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 8.4.1
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 7.7.3, 8.6
>
>
> Currently when the "cores" global tag is parsed the parser automatically 
> refuses to accept any other attributes - and since the "strict" attribute 
> defaults to true there's no way to relax this rule.
> This becomes important when trying to spread the cores evenly across the 
> cluster - even minor variations will generate violations, while in most cases 
> a good enough spread is sufficient.
> It appears there's no other reason for this limitation apart from the rule 
> parser limitation.



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

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



[jira] [Updated] (LUCENE-8962) Can we merge small segments during refresh, for faster searching?

2020-03-24 Thread Alan Woodward (Jira)


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

Alan Woodward updated LUCENE-8962:
--
Fix Version/s: (was: 8.5)
   8.6

> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch
>
>  Time Spent: 9.5h
>  Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory 
> segments to disk and open an {{IndexReader}} to search them, and this is 
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}} 
> will accumulate write many small segments during {{refresh}} and this then 
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if 
> given a little time ... so, could we somehow improve {{IndexWriter'}}s 
> refresh to optionally kick off merge policy to merge segments below some 
> threshold before opening the near-real-time reader?  It'd be a bit tricky 
> because while we are waiting for merges, indexing may continue, and new 
> segments may be flushed, but those new segments shouldn't be included in the 
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy, 
> and some hackity logic to have the merge policy target small segments just 
> written by refresh, but it's tricky to then open a near-real-time reader, 
> excluding newly flushed but including newly merged segments since the refresh 
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for 
> discussion!



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

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



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

2020-03-24 Thread Alan Woodward (Jira)


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

Alan Woodward updated LUCENE-9170:
--
Fix Version/s: (was: 8.5)
   8.6

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



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

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



[GitHub] [lucene-solr] iverase opened a new pull request #1374: LUCENE-9287:Add DocValuesFieldExistsQuery as a never cache query in UsageTrackingQueryCachingPolicy

2020-03-24 Thread GitBox
iverase opened a new pull request #1374: LUCENE-9287:Add 
DocValuesFieldExistsQuery as a never cache query in 
UsageTrackingQueryCachingPolicy
URL: https://github.com/apache/lucene-solr/pull/1374
 
 
   see https://issues.apache.org/jira/browse/LUCENE-9287


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


With regards,
Apache Git Services

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



[jira] [Created] (SOLR-14361) SIP-4 Solr should own the bootstrap process

2020-03-24 Thread Jira
Jan Høydahl created SOLR-14361:
--

 Summary: SIP-4 Solr should own the bootstrap process
 Key: SOLR-14361
 URL: https://issues.apache.org/jira/browse/SOLR-14361
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Jan Høydahl


This is the JIRA corresponding to SIP-4.



--
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-8035) Move solr/webapp to solr/server/solr-webapp

2020-03-24 Thread Jira


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

Jan Høydahl resolved SOLR-8035.
---
Resolution: Done

Closing this as it is done long ago

> Move solr/webapp to solr/server/solr-webapp
> ---
>
> Key: SOLR-8035
> URL: https://issues.apache.org/jira/browse/SOLR-8035
> Project: Solr
>  Issue Type: Bug
>  Components: Admin UI
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-8035.patch
>
>
> Let's move solr/webapp *source* files to their final actual distro 
> destination.  This facilitates folks editing the UI in real-time (save 
> change, refresh in browser) rather than having to "stop, ant server, restart" 
> to see a change.



--
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-10894) Streaming expressions handling of escaped special characters bug

2020-03-24 Thread Christian Spitzlay (Jira)


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

Christian Spitzlay commented on SOLR-10894:
---

Now (>= 8.5) backticks are possible as quote character for phrases.  Does that 
mean there now is a change to the way double quotes are to be escaped inside 
the search term?

> Streaming expressions handling of escaped special characters bug
> 
>
> Key: SOLR-10894
> URL: https://issues.apache.org/jira/browse/SOLR-10894
> Project: Solr
>  Issue Type: Bug
>  Components: streaming expressions
>Reporter: Houston Putman
>Priority: Major
> Attachments: SOLR-10894.patch
>
>
> Streaming expressions expect all special characters in named parameter values 
> to be singly escaped. Since queries can contain strings surrounded by double 
> quotes, double-escaping is necessary.
> Given the following query: 
> {{summary:"\"This is a summary\"\+"}}
> A streaming expression would require surrounding the query with double 
> quotes, therefore every special character in the query should be escaped: 
> {{select(collection,q="\"\\\"This is a summary\\\"\\\+\"",)}}
> Streaming expressions should unescape the strings contained within double 
> quotes, however currently they are only unescaping {{\" -> "}}. Therefore it 
> is impossible to query for text fields containing double quotes. Also other 
> special characters are not unescaped; this inconsistency causes confusion.



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread Ignacio Vera (Jira)
Ignacio Vera created LUCENE-9287:


 Summary: Never cache DocValuesFieldExistsQuery
 Key: LUCENE-9287
 URL: https://issues.apache.org/jira/browse/LUCENE-9287
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Ignacio Vera


Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates on 
the field in question. This query is pretty efficient and some experiments show 
that caching the result might be much more expensive than the benefits we get 
from caching the result.

For example, indexing 10 million documents with long values and then executing 
this query:
 * without caching it takes around 1ms to run.
 * with caching it takes around 40ms to run and the size of the cache is around 
1MB (1212792 bytes).

I wonder if we should never cache this query as it seems the overhead of 
caching the results is not worthy.

 



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread Adrien Grand (Jira)


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

Adrien Grand commented on LUCENE-9287:
--

The change makes sense to me but I don't understand the benchmark, does it mean 
that the query takes 40ms once cached? Or is it the time it takes to cache the 
query?

> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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] jpountz commented on a change in pull request #1374: LUCENE-9287:Add DocValuesFieldExistsQuery as a never cache query in UsageTrackingQueryCachingPolicy

2020-03-24 Thread GitBox
jpountz commented on a change in pull request #1374: LUCENE-9287:Add 
DocValuesFieldExistsQuery as a never cache query in 
UsageTrackingQueryCachingPolicy
URL: https://github.com/apache/lucene-solr/pull/1374#discussion_r397172657
 
 

 ##
 File path: lucene/CHANGES.txt
 ##
 @@ -127,6 +127,9 @@ Optimizations
 * LUCENE-8103: DoubleValuesSource and QueryValueSource now use a 
TwoPhaseIterator if one is provided by the Query.
   (Michele Palmia, David Smiley)
 
+* LUCENE-9287:Add DocValuesFieldExistsQuery as a never cache query in 
UsageTrackingQueryCachingPolicy.
 
 Review comment:
   This is an implementation detail of this class, maybe say something like 
`UsageTrackingQueryCachingPolicy no longer caches DocValuesFieldExistsQuery`?


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


With regards,
Apache Git Services

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



[jira] [Commented] (SOLR-14352) External links from Solr Javadocs to Lucene docs are broken on the master (9.0.0)

2020-03-24 Thread Tomoko Uchida (Jira)


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

Tomoko Uchida commented on SOLR-14352:
--

I didn't intend to debug ant build though, it could be a blocker for 9.0.0 
release as long as we live with ant (?). If there are no comments, i'm going to 
fix gradle build only and let ant build as it is.

> External links from Solr Javadocs to Lucene docs are broken on the master 
> (9.0.0)
> -
>
> Key: SOLR-14352
> URL: https://issues.apache.org/jira/browse/SOLR-14352
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: SOLR-14352.patch, SOLR-14352.patch, image.png, 
> javadoc_solr_branch8x.png, javadoc_solr_master.png
>
>
> On branch_8x (w/ java 8), "ant documentation" generates external links from 
> Solr docs to Lucene docs like the capture:
> !javadoc_solr_branch8x.png!
> On the master branch (w/ java11), the links are not created with the same 
> command:
> !javadoc_solr_master.png!
> It looks like the Ant javadoc task does not recognize the {{element-list}} 
> file, that was introduced at (maybe) Java10 as the replacement of 
> {{package-list}}. (See also 
> https://docs.oracle.com/en/java/javase/11/tools/javadoc.html)



--
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] (SOLR-14352) External links from Solr Javadocs to Lucene docs are broken on the master (9.0.0)

2020-03-24 Thread Tomoko Uchida (Jira)


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

Tomoko Uchida edited comment on SOLR-14352 at 3/24/20, 2:04 PM:


I didn't intend to debug ant build though, it could be a blocker for 9.0.0 
release as long as we live with ant (??). If there are no comments, i'm going 
to fix gradle build only and let ant build as it is.


was (Author: tomoko uchida):
I didn't intend to debug ant build though, it could be a blocker for 9.0.0 
release as long as we live with ant (?). If there are no comments, i'm going to 
fix gradle build only and let ant build as it is.

> External links from Solr Javadocs to Lucene docs are broken on the master 
> (9.0.0)
> -
>
> Key: SOLR-14352
> URL: https://issues.apache.org/jira/browse/SOLR-14352
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: SOLR-14352.patch, SOLR-14352.patch, image.png, 
> javadoc_solr_branch8x.png, javadoc_solr_master.png
>
>
> On branch_8x (w/ java 8), "ant documentation" generates external links from 
> Solr docs to Lucene docs like the capture:
> !javadoc_solr_branch8x.png!
> On the master branch (w/ java11), the links are not created with the same 
> command:
> !javadoc_solr_master.png!
> It looks like the Ant javadoc task does not recognize the {{element-list}} 
> file, that was introduced at (maybe) Java10 as the replacement of 
> {{package-list}}. (See also 
> https://docs.oracle.com/en/java/javase/11/tools/javadoc.html)



--
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] epugh commented on issue #1033: SOLR-13965: Use Plugin to add new expressions to GraphHandler

2020-03-24 Thread GitBox
epugh commented on issue #1033: SOLR-13965: Use Plugin to add new expressions 
to GraphHandler
URL: https://github.com/apache/lucene-solr/pull/1033#issuecomment-603260295
 
 
   Closing as this was actually committed.


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] epugh closed pull request #1033: SOLR-13965: Use Plugin to add new expressions to GraphHandler

2020-03-24 Thread GitBox
epugh closed pull request #1033: SOLR-13965: Use Plugin to add new expressions 
to GraphHandler
URL: https://github.com/apache/lucene-solr/pull/1033
 
 
   


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9198) Remove news section from TLP website

2020-03-24 Thread Jira


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

Jan Høydahl commented on LUCENE-9198:
-

See my comment and screenshot from February 2nd:
{quote}Instead, the frontpage has no TLP news section at all unless you tag one 
or more TLP news file with the property frontpage: true on top of the Markdown 
file for the news story.
{quote}
So my thinking is that we will NOT keep adding a news item for every release to 
the TLP news. But there may still be cases for where we DO want to add a TLP 
news item, such as if e.g. we deprecate a sub project, add a new sub project, 
if we move the code repo etc. In those cases we can add a TLP news and tag it 
with "frontpage" if it shold show up in front page in addition to the 
/news.html. There is conditional logic now on the front page to show items only 
if they are tagged as frontpage=true.

I also thought that keeping the /news.html would keep old URL links working, 
but it won't since old news links would link to front page with an anchor, 
while they all now live under /news.html (with the same anchor).

However given how infrequent those posts are, I will not block you from 
completely removing TLP news if you feel strongly about it!

> Remove news section from TLP website
> 
>
> Key: LUCENE-9198
> URL: https://issues.apache.org/jira/browse/LUCENE-9198
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: new-tlp-conditional-news.png, 
> new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the front page [https://lucene.apache.org|https://lucene.apache.org/] we 
> today show a list of TLP news.
> For every release we author one news article for Solr, one news article for 
> LuceneCore, and one news article for TLP site, combining the two.
> In all these years we have never published a news item to TLP that is not a 
> release announcement, except in 2014 when we announced that OpenRelevance sub 
> project closed.
> I thus propose to remove this news section, and replace it with two widgets 
> that automatically display the last 5 news headings from LuceneCore, Solr and 
> PyLucene sub projects.
> If we have an important TLP announcement to make at some point, that can be 
> done right there on the front page, not?



--
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-14170) Tag package feature as experimental

2020-03-24 Thread Jira


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

Jan Høydahl commented on SOLR-14170:


Hey - was this not done already? [~ichattopadhyaya]?

> Tag package feature as experimental
> ---
>
> Key: SOLR-14170
> URL: https://issues.apache.org/jira/browse/SOLR-14170
> Project: Solr
>  Issue Type: Test
>  Components: documentation
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 8.6
>
>
> The new package store and package installation feature introduced in 8.4 was 
> supposed to be tagged as lucene.experimental with a clear warning in 
> ref-guide "Not yet recommended for production use"
> Let's add that for 8.5 so there is no doubt that if you use the feature you 
> know the risks. Once the APIs have stabilized and there are a number of 
> packages available "in the wild", we can decide to release it as a "GA" 
> feature, but not yet!



--
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-13101) Shared storage support in SolrCloud

2020-03-24 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-13101:


Commit ca6dc53c78b897a7f402fa1681d825c5cd7b412f in lucene-solr's branch 
refs/heads/jira/SOLR-13101 from Andy Vuong
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ca6dc53 ]

SOLR-13101: Make dir hash computation optional and resilient (#1359)

* Make dir hash computation optional and resilient

* Throw illegalstateexception and update comments

* Delete unused method, fix typo

> Shared storage support in SolrCloud
> ---
>
> Key: SOLR-13101
> URL: https://issues.apache.org/jira/browse/SOLR-13101
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Yonik Seeley
>Priority: Major
>  Time Spent: 13.5h
>  Remaining Estimate: 0h
>
> Solr should have first-class support for shared storage (blob/object stores 
> like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, 
> etc).
> The key component will likely be a new replica type for shared storage.  It 
> would have many of the benefits of the current "pull" replicas (not indexing 
> on all replicas, all shards identical with no shards getting out-of-sync, 
> etc), but would have additional benefits:
>  - Any shard could become leader (the blob store always has the index)
>  - Better elasticity scaling down
>- durability not linked to number of replcias.. a single replica could be 
> common for write workloads
>- could drop to 0 replicas for a shard when not needed (blob store always 
> has index)
>  - Allow for higher performance write workloads by skipping the transaction 
> log
>- don't pay for what you don't need
>- a commit will be necessary to flush to stable storage (blob store)
>  - A lot of the complexity and failure modes go away
> An additional component a Directory implementation that will work well with 
> blob stores.  We probably want one that treats local disk as a cache since 
> the latency to remote storage is so large.  I think there are still some 
> "locking" issues to be solved here (ensuring that more than one writer to the 
> same index won't corrupt it).  This should probably be pulled out into a 
> different JIRA issue.



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

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



[GitHub] [lucene-solr] yonik merged pull request #1359: SOLR-13101: Make dir hash computation optional and resilient

2020-03-24 Thread GitBox
yonik merged pull request #1359: SOLR-13101: Make dir hash computation optional 
and resilient
URL: https://github.com/apache/lucene-solr/pull/1359
 
 
   


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] iverase merged pull request #1374: LUCENE-9287:Add DocValuesFieldExistsQuery as a never cache query in UsageTrackingQueryCachingPolicy

2020-03-24 Thread GitBox
iverase merged pull request #1374: LUCENE-9287:Add DocValuesFieldExistsQuery as 
a never cache query in UsageTrackingQueryCachingPolicy
URL: https://github.com/apache/lucene-solr/pull/1374
 
 
   


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread ASF subversion and git services (Jira)


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

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

Commit 674aba6a8519ed390d57bdb7a42a88f426ce3ffa in lucene-solr's branch 
refs/heads/master from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=674aba6 ]

LUCENE-9287: UsageTrackingQueryCachingPolicy no longer caches 
DocValuesFieldExistsQuery (#1374)



> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread ASF subversion and git services (Jira)


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

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

Commit 955c67d066f766f16f41bc828a1fca6275387b63 in lucene-solr's branch 
refs/heads/branch_8x from Ignacio Vera
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=955c67d ]

LUCENE-9287: UsageTrackingQueryCachingPolicy no longer caches 
DocValuesFieldExistsQuery (#1374)



> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread Ignacio Vera (Jira)


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

Ignacio Vera commented on LUCENE-9287:
--

It takes 40 ms to run the query and adding the result to the cache. Running the 
query alone takes around 1ms, so the overhead is 40x.

 

 

> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread Ignacio Vera (Jira)


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

Ignacio Vera resolved LUCENE-9287.
--
Fix Version/s: 8.6
 Assignee: Ignacio Vera
   Resolution: Fixed

> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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-9287) Never cache DocValuesFieldExistsQuery

2020-03-24 Thread Adrien Grand (Jira)


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

Adrien Grand commented on LUCENE-9287:
--

That makes sense, thanks.

> Never cache DocValuesFieldExistsQuery
> -
>
> Key: LUCENE-9287
> URL: https://issues.apache.org/jira/browse/LUCENE-9287
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Minor
> Fix For: 8.6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently {{DocValuesFieldExistsQuery}} is cached if there are no DV updates 
> on the field in question. This query is pretty efficient and some experiments 
> show that caching the result might be much more expensive than the benefits 
> we get from caching the result.
> For example, indexing 10 million documents with long values and then 
> executing this query:
>  * without caching it takes around 1ms to run.
>  * with caching it takes around 40ms to run and the size of the cache is 
> around 1MB (1212792 bytes).
> I wonder if we should never cache this query as it seems the overhead of 
> caching the results is not worthy.
>  



--
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-14352) External links from Solr Javadocs to Lucene docs are broken on the master (9.0.0)

2020-03-24 Thread Erick Erickson (Jira)


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

Erick Erickson commented on SOLR-14352:
---

{quote}I didn't intend to debug ant build though
{quote}
 

+1.  I'm hoping to move exclusively to gradle for 9.0, pending consensus.

> External links from Solr Javadocs to Lucene docs are broken on the master 
> (9.0.0)
> -
>
> Key: SOLR-14352
> URL: https://issues.apache.org/jira/browse/SOLR-14352
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Tomoko Uchida
>Assignee: Tomoko Uchida
>Priority: Major
> Attachments: SOLR-14352.patch, SOLR-14352.patch, image.png, 
> javadoc_solr_branch8x.png, javadoc_solr_master.png
>
>
> On branch_8x (w/ java 8), "ant documentation" generates external links from 
> Solr docs to Lucene docs like the capture:
> !javadoc_solr_branch8x.png!
> On the master branch (w/ java11), the links are not created with the same 
> command:
> !javadoc_solr_master.png!
> It looks like the Ant javadoc task does not recognize the {{element-list}} 
> file, that was introduced at (maybe) Java10 as the replacement of 
> {{package-list}}. (See also 
> https://docs.oracle.com/en/java/javase/11/tools/javadoc.html)



--
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] gunasekhardora commented on a change in pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query

2020-03-24 Thread GitBox
gunasekhardora commented on a change in pull request #1371: SOLR-14333: print 
readable version of CollapsedPostFilter query
URL: https://github.com/apache/lucene-solr/pull/1371#discussion_r397209891
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
 ##
 @@ -184,6 +184,11 @@ public boolean equals(final Object other) {
 public int hashCode() {
   return 17 * (31 + selectorText.hashCode()) * (31 + type.hashCode());
 }
+
+@Override
+public String toString(){
+  return selectorText;
 
 Review comment:
   Added type too


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] gunasekhardora commented on a change in pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query

2020-03-24 Thread GitBox
gunasekhardora commented on a change in pull request #1371: SOLR-14333: print 
readable version of CollapsedPostFilter query
URL: https://github.com/apache/lucene-solr/pull/1371#discussion_r397210126
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
 ##
 @@ -276,7 +281,19 @@ public int getCost() {
 }
 
 public String toString(String s) {
-  return s;
+  return "!collapse field=" + this.collapseField +
+  ", nullPolicy=" + getNullPolicyString(this.nullPolicy) +
+  ", groupHeadSelector=" + this.groupHeadSelector.toString() +
+  (hint == null ? "": ", hint=" + this.hint) +
+  ", size=" + this.size;
+}
+
+private String getNullPolicyString(int nullPolicy) {
 
 Review comment:
   Converted this to enum


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] gunasekhardora commented on a change in pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query

2020-03-24 Thread GitBox
gunasekhardora commented on a change in pull request #1371: SOLR-14333: print 
readable version of CollapsedPostFilter query
URL: https://github.com/apache/lucene-solr/pull/1371#discussion_r397210022
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/search/CollapsingQParserPlugin.java
 ##
 @@ -276,7 +281,19 @@ public int getCost() {
 }
 
 public String toString(String s) {
-  return s;
+  return "!collapse field=" + this.collapseField +
 
 Review comment:
   Added them


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


With regards,
Apache Git Services

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



[GitHub] [lucene-solr] gunasekhardora commented on issue #1371: SOLR-14333: print readable version of CollapsedPostFilter query

2020-03-24 Thread GitBox
gunasekhardora commented on issue #1371: SOLR-14333: print readable version of 
CollapsedPostFilter query
URL: https://github.com/apache/lucene-solr/pull/1371#issuecomment-603283880
 
 
   Added relevant test cases too. @munendrasn Please review 


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


With regards,
Apache Git Services

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



[jira] [Updated] (SOLR-14361) SIP-4 Solr should own the bootstrap process

2020-03-24 Thread Jira


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

Jan Høydahl updated SOLR-14361:
---
Description: This is the JIRA corresponding to 
[SIP-4|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]
  (was: This is the JIRA corresponding to SIP-4.)

> SIP-4 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-4|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]



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

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



[jira] [Updated] (SOLR-14361) SIP-4 Solr should own the bootstrap process

2020-03-24 Thread Jira


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

Jan Høydahl updated SOLR-14361:
---
Description: 
This is the JIRA corresponding to 
[SIP-4.|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]

The overall design and planning will happen on the Confluence page.

Consept and architecture discussions can happen in the dev@ mail thread linked 
from the SIP.

This Jira will act as an umbrella/parent issue to track development and will 
not have much activity until the SIP is finalized and approved.

  was:This is the JIRA corresponding to 
[SIP-4|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]


> SIP-4 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-4.|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]
> The overall design and planning will happen on the Confluence page.
> Consept and architecture discussions can happen in the dev@ mail thread 
> linked from the SIP.
> This Jira will act as an umbrella/parent issue to track development and will 
> not have much activity until the SIP is finalized and approved.



--
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-6807) AbstractRangeQueryNode toQueryString not working as intended

2020-03-24 Thread Jira


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

Michał Torba commented on LUCENE-6807:
--

Bump. Why does toQueryString() method of a range query not produce a valid 
range query?

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch, 
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-6807) AbstractRangeQueryNode toQueryString not working as intended

2020-03-24 Thread Jira


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

Michał Torba edited comment on LUCENE-6807 at 3/24/20, 3:21 PM:


Bump. Why does toQueryString() method of a range query not produce a valid 
query string?


was (Author: deltharis):
Bump. Why does toQueryString() method of a range query not produce a valid 
range query?

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch, 
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-12267) Admin UI broken metrics

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki commented on SOLR-12267:
-

This difference is caused by two factors:
 * the representation of Timer fields now uses shorter (and different names) 
than in 6x
 * by default the UI retrieves the metrics in a "simple" format, which hides 
most of the properties of complex metrics such as Timers / Meters. This is just 
a default option that the UI uses - we could easily switch it to using 
"simple=false" but then the screens would become very crowded.

> Admin UI broken metrics
> ---
>
> Key: SOLR-12267
> URL: https://issues.apache.org/jira/browse/SOLR-12267
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, metrics
>Reporter: Varun Thacker
>Priority: Major
> Attachments: Solr662.png, Solr720.png
>
>
> Attaching Screenshots of the same metric on Solr 6.6.2 VS Solr 7.2.0 
> The admin UI shows completely different metrics



--
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] (SOLR-12267) Admin UI broken metrics

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki edited comment on SOLR-12267 at 3/24/20, 3:30 PM:
---

This difference is caused by two factors:
 * the representation of Timer fields now uses shorter (and different names) 
than in 6x
 * by default the UI retrieves the metrics in a "simple" format, which hides 
most of the properties of complex metrics such as Timers / Meters. This is just 
a default option that the UI uses - we could easily switch it to using 
"simple=false" but then the screens would become very crowded.

Edit: my angular skills are nonexistent, but it shouldn't be that hard to hack 
the UI to add a checkbox that switches between full and simple formats.


was (Author: ab):
This difference is caused by two factors:
 * the representation of Timer fields now uses shorter (and different names) 
than in 6x
 * by default the UI retrieves the metrics in a "simple" format, which hides 
most of the properties of complex metrics such as Timers / Meters. This is just 
a default option that the UI uses - we could easily switch it to using 
"simple=false" but then the screens would become very crowded.

> Admin UI broken metrics
> ---
>
> Key: SOLR-12267
> URL: https://issues.apache.org/jira/browse/SOLR-12267
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, metrics
>Reporter: Varun Thacker
>Priority: Major
> Attachments: Solr662.png, Solr720.png
>
>
> Attaching Screenshots of the same metric on Solr 6.6.2 VS Solr 7.2.0 
> The admin UI shows completely different metrics



--
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-14361) SIP-4 Solr should own the bootstrap process

2020-03-24 Thread Andrzej Bialecki (Jira)


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

Andrzej Bialecki commented on SOLR-14361:
-

[~janhoy] this should be SIP-6 - SIP-4 and SIP-5 are already taken.

> SIP-4 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-4.|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]
> The overall design and planning will happen on the Confluence page.
> Consept and architecture discussions can happen in the dev@ mail thread 
> linked from the SIP.
> This Jira will act as an umbrella/parent issue to track development and will 
> not have much activity until the SIP is finalized and approved.



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

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



[jira] [Updated] (LUCENE-6807) AbstractRangeQueryNode toQueryString not working as intended

2020-03-24 Thread Peter Barna (Jira)


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

Peter Barna updated LUCENE-6807:

Status: Patch Available  (was: Open)

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch, 
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-9288) poll_mirrors.py release script doesn't handle HTTPS

2020-03-24 Thread Alan Woodward (Jira)
Alan Woodward created LUCENE-9288:
-

 Summary: poll_mirrors.py release script doesn't handle HTTPS
 Key: LUCENE-9288
 URL: https://issues.apache.org/jira/browse/LUCENE-9288
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/tools
Affects Versions: 8.5, master (9.0)
Reporter: Alan Woodward


During the 8.5.0 release, the poll_mirrors.py script incorrectly reported that 
the release artifacts were not on various mirrors or on maven central, because 
it is configured to hit these endpoints using the `http` schema, where most of 
them now only accept `https`.



--
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-14325) Core status could be improved to not require an IndexSearcher

2020-03-24 Thread David Smiley (Jira)


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

David Smiley commented on SOLR-14325:
-

I briefly chatted with Yonik about this and shared my concerns.  One concern is 
that the request is asking for indexInfo yet we'd not return it sometimes 
(because I suggested passing {{false}} param to getRealtimeSearcher).  Also, 
it's debatable if realtime index info is better than non-realtime info (it's 
the difference between what hasn't been committed yet and what has).  Getting a 
realtime searcher will add overhead in common cases when there is a regular 
searcher already available.

I have an idea to conditionally not return the index info if the SolrCloud 
replica state is RECOVERING.  I will work on that.  Does that sound promising?  
There should probably be a new option since the caller may be depending on this.

[~ab] Do you know to what extent SolrCloud / metrics may depend on this extra 
information? "indexInfo" defaults to true.

> Core status could be improved to not require an IndexSearcher
> -
>
> Key: SOLR-14325
> URL: https://issues.apache.org/jira/browse/SOLR-14325
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-14325.patch, SOLR-14325.patch, SOLR-14325.patch
>
>
> When the core status is told to request "indexInfo", it currently grabs the 
> SolrIndexSearcher but only to grab the Directory.  SolrCore.getIndexSize also 
> only requires the Directory.  By insisting on a SolrIndexSearcher, we 
> potentially block for awhile if the core is in recovery since there is no 
> SolrIndexSearcher.
> [https://lists.apache.org/thread.html/r076218c964e9bd6ed0a53133be9170c3cf36cc874c1b4652120db417%40%3Cdev.lucene.apache.org%3E]
> It'd be nice to have a solution that conditionally used the Directory of the 
> SolrIndexSearcher only if it's present so that we don't waste time creating 
> one either.



--
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-14325) Core status could be improved to not require an IndexSearcher

2020-03-24 Thread Richard Goodman (Jira)


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

Richard Goodman commented on SOLR-14325:


I'd be interested to see your idea. I did start to wonder how the metrics side 
of this would work if indexInfo was blank for recovering replicas _(because at 
one point in a previous version of the patch, I got to that stage)_, and 
thought I could filter out replicas in recovery when it comes to querying 
prometheus. Just wasn't sure if that would then create "noise" to any potential 
graphs if an instance goes down and you suddenly see a change in the graph due 
to index info not being present.

I guess also a problem we have with some of our tooling is we just rely on 
calling {{/solr/admin/cores}} and providing {{&indexInfo=false}} would remove 
all the index info, rather than removing it for replicas which are recovering, 
so I think if I understand your point correctly, having a new option to tackle 
this could also be beneficial.

> Core status could be improved to not require an IndexSearcher
> -
>
> Key: SOLR-14325
> URL: https://issues.apache.org/jira/browse/SOLR-14325
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-14325.patch, SOLR-14325.patch, SOLR-14325.patch
>
>
> When the core status is told to request "indexInfo", it currently grabs the 
> SolrIndexSearcher but only to grab the Directory.  SolrCore.getIndexSize also 
> only requires the Directory.  By insisting on a SolrIndexSearcher, we 
> potentially block for awhile if the core is in recovery since there is no 
> SolrIndexSearcher.
> [https://lists.apache.org/thread.html/r076218c964e9bd6ed0a53133be9170c3cf36cc874c1b4652120db417%40%3Cdev.lucene.apache.org%3E]
> It'd be nice to have a solution that conditionally used the Directory of the 
> SolrIndexSearcher only if it's present so that we don't waste time creating 
> one either.



--
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-14034) remove deprecated min_rf references

2020-03-24 Thread Marcus Eagan (Jira)


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

Marcus Eagan commented on SOLR-14034:
-

 [~rabikumar.kc] Feel free to remove them in a PR. Here's the contributing 
guide: https://cwiki.apache.org/confluence/display/SOLR/HowToContribute

> remove deprecated min_rf references
> ---
>
> Key: SOLR-14034
> URL: https://issues.apache.org/jira/browse/SOLR-14034
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Blocker
> Fix For: master (9.0)
>
>
> * {{min_rf}} support was added under SOLR-5468 in version 4.9 
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.9.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L50)
>  and deprecated under SOLR-12767 in version 7.6 
> (https://github.com/apache/lucene-solr/blob/releases/lucene-solr/7.6.0/solr/solrj/src/java/org/apache/solr/client/solrj/request/UpdateRequest.java#L57-L61)
> * http://lucene.apache.org/solr/7_6_0/changes/Changes.html and 
> https://lucene.apache.org/solr/guide/8_0/major-changes-in-solr-8.html#solr-7-6
>  both clearly mention the deprecation
> This ticket is to fully remove {{min_rf}} references in code, tests and 
> documentation.



--
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] uschindler commented on a change in pull request #1360: LUCENE-9281: First mockup of SPIClassIterator retirement

2020-03-24 Thread GitBox
uschindler commented on a change in pull request #1360: LUCENE-9281: First 
mockup of SPIClassIterator retirement
URL: https://github.com/apache/lucene-solr/pull/1360#discussion_r397336753
 
 

 ##
 File path: 
lucene/analysis/common/src/java/org/apache/lucene/analysis/util/AnalysisSPILoader.java
 ##
 @@ -143,6 +144,24 @@ public S newInstance(String name, Map 
args) {
   public Set availableServices() {
 return originalNames;
   }  
+
+  /**
+   * Looks up SPI name (static "NAME" field) with appropriate modifiers.
+   * Also it must be a String class and declared in the concrete class.
+   * @return the SPI name
+   * @throws NoSuchFieldException - if the "NAME" field is not defined.
+   * @throws IllegalAccessException - if the "NAME" field is inaccessible.
+   * @throws IllegalStateException - if the "NAME" field does not have 
appropriate modifiers or isn't a String field.
+   */
+  public static String lookupSPIName(Class 
service) throws NoSuchFieldException, IllegalAccessException, 
IllegalStateException {
 
 Review comment:
   I thought that this method is useful if you want to figure out the name of a 
factory where you only have class reference. There is no reason to hide 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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9281) Retire SPIClassIterator from master because Java 9+ uses different mechanism to load services when module system is used

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on LUCENE-9281:
---

I updated the PR and added the no-arg ctor to all factories. Was a bit of 
annoying to do this (I remember [~tomoko] complaining when she added the 
{{NAME}} string field).

While doing this I found the following at the end of each ctor:
{code:java}
if (!args.isEmpty()) {
  throw new IllegalArgumentException("Unknown parameters: " + args);
}
{code}
This can be easily changed to a static method called from each ctor. We may add 
a check into the source code checker.

I am also looking to add a check into the source checker like we did for the 
{{NAME}} field.

Tests are currently running, lucene passed. Solr still ongoing.

> Retire SPIClassIterator from master because Java 9+ uses different mechanism 
> to load services when module system is used
> 
>
> Key: LUCENE-9281
> URL: https://issues.apache.org/jira/browse/LUCENE-9281
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We currently have our own implementation of the service loader standard (SPI) 
> fo several reasons:
> (1) In some older JDKs the order of classpath was not respected and this lead 
> to wrong order of codecs implementing the same SPI name. This caused tests to 
> sometimes use wrong class (we had this in Lucene 4 where we had a test-only 
> read/write Lucene3 codec that was listed before the read-only one). That's no 
> longer an issue, the order of loading does not matter. In addition, Java now 
> does everything correct.
> (2) In Analysis, we require SPI classes to have a constructor taking args (a 
> Map of params in our case). We also extract the NAME from a static field. 
> Standard service loader does not support this, it tries to instantiate the 
> class with default ctor.
> With Java 9+, the ServiceLoader now has a stream() method that allows to 
> filter and preprocess classes: 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html#stream()]
> This allows us to use the new interface and just get the loaded class (which 
> may come from module-info.class or a conventional SPI file): 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.Provider.html#type()]
> This change allows us to convert Lucene to modules listing all SPIs in the 
> module-info.java.



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

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



[jira] [Commented] (LUCENE-9281) Retire SPIClassIterator from master because Java 9+ uses different mechanism to load services when module system is used

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on LUCENE-9281:
---

I don't want to keep the PR open for too long time, as it might get outdated 
because it touches many files. So if there are any problem, please speak up 
soon!

> Retire SPIClassIterator from master because Java 9+ uses different mechanism 
> to load services when module system is used
> 
>
> Key: LUCENE-9281
> URL: https://issues.apache.org/jira/browse/LUCENE-9281
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We currently have our own implementation of the service loader standard (SPI) 
> fo several reasons:
> (1) In some older JDKs the order of classpath was not respected and this lead 
> to wrong order of codecs implementing the same SPI name. This caused tests to 
> sometimes use wrong class (we had this in Lucene 4 where we had a test-only 
> read/write Lucene3 codec that was listed before the read-only one). That's no 
> longer an issue, the order of loading does not matter. In addition, Java now 
> does everything correct.
> (2) In Analysis, we require SPI classes to have a constructor taking args (a 
> Map of params in our case). We also extract the NAME from a static field. 
> Standard service loader does not support this, it tries to instantiate the 
> class with default ctor.
> With Java 9+, the ServiceLoader now has a stream() method that allows to 
> filter and preprocess classes: 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.html#stream()]
> This allows us to use the new interface and just get the loaded class (which 
> may come from module-info.class or a conventional SPI file): 
> [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/ServiceLoader.Provider.html#type()]
> This change allows us to convert Lucene to modules listing all SPIs in the 
> module-info.java.



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

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



[jira] [Created] (SOLR-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)
Uwe Schindler created SOLR-14362:


 Summary: Tests no longer run with whitespace in Solr's checkout 
directory
 Key: SOLR-14362
 URL: https://issues.apache.org/jira/browse/SOLR-14362
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Affects Versions: master (9.0)
Reporter: Uwe Schindler


When trying to run the test suite from a directory with white-space in the path 
name, SolrTestCase does not load at all:

{noformat}
   [junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
   [junit4]> Throwable #1: java.security.AccessControlException: access 
denied ("java.io.FilePermission" 
"C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
 "read")
   [junit4]>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:895)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
   [junit4]>at java.base/java.io.File.exists(File.java:815)
   [junit4]>at 
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
   [junit4]>at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
   [junit4]>at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
   [junit4]>at 
org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
   [junit4]>at 
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
   [junit4]>at 
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
   [junit4]>at 
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
   [junit4]>at 
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
   [junit4]>at 
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
   [junit4]>at 
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
   [junit4]>at 
org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
   [junit4]>at java.base/java.lang.Class.forName0(Native Method)
   [junit4]>at java.base/java.lang.Class.forName(Class.java:398)
   [junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
FAILURES!
{noformat}

This is a new issue and seems to be introduced not long ago. The last time I 
ran tests, it worked. Does anybody know what changed. To me it looks like there 
is some wrong encoding involved.



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

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



[jira] [Updated] (SOLR-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler updated SOLR-14362:
-
Description: 
When trying to run the test suite from a directory with white-space in the path 
name, SolrTestCase does not load at all:

{noformat}
   [junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
   [junit4]> Throwable #1: java.security.AccessControlException: access 
denied ("java.io.FilePermission" 
"C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
 "read")
   [junit4]>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:895)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
   [junit4]>at java.base/java.io.File.exists(File.java:815)
   [junit4]>at 
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
   [junit4]>at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
   [junit4]>at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
   [junit4]>at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
   [junit4]>at 
org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
   [junit4]>at 
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
   [junit4]>at 
org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
   [junit4]>at 
org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
   [junit4]>at 
org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
   [junit4]>at 
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
   [junit4]>at 
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
   [junit4]>at 
org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
   [junit4]>at java.base/java.lang.Class.forName0(Native Method)
   [junit4]>at java.base/java.lang.Class.forName(Class.java:398)
   [junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
FAILURES!
{noformat}

This is a new issue and seems to be introduced not long ago. The last time I 
ran tests, it worked. Does anybody know what changed? To me it looks like there 
is some wrong encoding involved.

  was:
When trying to run the test suite from a directory with white-space in the path 
name, SolrTestCase does not load at all:

{noformat}
   [junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
   [junit4]> Throwable #1: java.security.AccessControlException: access 
denied ("java.io.FilePermission" 
"C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
 "read")
   [junit4]>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   [junit4]>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:895)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   [junit4]>at 
java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
   [junit4]>at java.base/java.io.File.exists(File.java:815)
   [junit4]>at 
org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
   [junit4]>at 
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getCo

[jira] [Commented] (LUCENE-6807) AbstractRangeQueryNode toQueryString not working as intended

2020-03-24 Thread Lucene/Solr QA (Jira)


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

Lucene/Solr QA commented on LUCENE-6807:


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


This message was automatically generated.



> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch, 
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of

[jira] [Commented] (SOLR-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on SOLR-14362:
--

This issue comes from broken URL parsing in log4j2 because it converts the 
classpath URL multiple times between strings trying several ways to interpret 
the string. God damn!

https://github.com/apache/logging-log4j2/blob/log4j-2.11.2/log4j-core/src/main/java/org/apache/logging/log4j/core/util/FileUtils.java#L62-L99

In line 87 it does the wrong thing: It calls {{URI#getFile()}} and then the 
desaster begins. It tries several ways to decode the path instead of just 
calling the correct method from the beginning: {{new File(uri)}}



> Tests no longer run with whitespace in Solr's checkout directory
> 
>
> Key: SOLR-14362
> URL: https://issues.apache.org/jira/browse/SOLR-14362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Priority: Major
>
> When trying to run the test suite from a directory with white-space in the 
> path name, SolrTestCase does not load at all:
> {noformat}
>[junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
>[junit4]> Throwable #1: java.security.AccessControlException: access 
> denied ("java.io.FilePermission" 
> "C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
>  "read")
>[junit4]>at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>[junit4]>at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
>[junit4]>at java.base/java.io.File.exists(File.java:815)
>[junit4]>at 
> org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>[junit4]>at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>[junit4]>at 
> org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
>[junit4]>at java.base/java.lang.Class.forName0(Native Method)
>[junit4]>at java.base/java.lang.Class.forName(Class.java:398)
>[junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
> FAILURES!
> {noformat}
> This is a new issue and seems to be introduced not long ago. The last time I 
> ran tests, it worked. Does anybody know what changed? To me it looks like 
> there is some wrong encoding involved.



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

-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org

[jira] [Commented] (SOLR-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on SOLR-14362:
--

[~rcmuir] stumbled on this in the past, too when he was adding security manager 
to Solr start scripts. He just switched to plain filenames. Here it reads the 
URL from {{ClassLoader#getResource}} and then converts it and tries to 
interpret it in several broken ways.

The only fix I would know of is to make the test framework set 
log4j.configurationFile very early using our methods to get the file behind the 
resource.

> Tests no longer run with whitespace in Solr's checkout directory
> 
>
> Key: SOLR-14362
> URL: https://issues.apache.org/jira/browse/SOLR-14362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Priority: Major
>
> When trying to run the test suite from a directory with white-space in the 
> path name, SolrTestCase does not load at all:
> {noformat}
>[junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
>[junit4]> Throwable #1: java.security.AccessControlException: access 
> denied ("java.io.FilePermission" 
> "C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
>  "read")
>[junit4]>at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>[junit4]>at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
>[junit4]>at java.base/java.io.File.exists(File.java:815)
>[junit4]>at 
> org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>[junit4]>at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>[junit4]>at 
> org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
>[junit4]>at java.base/java.lang.Class.forName0(Native Method)
>[junit4]>at java.base/java.lang.Class.forName(Class.java:398)
>[junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
> FAILURES!
> {noformat}
> This is a new issue and seems to be introduced not long ago. The last time I 
> ran tests, it worked. Does anybody know what changed? To me it looks like 
> there is some wrong encoding involved.



--
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-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on SOLR-14362:
--

Anyways we should open issue in log4j. This makes log4j not working with a 
security manager and log4j config files in classpath at all.

> Tests no longer run with whitespace in Solr's checkout directory
> 
>
> Key: SOLR-14362
> URL: https://issues.apache.org/jira/browse/SOLR-14362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Priority: Major
>
> When trying to run the test suite from a directory with white-space in the 
> path name, SolrTestCase does not load at all:
> {noformat}
>[junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
>[junit4]> Throwable #1: java.security.AccessControlException: access 
> denied ("java.io.FilePermission" 
> "C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
>  "read")
>[junit4]>at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>[junit4]>at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
>[junit4]>at java.base/java.io.File.exists(File.java:815)
>[junit4]>at 
> org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>[junit4]>at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>[junit4]>at 
> org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
>[junit4]>at java.base/java.lang.Class.forName0(Native Method)
>[junit4]>at java.base/java.lang.Class.forName(Class.java:398)
>[junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
> FAILURES!
> {noformat}
> This is a new issue and seems to be introduced not long ago. The last time I 
> ran tests, it worked. Does anybody know what changed? To me it looks like 
> there is some wrong encoding involved.



--
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-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Robert Muir (Jira)


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

Robert Muir commented on SOLR-14362:


Yes, maybe as a workaround we can set the sysprop from ant/gradle when running 
tests, too.

> Tests no longer run with whitespace in Solr's checkout directory
> 
>
> Key: SOLR-14362
> URL: https://issues.apache.org/jira/browse/SOLR-14362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Priority: Major
>
> When trying to run the test suite from a directory with white-space in the 
> path name, SolrTestCase does not load at all:
> {noformat}
>[junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
>[junit4]> Throwable #1: java.security.AccessControlException: access 
> denied ("java.io.FilePermission" 
> "C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
>  "read")
>[junit4]>at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>[junit4]>at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
>[junit4]>at java.base/java.io.File.exists(File.java:815)
>[junit4]>at 
> org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>[junit4]>at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>[junit4]>at 
> org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
>[junit4]>at java.base/java.lang.Class.forName0(Native Method)
>[junit4]>at java.base/java.lang.Class.forName(Class.java:398)
>[junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
> FAILURES!
> {noformat}
> This is a new issue and seems to be introduced not long ago. The last time I 
> ran tests, it worked. Does anybody know what changed? To me it looks like 
> there is some wrong encoding involved.



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

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



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

2020-03-24 Thread GitBox
dsmiley commented on issue #1368: SOLR-14351: Fix/improve MDCLoggingContext 
usage
URL: https://github.com/apache/lucene-solr/pull/1368#issuecomment-603448754
 
 
   I'll commit in two days according to lazy consensus.
   Proposed log entry:
   OTHER:
   * Improved / hardened MDCLoggingContext usage.


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


With regards,
Apache Git Services

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



[GitHub] [lucene-site] dsmiley commented on issue #18: Alessandro Benedetti new committer

2020-03-24 Thread GitBox
dsmiley commented on issue #18: Alessandro Benedetti new committer
URL: https://github.com/apache/lucene-site/pull/18#issuecomment-603450822
 
 
   @alessandrobenedetti I'm guessing you don't have permissions to merge via 
the GitHub UI?
   See this: https://gitbox.apache.org/setup/ "GitBox Account Linking Utility". 
 And as I understand it, you don't *have* to use GitHub since git repos are 
mirrored between ASF infra & GH infra.


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-6807) AbstractRangeQueryNode toQueryString not working as intended

2020-03-24 Thread Peter Barna (Jira)


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

Peter Barna commented on LUCENE-6807:
-

Errors appear to be an API change sometime in the intervening 5 years.

Appears to be a simple swap to {{PointsConfig}}, {{PointQueryNode}}, and 
{{PointRangeQueryNode}} from the {{Numeric*}} equivalents.

> AbstractRangeQueryNode toQueryString not working as intended
> 
>
> Key: LUCENE-6807
> URL: https://issues.apache.org/jira/browse/LUCENE-6807
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Affects Versions: 5.3
>Reporter: Peter Barna
>Priority: Minor
> Attachments: LUCENE-6807-option1.patch, LUCENE-6807-option1.patch, 
> LUCENE-6807-option2.patch, LUCENE-6807-option3.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> It is my understanding that for a given {{QueryNode}} node, 
> {{parse(node.toQueryString());}} should return a {{QueryNode}} which is 
> functionally identical to the original node.
> That is not the case with AbstractQueryNode:
> if we have a range query on FIELD from "A" to "B" ({{node = parse("FIELD:[A 
> B]")}}), then {{node.toQueryString()}} will return "[FIELD:A FIELD:B]" which, 
> in turn, is parsed as a range query on the default field from "FIELD:A" to 
> "FIELD:B".
> As far as I know, this affects all versions of lucene.
> I believe I have the knowledge to provide the patch, so I will be working on 
> that today.
> As of now, I have thought of two options to implement this fix, both of which 
> involve modifying the {{ValueQueryNode}} interface to include a method which 
> returns {{value}} as a {{CharSequence}}. 
> The first option is to add a new method to the interface which returns 
> (formatted if necessary) the value as a {{CharSequence}} and implement it in 
> all implementing classes ({{FieldQueryNode}} and {{NumericQueryNode}}). Then 
> in {{AbstractQueryNode#toQueryString()}} we will call that method and escape 
> the values using the provided {{EscapeQuerySyntax}}.
> The second option is to make the protected method {{getTermEscaped()}}, which 
> is already present in all implementing classes, public, and add it to the 
> interface.
> While I think that the second option is certainly cleaner, I do not know why 
> this method is protected in the first place, so I will proceed with the first 
> option until someone who is more familiar with the lucene project than I am 
> can comment on the matter.
> As I am writing this, it occurs to me that implementing the first option is 
> essentially just bypassing the protected scope on {{getTermEscapeed()}}, so 
> maybe it is correct to just review whether or not that method needs to be 
> protected. It also occurred to me to use the existing {{getValue()}} method, 
> and format and escape the {{toString()}} of that, but that depends on a 
> generic class having implemented {{toString()}} in a way that plays nicely 
> with the query parser, so, to me, this is below the two previously mentioned 
> options.



--
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-14316) Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's equals() method

2020-03-24 Thread David Smiley (Jira)


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

David Smiley commented on SOLR-14316:
-

FWIW I think this sort of change belongs in "Other" instead of improvements 
because it's not something a user would ever notice/see.

> Remove unchecked type conversion warning in JavaBinCodec's readMapEntry's 
> equals() method
> -
>
> Key: SOLR-14316
> URL: https://issues.apache.org/jira/browse/SOLR-14316
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.7.2, 8.4.1
>Reporter: Aroop
>Priority: Minor
>  Labels: patch
> Fix For: master (9.0), 8.6
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> There is an unchecked type conversion warning in JavaBinCodec's 
> readMapEntry's equals() method. 
> This change removes that warning by handling a checked conversion and also 
> adds to tests to an earlier untested 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] dsmiley closed pull request #1373: SOLR-14340 - ZkStateReader.readConfigName is doing too much work

2020-03-24 Thread GitBox
dsmiley closed pull request #1373: SOLR-14340 - ZkStateReader.readConfigName is 
doing too much work
URL: https://github.com/apache/lucene-solr/pull/1373
 
 
   


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


With regards,
Apache Git Services

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



[jira] [Commented] (SOLR-14340) ZkStateReader.readConfigName is doing too much work

2020-03-24 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14340:


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

SOLR-14340: Remove unnecessary configset verification checks
Improves CLUSTERSTATUS times for massive clusters.
Closes #1373


> ZkStateReader.readConfigName is doing too much work
> ---
>
> Key: SOLR-14340
> URL: https://issues.apache.org/jira/browse/SOLR-14340
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ZkStateReader.readConfigName reads the configSet name given a collection name 
> parameter.  Simple.  It's doing too much work to do this though.  First it's 
> calling zkClient.exists() which is redundant given that we then call getData 
> will will detect if it doesn't exist.  Then we validate that the config path 
> exists.  But I don't think that should be verified on read, only on write.  
> This method is a hotspot for nodes with lots of cores, proven out with 
> profiling.
> Ideally the configSet name ought to be moved to state.json which is where all 
> the other collection metadata is and is thus already read by most spots that 
> want to read the configSet name.  That would speed things up further and 
> generally simplify things as well.  That can happen on a follow-on issue, I 
> think.



--
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-14340) ZkStateReader.readConfigName is doing too much work

2020-03-24 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on SOLR-14340:


Commit 23eac4db5d01803dc77afbfe2c998705532b7959 in lucene-solr's branch 
refs/heads/branch_8x from mariemat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=23eac4d ]

SOLR-14340: Remove unnecessary configset verification checks
Improves CLUSTERSTATUS times for massive clusters.
Closes #1373

(cherry picked from commit aad814ba63c9170642ddfc8e9855736177019f13)


> ZkStateReader.readConfigName is doing too much work
> ---
>
> Key: SOLR-14340
> URL: https://issues.apache.org/jira/browse/SOLR-14340
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ZkStateReader.readConfigName reads the configSet name given a collection name 
> parameter.  Simple.  It's doing too much work to do this though.  First it's 
> calling zkClient.exists() which is redundant given that we then call getData 
> will will detect if it doesn't exist.  Then we validate that the config path 
> exists.  But I don't think that should be verified on read, only on write.  
> This method is a hotspot for nodes with lots of cores, proven out with 
> profiling.
> Ideally the configSet name ought to be moved to state.json which is where all 
> the other collection metadata is and is thus already read by most spots that 
> want to read the configSet name.  That would speed things up further and 
> generally simplify things as well.  That can happen on a follow-on issue, I 
> think.



--
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-14362) Tests no longer run with whitespace in Solr's checkout directory

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on SOLR-14362:
--

Robert, I tested this. It works. I did a quick check by patching SoltTestCase 
to set the sysprop first. After that all tests work.

It's mainly the broken way how log4j2 tries to resolve the file, using a series 
of different ways how to interpret the classpath.

> Tests no longer run with whitespace in Solr's checkout directory
> 
>
> Key: SOLR-14362
> URL: https://issues.apache.org/jira/browse/SOLR-14362
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Affects Versions: master (9.0)
>Reporter: Uwe Schindler
>Priority: Major
>
> When trying to run the test suite from a directory with white-space in the 
> path name, SolrTestCase does not load at all:
> {noformat}
>[junit4] ERROR   0.00s J3 | SearchHandlerTest (suite) <<<
>[junit4]> Throwable #1: java.security.AccessControlException: access 
> denied ("java.io.FilePermission" 
> "C:\Users\Uwe%20Schindler\Projects\lucene\trunk-lusolr1\solr\core\src\test-files\log4j2.xml"
>  "read")
>[junit4]>at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>[junit4]>at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>[junit4]>at 
> java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:661)
>[junit4]>at java.base/java.io.File.exists(File.java:815)
>[junit4]>at 
> org.apache.logging.log4j.core.util.FileUtils.fileFromUri(FileUtils.java:88)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationSource.fromResource(ConfigurationSource.java:281)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:449)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:386)
>[junit4]>at 
> org.apache.logging.log4j.core.config.ConfigurationFactory.getConfiguration(ConfigurationFactory.java:261)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:616)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:637)
>[junit4]>at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:153)
>[junit4]>at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
>[junit4]>at 
> org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getContext(AbstractLoggerAdapter.java:121)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getContext(Log4jLoggerFactory.java:43)
>[junit4]>at 
> org.apache.logging.log4j.spi.AbstractLoggerAdapter.getLogger(AbstractLoggerAdapter.java:46)
>[junit4]>at 
> org.apache.logging.slf4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:29)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:358)
>[junit4]>at 
> org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
>[junit4]>at 
> org.apache.solr.SolrTestCase.(SolrTestCase.java:66)
>[junit4]>at java.base/java.lang.Class.forName0(Native Method)
>[junit4]>at java.base/java.lang.Class.forName(Class.java:398)
>[junit4] Completed [1/907 (1!)] on J3 in 1.73s, 0 tests, 1 error <<< 
> FAILURES!
> {noformat}
> This is a new issue and seems to be introduced not long ago. The last time I 
> ran tests, it worked. Does anybody know what changed? To me it looks like 
> there is some wrong encoding involved.



--
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-14340) ZkStateReader.readConfigName is doing too much work

2020-03-24 Thread David Smiley (Jira)


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

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

Thanks [~matmarie] for your 2nd contribution!  (Mathieu is a close colleague of 
mine).

We'll see who has time to move the config name to state.json where it ought to 
have been all along.  I don't have time for that in the immediate future.

> ZkStateReader.readConfigName is doing too much work
> ---
>
> Key: SOLR-14340
> URL: https://issues.apache.org/jira/browse/SOLR-14340
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.6
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ZkStateReader.readConfigName reads the configSet name given a collection name 
> parameter.  Simple.  It's doing too much work to do this though.  First it's 
> calling zkClient.exists() which is redundant given that we then call getData 
> will will detect if it doesn't exist.  Then we validate that the config path 
> exists.  But I don't think that should be verified on read, only on write.  
> This method is a hotspot for nodes with lots of cores, proven out with 
> profiling.
> Ideally the configSet name ought to be moved to state.json which is where all 
> the other collection metadata is and is thus already read by most spots that 
> want to read the configSet name.  That would speed things up further and 
> generally simplify things as well.  That can happen on a follow-on issue, I 
> think.



--
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-8962) Can we merge small segments during refresh, for faster searching?

2020-03-24 Thread David Smiley (Jira)


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

David Smiley commented on LUCENE-8962:
--

I see this in 8.5 CHANGES.txt yet this issue isn't "Closed".  So in CHANGES.txt 
wrong or the Jira status?

> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch
>
>  Time Spent: 9.5h
>  Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory 
> segments to disk and open an {{IndexReader}} to search them, and this is 
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}} 
> will accumulate write many small segments during {{refresh}} and this then 
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if 
> given a little time ... so, could we somehow improve {{IndexWriter'}}s 
> refresh to optionally kick off merge policy to merge segments below some 
> threshold before opening the near-real-time reader?  It'd be a bit tricky 
> because while we are waiting for merges, indexing may continue, and new 
> segments may be flushed, but those new segments shouldn't be included in the 
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy, 
> and some hackity logic to have the merge policy target small segments just 
> written by refresh, but it's tricky to then open a near-real-time reader, 
> excluding newly flushed but including newly merged segments since the refresh 
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for 
> discussion!



--
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-9198) Remove news section from TLP website

2020-03-24 Thread David Smiley (Jira)


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

David Smiley commented on LUCENE-9198:
--

Major version releases are front-page worthy IMO.

> Remove news section from TLP website
> 
>
> Key: LUCENE-9198
> URL: https://issues.apache.org/jira/browse/LUCENE-9198
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: new-tlp-conditional-news.png, 
> new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the front page [https://lucene.apache.org|https://lucene.apache.org/] we 
> today show a list of TLP news.
> For every release we author one news article for Solr, one news article for 
> LuceneCore, and one news article for TLP site, combining the two.
> In all these years we have never published a news item to TLP that is not a 
> release announcement, except in 2014 when we announced that OpenRelevance sub 
> project closed.
> I thus propose to remove this news section, and replace it with two widgets 
> that automatically display the last 5 news headings from LuceneCore, Solr and 
> PyLucene sub projects.
> If we have an important TLP announcement to make at some point, that can be 
> done right there on the front page, not?



--
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-14361) SIP-4 Solr should own the bootstrap process

2020-03-24 Thread Jira


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

Jan Høydahl commented on SOLR-14361:


The SIP main page 
https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals 
only listed 3 so I filled in the next available number in the table.
I see now that there are some orphan child pages that are not listed in the 
table. Can you please fix that and at the same time re-number my SIP to SIP-6? 
I will change the subject of the mail thread.

> SIP-4 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-4.|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]
> The overall design and planning will happen on the Confluence page.
> Consept and architecture discussions can happen in the dev@ mail thread 
> linked from the SIP.
> This Jira will act as an umbrella/parent issue to track development and will 
> not have much activity until the SIP is finalized and approved.



--
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-9198) Remove news section from TLP website

2020-03-24 Thread Uwe Schindler (Jira)


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

Uwe Schindler commented on LUCENE-9198:
---

[~dsmiley]: they will still appear on front page. We're talking about the 
news.htnl page.

> Remove news section from TLP website
> 
>
> Key: LUCENE-9198
> URL: https://issues.apache.org/jira/browse/LUCENE-9198
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: new-tlp-conditional-news.png, 
> new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the front page [https://lucene.apache.org|https://lucene.apache.org/] we 
> today show a list of TLP news.
> For every release we author one news article for Solr, one news article for 
> LuceneCore, and one news article for TLP site, combining the two.
> In all these years we have never published a news item to TLP that is not a 
> release announcement, except in 2014 when we announced that OpenRelevance sub 
> project closed.
> I thus propose to remove this news section, and replace it with two widgets 
> that automatically display the last 5 news headings from LuceneCore, Solr and 
> PyLucene sub projects.
> If we have an important TLP announcement to make at some point, that can be 
> done right there on the front page, not?



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

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



[GitHub] [lucene-solr] dsmiley commented on issue #1366: SOLR-14342: Optimize core loading order in SolrCloud.

2020-03-24 Thread GitBox
dsmiley commented on issue #1366: SOLR-14342: Optimize core loading order in 
SolrCloud.
URL: https://github.com/apache/lucene-solr/pull/1366#issuecomment-603492062
 
 
   I'll commit in two days according to lazy concensus if there's no further 
input.
   
   The original issue was filed as a bug fix with a CHANGES.txt entry: "In 
cloud-mode sort the cores smartly before loading & limit threads to improve 
cluster stability".
   
   There were aspects to the original other than core load order -- namely 
limiting the number of threads that load cores at once from 24 to 8.
   
   I don't really think of core load order as a bug fix even if it helps with 
stability because this is a best-effort sort of thing.  It's an improvement 
(perhaps optimization).  AFAICT users would see this during cross-cluster 
simultaneous node startup but also to a degree even the local node since some 
collections should come online quickly if there isn't agreement needed on other 
nodes.  
   
   Proposed CHANGES entry:
   Improvement:
   * Load cores in an order that makes collections available sooner and reduces 
leaderVoteWait timeouts in large SolrCloud clusters.


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


With regards,
Apache Git Services

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



[jira] [Commented] (LUCENE-9198) Remove news section from TLP website

2020-03-24 Thread Jira


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

Jan Høydahl commented on LUCENE-9198:
-

That's right, the latest 3 Lucene and Solr news items already show, and will 
cover all releases.

See this comment for how a TLP news items will be shown on the front page below 
Lucene/Solr specific news, but only if marked with the special attribute 
frontpage:true in the header of the news markdown file itself. Right now none 
of the TLP news items have this, so no TLP news are shown.

> Remove news section from TLP website
> 
>
> Key: LUCENE-9198
> URL: https://issues.apache.org/jira/browse/LUCENE-9198
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: new-tlp-conditional-news.png, 
> new-tlp-frontpage-layout.png, new-tlp-frontpage-layout.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> On the front page [https://lucene.apache.org|https://lucene.apache.org/] we 
> today show a list of TLP news.
> For every release we author one news article for Solr, one news article for 
> LuceneCore, and one news article for TLP site, combining the two.
> In all these years we have never published a news item to TLP that is not a 
> release announcement, except in 2014 when we announced that OpenRelevance sub 
> project closed.
> I thus propose to remove this news section, and replace it with two widgets 
> that automatically display the last 5 news headings from LuceneCore, Solr and 
> PyLucene sub projects.
> If we have an important TLP announcement to make at some point, that can be 
> done right there on the front page, not?



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

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



[jira] [Updated] (SOLR-14361) SIP-6 Solr should own the bootstrap process

2020-03-24 Thread Jira


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

Jan Høydahl updated SOLR-14361:
---
Description: 
This is the JIRA corresponding to 
[SIP-6|https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process].

The overall design and planning will happen on the Confluence page.

Consept and architecture discussions can happen in the dev@ mail thread linked 
from the SIP.

This Jira will act as an umbrella/parent issue to track development and will 
not have much activity until the SIP is finalized and approved.

  was:
This is the JIRA corresponding to 
[SIP-4.|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Solr+should+own+the+bootstrap+process]

The overall design and planning will happen on the Confluence page.

Consept and architecture discussions can happen in the dev@ mail thread linked 
from the SIP.

This Jira will act as an umbrella/parent issue to track development and will 
not have much activity until the SIP is finalized and approved.

Summary: SIP-6 Solr should own the bootstrap process  (was: SIP-4 Solr 
should own the bootstrap process)

> SIP-6 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-6|https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process].
> The overall design and planning will happen on the Confluence page.
> Consept and architecture discussions can happen in the dev@ mail thread 
> linked from the SIP.
> This Jira will act as an umbrella/parent issue to track development and will 
> not have much activity until the SIP is finalized and approved.



--
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] (SOLR-14361) SIP-6 Solr should own the bootstrap process

2020-03-24 Thread Jira


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

Jan Høydahl edited comment on SOLR-14361 at 3/24/20, 11:32 PM:
---

The SIP main page 
https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals 
only listed 3 so I filled in the next available number in the table :) I see 
now that there are some orphan child pages that are not listed in the table. I 
went ahead and renamed this as SIP-6. Can you please add SIP-4 and SIP-5 to the 
table on the main SIP page?


was (Author: janhoy):
The SIP main page 
https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals 
only listed 3 so I filled in the next available number in the table.
I see now that there are some orphan child pages that are not listed in the 
table. Can you please fix that and at the same time re-number my SIP to SIP-6? 
I will change the subject of the mail thread.

> SIP-6 Solr should own the bootstrap process
> ---
>
> Key: SOLR-14361
> URL: https://issues.apache.org/jira/browse/SOLR-14361
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jan Høydahl
>Priority: Major
>
> This is the JIRA corresponding to 
> [SIP-6|https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process].
> The overall design and planning will happen on the Confluence page.
> Consept and architecture discussions can happen in the dev@ mail thread 
> linked from the SIP.
> This Jira will act as an umbrella/parent issue to track development and will 
> not have much activity until the SIP is finalized and approved.



--
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-14325) Core status could be improved to not require an IndexSearcher

2020-03-24 Thread David Smiley (Jira)


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

David Smiley commented on SOLR-14325:
-

Surprising observation: I changed the default of indexInfo to false and all 
tests pass (*).  That's not a great thing; it suggests a possible gap in the 
tests, but it at least suggests SolrCloud/metrics do not depend on this. 

I confess I'm less interested in this issue relative to other issues vying for 
my attention.  For your use-case, can you call cluster status first to see who 
is in recovery and then conditionally get indexInfo on those not in recovery?

(*) Details: StatusOp.java "isIndexInfoNeeded" variable (line 38), and 
CoreAdminRequest.java "isIndexInfoNeeded" field (line 44), 
CoreAdminRequest.java getCoreStatus true->false (line 635), 
CoreAdminHandlerTest true->false (line 372).

> Core status could be improved to not require an IndexSearcher
> -
>
> Key: SOLR-14325
> URL: https://issues.apache.org/jira/browse/SOLR-14325
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-14325.patch, SOLR-14325.patch, SOLR-14325.patch
>
>
> When the core status is told to request "indexInfo", it currently grabs the 
> SolrIndexSearcher but only to grab the Directory.  SolrCore.getIndexSize also 
> only requires the Directory.  By insisting on a SolrIndexSearcher, we 
> potentially block for awhile if the core is in recovery since there is no 
> SolrIndexSearcher.
> [https://lists.apache.org/thread.html/r076218c964e9bd6ed0a53133be9170c3cf36cc874c1b4652120db417%40%3Cdev.lucene.apache.org%3E]
> It'd be nice to have a solution that conditionally used the Directory of the 
> SolrIndexSearcher only if it's present so that we don't waste time creating 
> one either.



--
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] [Moved] (LUCENE-9289) Speed up Levenshtein distance calculation when we don't need the exact distance

2020-03-24 Thread David Smiley (Jira)


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

David Smiley moved SOLR-14360 to LUCENE-9289:
-

  Key: LUCENE-9289  (was: SOLR-14360)
Lucene Fields: New
  Project: Lucene - Core  (was: Solr)
 Security: (was: Public)

> Speed up Levenshtein distance calculation when we don't need the exact 
> distance
> ---
>
> Key: LUCENE-9289
> URL: https://issues.apache.org/jira/browse/LUCENE-9289
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14360-01.patch
>
>
> Sometimes when we calculate the Levenshtein distance we don't need the exact 
> distance, we only want to know if the strings are similar enough.
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/spelling/SolrSpellChecker.java#L113-L114]
> {noformat}
> sug.score = sd.getDistance(original, sug.string);
> if (sug.score < min) continue; {noformat}
> If we use this threshold in the distance calculation, we can speed it up, we 
> can stop the calculation when we already know that the the the distance will 
> be lower than the threshold.



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

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



[jira] [Updated] (LUCENE-9289) Speed up Levenshtein distance calculation when we don't need the exact distance

2020-03-24 Thread David Smiley (Jira)


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

David Smiley updated LUCENE-9289:
-
Component/s: modules/spellchecker

> Speed up Levenshtein distance calculation when we don't need the exact 
> distance
> ---
>
> Key: LUCENE-9289
> URL: https://issues.apache.org/jira/browse/LUCENE-9289
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spellchecker
>Reporter: Andras Salamon
>Priority: Minor
> Attachments: SOLR-14360-01.patch
>
>
> Sometimes when we calculate the Levenshtein distance we don't need the exact 
> distance, we only want to know if the strings are similar enough.
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/spelling/SolrSpellChecker.java#L113-L114]
> {noformat}
> sug.score = sd.getDistance(original, sug.string);
> if (sug.score < min) continue; {noformat}
> If we use this threshold in the distance calculation, we can speed it up, we 
> can stop the calculation when we already know that the the the distance will 
> be lower than the threshold.



--
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-14147) enable security manager by default

2020-03-24 Thread Marcus Eagan (Jira)


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

Marcus Eagan commented on SOLR-14147:
-

[~ctargett]no objection. Sorry for the delay!

> enable security manager by default
> --
>
> Key: SOLR-14147
> URL: https://issues.apache.org/jira/browse/SOLR-14147
> Project: Solr
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
>  Time Spent: 6h 20m
>  Remaining Estimate: 0h
>
> For 9.0, set SOLR_SECURITY_MANAGER_ENABLED=true by default. Remove the step 
> from securing solr page as it will be done by default (defaults become safe). 
> Users can disable if they are running hadoop or doing other crazy stuff.



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