[jira] [Commented] (SOLR-14333) Implement toString() in CollapsingPostFilter
[
https://issues.apache.org/jira/browse/SOLR-14333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063824#comment-17063824
]
Guna Sekhar Dora commented on SOLR-14333:
-
[~munendrasn] I'll take this up.
> Implement toString() in CollapsingPostFilter
>
>
> Key: SOLR-14333
> URL: https://issues.apache.org/jira/browse/SOLR-14333
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Priority: Major
>
> {{toString()}} is not overridden in CollapsingPostFilter. Debug component
> returns {{parsed_filter_queries}}, for multiple CollapsingPostFilter in
> request, value in {{parsed_filter_queries}} is always
> {{CollapsingPostFilter()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dweiss commented on issue #1367: ivy settings: local maven repo pattern needs classifier
dweiss commented on issue #1367: ivy settings: local maven repo pattern needs classifier URL: https://github.com/apache/lucene-solr/pull/1367#issuecomment-602020903 LGTM. Thanks David. 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 opened a new pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query
gunasekhardora opened a new pull request #1371: SOLR-14333: print readable version of CollapsedPostFilter query URL: https://github.com/apache/lucene-solr/pull/1371 # Description Prints a readable version of parsed_filter_queries in CollapsedPostFilter query # Solution The debug response will now be in the lines of ``` "parsed_filter_queries": [ "CollapsingPostFilter(!collapse field=id, nullPolicy=expand, groupHeadSelector=_version_ asc, size=100)" ] ``` # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [x] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14333) Implement toString() in CollapsingPostFilter
[
https://issues.apache.org/jira/browse/SOLR-14333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063832#comment-17063832
]
Guna Sekhar Dora commented on SOLR-14333:
-
[~munendrasn] Added a fix for this at
[https://github.com/apache/lucene-solr/pull/1371]. Please review.
> Implement toString() in CollapsingPostFilter
>
>
> Key: SOLR-14333
> URL: https://issues.apache.org/jira/browse/SOLR-14333
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{toString()}} is not overridden in CollapsingPostFilter. Debug component
> returns {{parsed_filter_queries}}, for multiple CollapsingPostFilter in
> request, value in {{parsed_filter_queries}} is always
> {{CollapsingPostFilter()}}
--
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-9286) FST construction explodes memory in BitTable
Dawid Weiss created LUCENE-9286: --- Summary: FST construction explodes memory in BitTable Key: LUCENE-9286 URL: https://issues.apache.org/jira/browse/LUCENE-9286 Project: Lucene - Core Issue Type: Bug Reporter: Dawid Weiss I see a dramatic increase in the amount of memory required for construction of (arguably large) automata. It currently OOMs with 8GB of memory consumed for bit tables. I am pretty sure this didn't require so much momory before (the automata is ~50MB after construction). Something bad happened in between. [~broustant]? -- 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-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9286: Attachment: screen-[1].png > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much momory before > (the automata is ~50MB after construction). > Something bad happened in between. [~broustant]? -- 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-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9286: Affects Version/s: 8.5 > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much momory before > (the automata is ~50MB after construction). > Something bad happened in between. [~broustant]? -- 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-site] alessandrobenedetti opened a new pull request #18: Alessandro Benedetti new committer
alessandrobenedetti opened a new pull request #18: Alessandro Benedetti new committer URL: https://github.com/apache/lucene-site/pull/18 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] mikemccand commented on issue #1361: LUCENE-8118: Throw exception if DWPT grows beyond it's maximum ram limit
mikemccand commented on issue #1361: LUCENE-8118: Throw exception if DWPT grows beyond it's maximum ram limit URL: https://github.com/apache/lucene-solr/pull/1361#issuecomment-602027021 > > 1. fixing exception handling in DW.updateDocuments to handle this exception gracefully (non-aborting). > > the problem in this method was that we need to flush the DWPT to disk even if we hit an non-aborting exception. Otherwise the next doc would hit the same exception or we would violate the assumption that we never receive a flush pending DWPT. Thanks for the explanation; make sense. > One thing that I keep thinking about is what happens if we index documents close to the limit and then the next batch of documents would exceed that limit. That would mean that we reject docs event though we could index them into a different DWPT. Should we at least try to index it again in a fresh DWPT unless the DWPT that rejected it was empty? I mean that would prevent the issue and should be straight forward to implement. I can work on this in a followup. +1, that's an awesome idea! In general when picking among the N free DWPTs when a new document arrives shouldn't we pick the DWPT that's smallest (least `.ramBytesUsed()`)? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9286: Description: I see a dramatic increase in the amount of memory required for construction of (arguably large) automata. It currently OOMs with 8GB of memory consumed for bit tables. I am pretty sure this didn't require so much memory before (the automaton is ~50MB after construction). Something bad happened in between. Thoughts, [~broustant][[~sokolov]? was: I see a dramatic increase in the amount of memory required for construction of (arguably large) automata. It currently OOMs with 8GB of memory consumed for bit tables. I am pretty sure this didn't require so much momory before (the automata is ~50MB after construction). Something bad happened in between. [~broustant]? > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant][[~sokolov]? -- 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-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9286: Description: I see a dramatic increase in the amount of memory required for construction of (arguably large) automata. It currently OOMs with 8GB of memory consumed for bit tables. I am pretty sure this didn't require so much memory before (the automaton is ~50MB after construction). Something bad happened in between. Thoughts, [~broustant], [~sokolov]? was: I see a dramatic increase in the amount of memory required for construction of (arguably large) automata. It currently OOMs with 8GB of memory consumed for bit tables. I am pretty sure this didn't require so much memory before (the automaton is ~50MB after construction). Something bad happened in between. Thoughts, [~broustant][[~sokolov]? > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- 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] (LUCENE-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss reassigned LUCENE-9286: --- Assignee: Dawid Weiss > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- 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-13492) Disallow explicit GC by default during Solr startup
[ https://issues.apache.org/jira/browse/SOLR-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063904#comment-17063904 ] Erick Erickson commented on SOLR-13492: --- Sorry to chime in late here, but I'm -1 on this if this will disable, say, pressing the "gc now" button from jconsole or similar. When troubleshooting memory issues, there are many times I want to see what happens to memory after an explicit operation. At times this is in a production system, and having to restart with different settings here is not necessarily possible. Also, this is only one of a million ways people can shoot themselves in the foot with custom code. This one is in the "might cause performance issues" rather than the "will cause horrible problems" category. I'd change to +/- 0 of you can verify that external tools like jconsole _will_ still allow GC to be invoked externally. > Disallow explicit GC by default during Solr startup > --- > > Key: SOLR-13492 > URL: https://issues.apache.org/jira/browse/SOLR-13492 > Project: Solr > Issue Type: Improvement > Components: scripts and tools >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Solr should use the -XX:+DisableExplicitGC option as part of its default GC > tuning. > None of Solr's stock code uses explicit GCs, so that option will have no > effect on most installs. The effective result of this is that if somebody > adds custom code to Solr and THAT code does an explicit GC, it won't be > allowed to function. -- 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-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063920#comment-17063920 ] Bruno Roustant commented on LUCENE-9286: We expect to not take more memory than before, some tests verify that in some cases. [~dweiss] would you have a test to reproduce? I'd like to debug that, but I'll need an idea of the data used to build the FST. Another option could be that I share some code that add traces so that you can run it and provide those stats. > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- 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 merged pull request #1367: ivy settings: local maven repo pattern needs classifier
dsmiley merged pull request #1367: ivy settings: local maven repo pattern needs classifier URL: https://github.com/apache/lucene-solr/pull/1367 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-9286) FST construction explodes memory in BitTable
[ https://issues.apache.org/jira/browse/LUCENE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063975#comment-17063975 ] Dawid Weiss commented on LUCENE-9286: - Let me try to reproduce it or at least confirm my suspicion that it used to me much more memory conservative. Thanks Bruno. > FST construction explodes memory in BitTable > > > Key: LUCENE-9286 > URL: https://issues.apache.org/jira/browse/LUCENE-9286 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 8.5 >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Attachments: screen-[1].png > > > I see a dramatic increase in the amount of memory required for construction > of (arguably large) automata. It currently OOMs with 8GB of memory consumed > for bit tables. I am pretty sure this didn't require so much memory before > (the automaton is ~50MB after construction). > Something bad happened in between. Thoughts, [~broustant], [~sokolov]? -- 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
