[jira] [Updated] (SOLR-7624) Correct wrong spelling of zkCredentialsProvider
[ https://issues.apache.org/jira/browse/SOLR-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-7624: --- Attachment: SOLR-7624.patch Simple fix and a test case. Correct wrong spelling of zkCredentialsProvider --- Key: SOLR-7624 URL: https://issues.apache.org/jira/browse/SOLR-7624 Project: Solr Issue Type: Bug Components: security, SolrCloud Reporter: Per Steffensen Priority: Minor Attachments: SOLR-7624.patch SolrXmlConfig.java contain the string zkCredientialsProvider. It should be corrected to zkCredentialsProvider. I believe no other changes are necessary - there are no tests covering this AFAIK -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7618) MultiFunction.anyExists - creating FunctionValues[] objects for every document
[
https://issues.apache.org/jira/browse/SOLR-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14567930#comment-14567930
]
Xu Zhang commented on SOLR-7618:
It would be really nice if you upload a patch here.
http://wiki.apache.org/solr/HowToContribute
MultiFunction.anyExists - creating FunctionValues[] objects for every document
--
Key: SOLR-7618
URL: https://issues.apache.org/jira/browse/SOLR-7618
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Affects Versions: 5.1
Reporter: Jacob Graves
Priority: Minor
Labels: easyfix, newbie, patch, performance
Fix For: 5.1
Original Estimate: 2h
Remaining Estimate: 2h
In the class org.apache.lucene.queries.function.valuesource.MultiFunction
there is the following method signature (line 52)
public static boolean allExists(int doc, FunctionValues... values)
this method is called from the class
org.apache.lucene.queries.function.valuesource.DualFloatFunction (line 68)
public boolean exists(int doc) {
return MultiFunction.allExists(doc, aVals, bVals);
}
Because MultiFunction.allExists uses Java varargs syntax (...) a new
FunctionValues[] object will be created every time this call takes place.
The problem is that the call takes place in a document level function, which
means that it will create new objects in the heap for every document in the
query results.
for example if you use the following boost function (where ds and dc1 are
both TrieDateField)
bf=min(ms(ds,dc1),60480)
You will get extra objects created for each document in the result set, which
has a big impact on performance and memory usage if you are searching a large
result set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7124) Add delconfig command to zkcli
[ https://issues.apache.org/jira/browse/SOLR-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-7124: --- Attachment: SOLR-7124.patch Here is a quick implementation. When deleting configset, will check if any collection using the config. Add delconfig command to zkcli Key: SOLR-7124 URL: https://issues.apache.org/jira/browse/SOLR-7124 Project: Solr Issue Type: New Feature Components: SolrCloud Affects Versions: 5.0 Reporter: Shawn Heisey Priority: Minor Fix For: Trunk, 5.2 Attachments: SOLR-7124.patch As far as I know, there is no functionality included with Solr that can delete a SolrCloud config in zookeeper. A delconfig command should be added to ZkCli and the zkcli script that can accomplish this. It should refuse to delete a config that is in use by any current collection. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14566096#comment-14566096
]
Xu Zhang edited comment on SOLR-7495 at 5/31/15 7:13 AM:
-
Currently, I think Facet.field only works fine when the it is multi-valued or
single-valued StrField when grouping. There isn't a GroupedFacetCollector that
works on numerics.
The reason is in TermGroupFacetCollector class, we init facetFieldTermsIndex as
SortedDocValues (if single-valued). In this case, if facet.field is numeric, it
will throw this exception.
was (Author: simplebread):
Currently, I think Facet.field only works fine when the it is multi-valued or
single-valued StrField.
The reason is in TermGroupFacetCollector class, we init facetFieldTermsIndex as
SortedDocValues (if single-valued). In this case, if facet.field is numeric, it
will throw this exception.
Unexpected docvalues type NUMERIC when grouping by a int facet
--
Key: SOLR-7495
URL: https://issues.apache.org/jira/browse/SOLR-7495
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Fabio Batista da Silva
Hey All,
After upgrading from solr 4.10 to 5.1 with solr could
I'm getting a IllegalStateException when i try to facet a int field.
IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
(expected=SORTED). Use UninvertingReader or index with docvalues.
schema.xml
{code}
?xml version=1.0 ?
schema name=schema version=1.2
fields
!-- solar cloud version field --
field name=_version_ type=long indexed=true stored=true/
!-- Common fields --
field name=id type=string indexed=true stored=true
multiValued=false required=true/
field name=index_type type=string indexed=true stored=true
multiValued=false required=true/
field name=year type=int indexed=true stored=true/
field name=model type=string indexed=true stored=true/
field name=year_make_model type=string indexed=true
stored=true/
/fields
!-- Field Types --
types
fieldType name=string class=solr.StrField sortMissingLast=true
/
fieldType name=boolean class=solr.BoolField
sortMissingLast=true/
fieldType name=int class=solr.TrieIntField precisionStep=0
positionIncrementGap=0/
fieldType name=float class=solr.TrieFloatField precisionStep=0
positionIncrementGap=0/
fieldType name=long class=solr.TrieLongField precisionStep=0
positionIncrementGap=0/
fieldType name=double class=solr.TrieDoubleField
precisionStep=0 positionIncrementGap=0/
fieldType name=date class=solr.TrieDateField precisionStep=0
positionIncrementGap=0/
fieldType name=text_ngram class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=text_general class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=location_rpt
class=solr.SpatialRecursivePrefixTreeFieldType geo=true
distErrPct=0.025 maxDistErr=0.09 units=degrees /
/types
uniqueKeyid/uniqueKey
defaultSearchFieldname/defaultSearchField
solrQueryParser defaultOperator=OR/
/schema
{code}
query :
{code}
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14566096#comment-14566096
]
Xu Zhang commented on SOLR-7495:
Currently, I think Facet.field only works fine when the it is multi-valued or
single-valued StrField.
The reason is in TermGroupFacetCollector class, we init facetFieldTermsIndex as
SortedDocValues (if single-valued). In this case, if facet.field is numeric, it
will throw this exception.
Unexpected docvalues type NUMERIC when grouping by a int facet
--
Key: SOLR-7495
URL: https://issues.apache.org/jira/browse/SOLR-7495
Project: Solr
Issue Type: Bug
Affects Versions: 5.1
Reporter: Fabio Batista da Silva
Hey All,
After upgrading from solr 4.10 to 5.1 with solr could
I'm getting a IllegalStateException when i try to facet a int field.
IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
(expected=SORTED). Use UninvertingReader or index with docvalues.
schema.xml
{code}
?xml version=1.0 ?
schema name=schema version=1.2
fields
!-- solar cloud version field --
field name=_version_ type=long indexed=true stored=true/
!-- Common fields --
field name=id type=string indexed=true stored=true
multiValued=false required=true/
field name=index_type type=string indexed=true stored=true
multiValued=false required=true/
field name=year type=int indexed=true stored=true/
field name=model type=string indexed=true stored=true/
field name=year_make_model type=string indexed=true
stored=true/
/fields
!-- Field Types --
types
fieldType name=string class=solr.StrField sortMissingLast=true
/
fieldType name=boolean class=solr.BoolField
sortMissingLast=true/
fieldType name=int class=solr.TrieIntField precisionStep=0
positionIncrementGap=0/
fieldType name=float class=solr.TrieFloatField precisionStep=0
positionIncrementGap=0/
fieldType name=long class=solr.TrieLongField precisionStep=0
positionIncrementGap=0/
fieldType name=double class=solr.TrieDoubleField
precisionStep=0 positionIncrementGap=0/
fieldType name=date class=solr.TrieDateField precisionStep=0
positionIncrementGap=0/
fieldType name=text_ngram class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=text_general class=solr.TextField
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true
words=stopwords.txt /
filter class=solr.SynonymFilterFactory
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=location_rpt
class=solr.SpatialRecursivePrefixTreeFieldType geo=true
distErrPct=0.025 maxDistErr=0.09 units=degrees /
/types
uniqueKeyid/uniqueKey
defaultSearchFieldname/defaultSearchField
solrQueryParser defaultOperator=OR/
/schema
{code}
query :
{code}
http://solr.dev:8983/solr/my_collection/select?wt=jsonfl=idfq=index_type:foobargroup=truegroup.field=year_make_modelgroup.facet=truefacet=truefacet.field=year
{code}
Exception :
{code}
ull:org.apache.solr.common.SolrException: Exception during facet.field: year
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
[jira] [Comment Edited] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14368355#comment-14368355
]
Xu Zhang edited comment on SOLR-6350 at 3/19/15 2:07 AM:
-
Update based on Hoss's suggestions.
1, Modify test.
2, add parseParams in to Stat
3, add compression into local parameters for percentiles, similar to Elastic
was (Author: simplebread):
Update based on Hoss's suggestions.
1, Modify test.
2, add parseParams in to Stat
3, add a percentilOptions into local parameters.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch,
SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350.patch
Update based on Hoss's suggestions.
1, Modify test.
2, add parseParams in to Stat
3, add a percentilOptions into local parameters.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch,
SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364256#comment-14364256
]
Xu Zhang commented on SOLR-6350:
Thanks Hoss.
I think I screwed it up. Really sorry about it. Will fix it tonight.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350.patch
I deleted my last patch. This has my last fix and has Hoss's change.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: (was: SOLR-6350.patch)
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364541#comment-14364541
]
Xu Zhang commented on SOLR-6350:
{quote}
This also shows the edge case: when user asking percentiles for empty document
set, we will give NaN.
I think we should probably return 'null' for each percentile in that case?
{quote}
Sure, will add some test cases for this .
{quote}
I'm still not really comfortable with how those inpts are parsed though ...
ultimately i'd like to refactor all of that stuff and push it down into the
StatsValuesFactories (so each factor has an API returning what Stats it
supports, failures are produced if you request an unsupported stat) – but for
now, maybe we can just introduce a boolean parseParams(StatsField) into each
Stat - most Stat instances could use a default impl that would look something
like...
{code}
/** return value of true means user is requesting this stat */
boolean parseParams(StatsField sf) {
return sf.getLocalParams().getBool(this.getName());
}
{code}
...but percentiles could be more interesting? ...
{code}
/** return value of true means user is requesting this stat */
boolean parseParams(StatsField sf) {
String input = sf.getLocalParams().get(this.getName());
if (null ! = input) {
sf.setTDigetsOptions(input);
return true;
}
return false;
}
{code}
...what do you think?
{quote}
+1 :)
{quote}
Yeah, i definitely think we should make those options configurable via another
local param percentilOptions=... (or maybe a suffix on the list of
percentiles?)
{quote}
I think percentilOptions would be really nice. I will improve the patch based
on Hoss's comments, maybe tomorrow.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362286#comment-14362286
]
Xu Zhang commented on SOLR-6350:
Thanks so much Hoss :) .
I think I fix the NaN errors, which is because my patch doesn't compute
percentile stats with the new trunk change. This also shows the edge case:
when user asking percentiles for empty document set, we will give NaN.
{quote}
I didn't do any in depth review yet, but i did sprinkle some nocommits arround
related to things that jumped out at me while resolving conflicts
{quote}
Some work seems quite dirty to me, will spend some time to improve that. For
example, we have a test case which will test all stats combinations, I just
exclude percentiles right now, which is quite awful.
And another thing is I didn't do too much performance tests around this. There
are plenty of parameters for Tdigest. I just pick a default number and
ArrayDigest.
{quote}
I didn't notice any distributed test, not sure if that's something still
needing done, or if that was just because of a mistake in creating the patch
file and new files weren't included.
{quote}
I just added 4 simple test cases in the TestDistributedSearch.java. I probably
missed them in my last patch. Have them back.
{quote}
BTW: no need ot put your name as a suffix in the patch filename – convention is
to just name the patch after the jira. The only reason to worry about
distinguishing the file names is in cases where you explicitly posting a
variant patch (ie: a strawman that you feel/know is broken and shouldn't be
taken seriously long term, an alternative proposal to some other existing
patch, an orthogonal patch only containing tests or some other independent
changes, etc...)
{quote}
Ha, thanks a lot.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350.patch
This patch has the latest trunk change, and should fix NaN errors.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch, SOLR-6350.patch, SOLR-6350.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350-Xu.patch
Almost same, fix existing tests.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: (was: SOLR-6350-Xu.patch)
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-xu.patch,
SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350-Xu.patch
Add another test case with isShard= true and distributed test case.
The patch included Hoss's patch for Solr-6349, against trunk.
Will keep updating and improve
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-Xu.patch,
SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350-Xu.patch
Sure. With pleasure :-)
New patch that have the Hoss's new change about solr6349. I will continue to do
more tests around this and improve this.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-Xu.patch, SOLR-6350-xu.patch,
SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14350824#comment-14350824
]
Xu Zhang commented on SOLR-6350:
Sorry for losing tracking of this Jira. I can work on this this weekend.
[~hossman] Any quick feedback?
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7195) bin/solr script thinks port 8983 is in use, when in fact it is 18983 that is in use
[ https://issues.apache.org/jira/browse/SOLR-7195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-7195: --- Attachment: SOLR-7195.patch This is a quick and dirty fix. The problem happens when doing grep for the port number. It will falsely match 18983 when looking for 8983. bin/solr script thinks port 8983 is in use, when in fact it is 18983 that is in use --- Key: SOLR-7195 URL: https://issues.apache.org/jira/browse/SOLR-7195 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.0 Environment: Linux bigindy5 3.10.0-123.9.2.el7.x86_64 #1 SMP Tue Oct 28 18:05:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Reporter: Shawn Heisey Fix For: 5.1 Attachments: SOLR-7195.patch I'm trying to start solr instance using the bin/solr script, but it is saying that port 8983 is in use. It's not in use ... but I am using 18983 for the JMX port on another copy of Solr (listen port is 8982), and this is what is being detected. [solr@bigindy5 solr]$ lsof -i -Pn | grep 8983 java21609 solr 12u IPv6 11401290 0t0 TCP *:18983 (LISTEN) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7195) bin/solr script thinks port 8983 is in use, when in fact it is 18983 that is in use
[ https://issues.apache.org/jira/browse/SOLR-7195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14351041#comment-14351041 ] Xu Zhang commented on SOLR-7195: We can just use grep -w $SOLR_PORT bin/solr script thinks port 8983 is in use, when in fact it is 18983 that is in use --- Key: SOLR-7195 URL: https://issues.apache.org/jira/browse/SOLR-7195 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.0 Environment: Linux bigindy5 3.10.0-123.9.2.el7.x86_64 #1 SMP Tue Oct 28 18:05:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Reporter: Shawn Heisey Assignee: Shawn Heisey Fix For: 5.1 Attachments: SOLR-7195.patch, SOLR-7195.patch I'm trying to start solr instance using the bin/solr script, but it is saying that port 8983 is in use. It's not in use ... but I am using 18983 for the JMX port on another copy of Solr (listen port is 8982), and this is what is being detected. [solr@bigindy5 solr]$ lsof -i -Pn | grep 8983 java21609 solr 12u IPv6 11401290 0t0 TCP *:18983 (LISTEN) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6682) EnumField + StatsComponent gives bad toString() for min/max, probably doesn't work in distributed search ... definitely needs more tests
[
https://issues.apache.org/jira/browse/SOLR-6682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6682:
---
Attachment: SOLR-6682.patch
Add test for enum, both single node mode and distributed mode
EnumField + StatsComponent gives bad toString() for min/max, probably doesn't
work in distributed search ... definitely needs more tests
Key: SOLR-6682
URL: https://issues.apache.org/jira/browse/SOLR-6682
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: SOLR-6682.patch, SOLR-6682.patch
when EnumField was added, support was included in StatsComponent for it (via
the EnumStatsValues) but it doesn't seem to have ever had any tests written
for it.
doing some quick manual testing, it seems like the min/max values just wind
up being the toString() value of the EnumFieldValue, so you get a response
like this...
{code}
lst name=stats
lst name=stats_fields
lst name=hoss
str name=minorg.apache.solr.common.EnumFieldValue:Low/str
str name=maxorg.apache.solr.common.EnumFieldValue:High/str
long name=count2/long
long name=missing0/long
lst name=facets//lst
/lst
/lst
{code}
we should fix this to return just the stat label, and update the various
StatsComponent tests to also cover enums make sure it works as well as
strings numbers.
notably: i'm fairly certain this EnumStatsValues class won't work at all in a
distributed (stats) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6682) EnumField + StatsComponent gives bad toString() for min/max, probably doesn't work in distributed search ... definitely needs more tests
[
https://issues.apache.org/jira/browse/SOLR-6682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6682:
---
Attachment: SOLR-6682.patch
Simple fix for min/max. And added tests. Single node mode.
Will take a look distributed search tomorrow.
EnumField + StatsComponent gives bad toString() for min/max, probably doesn't
work in distributed search ... definitely needs more tests
Key: SOLR-6682
URL: https://issues.apache.org/jira/browse/SOLR-6682
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Attachments: SOLR-6682.patch
when EnumField was added, support was included in StatsComponent for it (via
the EnumStatsValues) but it doesn't seem to have ever had any tests written
for it.
doing some quick manual testing, it seems like the min/max values just wind
up being the toString() value of the EnumFieldValue, so you get a response
like this...
{code}
lst name=stats
lst name=stats_fields
lst name=hoss
str name=minorg.apache.solr.common.EnumFieldValue:Low/str
str name=maxorg.apache.solr.common.EnumFieldValue:High/str
long name=count2/long
long name=missing0/long
lst name=facets//lst
/lst
/lst
{code}
we should fix this to return just the stat label, and update the various
StatsComponent tests to also cover enums make sure it works as well as
strings numbers.
notably: i'm fairly certain this EnumStatsValues class won't work at all in a
distributed (stats) request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6776) Data lost when use SoftCommit and TLog
[
https://issues.apache.org/jira/browse/SOLR-6776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225445#comment-14225445
]
Xu Zhang commented on SOLR-6776:
Probably this is not a bug. Finish() is about flush tlog into hard disk and
soft-commit is just about visibility.
Data lost when use SoftCommit and TLog
--
Key: SOLR-6776
URL: https://issues.apache.org/jira/browse/SOLR-6776
Project: Solr
Issue Type: Bug
Affects Versions: 4.10
Reporter: yuanyun.cn
Labels: softCommit, updateLog
Fix For: 4.10.3
We enabled update log and change autoCommit to some bigger value 10 mins.
After restart, we push one doc with softCommit=true
http://localhost:8983/solr/update?stream.body=adddocfield
name=idid1/field/doc/addsoftCommit=true
Then we kill the java process after a min.
After restart, Tlog failed to replay with following exception, and there is
no data in solr.
6245 [coreLoadExecutor-5-thread-1] ERROR org.apache.solr.update.UpdateLog û
Failure to open existing log file (non fatal)
E:\jeffery\src\apache\solr\4.10.2\solr-4.10.2\example\solr\collection1\data\t
log\tlog.000:org.apache.solr.common.SolrException:
java.io.EOFException
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:181)
at org.apache.solr.update.UpdateLog.init(UpdateLog.java:261)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:134)
at org.apache.solr.update.UpdateHandler.init(UpdateHandler.java:94)
at
org.apache.solr.update.DirectUpdateHandler2.init(DirectUpdateHandler2.java:100)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:550)
at
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:620)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835)
at org.apache.solr.core.SolrCore.init(SolrCore.java:646)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException
at
org.apache.solr.common.util.FastInputStream.readUnsignedByte(FastInputStream.java:73)
at
org.apache.solr.common.util.FastInputStream.readInt(FastInputStream.java:216)
at
org.apache.solr.update.TransactionLog.readHeader(TransactionLog.java:268)
at
org.apache.solr.update.TransactionLog.init(TransactionLog.java:159)
... 19 more
Check the code: seems this is related with:
org.apache.solr.update.processor.RunUpdateProcessor, in processCommit, it
sets changesSinceCommit=false(even we are using softCommit)
So in finish, updateLog.finish will not be called.
public void finish() throws IOException {
if (changesSinceCommit updateHandler.getUpdateLog() != null) {
updateHandler.getUpdateLog().finish(null);
}
super.finish();
}
To fix this issue: I have to change RunUpdateProcessor.processCommit like
below:
if (!cmd.softCommit) {
changesSinceCommit = false;
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')
[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223731#comment-14223731
]
Xu Zhang commented on SOLR-6351:
Solr-6349 is what you asking for.
Let Stats Hang off of Pivots (via 'tag')
Key: SOLR-6351
URL: https://issues.apache.org/jira/browse/SOLR-6351
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 5.0, Trunk
Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch
he goal here is basically flip the notion of stats.facet on it's head, so
that instead of asking the stats component to also do some faceting
(something that's never worked well with the variety of field types and has
never worked in distributed mode) we instead ask the PivotFacet code to
compute some stats X for each leaf in a pivot. We'll do this with the
existing {{stats.field}} params, but we'll leverage the {{tag}} local param
of the {{stats.field}} instances to be able to associate which stats we want
hanging off of which {{facet.pivot}}
Example...
{noformat}
facet.pivot={!stats=s1}category,manufacturer
stats.field={!key=avg_price tag=s1 mean=true}price
stats.field={!tag=s1 min=true max=true}user_rating
{noformat}
...with the request above, in addition to computing the min/max user_rating
and mean price (labeled avg_price) over the entire result set, the
PivotFacet component will also include those stats for every node of the tree
it builds up when generating a pivot of the fields category,manufacturer
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6349) LocalParams for enabling/disabling individual stats
[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6349:
---
Attachment: SOLR-6349-xu.patch
Super naive implementation, but should work.
Added more tests around calcDistinct, basically tests every case in the Hoss's
comment.
LocalParams for enabling/disabling individual stats
---
Key: SOLR-6349
URL: https://issues.apache.org/jira/browse/SOLR-6349
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349-xu.patch,
SOLR-6349-xu.patch, SOLR-6349___bad_idea_broken.patch
Stats component currently computes all stats (except for one) every time
because they are relatively cheap, and in some cases dependent on eachother
for distrib computation -- but if we start layering stats on other things it
becomes unnecessarily expensive to compute all the stats when they just want
the sum (and it will definitely become excessively verbose in the
responses).
The plan here is to use local params to make this configurable. All of the
existing stat options could be modeled as a simple boolean param, but future
params (like percentiles) might take in a more complex param value...
Example:
{noformat}
stats.field={!min=true max=true percentiles='99,99.999'}price
stats.field={!mean=true}weight
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6349) LocalParams for enabling/disabling individual stats
[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6349:
---
Attachment: SOLR-6349-xu.patch
Updated:
1. Use lower case calcdistinct in local parameters, as the same with the one in
top level parameter.
2. Clean unneeded methods in UnInvertedField class.
Pass all tests.
LocalParams for enabling/disabling individual stats
---
Key: SOLR-6349
URL: https://issues.apache.org/jira/browse/SOLR-6349
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349-xu.patch,
SOLR-6349-xu.patch, SOLR-6349-xu.patch, SOLR-6349___bad_idea_broken.patch
Stats component currently computes all stats (except for one) every time
because they are relatively cheap, and in some cases dependent on eachother
for distrib computation -- but if we start layering stats on other things it
becomes unnecessarily expensive to compute all the stats when they just want
the sum (and it will definitely become excessively verbose in the
responses).
The plan here is to use local params to make this configurable. All of the
existing stat options could be modeled as a simple boolean param, but future
params (like percentiles) might take in a more complex param value...
Example:
{noformat}
stats.field={!min=true max=true percentiles='99,99.999'}price
stats.field={!mean=true}weight
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6349) LocalParams for enabling/disabling individual stats
[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180718#comment-14180718
]
Xu Zhang commented on SOLR-6349:
Thanks so much, totally agree.
I will try to update Tomas's change and tests this evening.
LocalParams for enabling/disabling individual stats
---
Key: SOLR-6349
URL: https://issues.apache.org/jira/browse/SOLR-6349
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349-xu.patch,
SOLR-6349___bad_idea_broken.patch
Stats component currently computes all stats (except for one) every time
because they are relatively cheap, and in some cases dependent on eachother
for distrib computation -- but if we start layering stats on other things it
becomes unnecessarily expensive to compute all the stats when they just want
the sum (and it will definitely become excessively verbose in the
responses).
The plan here is to use local params to make this configurable. All of the
existing stat options could be modeled as a simple boolean param, but future
params (like percentiles) might take in a more complex param value...
Example:
{noformat}
stats.field={!min=true max=true percentiles='99,99.999'}price
stats.field={!mean=true}weight
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6349) LocalParams for enabling/disabling individual stats
[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6349:
---
Attachment: SOLR-6349-xu.patch
Made some adjustments based on Hoss's comments.
1. Only use EnumSet now.
2. Move calcDistinct into Enum.
But the question is, do we consider calcDistinct is a local parameter like
min/max, or it should be the top-level parameter. (Which keeps the existing
behavior for things like stats.field=foostats.calcDistinct=true)
3. Support distributed request, add faking test.
4. Remove static dependsOn(Stat) methods, use Enum property instead.
LocalParams for enabling/disabling individual stats
---
Key: SOLR-6349
URL: https://issues.apache.org/jira/browse/SOLR-6349
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349-xu.patch,
SOLR-6349___bad_idea_broken.patch
Stats component currently computes all stats (except for one) every time
because they are relatively cheap, and in some cases dependent on eachother
for distrib computation -- but if we start layering stats on other things it
becomes unnecessarily expensive to compute all the stats when they just want
the sum (and it will definitely become excessively verbose in the
responses).
The plan here is to use local params to make this configurable. All of the
existing stat options could be modeled as a simple boolean param, but future
params (like percentiles) might take in a more complex param value...
Example:
{noformat}
stats.field={!min=true max=true percentiles='99,99.999'}price
stats.field={!mean=true}weight
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175591#comment-14175591
]
Xu Zhang commented on SOLR-6350:
Probably we should give compression parameter to users.
The T-Digest algorithm use compression parameter to control the trade-off
between the size of the T-Digest and the accuracy which quantiles are
estimated. Users should be able to pick the trade-off by themselves.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175591#comment-14175591
]
Xu Zhang edited comment on SOLR-6350 at 10/17/14 10:02 PM:
---
Probably we should give compression parameter to users.
The T-Digest algorithm use compression parameter to control the trade-off
between the size of the T-Digest and the accuracy which quantiles are
estimated. Users should be able to pick the trade-off by themselves.
And probably AVL t-digest implementation is better.
was (Author: simplebread):
Probably we should give compression parameter to users.
The T-Digest algorithm use compression parameter to control the trade-off
between the size of the T-Digest and the accuracy which quantiles are
estimated. Users should be able to pick the trade-off by themselves.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350-xu.patch
Implement Percentiles for distributed mode and test.
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-xu.patch, SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6350) Percentiles in StatsComponent
[
https://issues.apache.org/jira/browse/SOLR-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6350:
---
Attachment: SOLR-6350-xu.patch
First try, followed the proposed implementation. Added dependency, t-digest in
single mode, and a quick-and-dirty test. Will take a look at distributed mode
tomorrow.
Also need to figure out how to use t-diges (initial page size, compression,
whether to compress, and when to compress).
Percentiles in StatsComponent
-
Key: SOLR-6350
URL: https://issues.apache.org/jira/browse/SOLR-6350
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6350-xu.patch
Add an option to compute user specified percentiles when computing stats
Example...
{noformat}
stats.field={!percentiles='1,2,98,99,99.999'}price
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6623) NPE in StoredFieldsShardResponseProcessor possible when using TIME_ALLOWED param
[
https://issues.apache.org/jira/browse/SOLR-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14171344#comment-14171344
]
Xu Zhang commented on SOLR-6623:
We can reproduce the NPE by letting Method SolrQueryTimeoutImpl:shouldExit()
return true.
NPE in StoredFieldsShardResponseProcessor possible when using TIME_ALLOWED
param
Key: SOLR-6623
URL: https://issues.apache.org/jira/browse/SOLR-6623
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Anshum Gupta
I'm not sure if this is an existing bug, or something new caused by changes
in SOLR-5986, but it just poped up in jenkinds today...
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1844
Revision: 1631656
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestDistributedGrouping -Dtests.method=testDistribSearch
-Dtests.seed=E9460FA0973F6672 -Dtests.slow=true -Dtests.locale=cs
-Dtests.timezone=Indian/Mayotte -Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 55.9s | TestDistributedGrouping.testDistribSearch
[junit4] Throwable #1:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
java.lang.NullPointerException
[junit4] at
org.apache.solr.search.grouping.distributed.responseprocessor.StoredFieldsShardResponseProcessor.process(StoredFieldsShardResponseProcessor.java:45)
[junit4] at
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:708)
[junit4] at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:691)
[junit4] at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:337)
[junit4] at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:136)
[junit4] at
org.apache.solr.core.SolrCore.execute(SolrCore.java:1983)
[junit4] at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:773)
[junit4] at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:408)
[junit4] at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:202)
[junit4] at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
[junit4] at
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:137)
[junit4] at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
[junit4] at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
[junit4] at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
[junit4] at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
[junit4] at
org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:301)
[junit4] at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1077)
[junit4] at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
[junit4] at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
[junit4] at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
[junit4] at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
[junit4] at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
[junit4] at
org.eclipse.jetty.server.Server.handle(Server.java:368)
[junit4] at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
[junit4] at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
[junit4] at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
[junit4] at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
[junit4] at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
[junit4] at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
[junit4] at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
[junit4] at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
[junit4] at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
[junit4]
[jira] [Updated] (SOLR-6349) LocalParams for enabling/disabling individual stats
[
https://issues.apache.org/jira/browse/SOLR-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Zhang updated SOLR-6349:
---
Attachment: SOLR-6349-xu.patch
+1 for Tomas's idea.
I tried to improve it a little bit by using bit wise operation, but no big
difference.
And modified the Individual test in Tomas's patch, which basically test all
combinations of all individual stats.
LocalParams for enabling/disabling individual stats
---
Key: SOLR-6349
URL: https://issues.apache.org/jira/browse/SOLR-6349
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Attachments: SOLR-6349-tflobbe.patch, SOLR-6349-tflobbe.patch,
SOLR-6349-tflobbe.patch, SOLR-6349-xu.patch, SOLR-6349___bad_idea_broken.patch
Stats component currently computes all stats (except for one) every time
because they are relatively cheap, and in some cases dependent on eachother
for distrib computation -- but if we start layering stats on other things it
becomes unnecessarily expensive to compute all the stats when they just want
the sum (and it will definitely become excessively verbose in the
responses).
The plan here is to use local params to make this configurable. All of the
existing stat options could be modeled as a simple boolean param, but future
params (like percentiles) might take in a more complex param value...
Example:
{noformat}
stats.field={!min=true max=true percentiles='99,99.999'}price
stats.field={!mean=true}weight
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6562) Function query calculates the wrong value
[ https://issues.apache.org/jira/browse/SOLR-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14148402#comment-14148402 ] Xu Zhang commented on SOLR-6562: This is floating number precision nature, when using float to represent big numbers, we will lose precision. Do we really need to support arbitrary-precision numbers ? Function query calculates the wrong value - Key: SOLR-6562 URL: https://issues.apache.org/jira/browse/SOLR-6562 Project: Solr Issue Type: Bug Affects Versions: 4.9 Reporter: Stefan Neumüller Priority: Critical This calculation fl=sub(sum(abs(sub(1416906516710,141678360)),abs(sub(1036800,1416906516710))),10226321640) should return 0. But the calculated value is 8388608 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6545) Query field list with wild card on dynamic field fails
[ https://issues.apache.org/jira/browse/SOLR-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-6545: --- Attachment: SOLR-6545.patch Upload a patch base on lucene_solr_4_10. Run through all tests, the new change doesn't break any other test. Query field list with wild card on dynamic field fails -- Key: SOLR-6545 URL: https://issues.apache.org/jira/browse/SOLR-6545 Project: Solr Issue Type: Bug Affects Versions: 4.10 Environment: Mac OS X 10.9.5, Ubuntu 14.04.1 LTS Reporter: Burke Webster Priority: Critical Attachments: SOLR-6545.patch Downloaded 4.10.0, unpacked, and setup a solrcloud 2-node cluster by running: bin/solr -e cloud Accepting all the default options and you will have a 2 node cloud running with replication factor of 2. Now add 2 documents by going to example/exampledocs, creating the following file named my_test.xml: add doc field name=id1000/field field name=nametest 1/field field name=desc_tText about test 1./field field name=cat_A_sCategory A/field /doc doc field name=id1001/field field name=nametest 2/field field name=desc_tStuff about test 2./field field name=cat_B_sCategory B/field /doc /add Then import these documents by running: java -Durl=http://localhost:7574/solr/gettingstarted/update -jar post.jar my_test.xml Verify the docs are there by hitting: http://localhost:8983/solr/gettingstarted/select?q=*:* Now run a query and ask for only the id and cat_*_s fields: http://localhost:8983/solr/gettingstarted/select?q=*:*fl=id,cat_* You will only get the id fields back. Change the query a little to include a third field: http://localhost:8983/solr/gettingstarted/select?q=*:*fl=id,name,cat_* You will now get the following exception: java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:1257) at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:720) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:695) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:324) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1967) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:368) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at
[jira] [Commented] (SOLR-6545) Query field list with wild card on dynamic field fails
[ https://issues.apache.org/jira/browse/SOLR-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14142765#comment-14142765 ] Xu Zhang commented on SOLR-6545: Looks like code broken when doing distributed queries. Single node works fine. Query field list with wild card on dynamic field fails -- Key: SOLR-6545 URL: https://issues.apache.org/jira/browse/SOLR-6545 Project: Solr Issue Type: Bug Affects Versions: 4.10 Environment: Mac OS X 10.9.5, Ubuntu 14.04.1 LTS Reporter: Burke Webster Priority: Critical Downloaded 4.10.0, unpacked, and setup a solrcloud 2-node cluster by running: bin/solr -e cloud Accepting all the default options and you will have a 2 node cloud running with replication factor of 2. Now add 2 documents by going to example/exampledocs, creating the following file named my_test.xml: add doc field name=id1000/field field name=nametest 1/field field name=desc_tText about test 1./field field name=cat_A_sCategory A/field /doc doc field name=id1001/field field name=nametest 2/field field name=desc_tStuff about test 2./field field name=cat_B_sCategory B/field /doc /add Then import these documents by running: java -Durl=http://localhost:7574/solr/gettingstarted/update -jar post.jar my_test.xml Verify the docs are there by hitting: http://localhost:8983/solr/gettingstarted/select?q=*:* Now run a query and ask for only the id and cat_*_s fields: http://localhost:8983/solr/gettingstarted/select?q=*:*fl=id,cat_* You will only get the id fields back. Change the query a little to include a third field: http://localhost:8983/solr/gettingstarted/select?q=*:*fl=id,name,cat_* You will now get the following exception: java.lang.NullPointerException at org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:1257) at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:720) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:695) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:324) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1967) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:368) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) at
[jira] [Commented] (SOLR-6521) CloudSolrServer should synchronize cache cluster state loading
[ https://issues.apache.org/jira/browse/SOLR-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136156#comment-14136156 ] Xu Zhang commented on SOLR-6521: Thanks Jessica, I think we met a similar question. Could I get more information about your tests? I would like to reproduce it. Just curious, you said you using guava's cache for collectionStateCache ? Is it right? CloudSolrServer should synchronize cache cluster state loading -- Key: SOLR-6521 URL: https://issues.apache.org/jira/browse/SOLR-6521 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Jessica Cheng Mallet Assignee: Noble Paul Labels: SolrCloud Under heavy load-testing with the new solrj client that caches the cluster state instead of setting a watcher, I started seeing lots of zk connection loss on the client-side when refreshing the CloudSolrServer collectionStateCache, and this was causing crazy client-side 99.9% latency (~15 sec). I swapped the cache out with guava's LoadingCache (which does locking to ensure only one thread loads the content under one key while the other threads that want the same key wait) and the connection loss went away and the 99.9% latency also went down to just about 1 sec. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6506) SolrCloud route.name=implicit not effect
[ https://issues.apache.org/jira/browse/SOLR-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134537#comment-14134537 ] Xu Zhang commented on SOLR-6506: I'm not sure if this is a bug, collection API works fine for me. Actually I think the best way to setup collection correctly is by using Collection API. SolrCloud route.name=implicit not effect --- Key: SOLR-6506 URL: https://issues.apache.org/jira/browse/SOLR-6506 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.9 Reporter: Zhang Jingpeng The first node i start with java -Xms512m -Xmx1536m -DzkRun -Djetty.port=8983 -Dshards=shard1,shard2,shard3 -Droute.name=implicit -Dsolr.data.dir=/data/data1 -Dsolr.solr.home=multicore -Dbootstrap_conf=true -DzkHost=localhost:2182 -jar start.jar I want to start up the second node to shard2, but it defaut belong to shard1, the second node command is java -Xms512m -Xmx1536m -Djetty.port=8988 -Dsolr.data.dir=/data/data6 -Dsolr.solr.home=multicore -DzkHost=localhost:2182 -jar start.jar I use http://ip:port/solr/admin/collections?action=CREATESHARDshard=shard2collection=mycol; to create a new shard also does not effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6452) StatsComponent missing stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14133461#comment-14133461 ] Xu Zhang commented on SOLR-6452: This is a known issue, facet value stats only works for string type right now, tracked in: SOLR-1782 This Jira is only for missing stat. StatsComponent missing stat won't work with docValues=true and indexed=false -- Key: SOLR-6452 URL: https://issues.apache.org/jira/browse/SOLR-6452 Project: Solr Issue Type: Bug Affects Versions: 4.10, 5.0 Reporter: Tomás Fernández Löbbe Assignee: Tomás Fernández Löbbe Fix For: 4.11, 5.0 Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, SOLR-6452.patch, SOLR-6452.patch, SOLR-6452.patch StatsComponent can work with DocValues, but it still required to use indexed=true for the missing stat to work. Missing values should be obtained from the docValues too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6506) SolrCloud route.name=implicit not effect
[ https://issues.apache.org/jira/browse/SOLR-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130374#comment-14130374 ] Xu Zhang commented on SOLR-6506: I think people need more information about your setup or how to reproduce the bug. If you could provide your bootstrap parameter or some logs would be really helpful. SolrCloud route.name=implicit not effect --- Key: SOLR-6506 URL: https://issues.apache.org/jira/browse/SOLR-6506 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.9 Reporter: Zhang Jingpeng when i start up my first node (solrCloud model ) with -Dshard=shard1,shard2,shard3，but when i start up the second node ,the second node blong to shard1 not individual shard2 ， I use http://ip:port/solr/admin/collections?action=CREATESHARDshard=shard2collection=mycol; to create a new shard also does not effect. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6452) StatsComponent missing stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-6452: --- Attachment: SOLR-6452.patch Update based on the comments. Thanks Tomas StatsComponent missing stat won't work with docValues=true and indexed=false -- Key: SOLR-6452 URL: https://issues.apache.org/jira/browse/SOLR-6452 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.10 Reporter: Tomás Fernández Löbbe Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch, SOLR-6452.patch StatsComponent can work with DocValues, but it still required to use indexed=true for the missing stat to work. Missing values should be obtained from the docValues too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6452) StatsComponent missing stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-6452: --- Attachment: SOLR-6452-trunk.patch I talked with Tomas, new to fix the bug based on Tomas's comment. Right now, for multi-value stats field, we only test stats.facet on String fieldtype. I add another simple test case testing stats.facet on int type. Looks like this part is still buggy. StatsComponent missing stat won't work with docValues=true and indexed=false -- Key: SOLR-6452 URL: https://issues.apache.org/jira/browse/SOLR-6452 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.10 Reporter: Tomás Fernández Löbbe Attachments: SOLR-6452-trunk.patch, SOLR-6452-trunk.patch StatsComponent can work with DocValues, but it still required to use indexed=true for the missing stat to work. Missing values should be obtained from the docValues too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-6487) StatsComponents stats.facet only work for string type field
Xu Zhang created SOLR-6487: -- Summary: StatsComponents stats.facet only work for string type field Key: SOLR-6487 URL: https://issues.apache.org/jira/browse/SOLR-6487 Project: Solr Issue Type: Bug Affects Versions: 5.0 Reporter: Xu Zhang StatsComponents stats.facet only work for string field, (stats on multi-valued field). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6452) StatsComponent missing stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Zhang updated SOLR-6452: --- Attachment: SOLR-6452-trunk.patch Upload my first fix for missing stat. Still working on it and need some suggestions. My first patch :P StatsComponent missing stat won't work with docValues=true and indexed=false -- Key: SOLR-6452 URL: https://issues.apache.org/jira/browse/SOLR-6452 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.10 Reporter: Tomás Fernández Löbbe Attachments: SOLR-6452-trunk.patch StatsComponent can work with DocValues, but it still required to use indexed=true for the missing stat to work. Missing values should be obtained from the docValues too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6452) StatsComponent missing stat won't work with docValues=true and indexed=false
[ https://issues.apache.org/jira/browse/SOLR-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115991#comment-14115991 ] Xu Zhang commented on SOLR-6452: Looks like this bug is only for multi-valued field. StatsComponent missing stat won't work with docValues=true and indexed=false -- Key: SOLR-6452 URL: https://issues.apache.org/jira/browse/SOLR-6452 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.10 Reporter: Tomás Fernández Löbbe StatsComponent can work with DocValues, but it still required to use indexed=true for the missing stat to work. Missing values should be obtained from the docValues too. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
