[jira] [Created] (SOLR-13591) AlreadyClosedException in SolrJ
Markus Jelsma created SOLR-13591:
Summary: AlreadyClosedException in SolrJ
Key: SOLR-13591
URL: https://issues.apache.org/jira/browse/SOLR-13591
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 8.1.1
Reporter: Markus Jelsma
Fix For: master (9.0), 8.2
Since upgrading from 7.7 to 8.1, we regulary get the following exception in
SolrJ. The message is null, the stack trace is:
{code}
org.apache.solr.common.AlreadyClosedException
at
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getZkStateReader(ZkClientClusterStateProvider.java:165)
at
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.connect(BaseCloudSolrClient.java:329)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:779)
at
org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769)
at
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
{code}
The clients are always 8.1.1, the servers are either 7.5 or 8.1.1. There are no
indications in the server logs, although they are set to log level WARN.
We run Zookeeper 3.4.13.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804768#comment-16804768 ] Markus Jelsma commented on LUCENE-8745: --- Hello Alan, i am not sure, but probably. It appears i would have to extend the class but i have no idea how to embed that in a Solr analyzer chain. With this patch i can just flip the switch with a search and replace throughout the schema.xml. Thanks > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8740) AssertionError FlattenGraphFilter
[ https://issues.apache.org/jira/browse/LUCENE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804763#comment-16804763 ] Markus Jelsma commented on LUCENE-8740: --- Hello Michael, it looks very similar indeed. However, my unit test case requires MinHash to be present at the tail of the chain. Perhaps a fix for that issue fixes this one as well! > AssertionError FlattenGraphFilter > - > > Key: LUCENE-8740 > URL: https://issues.apache.org/jira/browse/LUCENE-8740 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.5, 8.0 >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8740.patch > > > Our unit tests picked up an unusual AssertionError in FlattenGraphFilter > which manifests itself only in very specific circumstances involving > WordDelimiterGraph, StopFilter, FlattenGraphFilter and MinhashFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8741) ClassCastException in ValueSource$ScoreAndDoc
[
https://issues.apache.org/jira/browse/LUCENE-8741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804762#comment-16804762
]
Markus Jelsma commented on LUCENE-8741:
---
Thanks Alan!
> ClassCastException in ValueSource$ScoreAndDoc
> -
>
> Key: LUCENE-8741
> URL: https://issues.apache.org/jira/browse/LUCENE-8741
> Project: Lucene - Core
> Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Markus Jelsma
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 8.1, master (9.0)
>
> Attachments: LUCENE-8741.patch
>
>
> Upgrading to Apache Solr/Lucene 8.0, this popped up in our unit tests:
> {code}
> Caused by: java.lang.ClassCastException:
> org.apache.lucene.queries.function.ValueSource$ScoreAndDoc cannot be cast to
> org.apache.lucene.search.Scorer
> at
> org.apache.lucene.queries.function.ValueSource$FromDoubleValuesSource.getValues(ValueSource.java:288)
> at
> org.apache.lucene.queries.function.valuesource.MultiFloatFunction.getValues(MultiFloatFunction.java:76)
> at
> org.apache.lucene.queries.function.valuesource.ReciprocalFloatFunction.getValues(ReciprocalFloatFunction.java:64)
> at
> org.apache.lucene.queries.function.valuesource.MultiFloatFunction.getValues(MultiFloatFunction.java:76)
> at
> org.apache.lucene.queries.function.ValueSource$WrappedDoubleValuesSource.getValues(ValueSource.java:203)
> at
> org.apache.lucene.queries.function.FunctionScoreQuery$MultiplicativeBoostValuesSource.getValues(FunctionScoreQuery.java:248)
> at
> org.apache.lucene.queries.function.FunctionScoreQuery$FunctionScoreWeight.scorer(FunctionScoreQuery.java:211)
> at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:143)
> at
> org.apache.lucene.search.BooleanWeight.scorerSupplier(BooleanWeight.java:374)
> at
> org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:340)
> at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
> at
> org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:334)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
> at
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> {code}
> It only happens when, edismax, we boost by geodist:
> {code}
> recip(max(100,geodist()),1,10,1)
> {code}
> http://mail-archives.apache.org/mod_mbox/lucene-java-user/201903.mbox/browser
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Attachment: LUCENE-8745.patch > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Environment: (was: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave.) > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
[ https://issues.apache.org/jira/browse/LUCENE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8745: -- Description: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave. > SynonymGraphFilter to optionally skip keywords > -- > > Key: LUCENE-8745 > URL: https://issues.apache.org/jira/browse/LUCENE-8745 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8745.patch > > > Right now, SynonymGraphFilter operates on the original input term, and the > repeated term that is marked as Keyword. This issue is to optionally keep it > from operating on the term marked as Keyword, just as like stemmers (should) > behave. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8745) SynonymGraphFilter to optionally skip keywords
Markus Jelsma created LUCENE-8745: - Summary: SynonymGraphFilter to optionally skip keywords Key: LUCENE-8745 URL: https://issues.apache.org/jira/browse/LUCENE-8745 Project: Lucene - Core Issue Type: Improvement Environment: Right now, SynonymGraphFilter operates on the original input term, and the repeated term that is marked as Keyword. This issue is to optionally keep it from operating on the term marked as Keyword, just as like stemmers (should) behave. Reporter: Markus Jelsma Fix For: 8.1, master (9.0) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8741) ClassCastException in ValueSource$ScoreAndDoc
Markus Jelsma created LUCENE-8741:
-
Summary: ClassCastException in ValueSource$ScoreAndDoc
Key: LUCENE-8741
URL: https://issues.apache.org/jira/browse/LUCENE-8741
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 8.0
Reporter: Markus Jelsma
Fix For: 8.1, master (9.0)
Upgrading to Apache Solr/Lucene 8.0, this popped up in our unit tests:
{code}
Caused by: java.lang.ClassCastException:
org.apache.lucene.queries.function.ValueSource$ScoreAndDoc cannot be cast to
org.apache.lucene.search.Scorer
at
org.apache.lucene.queries.function.ValueSource$FromDoubleValuesSource.getValues(ValueSource.java:288)
at
org.apache.lucene.queries.function.valuesource.MultiFloatFunction.getValues(MultiFloatFunction.java:76)
at
org.apache.lucene.queries.function.valuesource.ReciprocalFloatFunction.getValues(ReciprocalFloatFunction.java:64)
at
org.apache.lucene.queries.function.valuesource.MultiFloatFunction.getValues(MultiFloatFunction.java:76)
at
org.apache.lucene.queries.function.ValueSource$WrappedDoubleValuesSource.getValues(ValueSource.java:203)
at
org.apache.lucene.queries.function.FunctionScoreQuery$MultiplicativeBoostValuesSource.getValues(FunctionScoreQuery.java:248)
at
org.apache.lucene.queries.function.FunctionScoreQuery$FunctionScoreWeight.scorer(FunctionScoreQuery.java:211)
at org.apache.lucene.search.Weight.scorerSupplier(Weight.java:143)
at
org.apache.lucene.search.BooleanWeight.scorerSupplier(BooleanWeight.java:374)
at org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:340)
at org.apache.lucene.search.Weight.bulkScorer(Weight.java:177)
at
org.apache.lucene.search.BooleanWeight.bulkScorer(BooleanWeight.java:334)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:649)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:443)
at
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
at
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
at
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1434)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:373)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
{code}
It only happens when, edismax, we boost by geodist:
{code}
recip(max(100,geodist()),1,10,1)
{code}
http://mail-archives.apache.org/mod_mbox/lucene-java-user/201903.mbox/browser
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8740) AssertionError FlattenGraphFilter
[ https://issues.apache.org/jira/browse/LUCENE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated LUCENE-8740: -- Attachment: LUCENE-8740.patch > AssertionError FlattenGraphFilter > - > > Key: LUCENE-8740 > URL: https://issues.apache.org/jira/browse/LUCENE-8740 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.5, 8.0 >Reporter: Markus Jelsma >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: LUCENE-8740.patch > > > Our unit tests picked up an unusual AssertionError in FlattenGraphFilter > which manifests itself only in very specific circumstances involving > WordDelimiterGraph, StopFilter, FlattenGraphFilter and MinhashFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8740) AssertionError FlattenGraphFilter
Markus Jelsma created LUCENE-8740: - Summary: AssertionError FlattenGraphFilter Key: LUCENE-8740 URL: https://issues.apache.org/jira/browse/LUCENE-8740 Project: Lucene - Core Issue Type: Bug Affects Versions: 8.0, 7.5 Reporter: Markus Jelsma Fix For: 8.1, master (9.0) Our unit tests picked up an unusual AssertionError in FlattenGraphFilter which manifests itself only in very specific circumstances involving WordDelimiterGraph, StopFilter, FlattenGraphFilter and MinhashFilter. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13265) TLOG replica, updateHandler errors in metrics, no logs
Markus Jelsma created SOLR-13265: Summary: TLOG replica, updateHandler errors in metrics, no logs Key: SOLR-13265 URL: https://issues.apache.org/jira/browse/SOLR-13265 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.7, 7.5 Reporter: Markus Jelsma Fix For: master (9.0) When indexing, we see UPDATE.updateHandler.errors increment for each document being indexed, there is nothing in the logs. This happens only to TLOG replica's, the NRT is unaffected. Nothing bad is happening, but this is messing up our Grafana graphs that we use to check the health. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13265) TLOG replica, updateHandler errors in metrics, no logs
[ https://issues.apache.org/jira/browse/SOLR-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-13265: - Description: When indexing, we see UPDATE.updateHandler.errors increment for each document being indexed, there is nothing in the logs. This happens only to TLOG replica's, the NRT is unaffected. 7.5 and 7.7 both have the problem. Nothing bad is happening, but this is messing up our Grafana graphs that we use to check the health. was: When indexing, we see UPDATE.updateHandler.errors increment for each document being indexed, there is nothing in the logs. This happens only to TLOG replica's, the NRT is unaffected. Nothing bad is happening, but this is messing up our Grafana graphs that we use to check the health. > TLOG replica, updateHandler errors in metrics, no logs > -- > > Key: SOLR-13265 > URL: https://issues.apache.org/jira/browse/SOLR-13265 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.5, 7.7 >Reporter: Markus Jelsma >Priority: Major > Fix For: master (9.0) > > > When indexing, we see UPDATE.updateHandler.errors increment for each document > being indexed, there is nothing in the logs. > This happens only to TLOG replica's, the NRT is unaffected. 7.5 and 7.7 both > have the problem. > Nothing bad is happening, but this is messing up our Grafana graphs that we > use to check the health. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 25.1-jre
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16772432#comment-16772432 ] Markus Jelsma commented on SOLR-11763: -- Thanks! > Upgrade Guava to 25.1-jre > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Markus Jelsma >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.x, master (9.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch, SOLR-11763.patch, > SOLR-11763.patch, SOLR-11763.patch > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13249) ByteArrayUtf8CharSequence.getStringOrNull returns null
[ https://issues.apache.org/jira/browse/SOLR-13249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16771838#comment-16771838 ] Markus Jelsma commented on SOLR-13249: -- Thanks! > ByteArrayUtf8CharSequence.getStringOrNull returns null > --- > > Key: SOLR-13249 > URL: https://issues.apache.org/jira/browse/SOLR-13249 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Markus Jelsma >Assignee: Noble Paul >Priority: Minor > Fix For: 8.0 > > > I have an URP that, in processAdd(), gets a field value via > SolrInputField.getValue(). In a normal unit test this yields me a String. But > in a distributed test i get a ByteArrayUtf8CharSequence. > If it is a ByteArrayUtf8CharSequence the getStringOrNull() method always > returns null unless some internal method called _getStr first. > This is either by design or a mistake. If it is a mistake, then the fix is to > use toString() and the getStringOrNull() method can be removed (it would > become a duplicate for toString(). If it is by design, then nothing is > obvious from the JavaDoc and it should clarify. > This is since 7.7.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13249) ByteArrayUtf8CharSequence.getStringOrNull returns null
[ https://issues.apache.org/jira/browse/SOLR-13249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-13249: - Priority: Minor (was: Major) > ByteArrayUtf8CharSequence.getStringOrNull returns null > --- > > Key: SOLR-13249 > URL: https://issues.apache.org/jira/browse/SOLR-13249 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.7 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 8.0 > > > I have an URP that, in processAdd(), gets a field value via > SolrInputField.getValue(). In a normal unit test this yields me a String. But > in a distributed test i get a ByteArrayUtf8CharSequence. > If it is a ByteArrayUtf8CharSequence the getStringOrNull() method always > returns null unless some internal method called _getStr first. > This is either by design or a mistake. If it is a mistake, then the fix is to > use toString() and the getStringOrNull() method can be removed (it would > become a duplicate for toString(). If it is by design, then nothing is > obvious from the JavaDoc and it should clarify. > This is since 7.7.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13249) ByteArrayUtf8CharSequence.getStringOrNull returns null
Markus Jelsma created SOLR-13249: Summary: ByteArrayUtf8CharSequence.getStringOrNull returns null Key: SOLR-13249 URL: https://issues.apache.org/jira/browse/SOLR-13249 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.7 Reporter: Markus Jelsma Fix For: 8.0 I have an URP that, in processAdd(), gets a field value via SolrInputField.getValue(). In a normal unit test this yields me a String. But in a distributed test i get a ByteArrayUtf8CharSequence. If it is a ByteArrayUtf8CharSequence the getStringOrNull() method always returns null unless some internal method called _getStr first. This is either by design or a mistake. If it is a mistake, then the fix is to use toString() and the getStringOrNull() method can be removed (it would become a duplicate for toString(). If it is by design, then nothing is obvious from the JavaDoc and it should clarify. This is since 7.7.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 25.1-jre
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762540#comment-16762540 ] Markus Jelsma commented on SOLR-11763: -- Sigh, my apologies [~krisden], i didn't notice my revision was not completely fresh. The patch applies nicely! Thanks! > Upgrade Guava to 25.1-jre > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Markus Jelsma >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.x, master (9.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch, SOLR-11763.patch, > SOLR-11763.patch, SOLR-11763.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761841#comment-16761841
]
Markus Jelsma commented on SOLR-12743:
--
Thanks [~dsmiley]!
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760968#comment-16760968
]
Markus Jelsma commented on SOLR-12743:
--
Bad news, after having two nodes on 7.6 with LFUCache running fine for just
over 24 hours, both went nuts (41M Term instances, 2M PhraseQuery instances,
etc) and ran OOM, just about the same time, while just a few hundred documents
were being indexed.
It doesn't appear to be caused by LFUCache, we had two other 7.2.1 nodes also
on LFUCache, they are still running fine. So it seems that besides this issue,
we might have an even worse problem, one that i cannot reproduce locally nor
consistently on production, yesterday it happened immediately after start up,
now after 24 hours.
Reindexing the same Nutch segment when things went bad doesn't trigger a new
OOM. The heap eating went fast, the nodes died within minutes, just as
yesterday. There is nothing in the logs.
Is this something anyone else has had?
Thanks,
Markus
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 25.1-jre
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759947#comment-16759947 ] Markus Jelsma commented on SOLR-11763: -- The patch goes well for all files on master and 7.6 except lucene/ivy-versions.properties. I tried master and 7.6. > Upgrade Guava to 25.1-jre > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Markus Jelsma >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.x, master (9.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch, SOLR-11763.patch, > SOLR-11763.patch, SOLR-11763.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 25.1-jre
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759934#comment-16759934 ] Markus Jelsma commented on SOLR-11763: -- Hello [~krisden], the patch fails for 7.6 and master: checking file lucene/ivy-versions.properties Hunk #1 FAILED at 24. Hunk #2 succeeded at 33 (offset 1 line). Hunk #4 succeeded at 115 with fuzz 2 (offset -2 lines). Hunk #5 succeeded at 238 with fuzz 2 (offset 15 lines). 1 out of 5 hunks FAILED > Upgrade Guava to 25.1-jre > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Markus Jelsma >Assignee: Kevin Risden >Priority: Minor > Fix For: 8.x, master (9.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch, SOLR-11763.patch, > SOLR-11763.patch, SOLR-11763.patch > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759790#comment-16759790
]
Markus Jelsma edited comment on SOLR-12743 at 2/4/19 11:37 AM:
---
Hello all,
Because i can only reproduce it on production, i only have a limited number of
tries per day, it takes over an hour to test a minor change and more when i
need to revert. Here are some new notes:
* it doesn't "appear" to be caused by the metrics part, i took out everything
inside initializeMetrics(), but the leak persisted;
* i swapped FastLRU for LFU cache, otherwise same settings, the node ran OOM
within minutes even before the commit got issued;
* no idea what happened, but because Solr can run OOM for no clear reason,
restarted and tried again, *this time the otherwise leaking reference is
collected as it should*!
So i finally see a "stable" 7.6 with LFUCache instead of FastLRUCache. To be
clear, FastLRU does work without leaking, but only with a zero autoWarmCount.
I have no idea what is going on with the warming, the warming code is almost
identical and i can't see how a SolrIndexSearcher instance would leak with
FastLRU, but not with LFU. The CacheRegenerator is not leaking the reference,
nor the calling code in SolrCore seems to be the problem.
I'll keep this single node on 7.6 for now and keep an eye on it.
Thanks!
was (Author: markus17):
Hello all,
Because i can only reproduce it on production, i only have a limited number of
tries per day, it takes over an hour to test a minor change and more when i
need to revert. Here are some new notes:
* it doesn't "appear" to be caused by the metrics part, i took out everything
inside initializeMetrics(), but the leak persisted;
* i swapped FastLRU for LFU cache, otherwise same settings, the node ran OOM
within minutes even before the commit got issued;
* no idea what happened, but because Solr can run OOM for no clear reason,
restarted and tried again, this time the otherwise leaking reference is
collected as it should!
So i finally see a "stable" 7.6 with LFUCache instead of FastLRUCache. To be
clear, FastLRU does work without leaking, but only with a zero autoWarmCount.
I have no idea what is going on with the warming, the warming code is almost
identical and i can't see how a SolrIndexSearcher instance would leak with
FastLRU, but not with LFU. The CacheRegenerator is not leaking the reference,
nor the calling code in SolrCore seems to be the problem.
I'll keep this single node on 7.6 for now and keep an eye on it.
Thanks!
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> •
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16759790#comment-16759790
]
Markus Jelsma commented on SOLR-12743:
--
Hello all,
Because i can only reproduce it on production, i only have a limited number of
tries per day, it takes over an hour to test a minor change and more when i
need to revert. Here are some new notes:
* it doesn't "appear" to be caused by the metrics part, i took out everything
inside initializeMetrics(), but the leak persisted;
* i swapped FastLRU for LFU cache, otherwise same settings, the node ran OOM
within minutes even before the commit got issued;
* no idea what happened, but because Solr can run OOM for no clear reason,
restarted and tried again, this time the otherwise leaking reference is
collected as it should!
So i finally see a "stable" 7.6 with LFUCache instead of FastLRUCache. To be
clear, FastLRU does work without leaking, but only with a zero autoWarmCount.
I have no idea what is going on with the warming, the warming code is almost
identical and i can't see how a SolrIndexSearcher instance would leak with
FastLRU, but not with LFU. The CacheRegenerator is not leaking the reference,
nor the calling code in SolrCore seems to be the problem.
I'll keep this single node on 7.6 for now and keep an eye on it.
Thanks!
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16758193#comment-16758193
]
Markus Jelsma commented on SOLR-12743:
--
Hello [~mgibney],
# There are no blocked threads, nothing peculiar and nothing relating to
autowarming, caches whatsoever. There are as many searcherExecutor threads as
there are cores on the system, so it 'appears' it is not leaking threads but
just object instances;
# the system is in general not under heavy load at all;
# this specific collection, the one having this problem, does not have
autoCommit configured. This collection receives manual commits only, once every
15-20 minutes or so;
# there never are, overlapping commits on this system, maxWarmingSearchers was
set to 1 already many years ago. The instance is leaked during the first commit
after start up;
# precisely, the instance count increments at each commit, a forced GC does't
clean it up. A second commit 15-20 minutes later it increments again, up until
the nodes dies horribly.
Thanks!
Markus
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757133#comment-16757133
]
Markus Jelsma commented on SOLR-12743:
--
Hello [~mgibney],
I tried to pin down the problem once more, and can confirm a few things:
* disabling the FilterCache solves the SolrIndexSearcher leaks on commit;
* enabling the FilterCache with a zero autoWarmCount also solves the leak;
* the FilterCache with a modest autoWarmCount (128), opposed to a high count
(>2k) we had before, immediately leaks a SolrIndexSearcher instance on commit.
Unfortunately, the patch doesn't prevent the leaking.
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Attachments: SOLR-12743.patch
>
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755052#comment-16755052
]
Markus Jelsma commented on SOLR-12743:
--
Hello [~bjoernhaeuser], thanks for confirming.
I, sadly, confirm the problem persists with Solr 7.6.0. We still can not
reproduce it locally, not even if we take the index from production.
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13009) ExtendedSolrQueryParser cannot handle with KeywordRepeat, Synonyms and minShouldMatch
[
https://issues.apache.org/jira/browse/SOLR-13009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-13009:
-
Attachment: SOLR-13009-unittest.patch
> ExtendedSolrQueryParser cannot handle with KeywordRepeat, Synonyms and
> minShouldMatch
> -
>
> Key: SOLR-13009
> URL: https://issues.apache.org/jira/browse/SOLR-13009
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-13009-unittest.patch
>
>
> As described on the mailing list [1].
> Consider this example synonym set [bier,brouw] where bier means beer and
> brouw is the stemmed version of brouwsel (brewage, concoction), and consider
> these parameters on /select:
> {code}qf=content_nl=edismax=2<-1 5<-2 6<90%25{code}
> The queries q=bier and q=brouw both give the desired results. However, for
> q=brouwsel something (partially) unexpected happens:
> {code}+(((content_nl:brouwsel Synonym(content_nl:bier
> content_nl:brouw))~2)){code}
> This results in a BooleanQuery where, due to mm=2, both clauses need to
> match, giving very few matches. Removing KeywordRepeat or setting mm=1 of
> course fixes the problem, but that is not what we want.
> Will shortly attatch a patch containing a unit test proving the problem is
> real.
> [1]
> http://lucene.472066.n3.nabble.com/KeywordRepeat-stemming-single-term-synonyms-and-minimum-should-match-edismax-td4413690.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13009) ExtendedSolrQueryParser cannot handle with KeywordRepeat, Synonyms and minShouldMatch
Markus Jelsma created SOLR-13009:
Summary: ExtendedSolrQueryParser cannot handle with KeywordRepeat,
Synonyms and minShouldMatch
Key: SOLR-13009
URL: https://issues.apache.org/jira/browse/SOLR-13009
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Affects Versions: 7.5
Reporter: Markus Jelsma
Fix For: master (8.0)
As described on the mailing list [1].
Consider this example synonym set [bier,brouw] where bier means beer and brouw
is the stemmed version of brouwsel (brewage, concoction), and consider these
parameters on /select:
{code}qf=content_nl=edismax=2<-1 5<-2 6<90%25{code}
The queries q=bier and q=brouw both give the desired results. However, for
q=brouwsel something (partially) unexpected happens:
{code}+(((content_nl:brouwsel Synonym(content_nl:bier
content_nl:brouw))~2)){code}
This results in a BooleanQuery where, due to mm=2, both clauses need to match,
giving very few matches. Removing KeywordRepeat or setting mm=1 of course fixes
the problem, but that is not what we want.
Will shortly attatch a patch containing a unit test proving the problem is real.
[1]
http://lucene.472066.n3.nabble.com/KeywordRepeat-stemming-single-term-synonyms-and-minimum-should-match-edismax-td4413690.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12995) UnsupportedOperationException in HttpSolrCall.getRemotCoreUrl()
Markus Jelsma created SOLR-12995:
Summary: UnsupportedOperationException in
HttpSolrCall.getRemotCoreUrl()
Key: SOLR-12995
URL: https://issues.apache.org/jira/browse/SOLR-12995
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.5
Environment: Debian 9.3, OpenJDK Runtime Environment (build
1.8.0_181-8u181-b13-2~deb9u1-b13)
Reporter: Markus Jelsma
Fix For: master (8.0)
Spotted two of these in the logs of a production server. That collection's
other replicas didn't log this error. In all the logs, i have seen only two
occurences, just four minutes apart.
{code}
2018-11-07 16:14:04.340 ERROR (qtp831236296-1185) [ ] o.a.s.s.HttpSolrCall
null:java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)
at java.util.AbstractList.add(AbstractList.java:108)
at
org.apache.solr.servlet.HttpSolrCall.getRemotCoreUrl(HttpSolrCall.java:905)
at
org.apache.solr.servlet.HttpSolrCall.extractRemotePath(HttpSolrCall.java:431)
at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:288)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:469)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:531)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
at
org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661981#comment-16661981
]
Markus Jelsma commented on SOLR-12743:
--
Hello, [~bjoernhaeuser], just pinging again. Could you please verify if your
nodes are no longer leaking SolrIndexSearcher instances on commit? And can you
confirm that it was your problem to begin with? I am still not sure if you are
seeing the same problem as i have.
Thanks,
Markus
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12893) ExtendedSolrQueryParser.newFieldQuery does not use the specified analyzer
[
https://issues.apache.org/jira/browse/SOLR-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16658859#comment-16658859
]
Markus Jelsma commented on SOLR-12893:
--
Attached patch for master
> ExtendedSolrQueryParser.newFieldQuery does not use the specified analyzer
> -
>
> Key: SOLR-12893
> URL: https://issues.apache.org/jira/browse/SOLR-12893
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12893.patch
>
>
> {code}
> @Override
> protected Query newFieldQuery(Analyzer analyzer, String field, String
> queryText,
> boolean quoted, boolean
> fieldAutoGenPhraseQueries, boolean enableGraphQueries,
> SynonymQueryStyle synonymQueryStyle)
> throws SyntaxError {
> Analyzer actualAnalyzer;
> if (removeStopFilter) {
> if (nonStopFilterAnalyzerPerField == null) {
> nonStopFilterAnalyzerPerField = new HashMap<>();
> }
> actualAnalyzer = nonStopFilterAnalyzerPerField.get(field);
> if (actualAnalyzer == null) {
> actualAnalyzer = noStopwordFilterAnalyzer(field);
> }
> } else {
> actualAnalyzer =
> parser.getReq().getSchema().getFieldType(field).getQueryAnalyzer();
> }
> return super.newFieldQuery(actualAnalyzer, field, queryText, quoted,
> fieldAutoGenPhraseQueries, enableGraphQueries, synonymQueryStyle);
> }
> {code}
> The given Analyzer is not passed down to its super classes, preventing
> extending classes to construct their own modified analyzers (which i need).
> As a side, the nonStopFilterAnalyzerPerField cache is never filled, this
> patch also fixes that issue.
> Two tests fail:
>[junit4] -
> org.apache.solr.search.TestExtendedDismaxParser.testFocusQueryParser
>[junit4] - org.apache.solr.search.TestExtendedDismaxParser.testPfPs
> Specifically tests on pf3, i have no idea why so far.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12893) ExtendedSolrQueryParser.newFieldQuery does not use the specified analyzer
[
https://issues.apache.org/jira/browse/SOLR-12893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12893:
-
Attachment: SOLR-12893.patch
> ExtendedSolrQueryParser.newFieldQuery does not use the specified analyzer
> -
>
> Key: SOLR-12893
> URL: https://issues.apache.org/jira/browse/SOLR-12893
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12893.patch
>
>
> {code}
> @Override
> protected Query newFieldQuery(Analyzer analyzer, String field, String
> queryText,
> boolean quoted, boolean
> fieldAutoGenPhraseQueries, boolean enableGraphQueries,
> SynonymQueryStyle synonymQueryStyle)
> throws SyntaxError {
> Analyzer actualAnalyzer;
> if (removeStopFilter) {
> if (nonStopFilterAnalyzerPerField == null) {
> nonStopFilterAnalyzerPerField = new HashMap<>();
> }
> actualAnalyzer = nonStopFilterAnalyzerPerField.get(field);
> if (actualAnalyzer == null) {
> actualAnalyzer = noStopwordFilterAnalyzer(field);
> }
> } else {
> actualAnalyzer =
> parser.getReq().getSchema().getFieldType(field).getQueryAnalyzer();
> }
> return super.newFieldQuery(actualAnalyzer, field, queryText, quoted,
> fieldAutoGenPhraseQueries, enableGraphQueries, synonymQueryStyle);
> }
> {code}
> The given Analyzer is not passed down to its super classes, preventing
> extending classes to construct their own modified analyzers (which i need).
> As a side, the nonStopFilterAnalyzerPerField cache is never filled, this
> patch also fixes that issue.
> Two tests fail:
>[junit4] -
> org.apache.solr.search.TestExtendedDismaxParser.testFocusQueryParser
>[junit4] - org.apache.solr.search.TestExtendedDismaxParser.testPfPs
> Specifically tests on pf3, i have no idea why so far.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12893) ExtendedSolrQueryParser.newFieldQuery does not use the specified analyzer
Markus Jelsma created SOLR-12893:
Summary: ExtendedSolrQueryParser.newFieldQuery does not use the
specified analyzer
Key: SOLR-12893
URL: https://issues.apache.org/jira/browse/SOLR-12893
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Reporter: Markus Jelsma
Fix For: master (8.0)
Attachments: SOLR-12893.patch
{code}
@Override
protected Query newFieldQuery(Analyzer analyzer, String field, String
queryText,
boolean quoted, boolean
fieldAutoGenPhraseQueries, boolean enableGraphQueries,
SynonymQueryStyle synonymQueryStyle)
throws SyntaxError {
Analyzer actualAnalyzer;
if (removeStopFilter) {
if (nonStopFilterAnalyzerPerField == null) {
nonStopFilterAnalyzerPerField = new HashMap<>();
}
actualAnalyzer = nonStopFilterAnalyzerPerField.get(field);
if (actualAnalyzer == null) {
actualAnalyzer = noStopwordFilterAnalyzer(field);
}
} else {
actualAnalyzer =
parser.getReq().getSchema().getFieldType(field).getQueryAnalyzer();
}
return super.newFieldQuery(actualAnalyzer, field, queryText, quoted,
fieldAutoGenPhraseQueries, enableGraphQueries, synonymQueryStyle);
}
{code}
The given Analyzer is not passed down to its super classes, preventing
extending classes to construct their own modified analyzers (which i need). As
a side, the nonStopFilterAnalyzerPerField cache is never filled, this patch
also fixes that issue.
Two tests fail:
[junit4] -
org.apache.solr.search.TestExtendedDismaxParser.testFocusQueryParser
[junit4] - org.apache.solr.search.TestExtendedDismaxParser.testPfPs
Specifically tests on pf3, i have no idea why so far.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12886) QParserPlugin to support SolrCoreAware
Markus Jelsma created SOLR-12886: Summary: QParserPlugin to support SolrCoreAware Key: SOLR-12886 URL: https://issues.apache.org/jira/browse/SOLR-12886 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Markus Jelsma Fix For: master (8.0) Attachments: SOLR-12886.patch Currently QParserPlugin does not support SolrCoreAware due to SOLR-8311. This adds supports similar to SOLR-11735 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12886) QParserPlugin to support SolrCoreAware
[ https://issues.apache.org/jira/browse/SOLR-12886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-12886: - Attachment: SOLR-12886.patch > QParserPlugin to support SolrCoreAware > -- > > Key: SOLR-12886 > URL: https://issues.apache.org/jira/browse/SOLR-12886 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-12886.patch > > > Currently QParserPlugin does not support SolrCoreAware due to SOLR-8311. This > adds supports similar to SOLR-11735 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651462#comment-16651462
]
Markus Jelsma commented on SOLR-12852:
--
Hello David - are you querying with distrib=true? I don't know what the
example's default is but it could be set to false.
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12852.patch
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide, changed title and snippet
> parameters)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
> http://localhost:8983/solr/collection/clustering?q=*:*
> All libraries are present, Solr no longer complains about missing classes,
> instead i got this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647792#comment-16647792
]
Markus Jelsma commented on SOLR-12852:
--
Attached patch to check for the correct distributed stage (not phase as i said
earlier). If the doclist and the fields are available, run the component. This
does not yet work non-cloud setups.
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12852.patch
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide, changed title and snippet
> parameters)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
> http://localhost:8983/solr/collection/clustering?q=*:*
> All libraries are present, Solr no longer complains about missing classes,
> instead i got this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12852:
-
Attachment: SOLR-12852.patch
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-12852.patch
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide, changed title and snippet
> parameters)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
> http://localhost:8983/solr/collection/clustering?q=*:*
> All libraries are present, Solr no longer complains about missing classes,
> instead i got this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16646915#comment-16646915
]
Markus Jelsma commented on SOLR-12852:
--
Hello David,
We have regular SolrCloud collections using various number of shards. I
wouldn't see how our collection's characteristics could mess up.
I know distributed search calls SearchComponent's process() multiple times per
request, at different phases, only at the final phase fields are available to
do highlighting or clustering on. So i think this component never had support
for distributed search in the first place. That doesn't explain
DistributedClusteringComponentTest passing though.
Testing for the correct phase, and perhaps even the null check might solve it.
Perhaps a committer having experience dealing with SearchComponent and
different distributed search phases could chime in on this?
Regards,
Markus
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (8.0)
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide, changed title and snippet
> parameters)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
> http://localhost:8983/solr/collection/clustering?q=*:*
> All libraries are present, Solr no longer complains about missing classes,
> instead i got this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12852:
-
Description:
Got this exception:
{code}
o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at
org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
{code}
with this config (copied from reference guide)
{code}
lingo
org.carrot2.clustering.lingo.LingoClusteringAlgorithm
stc
org.carrot2.clustering.stc.STCClusteringAlgorithm
true
true
id
title_nl
content_nl
100
*,score
clustering
{code}
using this query:
http://localhost:8983/solr/collection/clustering?q=*:*
All libraries are present, Solr no longer complains about missing classes,
instead i got this.
was:
Got this exception:
{code}
o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at
org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
{code}
with this config (copied from reference guide)
{code}
lingo
org.carrot2.clustering.lingo.LingoClusteringAlgorithm
stc
org.carrot2.clustering.stc.STCClusteringAlgorithm
true
true
id
doctitle
content
100
*,score
clustering
{code}
using this query:
http://localhost:8983/solr/collection/clustering?q=*:*
All libraries are present, Solr no longer complains about missing classes,
instead i got this.
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0)
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
> http://localhost:8983/solr/collection/clustering?q=*:*
> All libraries are present, Solr no longer
[jira] [Updated] (SOLR-12852) NPE in ClusteringComponent
[
https://issues.apache.org/jira/browse/SOLR-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12852:
-
Description:
Got this exception:
{code}
o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at
org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
{code}
with this config (copied from reference guide, changed title and snippet
parameters)
{code}
lingo
org.carrot2.clustering.lingo.LingoClusteringAlgorithm
stc
org.carrot2.clustering.stc.STCClusteringAlgorithm
true
true
id
title_nl
content_nl
100
*,score
clustering
{code}
using this query:
http://localhost:8983/solr/collection/clustering?q=*:*
All libraries are present, Solr no longer complains about missing classes,
instead i got this.
was:
Got this exception:
{code}
o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at
org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
{code}
with this config (copied from reference guide)
{code}
lingo
org.carrot2.clustering.lingo.LingoClusteringAlgorithm
stc
org.carrot2.clustering.stc.STCClusteringAlgorithm
true
true
id
title_nl
content_nl
100
*,score
clustering
{code}
using this query:
http://localhost:8983/solr/collection/clustering?q=*:*
All libraries are present, Solr no longer complains about missing classes,
instead i got this.
> NPE in ClusteringComponent
> --
>
> Key: SOLR-12852
> URL: https://issues.apache.org/jira/browse/SOLR-12852
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Clustering
>Affects Versions: 7.5
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0)
>
>
> Got this exception:
> {code}
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
> at
> org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> {code}
> with this config (copied from reference guide, changed title and snippet
> parameters)
> {code}
>class="solr.clustering.ClusteringComponent">
>
>
> lingo
>name="carrot.algorithm">org.carrot2.clustering.lingo.LingoClusteringAlgorithm
>
>
>
> stc
>name="carrot.algorithm">org.carrot2.clustering.stc.STCClusteringAlgorithm
>
>
>
> class="solr.SearchHandler">
>
> true
> true
>
> id
> title_nl
> content_nl
>
> 100
> *,score
>
>
>
> clustering
>
>
> {code}
> using this query:
>
[jira] [Created] (SOLR-12852) NPE in ClusteringComponent
Markus Jelsma created SOLR-12852:
Summary: NPE in ClusteringComponent
Key: SOLR-12852
URL: https://issues.apache.org/jira/browse/SOLR-12852
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: contrib - Clustering
Affects Versions: 7.5
Reporter: Markus Jelsma
Fix For: master (8.0)
Got this exception:
{code}
o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
at
org.apache.solr.handler.clustering.ClusteringComponent.process(ClusteringComponent.java:234)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
{code}
with this config (copied from reference guide)
{code}
lingo
org.carrot2.clustering.lingo.LingoClusteringAlgorithm
stc
org.carrot2.clustering.stc.STCClusteringAlgorithm
true
true
id
doctitle
content
100
*,score
clustering
{code}
using this query:
http://localhost:8983/solr/collection/clustering?q=*:*
All libraries are present, Solr no longer complains about missing classes,
instead i got this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636754#comment-16636754
]
Markus Jelsma commented on SOLR-12743:
--
Using VisualVM's memory sampler tool, filtered on
org.apache.solr.search.SolrIndexSearcher, you should see the number of
instances increment by one for each commit. If you have multiple cores of the
same collection on the same instance, the number of instances should grow
accordingly.
Take great care, on Solrs where this bug is not present, the number of
instances of SolrIndexSearcher will increment too! But shortly after the
commit, the number will reduce again due to searcher warming and GC delay.
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627213#comment-16627213
]
Markus Jelsma commented on SOLR-12743:
--
Hello [~bjoernhaeuser],
Are you absolutely sure you are no longer leaking a SolrIndexSearcher instance
on commit after dialing back the auto-warm counts?
Despite having flooded the filter cache with entries comparable to production
and continuously indexing stuff, in local tests i am still not able to
reproduce the problem and so not confirm this work-around.
On the other hand, how could this solve the problem, we do not have overlapping
warm up searchers, maxWarmingSearchers is set to 1 and we only do a commit
roughly once every fifteen minutes when our crawler is ready to index a batch.
Thanks,
Markus
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16606883#comment-16606883
]
Markus Jelsma commented on SOLR-12743:
--
Erick wrote:
bq. It would be great if Markus and Björn could add some environment info on
the JIRA, in particular the version of Java you're both using and the op system
etc...
Alright. Debian GNU/Linux 9.3 Stretch, running OpenJDK 64bit
1.8.0_181-8u181-b13-1~deb9u1-b13.
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12743) Memory leak introduced in Solr 7.3.0
[
https://issues.apache.org/jira/browse/SOLR-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16605460#comment-16605460
]
Markus Jelsma commented on SOLR-12743:
--
That is a most regrettable typo, i meant i can't/cannot reproduce it locally,
even when i introduce continuous indexing and querying. That is the whole
problem i have, perhaps Björn can. I'll ask him on the list!
> Memory leak introduced in Solr 7.3.0
>
>
> Key: SOLR-12743
> URL: https://issues.apache.org/jira/browse/SOLR-12743
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
>
> Reported initially by [~markus17]([1], [2]), but other users have had the
> same issue [3]. Some of the key parts:
> {noformat}
> Some facts:
> * problem started after upgrading from 7.2.1 to 7.3.0;
> * it occurs only in our main text search collection, all other collections
> are unaffected;
> * despite what i said earlier, it is so far unreproducible outside
> production, even when mimicking production as good as we can;
> * SortedIntDocSet instances and ConcurrentLRUCache$CacheEntry instances are
> both leaked on commit;
> * filterCache is enabled using FastLRUCache;
> * filter queries are simple field:value using strings, and three filter query
> for time range using [NOW/DAY TO NOW+1DAY/DAY] syntax for 'today', 'last
> week' and 'last month', but rarely used;
> * reloading the core manually frees OldGen;
> * custom URP's don't cause the problem, disabling them doesn't solve it;
> * the collection uses custom extensions for QueryComponent and
> QueryElevationComponent, ExtendedDismaxQParser and MoreLikeThisQParser, a
> whole bunch of TokenFilters, and several DocTransformers and due it being
> only reproducible on production, i really cannot switch these back to
> Solr/Lucene versions;
> * useFilterForSortedQuery is/was not defined in schema so it was default
> (true?), SOLR-11769 could be the culprit, i disabled it just now only for the
> node running 7.4.0, rest of collection runs 7.2.1;
> {noformat}
> {noformat}
> You were right, it was leaking exactly one SolrIndexSearcher instance on each
> commit.
> {noformat}
> And from Björn Häuser ([3]):
> {noformat}
> Problem Suspect 1
> 91 instances of "org.apache.solr.search.SolrIndexSearcher", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.981.148.336 (38,26%) bytes.
> Biggest instances:
> • org.apache.solr.search.SolrIndexSearcher @ 0x6ffd47ea8 - 70.087.272
> (1,35%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x79ea9c040 - 65.678.264
> (1,27%) bytes.
> • org.apache.solr.search.SolrIndexSearcher @ 0x6855ad680 - 63.050.600
> (1,22%) bytes.
> Problem Suspect 2
> 223 instances of "org.apache.solr.util.ConcurrentLRUCache", loaded by
> "org.eclipse.jetty.webapp.WebAppClassLoader @ 0x6807d1048" occupy
> 1.373.110.208 (26,52%) bytes.
> {noformat}
> More details in the email threads.
> [1]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201804.mbox/%3Czarafa.5ae201c6.2f85.218a781d795b07b1%40mail1.ams.nl.openindex.io%3E]
> [2]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201806.mbox/%3Czarafa.5b351537.7b8c.647ddc93059f68eb%40mail1.ams.nl.openindex.io%3E]
> [3]
> [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201809.mbox/%3c7b5e78c6-8cf6-42ee-8d28-872230ded...@gmail.com%3E]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11735) TransformerFactory to support SolrCoreAware
[ https://issues.apache.org/jira/browse/SOLR-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526239#comment-16526239 ] Markus Jelsma commented on SOLR-11735: -- Thanks [~hlavki]! Now i can finally run unit test without packaging my own Solr patched artifact. > TransformerFactory to support SolrCoreAware > --- > > Key: SOLR-11735 > URL: https://issues.apache.org/jira/browse/SOLR-11735 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Major > Fix For: master (8.0) > > Attachments: SOLR-11735.patch > > > Currently TransformerFactory does not support SolrCoreAware due to SOLR-8311. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8357) Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue
[ https://issues.apache.org/jira/browse/LUCENE-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512310#comment-16512310 ] Markus Jelsma commented on LUCENE-8357: --- Thanks Alan! > Fix Explanations on FunctionScoreQuery.boostByQuery and boostByValue > > > Key: LUCENE-8357 > URL: https://issues.apache.org/jira/browse/LUCENE-8357 > Project: Lucene - Core > Issue Type: Bug >Affects Versions: 7.3, 7.3.1 >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8357.patch > > > As noted in SOLR-12414, the replacements for BoostingQuery and BoostedQuery > have truncated explanations. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching
[ https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503459#comment-16503459 ] Markus Jelsma commented on SOLR-11865: -- I am not sure this will work for me right away, but maybe i can get things to work via new API's. So i am fine with this for now. Thanks! > Refactor QueryElevationComponent to prepare query subset matching > - > > Key: SOLR-11865 > URL: https://issues.apache.org/jira/browse/SOLR-11865 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: master (8.0) >Reporter: Bruno Roustant >Priority: Minor > Labels: QueryComponent > Fix For: master (8.0) > > Attachments: > 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, > 0002-Refactor-QueryElevationComponent-after-review.patch, > 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch, > SOLR-11865.patch, SOLR-11865.patch, SOLR-11865.patch, SOLR-11865.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > The goal is to prepare a second improvement to support query terms subset > matching or query elevation rules. > Before that, we need to refactor the QueryElevationComponent. We make it > extendible. We introduce the ElevationProvider interface which will be > implemented later in a second patch to support subset matching. The current > full-query match policy becomes a default simple MapElevationProvider. > - Add overridable methods to handle exceptions during the component > initialization. > - Add overridable methods to provide the default values for config properties. > - No functional change beyond refactoring. > - Adapt unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching
[ https://issues.apache.org/jira/browse/SOLR-11865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503164#comment-16503164 ] Markus Jelsma commented on SOLR-11865: -- [~dsmiley] can you change those private members to protected in QueryElevationComponent? All those members such as initArgs and queryAnalyzer but also the methods should be extendible. > Refactor QueryElevationComponent to prepare query subset matching > - > > Key: SOLR-11865 > URL: https://issues.apache.org/jira/browse/SOLR-11865 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SearchComponents - other >Affects Versions: master (8.0) >Reporter: Bruno Roustant >Priority: Minor > Labels: QueryComponent > Fix For: master (8.0) > > Attachments: > 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, > 0002-Refactor-QueryElevationComponent-after-review.patch, > 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch, > SOLR-11865.patch, SOLR-11865.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > The goal is to prepare a second improvement to support query terms subset > matching or query elevation rules. > Before that, we need to refactor the QueryElevationComponent. We make it > extendible. We introduce the ElevationProvider interface which will be > implemented later in a second patch to support subset matching. The current > full-query match policy becomes a default simple MapElevationProvider. > - Add overridable methods to handle exceptions during the component > initialization. > - Add overridable methods to provide the default values for config properties. > - No functional change beyond refactoring. > - Adapt unit test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent
[ https://issues.apache.org/jira/browse/SOLR-12453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-12453: - Fix Version/s: 7.4 > Allow extending QueryElevationComponent > --- > > Key: SOLR-12453 > URL: https://issues.apache.org/jira/browse/SOLR-12453 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 7.4, master (8.0) > > Attachments: SOLR-12453.patch > > > Similar to SOLR-7968 for extending QueryComponent, i would love to extend the > elevator as well. Up until now i had to copy all code and it becomes a real > mess like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent
[ https://issues.apache.org/jira/browse/SOLR-12453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-12453: - Attachment: SOLR-12453.patch > Allow extending QueryElevationComponent > --- > > Key: SOLR-12453 > URL: https://issues.apache.org/jira/browse/SOLR-12453 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-12453.patch > > > Similar to SOLR-7968 for extending QueryComponent, i would love to extend the > elevator as well. Up until now i had to copy all code and it becomes a real > mess like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12453) Allow extending QueryElevationComponent
[ https://issues.apache.org/jira/browse/SOLR-12453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501862#comment-16501862 ] Markus Jelsma commented on SOLR-12453: -- This patch changes: * private to protected * protected where no visibility is specified * properly indents inner class ElevationComparatorSource > Allow extending QueryElevationComponent > --- > > Key: SOLR-12453 > URL: https://issues.apache.org/jira/browse/SOLR-12453 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-12453.patch > > > Similar to SOLR-7968 for extending QueryComponent, i would love to extend the > elevator as well. Up until now i had to copy all code and it becomes a real > mess like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent
[ https://issues.apache.org/jira/browse/SOLR-12453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-12453: - Environment: (was: Similar to SOLR-7968 for extending QueryComponent, i would love to extend the elevator as well. Up until now i had to copy all code and it becomes a real mess like this. ) Description: Similar to SOLR-7968 for extending QueryComponent, i would love to extend the elevator as well. Up until now i had to copy all code and it becomes a real mess like this. > Allow extending QueryElevationComponent > --- > > Key: SOLR-12453 > URL: https://issues.apache.org/jira/browse/SOLR-12453 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.3.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > > Similar to SOLR-7968 for extending QueryComponent, i would love to extend the > elevator as well. Up until now i had to copy all code and it becomes a real > mess like this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12453) Allow extending QueryElevationComponent
Markus Jelsma created SOLR-12453: Summary: Allow extending QueryElevationComponent Key: SOLR-12453 URL: https://issues.apache.org/jira/browse/SOLR-12453 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.3.1 Environment: Similar to SOLR-7968 for extending QueryComponent, i would love to extend the elevator as well. Up until now i had to copy all code and it becomes a real mess like this. Reporter: Markus Jelsma Fix For: master (8.0) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12414) FunctionScoreQuery no longer displays debug output
[
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494367#comment-16494367
]
Markus Jelsma edited comment on SOLR-12414 at 5/29/18 10:18 PM:
No, in 7.x we only got poor performance with Point* fields, which could be
related to your recent posts i've quickly read.
We upgraded all our low latency collections and our event log processing
collection to 7.3. Our main text search collection is still on 7.2, due to this
bug, and a memory leak we suffer on 7.3 on that collection - which is visible
in production, but i have been unable to reproduce in a controlled environment
for weeks $%$#*##@@%%!!.
The main text search collection is the only using BoostQuery (or
FunctionScoreQuery on 7.3) and with 7.2 and Trie* fields has no performance
issues.
was (Author: markus17):
No, in 7.x we only got poor performance with Point* fields, which could be
related to your recent posts i've quickly read.
We upgraded all our low latency collections and our event log processing
collection to 7.3. Our main text search collection is still on 7.2, due to this
bug, and a memory leak we suffer on 7.3 on that collection - which is visible
in production, but i have been unable to reproduce in a controlled environment
for weeks $%$#*##@@%%!!.
The main text search collection is the only using BoostQuery and with 7.2 and
Trie* fields has not performance issues.
> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
> 1.0 = boost
> 0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 =
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))),
> product of:
> 0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
> 0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:
> 1.0 = termFreq=1.0
> 1.2 = parameter k1
> 0.75 = parameter b
> 2.0 = avgFieldLength
> 2.0 = fieldLength
> 2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
> {code}
> This bug was introduced in Solr/Lucene 7.3.
> Mailing list reference:
> http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12414) FunctionScoreQuery no longer displays debug output
[
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494367#comment-16494367
]
Markus Jelsma commented on SOLR-12414:
--
No, in 7.x we only got poor performance with Point* fields, which could be
related to your recent posts i've quickly read.
We upgraded all our low latency collections and our event log processing
collection to 7.3. Our main text search collection is still on 7.2, due to this
bug, and a memory leak we suffer on 7.3 on that collection - which is there in
production, but i have been unable to reproduce in a controlled environment for
weeks $%$#*##@@%%!!.
The main text search collection is the only using BoostQuery and with 7.2 and
Trie* fields has not performance issues.
> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
> 1.0 = boost
> 0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 =
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))),
> product of:
> 0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
> 0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:
> 1.0 = termFreq=1.0
> 1.2 = parameter k1
> 0.75 = parameter b
> 2.0 = avgFieldLength
> 2.0 = fieldLength
> 2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
> {code}
> This bug was introduced in Solr/Lucene 7.3.
> Mailing list reference:
> http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12414) FunctionScoreQuery no longer displays debug output
[
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494367#comment-16494367
]
Markus Jelsma edited comment on SOLR-12414 at 5/29/18 10:16 PM:
No, in 7.x we only got poor performance with Point* fields, which could be
related to your recent posts i've quickly read.
We upgraded all our low latency collections and our event log processing
collection to 7.3. Our main text search collection is still on 7.2, due to this
bug, and a memory leak we suffer on 7.3 on that collection - which is visible
in production, but i have been unable to reproduce in a controlled environment
for weeks $%$#*##@@%%!!.
The main text search collection is the only using BoostQuery and with 7.2 and
Trie* fields has not performance issues.
was (Author: markus17):
No, in 7.x we only got poor performance with Point* fields, which could be
related to your recent posts i've quickly read.
We upgraded all our low latency collections and our event log processing
collection to 7.3. Our main text search collection is still on 7.2, due to this
bug, and a memory leak we suffer on 7.3 on that collection - which is there in
production, but i have been unable to reproduce in a controlled environment for
weeks $%$#*##@@%%!!.
The main text search collection is the only using BoostQuery and with 7.2 and
Trie* fields has not performance issues.
> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
> 1.0 = boost
> 0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 =
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))),
> product of:
> 0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
> 0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:
> 1.0 = termFreq=1.0
> 1.2 = parameter k1
> 0.75 = parameter b
> 2.0 = avgFieldLength
> 2.0 = fieldLength
> 2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
> {code}
> This bug was introduced in Solr/Lucene 7.3.
> Mailing list reference:
> http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12414) FunctionScoreQuery no longer displays debug output
[
https://issues.apache.org/jira/browse/SOLR-12414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12414:
-
Description:
I have two documents:
{code}
{"text":"some text", "lang":"cn"}
{"text":"more text", "lang":"en"}
{code}
And the following query, a simple edismax with a boost on lang:en:
{code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
{code}
The parsedQuery is now slightly different because of it being wrapped in a
FunctionScoreQuery. The problem is the explain for the document, which is:
{code}
0.3971361 = product of:
1.0 = boost
0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
{code}
Which is now unreadable for complicated queries with many clauses. It should
resemble the output of 7.2, which was:
{code}
0.36464313 =
boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))), product
of:
0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
), product of:
0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
(docFreq + 0.5)) from:
2.0 = docFreq
2.0 = docCount
1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
fieldLength / avgFieldLength)) from:
1.0 = termFreq=1.0
1.2 = parameter k1
0.75 = parameter b
2.0 = avgFieldLength
2.0 = fieldLength
2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
{code}
This bug was introduced in Solr/Lucene 7.3.
Mailing list reference:
http://lucene.472066.n3.nabble.com/Solr-7-3-FunctionScoreQuery-no-longer-displays-debug-output-td4389093.html
was:
I have two documents:
{code}
{"text":"some text", "lang":"cn"}
{"text":"more text", "lang":"en"}
{code}
And the following query, a simple edismax with a boost on lang:en:
{code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
{code}
The parsedQuery is now slightly different because of it being wrapped in a
FunctionScoreQuery. The problem is the explain for the document, which is:
{code}
0.3971361 = product of:
1.0 = boost
0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
{code}
Which is now unreadable for complicated queries with many clauses. It should
resemble the output of 7.2, which was:
{code}
0.36464313 =
boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))), product
of:
0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
), product of:
0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
(docFreq + 0.5)) from:
2.0 = docFreq
2.0 = docCount
1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
fieldLength / avgFieldLength)) from:
1.0 = termFreq=1.0
1.2 = parameter k1
0.75 = parameter b
2.0 = avgFieldLength
2.0 = fieldLength
2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
{code}
This bug was introduced in Solr/Lucene 7.3.
> FunctionScoreQuery no longer displays debug output
> --
>
> Key: SOLR-12414
> URL: https://issues.apache.org/jira/browse/SOLR-12414
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> I have two documents:
> {code}
> {"text":"some text", "lang":"cn"}
> {"text":"more text", "lang":"en"}
> {code}
> And the following query, a simple edismax with a boost on lang:en:
> {code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
> {code}
> The parsedQuery is now slightly different because of it being wrapped in a
> FunctionScoreQuery. The problem is the explain for the document, which is:
> {code}
> 0.3971361 = product of:
> 1.0 = boost
> 0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
> {code}
> Which is now unreadable for complicated queries with many clauses. It should
> resemble the output of 7.2, which was:
> {code}
> 0.36464313 =
> boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))),
> product of:
> 0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
> 0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
> ), product of:
> 0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:
> 2.0 = docFreq
> 2.0 = docCount
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:
>
[jira] [Created] (SOLR-12414) FunctionScoreQuery no longer displays debug output
Markus Jelsma created SOLR-12414:
Summary: FunctionScoreQuery no longer displays debug output
Key: SOLR-12414
URL: https://issues.apache.org/jira/browse/SOLR-12414
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3.1, 7.3
Reporter: Markus Jelsma
Fix For: 7.4, master (8.0)
I have two documents:
{code}
{"text":"some text", "lang":"cn"}
{"text":"more text", "lang":"en"}
{code}
And the following query, a simple edismax with a boost on lang:en:
{code}http://localhost:8983/solr/test/select?wt=xml=text=edismax=text=true=if(exists(query($bqlang)),2,1)=lang:en
{code}
The parsedQuery is now slightly different because of it being wrapped in a
FunctionScoreQuery. The problem is the explain for the document, which is:
{code}
0.3971361 = product of:
1.0 = boost
0.3971361 = boost(if(exists(query(lang:en,def=0.0)),const(2),const(1)))
{code}
Which is now unreadable for complicated queries with many clauses. It should
resemble the output of 7.2, which was:
{code}
0.36464313 =
boost(text:text,if(exists(query(lang:en,def=0.0)),const(2),const(1))), product
of:
0.18232156 = weight(text:text in 0) [SchemaSimilarity], result of:
0.18232156 = score(doc=0,freq=1.0 = termFreq=1.0
), product of:
0.18232156 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
(docFreq + 0.5)) from:
2.0 = docFreq
2.0 = docCount
1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
fieldLength / avgFieldLength)) from:
1.0 = termFreq=1.0
1.2 = parameter k1
0.75 = parameter b
2.0 = avgFieldLength
2.0 = fieldLength
2.0 = if(exists(query(lang:en,def=0.0)=0.6931472),const(2),const(1))
{code}
This bug was introduced in Solr/Lucene 7.3.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12112) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-12112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467576#comment-16467576
]
Markus Jelsma commented on SOLR-12112:
--
Hello [~sarkaramr...@gmail.com],
Unfortunately it is not fixed in 7.3
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
{code}
> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>
>
> explicit
> 10
>
>
>
>
>
> score desc,id asc
> none
>
>
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12112) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-12112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467569#comment-16467569
]
Markus Jelsma commented on SOLR-12112:
--
Hello [~sarkaramr...@gmail.com],
I finally had the opportunity to test, but unfortunately, it is not fixed in
7.3. The stack trace is now slightly different:
{code}
2018-05-08 15:35:18.843 ERROR (qtp2137589296-17) [c:search s:shard2
r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at
io.openindex.lunar.handler.component.DeduplicatingQueryComponent.mergeIds(DeduplicatingQueryComponent.java:302)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
{code}
> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>
>
> explicit
> 10
>
>
>
>
>
> score desc,id asc
> none
>
>
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-12112) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-12112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-12112:
-
Comment: was deleted
(was: Hello [~sarkaramr...@gmail.com],
I finally had the opportunity to test, but unfortunately, it is not fixed in
7.3. The stack trace is now slightly different:
{code}
2018-05-08 15:35:18.843 ERROR (qtp2137589296-17) [c:search s:shard2
r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at
io.openindex.lunar.handler.component.DeduplicatingQueryComponent.mergeIds(DeduplicatingQueryComponent.java:302)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
{code})
> NPE in QueryComponent
> -
>
> Key: SOLR-12112
> URL: https://issues.apache.org/jira/browse/SOLR-12112
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.2.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> http://localhost:8983/solr/ss/select?q=*=/select2
> causes:
> {code}
> 2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2
> r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> {code}
> using config
> {code}
>
>
> explicit
> 10
>
>
>
>
>
> score desc,id asc
> none
>
>
> {code}
> The sort param in /select2 is the culprit here. Remove it and all goes well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11763) Upgrade Guava to 23.0
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-11763: - Attachment: SOLR-11763.patch > Upgrade Guava to 23.0 > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch > > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 23.0
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452268#comment-16452268 ] Markus Jelsma commented on SOLR-11763: -- Updated patch for master! > Upgrade Guava to 23.0 > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-11763.patch, SOLR-11763.patch > > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10837) JSON facetting to support Mean reciprocal rank
[ https://issues.apache.org/jira/browse/SOLR-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452242#comment-16452242 ] Markus Jelsma commented on SOLR-10837: -- Updated patch for master. > JSON facetting to support Mean reciprocal rank > -- > > Key: SOLR-10837 > URL: https://issues.apache.org/jira/browse/SOLR-10837 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 6.6 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 6.7, master (8.0) > > Attachments: SOLR-10837.patch, SOLR-10837.patch, SOLR-10837.patch, > SOLR-10837.patch > > > Provides support for mean reciprocal rank via JSON facetting. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10837) JSON facetting to support Mean reciprocal rank
[ https://issues.apache.org/jira/browse/SOLR-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-10837: - Attachment: SOLR-10837.patch > JSON facetting to support Mean reciprocal rank > -- > > Key: SOLR-10837 > URL: https://issues.apache.org/jira/browse/SOLR-10837 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 6.6 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 6.7, master (8.0) > > Attachments: SOLR-10837.patch, SOLR-10837.patch, SOLR-10837.patch, > SOLR-10837.patch > > > Provides support for mean reciprocal rank via JSON facetting. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10837) JSON facetting to support Mean reciprocal rank
[ https://issues.apache.org/jira/browse/SOLR-10837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-10837: - Fix Version/s: (was: 7.0) master (8.0) > JSON facetting to support Mean reciprocal rank > -- > > Key: SOLR-10837 > URL: https://issues.apache.org/jira/browse/SOLR-10837 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 6.6 >Reporter: Markus Jelsma >Priority: Minor > Fix For: 6.7, master (8.0) > > Attachments: SOLR-10837.patch, SOLR-10837.patch, SOLR-10837.patch, > SOLR-10837.patch > > > Provides support for mean reciprocal rank via JSON facetting. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12263) Log replay throwing ClassCastException
Markus Jelsma created SOLR-12263:
Summary: Log replay throwing ClassCastException
Key: SOLR-12263
URL: https://issues.apache.org/jira/browse/SOLR-12263
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.2.1
Reporter: Markus Jelsma
Fix For: master (8.0)
Node wants to replay transaction log after start up, but throws:
{code}
java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String
at
org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:601)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:315)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)
at
org.apache.solr.common.util.JavaBinCodec.readArray(JavaBinCodec.java:747)
at
org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:272)
at
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)
at
org.apache.solr.update.TransactionLog$LogReader.next(TransactionLog.java:690)
at
org.apache.solr.update.UpdateLog$LogReplayer.doReplay(UpdateLog.java:1758)
at org.apache.solr.update.UpdateLog$LogReplayer.run(UpdateLog.java:1676)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9104) NPE in CollapsingQParser when two fq={!collapse} and zero results
[
https://issues.apache.org/jira/browse/SOLR-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16445601#comment-16445601
]
Markus Jelsma commented on SOLR-9104:
-
Thanks Matthias, it sounds great but we need some committers to chime in
regarding side effects. Is there a patch available?
> NPE in CollapsingQParser when two fq={!collapse} and zero results
> -
>
> Key: SOLR-9104
> URL: https://issues.apache.org/jira/browse/SOLR-9104
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: 6.2, 7.0
>
>
> This is a very weird problem that is reproducible on a small production
> server, but not on the local machine although they run the same 6.0 version.,
> and have an almost identical index. The only minor difference is that
> production is a SolrCloud with 1 shard and two replica's, just for a bit of
> redundancy.
> The following query yields zero results and throws the NPE:
> {code}
> select?q=query:seis={!collapse field=query_digest}={!collapse
> field=result_digest}
> {code}
> The next query does yield results and does not throw anything, it just works
> as it should work:
> {code}
> select?q=query:seiz={!collapse field=query_digest}={!collapse
> field=result_digest}
> {code}
> The /select handler used does not add any fancy param other than rows.
> Here's the NPE:
> {code}
> 2016-05-11 14:10:27.666 ERROR (qtp1209271652-3338) [c:suggestions s:shard1
> r:core_node1 x:suggestions_shard1_replica1] o.a.s.s.HttpSolrCall
> null:java.lang.NullPointerException
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:814)
> at
> org.apache.solr.search.CollapsingQParserPlugin$IntScoreCollector.finish(CollapsingQParserPlugin.java:851)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:272)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1794)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1611)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:634)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:529)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:287)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> {code}
> Edit: for the sake of clarity. It really needs double fq={!collapse bla bla
> for the NPE to appear. If i remove either of the filters from the query, i
> get a nice zero resultset back. Both fields are defined as int.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12112) NPE in QueryComponent
Markus Jelsma created SOLR-12112:
Summary: NPE in QueryComponent
Key: SOLR-12112
URL: https://issues.apache.org/jira/browse/SOLR-12112
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.2.1
Reporter: Markus Jelsma
Fix For: 7.3, master (8.0)
http://localhost:8983/solr/ss/select?q=*=/select2
causes:
{code}
2018-03-16 14:46:59.153 ERROR (qtp1929600551-19) [c:search s:shard2
r:core_node4 x:search_shard2_replica_n2] o.a.s.s.HttpSolrCall
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1037)
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:885)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
{code}
using config
{code}
explicit
10
score desc,id asc
none
{code}
The sort param in /select2 is the culprit here. Remove it and all goes well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7759) DebugComponent's explain should be implemented as a distributed query
[ https://issues.apache.org/jira/browse/SOLR-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371153#comment-16371153 ] Markus Jelsma commented on SOLR-7759: - Alessandro, did you upload a patch three weeks ago? Against what version is that? > DebugComponent's explain should be implemented as a distributed query > - > > Key: SOLR-7759 > URL: https://issues.apache.org/jira/browse/SOLR-7759 > Project: Solr > Issue Type: Bug >Reporter: Varun Thacker >Priority: Major > Attachments: SOLR_7759.patch > > > Currently when we use debugQuery to see the explanation of the matched > documents, the query fired to get the statistics for the matched documents is > not a distributed query. > This is a problem when using distributed idf. The actual documents are being > scored using the global stats and not per shard stats , but the explain will > show us the score by taking into account the stats from the shard where the > document belongs to. > We should try to implement the explain query as a distributed request so that > the scores match the actual document scores. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10952) Exact*Stats are ignored due to query result cache
[
https://issues.apache.org/jira/browse/SOLR-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369986#comment-16369986
]
Markus Jelsma commented on SOLR-10952:
--
Ah, i understand. The cache is tucked away in SolrIndexSearcher so that is
never going to work unless cache replay is passed through regular search
handler and query component. Maybe QuerySenderListener could be of help to
regenerate the cache instead, it seems to be passed through the core's
execute().
> Exact*Stats are ignored due to query result cache
> -
>
> Key: SOLR-10952
> URL: https://issues.apache.org/jira/browse/SOLR-10952
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Mikhail Khludnev
>Priority: Major
>
> the case is described at
> https://issues.apache.org/jira/browse/SOLR-10824?focusedCommentId=16062814=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16062814
>
> {quote}
> * search id:11, got it cached in query results.
> * add docs, commit
> * it triggers cache regeneration, this query is executed per every shard.
> However, their scores are local only.
> * search id:11 again, got cache hit, retrieve local only scores. Ignore exact
> stats, even they are properly distributed via GET_TERM_STATS
> {quote}
> the seed to reproduce {{-ea -Dtestcase=TestExactSharedStatsCache
> -Dtests.method=test -Dtests.seed=EF21F7455842423F -Dtests.multiplier=2
> -Dtests.slow=true -Dtests.locale=de-GR -Dtests.timezone=Etc/GMT-11
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8}}, note the test was fixed
> by https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c44862 . So,
> to reproduce, it needs to be rolled back.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10952) Exact*Stats are ignored due to query result cache
[
https://issues.apache.org/jira/browse/SOLR-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369979#comment-16369979
]
Markus Jelsma edited comment on SOLR-10952 at 2/20/18 11:48 AM:
I have this problem to!
Instead of disabling the cache if ExactStats is active, why are the results
with ExactStats not cached instead? That makes much more sense, is it not?
was (Author: markus17):
I have this problem too!
Instead of disabling the cache if ExactStats is active, why are the results
with ExactStats not cached instead? That makes much more sense, is it not?
> Exact*Stats are ignored due to query result cache
> -
>
> Key: SOLR-10952
> URL: https://issues.apache.org/jira/browse/SOLR-10952
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Mikhail Khludnev
>Priority: Major
>
> the case is described at
> https://issues.apache.org/jira/browse/SOLR-10824?focusedCommentId=16062814=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16062814
>
> {quote}
> * search id:11, got it cached in query results.
> * add docs, commit
> * it triggers cache regeneration, this query is executed per every shard.
> However, their scores are local only.
> * search id:11 again, got cache hit, retrieve local only scores. Ignore exact
> stats, even they are properly distributed via GET_TERM_STATS
> {quote}
> the seed to reproduce {{-ea -Dtestcase=TestExactSharedStatsCache
> -Dtests.method=test -Dtests.seed=EF21F7455842423F -Dtests.multiplier=2
> -Dtests.slow=true -Dtests.locale=de-GR -Dtests.timezone=Etc/GMT-11
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8}}, note the test was fixed
> by https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c44862 . So,
> to reproduce, it needs to be rolled back.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10952) Exact*Stats are ignored due to query result cache
[
https://issues.apache.org/jira/browse/SOLR-10952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369979#comment-16369979
]
Markus Jelsma commented on SOLR-10952:
--
I have this problem too!
Instead of disabling the cache if ExactStats is active, why are the results
with ExactStats not cached instead? That makes much more sense, is it not?
> Exact*Stats are ignored due to query result cache
> -
>
> Key: SOLR-10952
> URL: https://issues.apache.org/jira/browse/SOLR-10952
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Reporter: Mikhail Khludnev
>Priority: Major
>
> the case is described at
> https://issues.apache.org/jira/browse/SOLR-10824?focusedCommentId=16062814=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16062814
>
> {quote}
> * search id:11, got it cached in query results.
> * add docs, commit
> * it triggers cache regeneration, this query is executed per every shard.
> However, their scores are local only.
> * search id:11 again, got cache hit, retrieve local only scores. Ignore exact
> stats, even they are properly distributed via GET_TERM_STATS
> {quote}
> the seed to reproduce {{-ea -Dtestcase=TestExactSharedStatsCache
> -Dtests.method=test -Dtests.seed=EF21F7455842423F -Dtests.multiplier=2
> -Dtests.slow=true -Dtests.locale=de-GR -Dtests.timezone=Etc/GMT-11
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8}}, note the test was fixed
> by https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7c44862 . So,
> to reproduce, it needs to be rolled back.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11858) NPE in DirectSpellChecker
[
https://issues.apache.org/jira/browse/SOLR-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16347659#comment-16347659
]
Markus Jelsma commented on SOLR-11858:
--
Hello Cassandra.
Your steps to reproduce account for the fact that it needs a misspelling and
more than 0 results. Apparently, that is not the only requirement for the
problem to occur.
When i reported this issue. it was the first time saw it, and the last time so
far. In the mean time we had plenty of times where there was a misspelling and
more than 0 results.
So i must apologize, i have no idea how to reproduce it in any consistent
manner.
But let's leave it open for now so others can find it.
> NPE in DirectSpellChecker
> -
>
> Key: SOLR-11858
> URL: https://issues.apache.org/jira/browse/SOLR-11858
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: spellchecker
>Affects Versions: 7.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> We just came across the following NPE. It seems this NPE only appears when
> the query is incorrectly spelled but response has more than 0 results. We
> have not observed this on other 7.1.0 deployments.
> {code}
> 2018-01-16 09:15:00.009 ERROR (qtp329611835-19) [c] o.a.s.h.RequestHand
> lerBase java.lang.NullPointerException
> at
> org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:421)
> at
> org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:353)
> at
> org.apache.solr.spelling.DirectSolrSpellChecker.getSuggestions(DirectSolrSpellChecker.java:186)
> at
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:195)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at
> {code}
> Config:
> {code}
>
> text_general
>
> default
> spellcheck
> solr.DirectSolrSpellChecker
> internal
> 0.5
> 2
> 1
> 5
> 4
> 0.01
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-10471:
-
Attachment: SOLR-10471.patch
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16346609#comment-16346609
]
Markus Jelsma commented on SOLR-10471:
--
Patch for master for all four affected files in solr/bin/
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11735) TransformerFactory to support SolrCoreAware
[ https://issues.apache.org/jira/browse/SOLR-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16337549#comment-16337549 ] Markus Jelsma commented on SOLR-11735: -- Any comments? I sure would like to support SolrCoreAware here and see no reason not to support this. Thanks! > TransformerFactory to support SolrCoreAware > --- > > Key: SOLR-11735 > URL: https://issues.apache.org/jira/browse/SOLR-11735 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Major > Fix For: master (8.0) > > Attachments: SOLR-11735.patch > > > Currently TransformerFactory does not support SolrCoreAware due to SOLR-8311. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11858) NPE in DirectSpellChecker
[
https://issues.apache.org/jira/browse/SOLR-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11858:
-
Description:
We just came across the following NPE. It seems this NPE only appears when the
query is incorrectly spelled but response has more than 0 results. We have not
observed this on other 7.1.0 deployments.
{code}
2018-01-16 09:15:00.009 ERROR (qtp329611835-19) [c] o.a.s.h.RequestHand
lerBase java.lang.NullPointerException
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:421)
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:353)
at
org.apache.solr.spelling.DirectSolrSpellChecker.getSuggestions(DirectSolrSpellChecker.java:186)
at
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:195)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at
{code}
Config:
{code}
text_general
default
spellcheck
solr.DirectSolrSpellChecker
internal
0.5
2
1
5
4
0.01
{code}
> NPE in DirectSpellChecker
> -
>
> Key: SOLR-11858
> URL: https://issues.apache.org/jira/browse/SOLR-11858
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
> We just came across the following NPE. It seems this NPE only appears when
> the query is incorrectly spelled but response has more than 0 results. We
> have not observed this on other 7.1.0 deployments.
> {code}
> 2018-01-16 09:15:00.009 ERROR (qtp329611835-19) [c] o.a.s.h.RequestHand
> lerBase java.lang.NullPointerException
> at
> org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:421)
> at
> org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:353)
> at
> org.apache.solr.spelling.DirectSolrSpellChecker.getSuggestions(DirectSolrSpellChecker.java:186)
> at
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:195)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at
> {code}
> Config:
> {code}
>
> text_general
>
> default
> spellcheck
> solr.DirectSolrSpellChecker
> internal
> 0.5
> 2
> 1
> 5
> 4
> 0.01
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11858) NPE in DirectSpellChecker
[
https://issues.apache.org/jira/browse/SOLR-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11858:
-
Environment: (was: We just came across the following NPE. It seems this
NPE only appears when the query is incorrectly spelled but response has more
than 0 results. We have not observed this on other 7.1.0 deployments.
{code}
2018-01-16 09:15:00.009 ERROR (qtp329611835-19) [c] o.a.s.h.RequestHand
lerBase java.lang.NullPointerException
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:421)
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:353)
at
org.apache.solr.spelling.DirectSolrSpellChecker.getSuggestions(DirectSolrSpellChecker.java:186)
at
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:195)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at
{code}
Config:
{code}
text_general
default
spellcheck
solr.DirectSolrSpellChecker
internal
0.5
2
1
5
4
0.01
{code})
> NPE in DirectSpellChecker
> -
>
> Key: SOLR-11858
> URL: https://issues.apache.org/jira/browse/SOLR-11858
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Markus Jelsma
>Priority: Major
> Fix For: master (8.0), 7.3
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11858) NPE in DirectSpellChecker
Markus Jelsma created SOLR-11858:
Summary: NPE in DirectSpellChecker
Key: SOLR-11858
URL: https://issues.apache.org/jira/browse/SOLR-11858
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Environment: We just came across the following NPE. It seems this NPE
only appears when the query is incorrectly spelled but response has more than 0
results. We have not observed this on other 7.1.0 deployments.
{code}
2018-01-16 09:15:00.009 ERROR (qtp329611835-19) [c] o.a.s.h.RequestHand
lerBase java.lang.NullPointerException
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:421)
at
org.apache.lucene.search.spell.DirectSpellChecker.suggestSimilar(DirectSpellChecker.java:353)
at
org.apache.solr.spelling.DirectSolrSpellChecker.getSuggestions(DirectSolrSpellChecker.java:186)
at
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:195)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at
{code}
Config:
{code}
text_general
default
spellcheck
solr.DirectSolrSpellChecker
internal
0.5
2
1
5
4
0.01
{code}
Reporter: Markus Jelsma
Fix For: master (8.0), 7.3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11787) StackOverflowError in leader election
[
https://issues.apache.org/jira/browse/SOLR-11787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11787:
-
Description:
Just got this:
{code}
Exception in thread "coreZkRegister-1-thread-1" Exception in thread
"coreZkRegister-1-thread-3" java.lang.StackOverflowError
at java.text.DecimalFormat.subformat(DecimalFormat.java:1639)
at java.text.DecimalFormat.format(DecimalFormat.java:712)
at java.text.DecimalFormat.format(DecimalFormat.java:646)
at
java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:1393)
at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1332)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
at
org.apache.log4j.pattern.DatePatternConverter$DefaultZoneDateFormat.format(DatePatternConverter.java:96)
at java.text.DateFormat.format(DateFormat.java:345)
at
org.apache.log4j.pattern.CachedDateFormat.format(CachedDateFormat.java:283)
at
org.apache.log4j.pattern.DatePatternConverter.format(DatePatternConverter.java:180)
at
org.apache.log4j.pattern.BridgePatternConverter.format(BridgePatternConverter.java:119)
at
org.apache.log4j.EnhancedPatternLayout.format(EnhancedPatternLayout.java:546)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at
org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:478)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:485)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:348)
at
org.apache.solr.cloud.SyncStrategy.syncWithReplicas(SyncStrategy.java:180)
at
org.apache.solr.cloud.SyncStrategy.syncReplicas(SyncStrategy.java:129)
at org.apache.solr.cloud.SyncStrategy.sync(SyncStrategy.java:108)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:386)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
{code}
Never saw it before, Solr is still running fine it seems.
edit: restarted Solr, got it again after a little while.
edit: it seems to be caused by:
{code}
2017-12-21 15:22:22.226 ERROR (qtp1929600551-22) [ ] o.a.s.s.HttpSolrCall
null:org.apache.solr.core.SolrCoreInitializationException: SolrCore
'logs_shard1_replica_n1' is not available due
to init failure: null
at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:1472)
at org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:267)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:480)
at
[jira] [Updated] (SOLR-11787) StackOverflowError in leader election
[
https://issues.apache.org/jira/browse/SOLR-11787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11787:
-
Description:
Just got this:
{code}
Exception in thread "coreZkRegister-1-thread-1" Exception in thread
"coreZkRegister-1-thread-3" java.lang.StackOverflowError
at java.text.DecimalFormat.subformat(DecimalFormat.java:1639)
at java.text.DecimalFormat.format(DecimalFormat.java:712)
at java.text.DecimalFormat.format(DecimalFormat.java:646)
at
java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:1393)
at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1332)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
at
org.apache.log4j.pattern.DatePatternConverter$DefaultZoneDateFormat.format(DatePatternConverter.java:96)
at java.text.DateFormat.format(DateFormat.java:345)
at
org.apache.log4j.pattern.CachedDateFormat.format(CachedDateFormat.java:283)
at
org.apache.log4j.pattern.DatePatternConverter.format(DatePatternConverter.java:180)
at
org.apache.log4j.pattern.BridgePatternConverter.format(BridgePatternConverter.java:119)
at
org.apache.log4j.EnhancedPatternLayout.format(EnhancedPatternLayout.java:546)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at
org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:478)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:485)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:348)
at
org.apache.solr.cloud.SyncStrategy.syncWithReplicas(SyncStrategy.java:180)
at
org.apache.solr.cloud.SyncStrategy.syncReplicas(SyncStrategy.java:129)
at org.apache.solr.cloud.SyncStrategy.sync(SyncStrategy.java:108)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:386)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
{code}
Never saw it before, Solr is still running fine it seems.
edit: restarted Solr, got it again after a little while.
was:
Just got this:
{code}
Exception in thread "coreZkRegister-1-thread-1" Exception in thread
"coreZkRegister-1-thread-3" java.lang.StackOverflowError
at java.text.DecimalFormat.subformat(DecimalFormat.java:1639)
at java.text.DecimalFormat.format(DecimalFormat.java:712)
at java.text.DecimalFormat.format(DecimalFormat.java:646)
at
java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:1393)
at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1332)
at
[jira] [Created] (SOLR-11787) StackOverflowError in leader election
Markus Jelsma created SOLR-11787:
Summary: StackOverflowError in leader election
Key: SOLR-11787
URL: https://issues.apache.org/jira/browse/SOLR-11787
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Markus Jelsma
Fix For: master (8.0)
Just got this:
{code}
Exception in thread "coreZkRegister-1-thread-1" Exception in thread
"coreZkRegister-1-thread-3" java.lang.StackOverflowError
at java.text.DecimalFormat.subformat(DecimalFormat.java:1639)
at java.text.DecimalFormat.format(DecimalFormat.java:712)
at java.text.DecimalFormat.format(DecimalFormat.java:646)
at
java.text.SimpleDateFormat.zeroPaddingNumber(SimpleDateFormat.java:1393)
at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1332)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936)
at
org.apache.log4j.pattern.DatePatternConverter$DefaultZoneDateFormat.format(DatePatternConverter.java:96)
at java.text.DateFormat.format(DateFormat.java:345)
at
org.apache.log4j.pattern.CachedDateFormat.format(CachedDateFormat.java:283)
at
org.apache.log4j.pattern.DatePatternConverter.format(DatePatternConverter.java:180)
at
org.apache.log4j.pattern.BridgePatternConverter.format(BridgePatternConverter.java:119)
at
org.apache.log4j.EnhancedPatternLayout.format(EnhancedPatternLayout.java:546)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:310)
at
org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:276)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.slf4j.impl.Log4jLoggerAdapter.warn(Log4jLoggerAdapter.java:478)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:485)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:348)
at
org.apache.solr.cloud.SyncStrategy.syncWithReplicas(SyncStrategy.java:180)
at
org.apache.solr.cloud.SyncStrategy.syncReplicas(SyncStrategy.java:129)
at org.apache.solr.cloud.SyncStrategy.sync(SyncStrategy.java:108)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:386)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
at
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:170)
at
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:135)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:307)
at
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:216)
at
org.apache.solr.cloud.ShardLeaderElectionContext.rejoinLeaderElection(ElectionContext.java:729)
at
org.apache.solr.cloud.ShardLeaderElectionContext.runLeaderProcess(ElectionContext.java:435)
{code}
Never saw it before, Solr is still running fine it seems.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11735) TransformerFactory to support SolrCoreAware
[ https://issues.apache.org/jira/browse/SOLR-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16300063#comment-16300063 ] Markus Jelsma commented on SOLR-11735: -- Any comments on this? We are using this now and it doesn't appear to cause any troubles. > TransformerFactory to support SolrCoreAware > --- > > Key: SOLR-11735 > URL: https://issues.apache.org/jira/browse/SOLR-11735 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma > Fix For: master (8.0) > > Attachments: SOLR-11735.patch > > > Currently TransformerFactory does not support SolrCoreAware due to SOLR-8311. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11768) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11768:
-
Description:
Got this in the logs for almost all queries.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
Yes it is a collection that got docValues for ID field recently. But, the same
collection is reindexed automatically every 2 hours orso. The collection was
not deleted and reindexed, just indexed over the existing documents, not
updating very old documents.
For now i reverted docValues=true and it is solved.
Some queries probably contained those older entries that did not get docValues
for the ID.
was:
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
Oh great, it is for every query.
> NPE in QueryComponent
> -
>
> Key: SOLR-11768
> URL: https://issues.apache.org/jira/browse/SOLR-11768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Markus Jelsma
> Fix For: master (8.0)
>
>
> Got this in the logs for almost all queries.
> {code}
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
> {code}
> Yes it is a collection that got docValues for ID field recently. But, the
> same collection is reindexed automatically every 2 hours orso. The collection
> was not deleted and reindexed, just indexed over the existing documents, not
> updating very old documents.
> For now i reverted docValues=true and it is solved.
> Some queries probably contained those older entries that did not get
> docValues for the ID.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11768) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11768:
-
Description:
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
Oh great, it is for every query.
was:
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
Oh great, it is for every query. Collection's ID recently got docValue=true
added, that might be the problem.
> NPE in QueryComponent
> -
>
> Key: SOLR-11768
> URL: https://issues.apache.org/jira/browse/SOLR-11768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Markus Jelsma
> Fix For: master (8.0)
>
>
> Got this in the logs, no idea yet.
> {code}
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
> {code}
> Oh great, it is for every query.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11768) NPE in QueryComponent
[
https://issues.apache.org/jira/browse/SOLR-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jelsma updated SOLR-11768:
-
Description:
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
Oh great, it is for every query. Collection's ID recently got docValue=true
added, that might be the problem.
was:
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
> NPE in QueryComponent
> -
>
> Key: SOLR-11768
> URL: https://issues.apache.org/jira/browse/SOLR-11768
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.1
>Reporter: Markus Jelsma
> Fix For: master (8.0)
>
>
> Got this in the logs, no idea yet.
> {code}
> null:java.lang.NullPointerException
> at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
> at
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
> {code}
> Oh great, it is for every query. Collection's ID recently got docValue=true
> added, that might be the problem.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11768) NPE in QueryComponent
Markus Jelsma created SOLR-11768:
Summary: NPE in QueryComponent
Key: SOLR-11768
URL: https://issues.apache.org/jira/browse/SOLR-11768
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Markus Jelsma
Fix For: master (8.0)
Got this in the logs, no idea yet.
{code}
null:java.lang.NullPointerException
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:940)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:585)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:564)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:423)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2484)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:720)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolr
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11763) Upgrade Guava to 23.0
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292453#comment-16292453 ] Markus Jelsma commented on SOLR-11763: -- All tests pass except: [junit4] HEARTBEAT J1 PID(1664@midas): 2017-12-15T13:42:58, stalled for 2283s at: HdfsDirectoryTest (suite) [junit4] HEARTBEAT J0 PID(1671@midas): 2017-12-15T13:42:58, stalled for 1752s at: HdfsAutoAddReplicasIntegrationTest (suite) It hang the whole night! > Upgrade Guava to 23.0 > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-11763.patch > > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11763) Upgrade Guava to 23.0
[ https://issues.apache.org/jira/browse/SOLR-11763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-11763: - Attachment: SOLR-11763.patch Patch for 7.1.0 > Upgrade Guava to 23.0 > - > > Key: SOLR-11763 > URL: https://issues.apache.org/jira/browse/SOLR-11763 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma >Priority: Minor > Fix For: master (8.0) > > Attachments: SOLR-11763.patch > > > Our code is running into version conflicts with Solr's old Guava dependency. > This fixes it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11763) Upgrade Guava to 23.0
Markus Jelsma created SOLR-11763: Summary: Upgrade Guava to 23.0 Key: SOLR-11763 URL: https://issues.apache.org/jira/browse/SOLR-11763 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.1 Reporter: Markus Jelsma Priority: Minor Fix For: master (8.0) Our code is running into version conflicts with Solr's old Guava dependency. This fixes it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11735) TransformerFactory to support SolrCoreAware
[ https://issues.apache.org/jira/browse/SOLR-11735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-11735: - Attachment: SOLR-11735.patch patch for master > TransformerFactory to support SolrCoreAware > --- > > Key: SOLR-11735 > URL: https://issues.apache.org/jira/browse/SOLR-11735 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Markus Jelsma > Fix For: master (8.0) > > Attachments: SOLR-11735.patch > > > Currently TransformerFactory does not support SolrCoreAware due to SOLR-8311. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11735) TransformerFactory to support SolrCoreAware
Markus Jelsma created SOLR-11735: Summary: TransformerFactory to support SolrCoreAware Key: SOLR-11735 URL: https://issues.apache.org/jira/browse/SOLR-11735 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.1 Reporter: Markus Jelsma Fix For: master (8.0) Currently TransformerFactory does not support SolrCoreAware due to SOLR-8311. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280813#comment-16280813 ] Markus Jelsma commented on SOLR-11078: -- I agree with Yonik, Strings are no substitute for numbers in some or many cases. We have numeric fields that we use for exact queries, ranges and in some cases arithmetic in boosts. It would be bad if in the future, with Trie* definitively gone, we would have to index the same value as Point, and as String. We know about this, novice users don't. > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > screenshot-3.png, solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, > solr-7-1-0-managed-schema, solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, > solr-sample-warning-log.txt, solr.in.sh, solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241830#comment-16241830 ] Markus Jelsma commented on SOLR-11078: -- To be clear, what is the official recommendation going to be? I have numbers and, intuitively, put them a type representing a number, not a string type. No new user will put numbers in strings. But new users using Point have a good change of a very bad performing search engine. Also, if we put numbers in string (docValues=true), can we still use them a numbers in function queries? > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > screenshot-3.png, solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, > solr-7-1-0-managed-schema, solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, > solr-sample-warning-log.txt, solr.in.sh, solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16236150#comment-16236150 ] Markus Jelsma commented on SOLR-11078: -- Hello David, The particular index we reverted does range queries, facets, json-facets and value look-ups. Some indexes we haven't reverted use Point for boosting only. Another index we won't move to Point does facets. > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy >Priority: Major > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, solr-7-1-0-managed-schema, > solr-7-1-0-solrconfig.xml, solr-sample-warning-log.txt, solr.in.sh, > solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16235350#comment-16235350 ] Markus Jelsma commented on SOLR-11078: -- We have observed it too, and immediately went back to Trie* fields! The difference is huge, one of our collections dropped from many hundreds (~600 to 800) QPS to a mere handful. 7.1.0 is fine, and faster than 6.x. Just don't use Point for the time being. > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy >Priority: Major > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, solr-7-1-0-managed-schema, > solr-7-1-0-solrconfig.xml, solr-sample-warning-log.txt, solr.in.sh, > solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
