[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2193 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2193/

1 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability

Error Message:
No live SolrServers available to handle this request

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request
at 
__randomizedtesting.SeedInfo.seed([9A878123E35157ED:5B4F5C6542378644]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:539)
at 
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91)
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301)
at 
org.apache.solr.client.solrj.TestLBHttpSolrServer.testReliability(TestLBHttpSolrServer.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
 

[jira] [Updated] (SOLR-6683) Need a configurable parameter to control the doc number between peersync and the snapshot pull recovery

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-6683:
--
Description: 
If there are >100 docs gap between the recovering node and the good node, the 
solr will do snap pull recovery instead of peersync.

Can the 100 docs be configurable? For example, there can be 1, 1000, or 10 
docs gap between the good node and the node to recover.

For 100 doc, a regular restart of a solr node will trigger a full recovery, 
which is a huge impact to the performance of the running systems

Thanks!

  was:
If there are >100 docs gap between the recovering node and the good node, the 
solr will do snap pull recovery instead of peersync.

Can the 100 docs be configurable? For example, there can be 1, 1000, or 10 
docs gap between the good node and the node to recover.

Thanks!


> Need a configurable parameter to control the doc number between peersync and 
> the snapshot pull recovery
> ---
>
> Key: SOLR-6683
> URL: https://issues.apache.org/jira/browse/SOLR-6683
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.7
> Environment: Redhat Linux 64bit
>Reporter: Forest Soup
>Priority: Critical
>  Labels: performance
>
> If there are >100 docs gap between the recovering node and the good node, the 
> solr will do snap pull recovery instead of peersync.
> Can the 100 docs be configurable? For example, there can be 1, 1000, or 
> 10 docs gap between the good node and the node to recover.
> For 100 doc, a regular restart of a solr node will trigger a full recovery, 
> which is a huge impact to the performance of the running systems
> Thanks!



--
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] (LUCENE-6037) PendingTerm cannot be cast to PendingBlock

[zhanlijun (JIRA)]

zhanlijun created LUCENE-6037:
-

 Summary: PendingTerm cannot be cast to PendingBlock
 Key: LUCENE-6037
 URL: https://issues.apache.org/jira/browse/LUCENE-6037
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/codecs
Affects Versions: 4.3.1
 Environment: ubuntu 64bit
Reporter: zhanlijun
Priority: Critical
 Fix For: 4.3.1


the error as follows:
java.lang.ClassCastException: 
org.apache.lucene.codecs.BlockTreeTermsWriter$PendingTerm cannot be cast to 
org.apache.lucene.codecs.BlockTreeTermsWriter$PendingBlock
at 
org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finish(BlockTreeTermsWriter.java:1014)
at 
org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:553)
at 
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
at 
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:493)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:480)
at 
org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
at 
org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:413)
at 
org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1283)
at 
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1243)
at 
org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1228)



--
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] (LUCENE-6038) FieldValueFilter regression

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6038:


 Summary: FieldValueFilter regression
 Key: LUCENE-6038
 URL: https://issues.apache.org/jira/browse/LUCENE-6038
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a 
regression in FieldValueFilter, which checks if the bits for documents with a 
field  is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet 
anymore.



--
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] (LUCENE-6038) FieldValueFilter regression

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6038:
-
Attachment: LUCENE-6038.patch

Here is a patch.

> FieldValueFilter regression
> ---
>
> Key: LUCENE-6038
> URL: https://issues.apache.org/jira/browse/LUCENE-6038
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6038.patch
>
>
> The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a 
> regression in FieldValueFilter, which checks if the bits for documents with a 
> field  is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet 
> anymore.



--
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] (LUCENE-6037) PendingTerm cannot be cast to PendingBlock

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6037:


Hmm, not good.  Can you provide some details about how you hit this?  Or maybe 
a small test case showing it?

> PendingTerm cannot be cast to PendingBlock
> --
>
> Key: LUCENE-6037
> URL: https://issues.apache.org/jira/browse/LUCENE-6037
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.3.1
> Environment: ubuntu 64bit
>Reporter: zhanlijun
>Priority: Critical
> Fix For: 4.3.1
>
>
> the error as follows:
> java.lang.ClassCastException: 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingTerm cannot be cast to 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingBlock
> at 
> org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finish(BlockTreeTermsWriter.java:1014)
> at 
> org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:553)
> at 
> org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
> at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
> at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
> at 
> org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:493)
> at 
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:480)
> at 
> org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:413)
> at 
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1283)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1243)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1228)



--
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-6678) Collection/core reload is causing a memory leak

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-6678:
-

But if this indeed is the problem, then that just exposes the issue that these 
hooks are not being GC'd? Either the unloaded core is hanging around or the 
hooks are being accumulated by the reloaded core?

> Collection/core reload is causing a memory leak
> ---
>
> Key: SOLR-6678
> URL: https://issues.apache.org/jira/browse/SOLR-6678
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Alexey Serba
> Attachments: ReloadMemoryLeak.png
>
>
> I have a use case where I need to periodically 
> [reload|https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api2]
>  a SolrCloud collection. Recently I did ~1k reload operations and noticed 
> that the cluster was running slower and slower, so I connected to it with 
> jconsole and noticed that heap was growing with every reload operation, 
> forcing GC wasn't helping.
> So I took a heap dump and noticed that I have too many SolrCore-s hanging 
> around. 
> It's hard for me to grok the root cause of this, but maybe someone more 
> knowledgable in Solr internals can figure it out by looking into this GC root 
> path (see attached image)? If I interpret this correctly, it looks like one 
> SolrCore is referencing another SolrCore through SolrSuggester. Maybe close 
> hook for SolrSuggester component doesn't release everything that it should be 
> releasing (like SolrSuggester.dictionary)?



--
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] (LUCENE-6037) PendingTerm cannot be cast to PendingBlock

[zhanlijun (JIRA)]

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

zhanlijun commented on LUCENE-6037:
---

I have multiple threads to operator IndexWriter.addDocuments()，and it very hard 
to reproduce the error after it run many hours

> PendingTerm cannot be cast to PendingBlock
> --
>
> Key: LUCENE-6037
> URL: https://issues.apache.org/jira/browse/LUCENE-6037
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.3.1
> Environment: ubuntu 64bit
>Reporter: zhanlijun
>Priority: Critical
> Fix For: 4.3.1
>
>
> the error as follows:
> java.lang.ClassCastException: 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingTerm cannot be cast to 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingBlock
> at 
> org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finish(BlockTreeTermsWriter.java:1014)
> at 
> org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:553)
> at 
> org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
> at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
> at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
> at 
> org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:493)
> at 
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:480)
> at 
> org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:413)
> at 
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1283)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1243)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1228)



--
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-6679) fix or remove suggester from stock solrconfig

[JIRA]

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

Jan Høydahl commented on SOLR-6679:
---

+1
Background thread build?
Would also like something more flexible than pure buildOnCommit. Perhaps an 
additional {{buildMinInterval=}} could tell the component that on a 
commit, it should only re-build if time-since-last-build > buildMinInterval.

> fix or remove suggester from stock solrconfig
> -
>
> Key: SOLR-6679
> URL: https://issues.apache.org/jira/browse/SOLR-6679
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10
>Reporter: Yonik Seeley
> Fix For: 5.0
>
>
> The stock solrconfig provides a bad experience with a large index... start up 
> Solr and it will spin at 100% CPU for minutes, unresponsive, while it 
> apparently builds a suggester index.



--
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-5302) Analytics Component

[Jack Krupansky (JIRA)]

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

Jack Krupansky commented on SOLR-5302:
--

Fix version still says trunk only... but this will be in 5.0 (branch_5x), right?

> Analytics Component
> ---
>
> Key: SOLR-5302
> URL: https://issues.apache.org/jira/browse/SOLR-5302
> Project: Solr
>  Issue Type: New Feature
>Reporter: Steven Bower
>Assignee: Erick Erickson
> Fix For: Trunk
>
> Attachments: SOLR-5302.patch, SOLR-5302.patch, SOLR-5302.patch, 
> SOLR-5302.patch, SOLR-5302_contrib.patch, Search Analytics Component.pdf, 
> Statistical Expressions.pdf, solr_analytics-2013.10.04-2.patch
>
>
> This ticket is to track a "replacement" for the StatsComponent. The 
> AnalyticsComponent supports the following features:
> * All functionality of StatsComponent (SOLR-4499)
> * Field Faceting (SOLR-3435)
> ** Support for limit
> ** Sorting (bucket name or any stat in the bucket
> ** Support for offset
> * Range Faceting
> ** Supports all options of standard range faceting
> * Query Faceting (SOLR-2925)
> * Ability to use overall/field facet statistics as input to range/query 
> faceting (ie calc min/max date and then facet over that range
> * Support for more complex aggregate/mapping operations (SOLR-1622)
> ** Aggregations: min, max, sum, sum-of-square, count, missing, stddev, mean, 
> median, percentiles
> ** Operations: negation, abs, add, multiply, divide, power, log, date math, 
> string reversal, string concat
> ** Easily pluggable framework to add additional operations
> * New / cleaner output format
> Outstanding Issues:
> * Multi-value field support for stats (supported for faceting)
> * Multi-shard support (may not be possible for some operations, eg median)



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6039:
--

 Summary: Add IndexOptions.NO and DocValuesType.NO, instead of null
 Key: LUCENE-6039
 URL: https://issues.apache.org/jira/browse/LUCENE-6039
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, Trunk


Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
via Indexable/FieldType and FieldInfo that we use null to mean it's
not indexed or has no doc values.

We should instead have an explicit choice (IndexOptions.NO,
DocValuesType.NO) in the enum?




--
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-5379) Query-time multi-word synonym expansion

[JIRA]

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

Jan Høydahl commented on SOLR-5379:
---

Interest in picking this up again? [~rpialum], I have not looked at your 
patches yet, but am interested in facilitating / reviewing

> Query-time multi-word synonym expansion
> ---
>
> Key: SOLR-5379
> URL: https://issues.apache.org/jira/browse/SOLR-5379
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Tien Nguyen Manh
>  Labels: multi-word, queryparser, synonym
> Fix For: 4.9, Trunk
>
> Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, 
> quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch
>
>
> While dealing with synonym at query time, solr failed to work with multi-word 
> synonyms due to some reasons:
> - First the lucene queryparser tokenizes user query by space so it split 
> multi-word term into two terms before feeding to synonym filter, so synonym 
> filter can't recognized multi-word term to do expansion
> - Second, if synonym filter expand into multiple terms which contains 
> multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
> handle synonyms. But MultiPhraseQuery don't work with term have different 
> number of words.
> For the first one, we can extend quoted all multi-word synonym in user query 
> so that lucene queryparser don't split it. There are a jira task related to 
> this one https://issues.apache.org/jira/browse/LUCENE-2605.
> For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
> SHOULD which contains multiple PhraseQuery in case tokens stream have 
> multi-word synonym.



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6039:
---
Attachment: LUCENE-6039.patch

Patch, tests pass, but this is really quite a dangerous change since I
could easily (and likely did) miss places in the code that still think
null means "not indexed" or "no doc values".

I tried adding @NotNull annotations and ran code inspection with
Intellij but was unable to get anything useful out of it: blatant
violations weren't caught, and trivial things were caught, or maybe
I just ran it wrong...  If anyone has experience getting \@NotNull/NonNull
to report useful issues please help :)

I also pulled DocValuesType and IndexOptions out of FieldInfo.java
into their own sources (in oal.index), and renamed
IndexOptions.DOCS_ONLY -> DOCS.


> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6039:
---

+1

Null is always bad. Its horrible to use null for empty collections instead of 
Collections.emptyList() or like that. To me the other worst thing is the "null" 
Scorer or "null" DocIdSets To me a query hitting no docs, should return an 
Empty Scorer implementation.

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6039:
-

Thank you Mike. I will review the patch.

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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-6365) specify appends, defaults, invariants outside of the component

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6365:
--

request_params -> initParams-> params in handler

this means the 

values are applied in that order for defaults and in the opposite order for 
invariants

so if you used "invariants" in the request handler , it would have taken 
precedence over initParams

We can go either way

bq.I haven't thought about it too deeply. Off the top of my head, having 
locally-defined parameters override the initParams seems best. 

Just keep one thing in mind that "invariants" is expected to work differently 
than "defaults"


> specify  appends, defaults, invariants outside of the component
> ---
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, 
> SOLR-6365.patch
>
>
> The components are configured in solrconfig.xml mostly for specifying these 
> extra parameters. If we separate these out, we can avoid specifying the 
> components altogether and make solrconfig much simpler. Eventually we want 
> users to see all functions as paths instead of components and control these 
> params from outside , through an API and persisted in ZK
> objectives :
> * define standard components implicitly and let users override some params 
> only
> * reuse standard params across components
> * define multiple param sets and mix and match these params at request time
> example
> {code:xml}
> 
> 
>   
>  json
>  _txt
>   
> 
> {code}
> other examples
> {code:xml}
> 
> 
>   A
> 
> 
>   B
> 
> 
>   C
> 
>   
>   
>   
>   
>class="DumpRequestHandler"/>
>   
>   
> 
>   A1
> 
> 
>   B1
> 
> 
>   C1
> 
>   
> {code}
>  



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6039:
-

+1 (i would commit it soon, so it doesnt go out of date). 

When reviewing usages, i noticed some cases like this (SegmentReader):

{code}
if (fieldInfo.getDocValuesType() == null) {
{code}

We should open a followup issue to decide what to do about helper methods of 
hasDocValues()/isIndexed()... either cutover consistently or remove the helpers?

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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-6676) Return 500 if bad json data is posted to Solr?

[liuqibj (JIRA)]

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

liuqibj commented on SOLR-6676:
---

Thanks. I use the tutorial to post a sample json but I make a change to the 
correct json to invalid.
Here is the json:
[
  {
"id" : "978-0641723445",
"cat" : ["book","hardcover"],
"name" : "The Lightning Thief",
"author" : "Rick Riordan",
"series_t" : "Percy Jackson and the Olympians",
"sequence_i" : 1,
"genre_s" : "fantasy\",
"inStock" : true,
"price" : 12.50,
"pages_i" : 384
  }
,
  {
"id" : "978-1423103349",
"cat" : ["book","paperback"],
"name" : "The Sea of Monsters",
"author" : "Rick Riordan",
"series_t" : "Percy Jackson and the Olympians",
"sequence_i" : 2,
"genre_s" : "fantasy",
"inStock" : true,
"price" : 6.49,
"pages_i" : 304
  }
,
  {
"id" : "978-1857995879",
"cat" : ["book","paperback"],
"name" : "Sophie's World : The Greek Philosophers",
"author" : "Jostein Gaarder",
"sequence_i" : 1,
"genre_s" : "fantasy",
"inStock" : true,
"price" : 3.07,
"pages_i" : 64
  }
,
  {
"id" : "978-1933988177",
"cat" : ["book","paperback"],
"name" : "Lucene in Action, Second Edition",
"author" : "Michael McCandless",
"sequence_i" : 1,
"genre_s" : "IT",
"inStock" : true,
"price" : 30.50,
"pages_i" : 475
  }
]

The results:
C:\solr4.7.0\solr-4.7.0\solr-4.7.0\example\exampledocs>java -Dtype=application/j
son -jar post.jar books.json
SimplePostTool version 1.5
Posting files to base url http://localhost:8983/solr/update using content-type a
pplication/json..
POSTing file books.json
SimplePostTool: WARNING: Solr returned an error #500 Server Error
SimplePostTool: WARNING: IOException while reading response: java.io.IOException
: Server returned HTTP response code: 500 for URL: http://localhost:8983/solr/up
date
1 files indexed.
COMMITting Solr index changes to http://localhost:8983/solr/update..
Time spent: 0:00:00.141

> Return 500 if bad json data is posted to Solr?
> --
>
> Key: SOLR-6676
> URL: https://issues.apache.org/jira/browse/SOLR-6676
> Project: Solr
>  Issue Type: Bug
>  Components: update
>Affects Versions: 4.7.2
>Reporter: liuqibj
>
> When posting  invalid json data to Solr and we often get 400 response code 
> but some cases return 500 if bad json data is posted. The call stack looks 
> like this(see below). There are multiple reasons if Solr return 500 errors.  
> Is there any way to distinguish whether the 500 errors is due to bad json 
> data or other reasons?
> at org.apache.noggit.JSONParser.err
> at org.apache.noggit.JSONParser.next
> at org.apache.noggit.JSONParser.nextEvent
> at 
> org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate
> at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load
> at org.apache.solr.handler.loader.JsonLoader.load



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

Re: "field exists" queries and benchmarks

[Tommaso Teofili]

thanks Uwe!

Performances do not seem much different (WildcardQuery seem to dominate),
are there any specific docValue settings to make that work the best?

One more question, does anyone know why TermRangeQuery (somefield:[* TO *])
and WildcardQuery (somefield:*) do not return the exact number of docs
having that field? See my test output for a field all 100k documents have
(with a random value):

   [junit4]   1> changing:[* TO *]

   [junit4]   1> 99526 hits

   [junit4]   1> changing:*

   [junit4]   1> 99526 hits

   [junit4]   1> fields:changing

   [junit4]   1> 10 hits

Regards,
Tommaso


2014-10-30 17:46 GMT+01:00 Uwe Schindler :

> Hi,
>
>
>
> there are already a Filter available (that optimizes this special case):
>
>
> http://lucene.apache.org/core/4_10_1/core/org/apache/lucene/search/FieldValueFilter.html
>
>
>
> To make a query out of it use ConstantScoreQuery. But this filter is
> better used as real filter, because it has a bitset behind.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
> *Sent:* Thursday, October 30, 2014 5:34 PM
> *To:* dev@lucene.apache.org
> *Subject:* "field exists" queries and benchmarks
>
>
>
> Hi all,
>
>
>
> I'm doing some (rough) tests / benchmarks in order to understand what's
> the best way of doing a "field exists" query.
>
>
>
> As far as I could find we can use TermRangeQuery (somefield:[* TO *]),
> WildcardQuery (somefield:*) or a plain TermQuery on another field where the
> doc's fieldnames have been indexed (fields:somfield).
>
>
>
> Besides some other suggestion on how to accomplish that (very much
> welcome), I'd like to understand what is the expected performance of each
> of the above approaches because in my case the TermRangeQuery seems to be
> the less performant while the other 2 are on average on the same level.
>
>
>
> One strange thing is that with TermRangeQuery and WildcardQuery the
> hitcount is not fully correct, I meaning that with 100k docs I get the
> correct hit count only with the TermQuery approach.
>
> Code and sample outputs can be found at [1].
>
> Any hint would be appreciated.
>
>
>
> Regards,
>
> Tommaso
>
>
>
> [1] : https://gist.github.com/tteofili/52856d938fcd465eab58
>

RE: "field exists" queries and benchmarks

[Uwe Schindler]

Hi,

 

be aware that FieldValueFilter uses FieldCache (and may possibly use DocValues, 
if indexed with that – I am not sure for this case), so it might be slower on 
the first run. In any case, as this is a BitSet filter, its best if executed 
with another query that drives the iteration. Otherwise it is plain stupid 
incrementing document numbers until a match is found.

 

In theory, TermRangeQuery should return the same results, but maybe you have 
some issues with deleted documents? Another thing might be that the wirldcard 
does not match all your fields, e.g. maybe because it’s the empty string? In 
theory it should match, it would just be something to look into. Maybe there is 
a real bug. Which version of Lucene?

 

Is the number returned by FieldValueFilter identical to TermRange/Wildcard? Or 
is it correct with respect to your other approach?

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] 
Sent: Friday, October 31, 2014 1:21 PM
To: dev@lucene.apache.org
Subject: Re: "field exists" queries and benchmarks

 

thanks Uwe!

 

Performances do not seem much different (WildcardQuery seem to dominate), are 
there any specific docValue settings to make that work the best?

 

One more question, does anyone know why TermRangeQuery (somefield:[* TO *]) and 
WildcardQuery (somefield:*) do not return the exact number of docs having that 
field? See my test output for a field all 100k documents have (with a random 
value):

   [junit4]   1> changing:[* TO *]

   [junit4]   1> 99526 hits

   [junit4]   1> changing:*

   [junit4]   1> 99526 hits

   [junit4]   1> fields:changing

   [junit4]   1> 10 hits

 

Regards,

Tommaso

 

 

2014-10-30 17:46 GMT+01:00 Uwe Schindler :

Hi,

 

there are already a Filter available (that optimizes this special case):

http://lucene.apache.org/core/4_10_1/core/org/apache/lucene/search/FieldValueFilter.html

 

To make a query out of it use ConstantScoreQuery. But this filter is better 
used as real filter, because it has a bitset behind.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] 
Sent: Thursday, October 30, 2014 5:34 PM
To: dev@lucene.apache.org
Subject: "field exists" queries and benchmarks

 

Hi all,

 

I'm doing some (rough) tests / benchmarks in order to understand what's the 
best way of doing a "field exists" query.

 

As far as I could find we can use TermRangeQuery (somefield:[* TO *]), 
WildcardQuery (somefield:*) or a plain TermQuery on another field where the 
doc's fieldnames have been indexed (fields:somfield).

 

Besides some other suggestion on how to accomplish that (very much welcome), 
I'd like to understand what is the expected performance of each of the above 
approaches because in my case the TermRangeQuery seems to be the less 
performant while the other 2 are on average on the same level.

 

One strange thing is that with TermRangeQuery and WildcardQuery the hitcount is 
not fully correct, I meaning that with 100k docs I get the correct hit count 
only with the TermQuery approach.

Code and sample outputs can be found at [1].

Any hint would be appreciated.

 

Regards,

Tommaso

 

[1] : https://gist.github.com/tteofili/52856d938fcd465eab58

 

[jira] [Commented] (SOLR-6533) Support editing common solrconfig.xml values

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6533:
--

TODO and printStacktrace etc will be fixed before any checkin happens

bq. I think users should be able to enable/disable this feature. 

Yes that will be added as a system property

> Support editing common solrconfig.xml values
> 
>
> Key: SOLR-6533
> URL: https://issues.apache.org/jira/browse/SOLR-6533
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Noble Paul
> Attachments: SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch, 
> SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch, SOLR-6533.patch
>
>
> There are a bunch of properties in solrconfig.xml which users want to edit. 
> We will attack them first
> These properties will be persisted to a separate file called config.json (or 
> whatever file). Instead of saving in the same format we will have well known 
> properties which users can directly edit
> {code}
> updateHandler.autoCommit.maxDocs
> query.filterCache.initialSize
> {code}   
> The api will be modeled around the bulk schema API
> {code:javascript}
> curl http://localhost:8983/solr/collection1/config -H 
> 'Content-type:application/json'  -d '{
> "set-property" : {"updateHandler.autoCommit.maxDocs":5},
> "unset-property": "updateHandler.autoCommit.maxDocs"
> }'
> {code}
> {code:javascript}
> //or use this to set ${mypropname} values
> curl http://localhost:8983/solr/collection1/config -H 
> 'Content-type:application/json'  -d '{
> "set-user-property" : {"mypropname":"my_prop_val"},
> "unset-user-property":{"mypropname"}
> }'
> {code}
> The values stored in the config.json will always take precedence and will be 
> applied after loading solrconfig.xml. 
> An http GET on /config path will give the real config that is applied . 
> An http GET of/config/overlay gives out the content of the configOverlay.json
> /config/ gives only the fchild of the same name from /config



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

Re: "field exists" queries and benchmarks

[Tommaso Teofili]

Hi,

2014-10-31 13:37 GMT+01:00 Uwe Schindler :

> Hi,
>
>
>
> be aware that FieldValueFilter uses FieldCache (and may possibly use
> DocValues, if indexed with that – I am not sure for this case),
>

yes, I'm trying with (binary/sorted) docValues.


> so it might be slower on the first run. In any case, as this is a BitSet
> filter, its best if executed with another query that drives the iteration.
> Otherwise it is plain stupid incrementing document numbers until a match is
> found.
>

my use case is for a plain "field xyx exists" query, so I am just
interested in retrieving those documents having the field xyz with whatever
value (empty string included)


>
>
> In theory, TermRangeQuery should return the same results, but maybe you
> have some issues with deleted documents?
>

no, that's just a testcase where I don't have deletions.


> Another thing might be that the wirldcard does not match all your fields,
> e.g. maybe because it’s the empty string? In theory it should match, it
> would just be something to look into. Maybe there is a real bug.
>

the strange thing is that both WildcardQuery and TermRanqueQuery return the
same (wrong) hitcount.


> Which version of Lucene?
>

I'm using trunk


>
>
> Is the number returned by FieldValueFilter identical to
> TermRange/Wildcard? Or is it correct with respect to your other approach?
>

the FieldValueFilter and the TermQuery (meaning I index each doc's field
names into another field and search for fields:xyz) return the right number
(100k), while TermRangeQuery and WildcardQuery both return less hits, I
figured out it's because of empty Strings, as you said this should be
working though.

Regards,
Tommaso


>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
> *Sent:* Friday, October 31, 2014 1:21 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: "field exists" queries and benchmarks
>
>
>
> thanks Uwe!
>
>
>
> Performances do not seem much different (WildcardQuery seem to dominate),
> are there any specific docValue settings to make that work the best?
>
>
>
> One more question, does anyone know why TermRangeQuery (somefield:[* TO
> *]) and WildcardQuery (somefield:*) do not return the exact number of docs
> having that field? See my test output for a field all 100k documents have
> (with a random value):
>
>[junit4]   1> changing:[* TO *]
>
>[junit4]   1> 99526 hits
>
>[junit4]   1> changing:*
>
>[junit4]   1> 99526 hits
>
>[junit4]   1> fields:changing
>
>[junit4]   1> 10 hits
>
>
>
> Regards,
>
> Tommaso
>
>
>
>
>
> 2014-10-30 17:46 GMT+01:00 Uwe Schindler :
>
> Hi,
>
>
>
> there are already a Filter available (that optimizes this special case):
>
>
> http://lucene.apache.org/core/4_10_1/core/org/apache/lucene/search/FieldValueFilter.html
>
>
>
> To make a query out of it use ConstantScoreQuery. But this filter is
> better used as real filter, because it has a bitset behind.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
> *Sent:* Thursday, October 30, 2014 5:34 PM
> *To:* dev@lucene.apache.org
> *Subject:* "field exists" queries and benchmarks
>
>
>
> Hi all,
>
>
>
> I'm doing some (rough) tests / benchmarks in order to understand what's
> the best way of doing a "field exists" query.
>
>
>
> As far as I could find we can use TermRangeQuery (somefield:[* TO *]),
> WildcardQuery (somefield:*) or a plain TermQuery on another field where the
> doc's fieldnames have been indexed (fields:somfield).
>
>
>
> Besides some other suggestion on how to accomplish that (very much
> welcome), I'd like to understand what is the expected performance of each
> of the above approaches because in my case the TermRangeQuery seems to be
> the less performant while the other 2 are on average on the same level.
>
>
>
> One strange thing is that with TermRangeQuery and WildcardQuery the
> hitcount is not fully correct, I meaning that with 100k docs I get the
> correct hit count only with the TermQuery approach.
>
> Code and sample outputs can be found at [1].
>
> Any hint would be appreciated.
>
>
>
> Regards,
>
> Tommaso
>
>
>
> [1] : https://gist.github.com/tteofili/52856d938fcd465eab58
>
>
>

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 672 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/672/

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload

Error Message:
expected:<[{indexVersion=1414758079019,generation=2,filelist=[_5.cfe, _5.cfs, 
_5.si, _7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, 
_7_MockRandom_0.sd, _7_MockRandom_0.tio, _7_MockRandom_0.tipo, _8.cfe, _8.cfs, 
_8.si, segments_2]}]> but 
was:<[{indexVersion=1414758079019,generation=3,filelist=[_7.fdt, _7.fdx, 
_7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, _7_MockRandom_0.sd, 
_7_MockRandom_0.tio, _7_MockRandom_0.tipo, _9.fdt, _9.fdx, _9.fnm, _9.nvd, 
_9.nvm, _9.si, _9_MockRandom_0.doc, _9_MockRandom_0.sd, _9_MockRandom_0.tib, 
_9_MockRandom_0.tii, segments_3]}, 
{indexVersion=1414758079019,generation=2,filelist=[_5.cfe, _5.cfs, _5.si, 
_7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, 
_7_MockRandom_0.sd, _7_MockRandom_0.tio, _7_MockRandom_0.tipo, _8.cfe, _8.cfs, 
_8.si, segments_2]}]>

Stack Trace:
java.lang.AssertionError: 
expected:<[{indexVersion=1414758079019,generation=2,filelist=[_5.cfe, _5.cfs, 
_5.si, _7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, 
_7_MockRandom_0.sd, _7_MockRandom_0.tio, _7_MockRandom_0.tipo, _8.cfe, _8.cfs, 
_8.si, segments_2]}]> but 
was:<[{indexVersion=1414758079019,generation=3,filelist=[_7.fdt, _7.fdx, 
_7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, _7_MockRandom_0.sd, 
_7_MockRandom_0.tio, _7_MockRandom_0.tipo, _9.fdt, _9.fdx, _9.fnm, _9.nvd, 
_9.nvm, _9.si, _9_MockRandom_0.doc, _9_MockRandom_0.sd, _9_MockRandom_0.tib, 
_9_MockRandom_0.tii, segments_3]}, 
{indexVersion=1414758079019,generation=2,filelist=[_5.cfe, _5.cfs, _5.si, 
_7.fdt, _7.fdx, _7.fnm, _7.nvd, _7.nvm, _7.si, _7_MockRandom_0.doc, 
_7_MockRandom_0.sd, _7_MockRandom_0.tio, _7_MockRandom_0.tipo, _8.cfe, _8.cfs, 
_8.si, segments_2]}]>
at 
__randomizedtesting.SeedInfo.seed([A0D6DBA6BD68BF69:8501C096CD20B16A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload(TestReplicationHandler.java:1175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.Abstra

[jira] [Created] (SOLR-6684) Fix up /export JSON

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-6684:


 Summary: Fix up /export JSON
 Key: SOLR-6684
 URL: https://issues.apache.org/jira/browse/SOLR-6684
 Project: Solr
  Issue Type: Bug
Reporter: Joel Bernstein


This ticket does a couple of things. 

1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
records. 

2) Changes the JSON format to match-up with normal JSON result set.

Both changes with go in trunk and 5x. Only the bug fix will go in the 4.10 
branch.

 



--
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-6684) Fix-up /export JSON

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-6684:
-
Summary: Fix-up /export JSON  (was: Fix up /export JSON)

> Fix-up /export JSON
> ---
>
> Key: SOLR-6684
> URL: https://issues.apache.org/jira/browse/SOLR-6684
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
>
> This ticket does a couple of things. 
> 1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
> records. 
> 2) Changes the JSON format to match-up with normal JSON result set.
> Both changes with go in trunk and 5x. Only the bug fix will go in the 4.10 
> branch.
>  



--
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-6684) Fix-up /export JSON

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-6684:
-
Description: 
This ticket does a couple of things. 

1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
records. 

2) Changes the JSON format to match-up with the normal JSON result set.

Both changes will go in trunk and 5x. Only the bug fix will go in the 4.10 
branch.

 

  was:
This ticket does a couple of things. 

1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
records. 

2) Changes the JSON format to match-up with normal JSON result set.

Both changes with go in trunk and 5x. Only the bug fix will go in the 4.10 
branch.

 


> Fix-up /export JSON
> ---
>
> Key: SOLR-6684
> URL: https://issues.apache.org/jira/browse/SOLR-6684
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-6684.patch
>
>
> This ticket does a couple of things. 
> 1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
> records. 
> 2) Changes the JSON format to match-up with the normal JSON result set.
> Both changes will go in trunk and 5x. Only the bug fix will go in the 4.10 
> branch.
>  



--
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-6684) Fix-up /export JSON

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-6684:
-
Attachment: SOLR-6684.patch

> Fix-up /export JSON
> ---
>
> Key: SOLR-6684
> URL: https://issues.apache.org/jira/browse/SOLR-6684
> Project: Solr
>  Issue Type: Bug
>Reporter: Joel Bernstein
> Attachments: SOLR-6684.patch
>
>
> This ticket does a couple of things. 
> 1) Fixes a bug in the /export JSON, where a comma is missed every 30,000 
> records. 
> 2) Changes the JSON format to match-up with normal JSON result set.
> Both changes with go in trunk and 5x. Only the bug fix will go in the 4.10 
> branch.
>  



--
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-5379) Query-time multi-word synonym expansion

[Jeremy Anderson (JIRA)]

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

Jeremy Anderson commented on SOLR-5379:
---

Unfortunately, I'm swamped with other stuff on my plate.  Thinking back, I 
think I abandoned this approach and instead took Nolan Lawson's route (see 
SOLR-4381).  I don't recall how mature and stable I had gotten my patches 
before switching paths.

> Query-time multi-word synonym expansion
> ---
>
> Key: SOLR-5379
> URL: https://issues.apache.org/jira/browse/SOLR-5379
> Project: Solr
>  Issue Type: Improvement
>  Components: query parsers
>Reporter: Tien Nguyen Manh
>  Labels: multi-word, queryparser, synonym
> Fix For: 4.9, Trunk
>
> Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, 
> quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch
>
>
> While dealing with synonym at query time, solr failed to work with multi-word 
> synonyms due to some reasons:
> - First the lucene queryparser tokenizes user query by space so it split 
> multi-word term into two terms before feeding to synonym filter, so synonym 
> filter can't recognized multi-word term to do expansion
> - Second, if synonym filter expand into multiple terms which contains 
> multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
> handle synonyms. But MultiPhraseQuery don't work with term have different 
> number of words.
> For the first one, we can extend quoted all multi-word synonym in user query 
> so that lucene queryparser don't split it. There are a jira task related to 
> this one https://issues.apache.org/jira/browse/LUCENE-2605.
> For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
> SHOULD which contains multiple PhraseQuery in case tokens stream have 
> multi-word synonym.



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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2194 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2194/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ReplicationFactorTest.testDistribSearch

Error Message:
Didn't see all replicas for shard shard1 in repfacttest_c8n_1x3 come up within 
3 ms! ClusterState: {   "repfacttest_c8n_1x3":{ "shards":{"shard1":{
 "range":"8000-7fff", "state":"active", 
"replicas":{   "core_node1":{ "state":"down", 
"base_url":"http://127.0.0.1:61209";, 
"core":"repfacttest_c8n_1x3_shard1_replica1", 
"node_name":"127.0.0.1:61209_"},   "core_node2":{ 
"node_name":"127.0.0.1:61240_", 
"core":"repfacttest_c8n_1x3_shard1_replica2", "state":"active", 
"base_url":"http://127.0.0.1:61240"},   "core_node3":{  
   "node_name":"127.0.0.1:61199_", 
"core":"repfacttest_c8n_1x3_shard1_replica3", "state":"active", 
"base_url":"http://127.0.0.1:61199";, "leader":"true",   
  "autoAddReplicas":"false", "maxShardsPerNode":"1", 
"replicationFactor":"3", "router":{"name":"compositeId"}},   
"control_collection":{ "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "node_name":"127.0.0.1:61199_",  
   "core":"collection1", "state":"active", 
"base_url":"http://127.0.0.1:61199";, "leader":"true", 
"autoCreated":"true", "autoAddReplicas":"false", 
"maxShardsPerNode":"1", "replicationFactor":"1", 
"router":{"name":"compositeId"}},   "collection1":{ "shards":{   
"shard1":{ "range":"8000-d554", "state":"active",   
  "replicas":{"core_node2":{ "node_name":"127.0.0.1:61222_",
 "core":"collection1", "state":"active", 
"base_url":"http://127.0.0.1:61222";, "leader":"true"}}},   
"shard2":{ "range":"d555-2aa9", "state":"active",   
  "replicas":{"core_node1":{ "node_name":"127.0.0.1:61209_",
 "core":"collection1", "state":"active", 
"base_url":"http://127.0.0.1:61209";, "leader":"true"}}},   
"shard3":{ "range":"2aaa-7fff", "state":"active",   
  "replicas":{"core_node3":{ "node_name":"127.0.0.1:61240_",
 "core":"collection1", "state":"active", 
"base_url":"http://127.0.0.1:61240";, "leader":"true", 
"autoCreated":"true", "autoAddReplicas":"false", 
"maxShardsPerNode":"1", "replicationFactor":"1", 
"router":{"name":"compositeId"}}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in 
repfacttest_c8n_1x3 come up within 3 ms! ClusterState: {
  "repfacttest_c8n_1x3":{
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"state":"down",
"base_url":"http://127.0.0.1:61209";,
"core":"repfacttest_c8n_1x3_shard1_replica1",
"node_name":"127.0.0.1:61209_"},
  "core_node2":{
"node_name":"127.0.0.1:61240_",
"core":"repfacttest_c8n_1x3_shard1_replica2",
"state":"active",
"base_url":"http://127.0.0.1:61240"},
  "core_node3":{
"node_name":"127.0.0.1:61199_",
"core":"repfacttest_c8n_1x3_shard1_replica3",
"state":"active",
"base_url":"http://127.0.0.1:61199";,
"leader":"true",
"autoAddReplicas":"false",
"maxShardsPerNode":"1",
"replicationFactor":"3",
"router":{"name":"compositeId"}},
  "control_collection":{
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"node_name":"127.0.0.1:61199_",
"core":"collection1",
"state":"active",
"base_url":"http://127.0.0.1:61199";,
"leader":"true",
"autoCreated":"true",
"autoAddReplicas":"false",
"maxShardsPerNode":"1",
"replicationFactor":"1",
"router":{"name":"compositeId"}},
  "collection1":{
"shards":{
  "shard1":{
"range":"8000-d554",
"state":"active",
"replicas":{"core_node2":{
"node_name":"127.0.0.1:61222_",
"core":"collection1",
"state":"active",
"base_url":"http://127.0.0.1:61222";,
"leader":"true"}}},
  "shard2":{
"range":"d555-2aa9",
"state":"active",
"replicas":{"core_node1":{
"node_name":"127.0.0.1:61209_",
"core":"collection1",
"state":"active",
"base_url":"http://127.0.0.1:61209";,
  

[jira] [Commented] (SOLR-6365) specify appends, defaults, invariants outside of the component

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6365:
--

Hmm, it seems more intuitive that the order be

initParams are superseded by params_in_handler which are superseded by 
request_params

Invariants:
Right, then I should think that the last step in the above is omitted.
initParams are superseded by params_in_handler
and request_params are ignored.

I guess my thinking is that initParams are the most general bucket, and users  
may have reasons
for different handlers to override some of them and people issuing requests 
would have the
last chance to change them

I urge that we apply them in the same order for both invariants and defaults, 
I'd much rather
learn one rule than two, and I really don't want to explain it over and over an 
over again
to confused users ;)

> specify  appends, defaults, invariants outside of the component
> ---
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, 
> SOLR-6365.patch
>
>
> The components are configured in solrconfig.xml mostly for specifying these 
> extra parameters. If we separate these out, we can avoid specifying the 
> components altogether and make solrconfig much simpler. Eventually we want 
> users to see all functions as paths instead of components and control these 
> params from outside , through an API and persisted in ZK
> objectives :
> * define standard components implicitly and let users override some params 
> only
> * reuse standard params across components
> * define multiple param sets and mix and match these params at request time
> example
> {code:xml}
> 
> 
>   
>  json
>  _txt
>   
> 
> {code}
> other examples
> {code:xml}
> 
> 
>   A
> 
> 
>   B
> 
> 
>   C
> 
>   
>   
>   
>   
>class="DumpRequestHandler"/>
>   
>   
> 
>   A1
> 
> 
>   B1
> 
> 
>   C1
> 
>   
> {code}
>  



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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_40-ea-b09) - Build # 4301 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4301/
Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([9E1ABDB7F4495C07]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([9E1ABDB7F4495C07]:0)




Build Log:
[...truncated 11151 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ChaosMonkeySafeLeaderTest-9E1ABDB7F4495C07-001\init-core-data-001
   [junit4]   2> 443449 T1176 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(true) and clientAuth (false)
   [junit4]   2> 443449 T1176 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /
   [junit4]   2> 443452 T1176 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 443452 T1176 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 443453 T1177 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 443550 T1176 oasc.ZkTestServer.run start zk server on 
port:59387
   [junit4]   2> 443550 T1176 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 443552 T1176 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 443558 T1183 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@7a2e96f8 
name:ZooKeeperConnection Watcher:127.0.0.1:59387 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 443558 T1176 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 443558 T1176 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 443558 T1176 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 443567 T1176 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 443570 T1176 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 443574 T1185 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@41fa0221 
name:ZooKeeperConnection Watcher:127.0.0.1:59387/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 443574 T1176 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 443574 T1176 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 443574 T1176 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 443578 T1176 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 443581 T1176 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 443583 T1176 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 443586 T1176 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 443587 T1176 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 443590 T1176 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 443595 T1176 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 443600 T1176 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 443600 T1176 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 443611 T1176 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 443611 T1176 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 443618 T1176 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsS

[jira] [Commented] (SOLR-6365) specify appends, defaults, invariants outside of the component

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-6365:


{code}
Hmm, it seems more intuitive that the order be

initParams are superseded by params_in_handler which are superseded by 
request_params

Invariants:
Right, then I should think that the last step in the above is omitted.
initParams are superseded by params_in_handler
and request_params are ignored.
{code}

+1, I'm exactly with [~erickerickson] on this.

> specify  appends, defaults, invariants outside of the component
> ---
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, 
> SOLR-6365.patch
>
>
> The components are configured in solrconfig.xml mostly for specifying these 
> extra parameters. If we separate these out, we can avoid specifying the 
> components altogether and make solrconfig much simpler. Eventually we want 
> users to see all functions as paths instead of components and control these 
> params from outside , through an API and persisted in ZK
> objectives :
> * define standard components implicitly and let users override some params 
> only
> * reuse standard params across components
> * define multiple param sets and mix and match these params at request time
> example
> {code:xml}
> 
> 
>   
>  json
>  _txt
>   
> 
> {code}
> other examples
> {code:xml}
> 
> 
>   A
> 
> 
>   B
> 
> 
>   C
> 
>   
>   
>   
>   
>class="DumpRequestHandler"/>
>   
>   
> 
>   A1
> 
> 
>   B1
> 
> 
>   C1
> 
>   
> {code}
>  



--
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-6365) specify appends, defaults, invariants outside of the component

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6365:
--

agreed
I shall change this right away


> specify  appends, defaults, invariants outside of the component
> ---
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch, 
> SOLR-6365.patch
>
>
> The components are configured in solrconfig.xml mostly for specifying these 
> extra parameters. If we separate these out, we can avoid specifying the 
> components altogether and make solrconfig much simpler. Eventually we want 
> users to see all functions as paths instead of components and control these 
> params from outside , through an API and persisted in ZK
> objectives :
> * define standard components implicitly and let users override some params 
> only
> * reuse standard params across components
> * define multiple param sets and mix and match these params at request time
> example
> {code:xml}
> 
> 
>   
>  json
>  _txt
>   
> 
> {code}
> other examples
> {code:xml}
> 
> 
>   A
> 
> 
>   B
> 
> 
>   C
> 
>   
>   
>   
>   
>class="DumpRequestHandler"/>
>   
>   
> 
>   A1
> 
> 
>   B1
> 
> 
>   C1
> 
>   
> {code}
>  



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6039:


Thanks, I'll commit shortly, and open a followup: I think we should remove the 
sugar methods, since they make it seem like there are somehow still separate 
booleans storing this information in the low schema.

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



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

Re: "field exists" queries and benchmarks

[Adrien Grand]

On Fri, Oct 31, 2014 at 2:03 PM, Tommaso Teofili
 wrote:
>> Which version of Lucene?
>
>
> I'm using trunk

Then it might be due to
https://issues.apache.org/jira/browse/LUCENE-6038. Maybe you can try
again with the patch applied?

-- 
Adrien

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-6058:
---

Commit 1635789 from [~sar...@syr.edu] in branch 'cms/branches/solr_6058'
[ https://svn.apache.org/r1635789 ]

SOLR-6058: Add Taming Text cover image to the front page; link from front page 
book cover images to the book's description on the resources pages; add book 
cover images and links to buy to the book section on the resources page; add 
Taming Text placeholder (needs blurb) to the book section on the resources page

> Solr needs a new website
> 
>
> Key: SOLR-6058
> URL: https://issues.apache.org/jira/browse/SOLR-6058
> Project: Solr
>  Issue Type: Task
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
> Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
> Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
> Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
> Solr_Logo_on_white.png, Solr_Styleguide.pdf
>
>
> Solr needs a new website:  better organization of content, less verbose, more 
> pleasing graphics, etc.



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[ASF subversion and git services (JIRA)]

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

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

Commit 1635790 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1635790 ]

LUCENE-6039: cutover to IndexOptions.NO/DocValuesType.NO instead of null

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6038) FieldValueFilter regression

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6038:
---

Thanks! In fact, this is not a regression, it just misses to apply the 
optimization. But the results are the same, just slower because of additional 
wrapping (which causes to do simple brute-force).

We should maybe add a test that verifies this optimization?

> FieldValueFilter regression
> ---
>
> Key: LUCENE-6038
> URL: https://issues.apache.org/jira/browse/LUCENE-6038
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6038.patch
>
>
> The decoupling of FixedBitSet from a DocIdSet (LUCENE-5441) introduced a 
> regression in FieldValueFilter, which checks if the bits for documents with a 
> field  is an instance of a DocIdSet. Yet FixedBitSet does not extend DocIdSet 
> anymore.



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

Re: "field exists" queries and benchmarks

[Tommaso Teofili]

2014-10-31 15:58 GMT+01:00 Adrien Grand :

> On Fri, Oct 31, 2014 at 2:03 PM, Tommaso Teofili
>  wrote:
> >> Which version of Lucene?
> >
> >
> > I'm using trunk
>
> Then it might be due to
> https://issues.apache.org/jira/browse/LUCENE-6038. Maybe you can try
> again with the patch applied?
>

the FieldValueFilter based one works ok, so I don't think it's that.

Thanks,
Tommaso


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

RE: "field exists" queries and benchmarks

[Uwe Schindler]

Hi

Hey this line confused me, too. But this should not be a regression, it just 
misses an "Optimization", right? This might explain why he sees no real 
performance.

The problem of Tomaso: He sees no hits for some documents in 
TermRangeQuery/Wildcard: The reason is that empty terms are not *indexed* but 
they appear in *DocValues* - so he sees the difference between the queries.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Adrien Grand [mailto:jpou...@gmail.com]
> Sent: Friday, October 31, 2014 3:59 PM
> To: dev@lucene.apache.org
> Subject: Re: "field exists" queries and benchmarks
> 
> On Fri, Oct 31, 2014 at 2:03 PM, Tommaso Teofili
>  wrote:
> >> Which version of Lucene?
> >
> >
> > I'm using trunk
> 
> Then it might be due to
> https://issues.apache.org/jira/browse/LUCENE-6038. Maybe you can try
> again with the patch applied?
> 
> --
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Commented] (SOLR-3975) Document Summarization toolkit, using LSA techniques

[yuanyun.cn (JIRA)]

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

yuanyun.cn commented on SOLR-3975:
--

It would be good if Solr can provide a document summarization processor, so 
during index, we can get the summary of the document and save it into index.

> Document Summarization toolkit, using LSA techniques
> 
>
> Key: SOLR-3975
> URL: https://issues.apache.org/jira/browse/SOLR-3975
> Project: Solr
>  Issue Type: New Feature
>Reporter: Lance Norskog
>Priority: Minor
> Attachments: 4.1.summary.patch, reuters.sh
>
>
> This package analyzes sentences and words as used across sentences to rank 
> the most important sentences and words. The general topic is called "document 
> summarization" and is a popular research topic in textual analysis. 
> How to use:
> 1) Check out the 4.x branch, apply the patch, build, and run the solr/example 
> instance.
> 2) Download the first Reuters article corpus from:
> http://kdd.ics.uci.edu/databases/reuters21578/reuters21578.tar.gz
> 3) Unpack this into a directory.
> 4) Run the attached 'reuters.sh' script:
> sh reuters.sh directory http://localhost:8983/solr/collection1
> 5) Wait several minutes.
> Now go to http://localhost:8983/solr/collection1/browse?summary=true and look 
> at the large gray box marked 'Document Summary'. This has a table of 
> statistics about the analysis, the three most important sentences, and 
> several of the most important words in the documents. The sentences have the 
> important words in italics.
> The code is packaged as a search component and as an analysis handler. The 
> /browse demo uses the search component, and you can also post raw text to  
> http://localhost:8983/solr/collection1/analysis/summary. Here is a sample 
> command:
> {code}
> curl -s 
> "http://localhost:8983/solr/analysis/summary?indent=true&echoParams=all&file=$FILE&wt=xml";
>  --data-binary @$FILE -H 'Content-type:application/xml'
> {code}
> This is an implementation of LSA-based document summarization. A short 
> explanation and a long evaluation are described in my blog, [Uncle Lance's 
> Ultra Whiz Bang|http://ultrawhizbang.blogspot.com], starting here: 
> [http://ultrawhizbang.blogspot.com/2012/09/document-summarization-with-lsa-1.html]



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[ASF subversion and git services (JIRA)]

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

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

Commit 1635804 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1635804 ]

LUCENE-6039: cutover to IndexOptions.NO/DocValuesType.NO instead of null

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[ASF subversion and git services (JIRA)]

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

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

Commit 1635807 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1635807 ]

LUCENE-6039: a few more null checks

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-5919:
-

I think we should resolve this as invalid?

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5850) Race condition in ConcurrentUpdateSolrServer

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5850:
---
Attachment: SOLR-5850.patch

Added a patch for this. Basically changing queue.add() to queue.offer(), which 
will wait till a timeout (configurable) for inserting into the queue, if it is 
full. 

> Race condition in ConcurrentUpdateSolrServer
> 
>
> Key: SOLR-5850
> URL: https://issues.apache.org/jira/browse/SOLR-5850
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java, search, SolrCloud, update
>Affects Versions: 4.6
>Reporter: Devansh Dhutia
>Priority: Critical
>  Labels: 500, cloud, difficulty-medium, error, impact-medium, 
> update
> Attachments: SOLR-5850.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Possibly related to SOLR-2308, we are seeing a Queue Full error message when 
> issuing writes to Solr Cloud
> Each Update has 200 documents, and a commit is issued after 2000 documents 
> have been added. 
> The writes are spread out to all the servers in the cloud (2 in this case) 
> and following is the stack trace from Solr: 
> {code:xml}
> 
> 
> 500 name="QTime">101Queue 
> fulljava.lang.IllegalStateException: Queue full
> at java.util.AbstractQueue.add(Unknown Source)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner$1.writeTo(ConcurrentUpdateSolrServer.java:181)
> at 
> org.apache.http.entity.EntityTemplate.writeTo(EntityTemplate.java:72)
> at 
> org.apache.http.entity.HttpEntityWrapper.writeTo(HttpEntityWrapper.java:98)
> at 
> org.apache.http.impl.client.EntityEnclosingRequestWrapper$EntityWrapper.writeTo(EntityEnclosingRequestWrapper.java:108)
> at 
> org.apache.http.impl.entity.EntitySerializer.serialize(EntitySerializer.java:122)
> at 
> org.apache.http.impl.AbstractHttpClientConnection.sendRequestEntity(AbstractHttpClientConnection.java:271)
> at 
> org.apache.http.impl.conn.ManagedClientConnectionImpl.sendRequestEntity(ManagedClientConnectionImpl.java:197)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:257)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
> at 
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
> at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> at 
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:232)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> 500
> 
> {code}



--
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-6662) "bin/solr -h" hangs w/o doing anything

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-6662:
---

Commit 1635812 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1635812 ]

SOLR-6662: better validation when parsing command-line options that expect a 
value

> "bin/solr -h" hangs w/o doing anything
> --
>
> Key: SOLR-6662
> URL: https://issues.apache.org/jira/browse/SOLR-6662
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Timothy Potter
>
> i ran "./bin/solr -h" thinking it would either give me "help" info about 
> running the script, or an error if that argument was invalid -- but instead 
> if just hangs printing nothing and doing nothing.
> I realize now that "-h" is for specifying a "host" - but that makes the 
> behavior all the more weird since it didn't give me an error about a missing 
> hostname



--
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-6058) Solr needs a new website

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-6058:
---

Commit 1635811 from [~sar...@syr.edu] in branch 'cms/branches/solr_6058'
[ https://svn.apache.org/r1635811 ]

SOLR-6058: revert h3 += offset class, intended to fix nav bar hiding of 
individual books at h3, but matched other inappropriate stuff too

> Solr needs a new website
> 
>
> Key: SOLR-6058
> URL: https://issues.apache.org/jira/browse/SOLR-6058
> Project: Solr
>  Issue Type: Task
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
> Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
> Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
> Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
> Solr_Logo_on_white.png, Solr_Styleguide.pdf
>
>
> Solr needs a new website:  better organization of content, less verbose, more 
> pleasing graphics, etc.



--
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] [Resolved] (SOLR-6597) SolrIndexConfig parameter in SolrIndexSearcher constructor is not used

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-6597.

Resolution: Fixed

> SolrIndexConfig parameter in SolrIndexSearcher constructor is not used
> --
>
> Key: SOLR-6597
> URL: https://issues.apache.org/jira/browse/SOLR-6597
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.10
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
> Fix For: 5.0
>
> Attachments: SOLR-6597.patch
>
>
> The following constructor of SolrIndexSearcher doesn't use 'config'.
> {code:title=SolrIndexSearcher}
> public SolrIndexSearcher(SolrCore core, String path, IndexSchema schema, 
> SolrIndexConfig config, String name, DirectoryReader r, boolean closeReader, 
> boolean enableCache, boolean reserveDirectory, DirectoryFactory 
> directoryFactory)
> {code}
> It doesn't make sense to pass in the SolrIndexConfig when we're passing in 
> the DirectoryReader (and asserting that it's never null). Prior to 
> LUCENE-5666, when 'r' was null, the config was used to get a reader but not 
> any more.
> I'll just remove the param from the constructor and remove it from all places 
> that calls this version of the constructor.



--
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] [Resolved] (SOLR-6544) Remove unused arguments from methods in DeleteReplicaTest

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-6544.

Resolution: Fixed

> Remove unused arguments from methods in DeleteReplicaTest
> -
>
> Key: SOLR-6544
> URL: https://issues.apache.org/jira/browse/SOLR-6544
> Project: Solr
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 5.0
>
> Attachments: SOLR-6544.patch
>
>
> There are unused arguments being passed in helper methods in 
> DeleteReplicaTest. We should remove those to avoid confusion.
> Also, the test has some unwanted iterations to get an active replica, fix 
> that.



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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 1914 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1914/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
REGRESSION:  org.apache.solr.TestDistributedGrouping.testDistribSearch

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:51138

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:51138
at 
__randomizedtesting.SeedInfo.seed([2D26F091FD6BBC5A:ACC07E898A34DC66]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:581)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:116)
at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:102)
at 
org.apache.solr.BaseDistributedSearchTestCase.index_specific(BaseDistributedSearchTestCase.java:488)
at 
org.apache.solr.TestDistributedGrouping.doTest(TestDistributedGrouping.java:139)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:875)
at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:54)
at 
org.apac

[jira] [Commented] (SOLR-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5919:


shalin: honestly i forgot all about this issue.

I defer to you & miller on this - but reading back over the comments i still 
think my two concerns seems concerning...

{quote}
1) ... all of the test scaffolding ... isn't actually comparing a cloud mode 
response with a standalone mode response – it's comparing a cloud mode 
multi-shard response with a cloud mode single-shard response.

2) can't this lead to inconsistencies in chaos tests if the chaos monkey shuts 
down the server running the control_collection?
{quote}

..but even if others agree, those should really be new/distinct issues.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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] [Resolved] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6039.

Resolution: Fixed

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6040) Speedup broadword bit selection

[Paul Elschot (JIRA)]

Paul Elschot created LUCENE-6040:


 Summary: Speedup broadword bit selection
 Key: LUCENE-6040
 URL: https://issues.apache.org/jira/browse/LUCENE-6040
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/other
Reporter: Paul Elschot
Priority: Minor


Use table lookup instead of some broadword manipulations



--
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] (LUCENE-6040) Speedup broadword bit selection

[Paul Elschot (JIRA)]

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

Paul Elschot updated LUCENE-6040:
-
Attachment: LUCENE-6040.patch

This adds two bit select methods to BroadWord.java.

selectWithByteLookup() works like select() but uses a lookup to select a bit 
from a byte in its last phase.

selectWithOverflowAndByteLookup() also adds a lookup to determine the byte of 
the bit to be selected.

Some very simple benchmarks on my machine (i7-4770, 3.4 GHz) are in the test 
code in the testPerf* methods. These show that selectWithByteLookup() takes 
about 20% less time than select(), and that selectWithOverflowAndByteLookup() 
takes about 33% less time.


> Speedup broadword bit selection
> ---
>
> Key: LUCENE-6040
> URL: https://issues.apache.org/jira/browse/LUCENE-6040
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6040.patch
>
>
> Use table lookup instead of some broadword manipulations



--
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-6685) ConcurrentModificationException in Overseer Stats API

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-6685:
---

 Summary: ConcurrentModificationException in Overseer Stats API
 Key: SOLR-6685
 URL: https://issues.apache.org/jira/browse/SOLR-6685
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.10.1
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: 5.0, Trunk


I just found a concurrent modification exception in OverseerCollectionProcessor 
while iterating over the overseer stats. The iteration should be synchronized.



--
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] (LUCENE-5236) Use broadword bit selection in EliasFanoDecoder

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-5236:
--

I opened LUCENE-6040 for speedup of broadword select by table lookups.

> Use broadword bit selection in EliasFanoDecoder
> ---
>
> Key: LUCENE-5236
> URL: https://issues.apache.org/jira/browse/LUCENE-5236
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Paul Elschot
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 4.6
>
> Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch, 
> LUCENE-5236.patch, TestDocIdSetBenchmark.java
>
>
> Try and speed up decoding



--
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-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-3619:
---

Commit 1635833 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1635833 ]

SOLR-3619: Fix IDEA project settings after move to server.

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, 
> managed-schema, server-name-layout.png, solrconfig.xml
>
>




--
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] (LUCENE-6041) remove sugar FieldInfo.isIndexed and .hasDocValues

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6041:
---
Attachment: LUCENE-6041.patch

Simple patch.

> remove sugar FieldInfo.isIndexed and .hasDocValues
> --
>
> Key: LUCENE-6041
> URL: https://issues.apache.org/jira/browse/LUCENE-6041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6041.patch
>
>
> Follow-on from LUCENE-6039; these two booleans don't really exist: they are 
> just sugar to check for IndexOptions.NO and DocValuesType.NO.  I think for 
> the low-level schema API in Lucene we should not expose such sugar: callers 
> should have to be explicit.



--
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] (LUCENE-6041) remove sugar FieldInfo.isIndexed and .hasDocValues

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6041:
--

 Summary: remove sugar FieldInfo.isIndexed and .hasDocValues
 Key: LUCENE-6041
 URL: https://issues.apache.org/jira/browse/LUCENE-6041
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, Trunk
 Attachments: LUCENE-6041.patch

Follow-on from LUCENE-6039; these two booleans don't really exist: they are 
just sugar to check for IndexOptions.NO and DocValuesType.NO.  I think for the 
low-level schema API in Lucene we should not expose such sugar: callers should 
have to be explicit.



--
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] (LUCENE-6040) Speedup broadword bit selection

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6040:
--

These array lookups are given in the article of 2013 by Simon Gog and  Matthias 
Petri, 2013, "Optimized Succinct Data Structures for Massive Data" in Section 
6.2, currently available at http://people.eng.unimelb.edu.au/sgog/optimized.pdf 
.

A quote from there:
bq. Unfortunately, the development of efficient select operations on 64 -bit 
integers ( select 64 ) has not been as rapid as for popcnt . There are no 
direct CPU instructions available to return the position of the i -th set bit.

As was noted at http://vigna.di.unimi.it/Sux/select.php ,  these two lookups 
have the overhead of java array accesses, so it would probably be wortwhile to 
use a native version of this, at least until better processor support becomes 
available.

For the patch here, I'd expect that some speedup in Java is still possible.

> Speedup broadword bit selection
> ---
>
> Key: LUCENE-6040
> URL: https://issues.apache.org/jira/browse/LUCENE-6040
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6040.patch
>
>
> Use table lookup instead of some broadword manipulations



--
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] (LUCENE-5317) [PATCH] Concordance capability

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5317:
-

I added my latest source code and standalone jars to work with 4.10.2 to my 
lucene-addons [repo|https://github.com/tballison/lucene-addons] in case anyone 
wants to try the code as is.  There may be surprises.

The next step is to turn back to the lucene5317 branch in my fork and update 
the trunk code.

The biggest functional difference between the original patch in October and the 
current working code is that I added multivalued field handling.

> [PATCH] Concordance capability
> --
>
> Key: LUCENE-5317
> URL: https://issues.apache.org/jira/browse/LUCENE-5317
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Affects Versions: 4.5
>Reporter: Tim Allison
>  Labels: patch
> Fix For: 4.9
>
> Attachments: LUCENE-5317.patch, concordance_v1.patch.gz
>
>
> This patch enables a Lucene-powered concordance search capability.
> Concordances are extremely useful for linguists, lawyers and other analysts 
> performing analytic search vs. traditional snippeting/document retrieval 
> tasks.  By "analytic search," I mean that the user wants to browse every time 
> a term appears (or at least the topn)  in a subset of documents and see the 
> words before and after.  
> Concordance technology is far simpler and less interesting than IR relevance 
> models/methods, but it can be extremely useful for some use cases.
> Traditional concordance sort orders are available (sort on words before the 
> target, words after, target then words before and target then words after).
> Under the hood, this is running SpanQuery's getSpans() and reanalyzing to 
> obtain character offsets.  There is plenty of room for optimizations and 
> refactoring.
> Many thanks to my colleague, Jason Robinson, for input on the design of this 
> patch.



--
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-6686) facet.threads can return wrong results when using facet.prefix multiple times on same field

[Michael Ryan (JIRA)]

Michael Ryan created SOLR-6686:
--

 Summary: facet.threads can return wrong results when using 
facet.prefix multiple times on same field
 Key: SOLR-6686
 URL: https://issues.apache.org/jira/browse/SOLR-6686
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 4.9
Reporter: Michael Ryan


When using facet.threads, SimpleFacets can return the wrong results when using 
facet.prefix multiple times on the same field.

The problem is that SimpleFacets essentially stores the prefix value in a 
global variable, rather than passing the current prefix value into the 
Callable. So, the prefix value that is used when getting the term counts is 
whichever one was the last one parsed.

STEPS TO REPRODUCE:
# Create a document with a string field named "myFieldName" and value "foo"
# Create another document with a string field named "myFieldName" and value 
"bar"
# Run this query: {noformat}q=*:*&rows=0&facet=true&facet.field={!key=key1 
facet.prefix=foo}myFieldName&facet.field={!key=key2 
facet.prefix=bar}myFieldName&facet.threads=1{noformat}

EXPECTED:
{noformat}
  
1
  
  
1
  
{noformat}

ACTUAL:
{noformat}
  
1
  
  
1
  
{noformat}

I'm using 4.9, but I think this affects all versions.

A user previously reported this here:
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201405.mbox/%3cbay169-w52cef09187a88286de5417d5...@phx.gbl%3E

I think this affects parameters other than facet.prefix, but I have not tried 
that yet.



--
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] (LUCENE-5317) [PATCH] Concordance capability

[Tim Allison (JIRA)]

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

Tim Allison edited comment on LUCENE-5317 at 10/31/14 6:57 PM:
---

I added my latest source code and standalone jars to work with 4.10.2 to my 
lucene-addons [repo|https://github.com/tballison/lucene-addons] in case anyone 
wants to try the code as is.  There may be surprises.

The next step is to turn back to the lucene5317 branch in my fork and update 
the trunk code.

The biggest functional difference between the original patch from last October 
and the current working code in my repo is that I added multivalued field 
handling.


was (Author: talli...@mitre.org):
I added my latest source code and standalone jars to work with 4.10.2 to my 
lucene-addons [repo|https://github.com/tballison/lucene-addons] in case anyone 
wants to try the code as is.  There may be surprises.

The next step is to turn back to the lucene5317 branch in my fork and update 
the trunk code.

The biggest functional difference between the original patch in October and the 
current working code is that I added multivalued field handling.

> [PATCH] Concordance capability
> --
>
> Key: LUCENE-5317
> URL: https://issues.apache.org/jira/browse/LUCENE-5317
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Affects Versions: 4.5
>Reporter: Tim Allison
>  Labels: patch
> Fix For: 4.9
>
> Attachments: LUCENE-5317.patch, concordance_v1.patch.gz
>
>
> This patch enables a Lucene-powered concordance search capability.
> Concordances are extremely useful for linguists, lawyers and other analysts 
> performing analytic search vs. traditional snippeting/document retrieval 
> tasks.  By "analytic search," I mean that the user wants to browse every time 
> a term appears (or at least the topn)  in a subset of documents and see the 
> words before and after.  
> Concordance technology is far simpler and less interesting than IR relevance 
> models/methods, but it can be extremely useful for some use cases.
> Traditional concordance sort orders are available (sort on words before the 
> target, words after, target then words before and target then words after).
> Under the hood, this is running SpanQuery's getSpans() and reanalyzing to 
> obtain character offsets.  There is plenty of room for optimizations and 
> refactoring.
> Many thanks to my colleague, Jason Robinson, for input on the design of this 
> patch.



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-6039:
-

thanks for fixing this mike!

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-5318) Co-occurrence counts from Concordance

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-5318:
-

Added working code (for 4.10.2) to github 
[repo|https://github.com/tballison/lucene-addons] -- combination of LUCENE-5317 
and this issue.  

Next step is to clean up code against trunk in github fork and then post to 
review board.

> Co-occurrence counts from Concordance
> -
>
> Key: LUCENE-5318
> URL: https://issues.apache.org/jira/browse/LUCENE-5318
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/search
>Affects Versions: 4.5
>Reporter: Tim Allison
>  Labels: patch
> Fix For: 4.9
>
> Attachments: cooccur_v1.patch.gz
>
>
> This patch calculates co-occurrence statistics on search terms within a 
> window of x tokens.  This can help in synonym discovery and anywhere else 
> co-occurrence stats have been used.
> The attached patch depends on LUCENE-5317.
> Again, many thanks to my colleague, Jason Robinson, for advice in developing 
> this code and for his modifications to this code to make it more 
> Solr-friendly.



--
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] (LUCENE-6040) Speedup broadword bit selection

[Adrien Grand (JIRA)]

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

Adrien Grand edited comment on LUCENE-6040 at 10/31/14 7:18 PM:


I just played with the patch and it makes the EliasFanoDocIdSet faster on large 
advance indeed. It doesn't seem useful to keep 4 impls, so maybe we should just 
remove the current {{select}} impl in trunk and replace it with 
{{selectWithOverflowAndByteLookup}}?


was (Author: jpountz):
I just played with the patch and it makes the EliasFanoDocIdSet faster on large 
advance indeed. It doesn't seem useful to keep 4 impls, so maybe we should just 
remove the current {{select}} impl in master and replace it with 
{{selectWithOverflowAndByteLookup}}?

> Speedup broadword bit selection
> ---
>
> Key: LUCENE-6040
> URL: https://issues.apache.org/jira/browse/LUCENE-6040
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6040.patch
>
>
> Use table lookup instead of some broadword manipulations



--
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] (LUCENE-6040) Speedup broadword bit selection

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6040:
--

I just played with the patch and it makes the EliasFanoDocIdSet faster on large 
advance indeed. It doesn't seem useful to keep 4 impls, so maybe we should just 
remove the current {{select}} impl in master and replace it with 
{{selectWithOverflowAndByteLookup}}?

> Speedup broadword bit selection
> ---
>
> Key: LUCENE-6040
> URL: https://issues.apache.org/jira/browse/LUCENE-6040
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6040.patch
>
>
> Use table lookup instead of some broadword manipulations



--
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-1672) RFE: facet reverse sort count

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-1672:


I ran into a need for "index desc" today too (for reverse chronological on a 
timestamp) with pivot faceting.  Maybe I'll flip the order of the data as an 
interim hack.

> RFE: facet reverse sort count
> -
>
> Key: SOLR-1672
> URL: https://issues.apache.org/jira/browse/SOLR-1672
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
> Environment: Java, Solrj, http
>Reporter: Peter Sturge
>Priority: Minor
> Attachments: SOLR-1672.patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> As suggested by Chris Hosstetter, I have added an optional Comparator to the 
> BoundedTreeSet in the UnInvertedField class.
> This optional comparator is used when a new (and also optional) field facet 
> parameter called 'facet.sortorder' is set to the string 'dsc' 
> (e.g. &f..facet.sortorder=dsc for per field, or 
> &facet.sortorder=dsc for all facets).
> Note that this parameter has no effect if facet.method=enum.
> Any value other than 'dsc' (including no value) reverts the BoundedTreeSet to 
> its default behaviour.
>  
> This change affects 2 source files:
> > UnInvertedField.java
> [line 438] The getCounts() method signature is modified to add the 
> 'facetSortOrder' parameter value to the end of the argument list.
>  
> DIFF UnInvertedField.java:
> - public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int 
> offset, int limit, Integer mincount, boolean missing, String sort, String 
> prefix) throws IOException {
> + public NamedList getCounts(SolrIndexSearcher searcher, DocSet baseDocs, int 
> offset, int limit, Integer mincount, boolean missing, String sort, String 
> prefix, String facetSortOrder) throws IOException {
> [line 556] The getCounts() method is modified to create an overridden 
> BoundedTreeSet(int, Comparator) if the 'facetSortOrder' parameter 
> equals 'dsc'.
> DIFF UnInvertedField.java:
> - final BoundedTreeSet queue = new BoundedTreeSet(maxsize);
> + final BoundedTreeSet queue = (sort.equals("count") || 
> sort.equals("true")) ? (facetSortOrder.equals("dsc") ? new 
> BoundedTreeSet(maxsize, new Comparator()
> { @Override
> public int compare(Object o1, Object o2)
> {
>   if (o1 == null || o2 == null)
> return 0;
>   int result = ((Long) o1).compareTo((Long) o2);
>   return (result != 0 ? result > 0 ? -1 : 1 : 0); //lowest number first sort
> }}) : new BoundedTreeSet(maxsize)) : null;
> > SimpleFacets.java
> [line 221] A getFieldParam(field, "facet.sortorder", "asc"); is added to 
> retrieve the new parameter, if present. 'asc' used as a default value.
> DIFF SimpleFacets.java:
> + String facetSortOrder = params.getFieldParam(field, "facet.sortorder", 
> "asc");
>  
> [line 253] The call to uif.getCounts() in the getTermCounts() method is 
> modified to pass the 'facetSortOrder' value string.
> DIFF SimpleFacets.java:
> - counts = uif.getCounts(searcher, base, offset, limit, 
> mincount,missing,sort,prefix);
> + counts = uif.getCounts(searcher, base, offset, limit, 
> mincount,missing,sort,prefix, facetSortOrder);
> Implementation Notes:
> I have noted in testing that I was not able to retrieve any '0' counts as I 
> had expected.
> I believe this could be because there appear to be some optimizations in 
> SimpleFacets/count caching such that zero counts are not iterated (at least 
> not by default)
> as a performance enhancement.
> I could be wrong about this, and zero counts may appear under some other as 
> yet untested circumstances. Perhaps an expert familiar with this part of the 
> code can clarify.
> In fact, this is not such a bad thing (at least for my requirements), as a 
> whole bunch of zero counts is not necessarily useful (for my requirements, 
> starting at '1' is just right).
>  
> There may, however, be instances where someone *will* want zero counts - e.g. 
> searching for zero product stock counts (e.g. 'what have we run out of'). I 
> was envisioning the facet.mincount field
> being the preferred place to set where the 'lowest value' begins (e.g. 0 or 1 
> or possibly higher), but because of the caching/optimization, the behaviour 
> is somewhat different than expected.



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Ryan Ernst (JIRA)]

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

Ryan Ernst commented on LUCENE-6039:


I realize I'm late to the party but...does anyone have an issue with these 
values being renamed to "NONE"?  "NO" is...very odd sounding.

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-4345) Create a Classification module

[yuanyun.cn (JIRA)]

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

yuanyun.cn commented on LUCENE-4345:


Hi, Tommaso:

Appreciate your great work and contribution to the community :)

But I can't find solr/contrib/classification in dev/trunk. Is it not checked in?

Also I read your presentation:
http://archive.apachecon.com/eu2012/presentations/08-Thursday/L1R-Lucene/aceu-2012-text-categorization-with-lucene-and-solr.pdf

and like your autmatic text caetgoration druing index: the 
CategorizationUpdateRequestProcessorFactory

Is it possible to also check in it to Solr?

Thanks.

> Create a Classification module
> --
>
> Key: LUCENE-4345
> URL: https://issues.apache.org/jira/browse/LUCENE-4345
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: Trunk
>
> Attachments: LUCENE-4345.patch, LUCENE-4345_2.patch, SOLR-3700.patch, 
> SOLR-3700_2.patch
>
>
> Lucene/Solr can host huge sets of documents containing lots of information in 
> fields so that these can be used as training examples (w/ features) in order 
> to very quickly create classifiers algorithms to use on new documents and / 
> or to provide an additional service.
> So the idea is to create a contrib module (called 'classification') to host a 
> ClassificationComponent that will use already seen data (the indexed 
> documents / fields) to classify new documents / text fragments.
> The first version will contain a (simplistic) Lucene based Naive Bayes 
> classifier but more implementations should be added in the future.



--
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] (LUCENE-6040) Speedup broadword bit selection

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-6040:
--

Replacing the existing implementation is indeed the goal, but after further 
testing, which you've already done.
The initial version of the patch is still here for those curious about the 
other implementations.

The selectWithOverflowAndByteLookup() method has an added precondition that the 
bit to select must exist.
As I recall this should the case because there is always a bitCount() before 
the select() call.
Anyway the existing docidset tests should easily catch this if necessary.




> Speedup broadword bit selection
> ---
>
> Key: LUCENE-6040
> URL: https://issues.apache.org/jira/browse/LUCENE-6040
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/other
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-6040.patch
>
>
> Use table lookup instead of some broadword manipulations



--
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-6687) eDisMax query parser does not parse phrases with facet filtering enabled

[Tim H (JIRA)]

Tim H created SOLR-6687:
---

 Summary: eDisMax query parser does not parse phrases with facet 
filtering enabled
 Key: SOLR-6687
 URL: https://issues.apache.org/jira/browse/SOLR-6687
 Project: Solr
  Issue Type: Bug
  Components: query parsers, SolrJ
Affects Versions: 4.10
 Environment: SolrJ Library, Eclipse IDE
Reporter: Tim H


I am writing a search bar application with Solr which I'd like to have the 
following two features:

phrase matching for user queries - results which match user phrase are boosted.

Field faceting based on 'tags' field.  

When I execute this query:

q=steve jobs&
fq=storeid:527bd613e4b0564cc755460a&
sort=score desc&
start=50&
rows=2&
fl=*,score&
qt=/query&
defType=edismax&
pf=concept_name^15 note_text^5 file_text^2.5&
pf3=1&
pf2=1&
ps=1&
group=true&
group.field=conceptid&
group.limit=10&
group.ngroups=true

The phrase boosting feature operates correctly and boosts results which closer 
match the phrase query "Steve Jobs"

However, when I execute the query after the user has selected a facet field 
(The facet fields are bought up from a seperate query) and execute the 
following query:

q=steve jobs&
fq=storeid:527bd613e4b0564cc755460a&
fq=tag:Person&
sort=score desc&
start=0&
rows=50&
fl=*,score&
qt=/query&
defType=edismax&
pf=concept_name^15 note_text^5 file_text^2.5&
pf3=1&
pf2=1&
ps=1&
group=true&
group.field=conceptid&
group.limit=10&
group.ngroups=true

The phrase boosting does not work, even though the facet filtering does.  

I'm not sure if this is a bug, but if it is not can someone point me to the 
relevant documentation that will help me fix this issue?  All queries were 
written using the SolrJ Library.



--
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] (LUCENE-6037) PendingTerm cannot be cast to PendingBlock

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6037:


Which JVM/OS are you using?  Any customizations to Lucene, its default 
settings, codecs, etc.?

> PendingTerm cannot be cast to PendingBlock
> --
>
> Key: LUCENE-6037
> URL: https://issues.apache.org/jira/browse/LUCENE-6037
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/codecs
>Affects Versions: 4.3.1
> Environment: ubuntu 64bit
>Reporter: zhanlijun
>Priority: Critical
> Fix For: 4.3.1
>
>
> the error as follows:
> java.lang.ClassCastException: 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingTerm cannot be cast to 
> org.apache.lucene.codecs.BlockTreeTermsWriter$PendingBlock
> at 
> org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finish(BlockTreeTermsWriter.java:1014)
> at 
> org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:553)
> at 
> org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
> at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
> at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
> at 
> org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
> at 
> org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:493)
> at 
> org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:480)
> at 
> org.apache.lucene.index.DocumentsWriter.postUpdate(DocumentsWriter.java:378)
> at 
> org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:413)
> at 
> org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1283)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1243)
> at 
> org.apache.lucene.index.IndexWriter.addDocuments(IndexWriter.java:1228)



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6039:


+1 for NONE; I'll change it.

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] [Reopened] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless reopened LUCENE-6039:


> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6030) Add norms patched compression which uses table for most common values

[ASF subversion and git services (JIRA)]

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

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

Commit 1635854 from [~rjernst] in branch 'dev/trunk'
[ https://svn.apache.org/r1635854 ]

LUCENE-6030: Add norms patched compression for a small number of common values

> Add norms patched compression which uses table for most common values
> -
>
> Key: LUCENE-6030
> URL: https://issues.apache.org/jira/browse/LUCENE-6030
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-6030.patch
>
>
> We have added the PATCHED norms sub format in lucene 50, which uses a bitset 
> to mark documents that have the most common value (when >97% of the documents 
> have that value).  This works well for fields that have a predominant value 
> length, and then a small number of docs with some other random values.  But 
> another common case is having a handful of very common value lengths, like 
> with a title field.
> We can use a table (see TABLE_COMPRESSION) to store the most common values, 
> and save an oridinal for the "other" case, at which point we can lookup in 
> the secondary patch table.



--
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] (LUCENE-6030) Add norms patched compression which uses table for most common values

[ASF subversion and git services (JIRA)]

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

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

Commit 1635856 from [~rjernst] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1635856 ]

LUCENE-6030: Add norms patched compression for a small number of common values 
(merged 1635854)

> Add norms patched compression which uses table for most common values
> -
>
> Key: LUCENE-6030
> URL: https://issues.apache.org/jira/browse/LUCENE-6030
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
> Attachments: LUCENE-6030.patch
>
>
> We have added the PATCHED norms sub format in lucene 50, which uses a bitset 
> to mark documents that have the most common value (when >97% of the documents 
> have that value).  This works well for fields that have a predominant value 
> length, and then a small number of docs with some other random values.  But 
> another common case is having a handful of very common value lengths, like 
> with a title field.
> We can use a table (see TABLE_COMPRESSION) to store the most common values, 
> and save an oridinal for the "other" case, at which point we can lookup in 
> the secondary patch table.



--
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] [Assigned] (LUCENE-6030) Add norms patched compression which uses table for most common values

[Ryan Ernst (JIRA)]

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

Ryan Ernst reassigned LUCENE-6030:
--

Assignee: Ryan Ernst

> Add norms patched compression which uses table for most common values
> -
>
> Key: LUCENE-6030
> URL: https://issues.apache.org/jira/browse/LUCENE-6030
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
>Assignee: Ryan Ernst
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6030.patch
>
>
> We have added the PATCHED norms sub format in lucene 50, which uses a bitset 
> to mark documents that have the most common value (when >97% of the documents 
> have that value).  This works well for fields that have a predominant value 
> length, and then a small number of docs with some other random values.  But 
> another common case is having a handful of very common value lengths, like 
> with a title field.
> We can use a table (see TABLE_COMPRESSION) to store the most common values, 
> and save an oridinal for the "other" case, at which point we can lookup in 
> the secondary patch table.



--
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] [Resolved] (LUCENE-6030) Add norms patched compression which uses table for most common values

[Ryan Ernst (JIRA)]

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

Ryan Ernst resolved LUCENE-6030.

   Resolution: Fixed
Fix Version/s: Trunk
   5.0

> Add norms patched compression which uses table for most common values
> -
>
> Key: LUCENE-6030
> URL: https://issues.apache.org/jira/browse/LUCENE-6030
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ryan Ernst
>Assignee: Ryan Ernst
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6030.patch
>
>
> We have added the PATCHED norms sub format in lucene 50, which uses a bitset 
> to mark documents that have the most common value (when >97% of the documents 
> have that value).  This works well for fields that have a predominant value 
> length, and then a small number of docs with some other random values.  But 
> another common case is having a handful of very common value lengths, like 
> with a title field.
> We can use a table (see TABLE_COMPRESSION) to store the most common values, 
> and save an oridinal for the "other" case, at which point we can lookup in 
> the secondary patch table.



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

[ANNOUNCE] Apache Lucene 4.10.2 released

[Michael McCandless]

October 2014, Apache Lucene™ 4.10.2 available

The Lucene PMC is pleased to announce the release of Apache Lucene 4.10.2

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

The release is available for immediate download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html

Lucene 4.10.2 includes 2 bug fixes.

See the CHANGES.txt file included with the release for a full list of
changes and further details.

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also goes for Maven access.

Happy Halloween,

Mike McCandless

http://blog.mikemccandless.com

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

[ANNOUNCE] Apache Solr 4.10.2 released

[Michael McCandless]

October 2014, Apache Solr™ 4.10.2 available

The Lucene PMC is pleased to announce the release of Apache Solr 4.10.2

Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search, dynamic
clustering, database integration, rich document (e.g., Word, PDF)
handling, and geospatial search. Solr is highly scalable, providing
fault tolerant distributed search and indexing, and powers the search
and navigation features of many of the world's largest internet sites.

Solr 4.10.2 is available for immediate download at:

http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

Solr 4.10.2 includes 10 bug fixes, as well as Lucene 4.10.2 and its 2 bug fixes.

See the CHANGES.txt file included with the release for a full list of
changes and further details.

Please report any feedback to the mailing lists
(http://lucene.apache.org/solr/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also goes for Maven access.

Happy Halloween,

Mike McCandless

http://blog.mikemccandless.com

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

[jira] [Commented] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[ASF subversion and git services (JIRA)]

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

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

Commit 1635861 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1635861 ]

LUCENE-6039: NO -> NONE

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] [Resolved] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6039.

Resolution: Fixed

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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] (LUCENE-6039) Add IndexOptions.NO and DocValuesType.NO, instead of null

[ASF subversion and git services (JIRA)]

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

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

Commit 1635864 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1635864 ]

LUCENE-6039: NO -> NONE

> Add IndexOptions.NO and DocValuesType.NO, instead of null
> -
>
> Key: LUCENE-6039
> URL: https://issues.apache.org/jira/browse/LUCENE-6039
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-6039.patch
>
>
> Idea from Simon: it seems dangerous for IndexOptions and DocValuesType
> via Indexable/FieldType and FieldInfo that we use null to mean it's
> not indexed or has no doc values.
> We should instead have an explicit choice (IndexOptions.NO,
> DocValuesType.NO) in the enum?



--
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-6554) Speed up overseer operations for collections with stateFormat > 1

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-6554:

Attachment: SOLR-6554.patch

I bit the bullet and refactored the overseer to be less of a mess than it is 
now.
# I grouped the cluster operations into cluster, collection, slice and replica 
and moved them to their own classes. 
# A new class ZkStateWriter is introduced which uses ZkWriteCommand to update 
the clusterstate.
# Each overseer operation returns a ZkWriteCommand
# The force update of cluster state is no longer required inside the main 
overseer loop. It is read once at the start of the loop and then we use ZK 
compare-and-set to update the cluster states using the versions already read.
# The above also means that there is no need to watch every collection with 
stateFormat > 1 on the overseer node anymore.

Todo
# There are some nocommits that need to be taken care of.
# Implement batching for collections with stateFormat > 1
# There are a few newer operations such as balanceSliceUnique which aren't 
implemented yet so some tests fail.
# More cleanup

Here are some performance numbers using the new code vs branch_5x:
{code}
Overseer queue size: 2 state requests

stateFormat = 1, With refactoring (trunk)
=
250962 T13 oasc.OverseerTest.testPerformance Overseer loop finished processing: 
250964 T13 oasc.OverseerTest.printTimingStatstotalTime: 241639.501565
250964 T13 oasc.OverseerTest.printTimingStatsavgRequestsPerMinute: 
0.0041383582263057345
250965 T13 oasc.OverseerTest.printTimingStats5minRateRequestsPerMinute: 0.0
250965 T13 oasc.OverseerTest.printTimingStats15minRateRequestsPerMinute: 0.0
250965 T13 oasc.OverseerTest.printTimingStatsavgTimePerRequest: 
241639.501565
250966 T13 oasc.OverseerTest.printTimingStatsmedianRequestTime: 
241639.501565
250966 T13 oasc.OverseerTest.printTimingStats75thPctlRequestTime: 
241639.501565
250966 T13 oasc.OverseerTest.printTimingStats95thPctlRequestTime: 
241639.501565
250966 T13 oasc.OverseerTest.printTimingStats99thPctlRequestTime: 
241639.501565
250967 T13 oasc.OverseerTest.printTimingStats999thPctlRequestTime: 
241639.501565
250967 T13 oasc.OverseerTest.testPerformance op: am_i_leader, success: 163, 
failure: 0
250967 T13 oasc.OverseerTest.printTimingStatstotalTime: 27.778517
250967 T13 oasc.OverseerTest.printTimingStatsavgRequestsPerMinute: 
40.51109030620299
250967 T13 oasc.OverseerTest.printTimingStats5minRateRequestsPerMinute: 
60.52909864226439
250968 T13 oasc.OverseerTest.printTimingStats15minRateRequestsPerMinute: 
67.32475977643367
250968 T13 oasc.OverseerTest.printTimingStatsavgTimePerRequest: 
0.17042034969325154
250968 T13 oasc.OverseerTest.printTimingStatsmedianRequestTime: 0.127852
250968 T13 oasc.OverseerTest.printTimingStats75thPctlRequestTime: 0.159049
250968 T13 oasc.OverseerTest.printTimingStats95thPctlRequestTime: 
0.207078595
250968 T13 oasc.OverseerTest.printTimingStats99thPctlRequestTime: 
2.989458679168
250968 T13 oasc.OverseerTest.printTimingStats999thPctlRequestTime: 6.591979
250968 T13 oasc.OverseerTest.testPerformance op: update_state, success: 161, 
failure: 0
250969 T13 oasc.OverseerTest.printTimingStatstotalTime: 105.56181
250969 T13 oasc.OverseerTest.printTimingStatsavgRequestsPerMinute: 
40.02790612569949
250969 T13 oasc.OverseerTest.printTimingStats5minRateRequestsPerMinute: 48.0
250969 T13 oasc.OverseerTest.printTimingStats15minRateRequestsPerMinute: 
48.0
250970 T13 oasc.OverseerTest.printTimingStatsavgTimePerRequest: 
0.6556634161490683
250970 T13 oasc.OverseerTest.printTimingStatsmedianRequestTime: 0.57833
250970 T13 oasc.OverseerTest.printTimingStats75thPctlRequestTime: 0.7091475
250970 T13 oasc.OverseerTest.printTimingStats95thPctlRequestTime: 
0.92942001
250970 T13 oasc.OverseerTest.printTimingStats99thPctlRequestTime: 
3.99709575999
250970 T13 oasc.OverseerTest.printTimingStats999thPctlRequestTime: 4.075775
250971 T13 oasc.OverseerTest.testPerformance op: state, success: 20001, 
failure: 0
250972 T13 oasc.OverseerTest.printTimingStatstotalTime: 24677.266392
250972 T13 oasc.OverseerTest.printTimingStatsavgRequestsPerMinute: 
4971.795405166019
250972 T13 oasc.OverseerTest.printTimingStats5minRateRequestsPerMinute: 
4190.29864341858
250972 T13 oasc.OverseerTest.printTimingStats15minRateRequestsPerMinute: 
3199.6744276725544
250972 T13 oasc.OverseerTest.printTimingStatsavgTimePerRequest: 
1.2338016295185241
250973 T13 oasc.OverseerTest.printTimingStatsmedianRequestTime: 1.1432815
250973 T13 oasc.OverseerTest.printTimingStats75thPctlRequestTime: 1.57099125
250973 T13 oasc.OverseerTest.printTimingStats95thPctlRequestTime: 1.8449494
250973 T13 oasc.OverseerTest.printTimingStats99thPctlReque

[jira] [Commented] (SOLR-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5919:
---

I think it's a valid issue in that it points out we are missing test coverage.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5919:
---

bq. it's comparing a cloud mode multi-shard response with a cloud mode 
single-shard response.

Thats as designed. If someone thinks it's an improvement to change it, that's 
probably worth it's own issue.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5919:
---

bq 2)

It won't shutdown anything in the control collection - that is the coverage we 
are missing - the fairly critical coverage of killing the Overseer randomly in 
ChaosMonkey tests - it's safe in the control collection.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-6687) eDisMax query parser does not parse phrases with facet filtering enabled

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-6687:
--

First, please raise issues like this on the user's list first, especially when 
it may be a usage question or pilot error. It gets more eyes and you may well 
get a much faster response.

When you do post over there, what assurance do you have that boosting "doesn't 
work"? Have you tried using &debug=all and examining the scores in the two 
cases?


> eDisMax query parser does not parse phrases with facet filtering enabled
> 
>
> Key: SOLR-6687
> URL: https://issues.apache.org/jira/browse/SOLR-6687
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers, SolrJ
>Affects Versions: 4.10
> Environment: SolrJ Library, Eclipse IDE
>Reporter: Tim H
>
> I am writing a search bar application with Solr which I'd like to have the 
> following two features:
> phrase matching for user queries - results which match user phrase are 
> boosted.
> Field faceting based on 'tags' field.  
> When I execute this query:
> q=steve jobs&
> fq=storeid:527bd613e4b0564cc755460a&
> sort=score desc&
> start=50&
> rows=2&
> fl=*,score&
> qt=/query&
> defType=edismax&
> pf=concept_name^15 note_text^5 file_text^2.5&
> pf3=1&
> pf2=1&
> ps=1&
> group=true&
> group.field=conceptid&
> group.limit=10&
> group.ngroups=true
> The phrase boosting feature operates correctly and boosts results which 
> closer match the phrase query "Steve Jobs"
> However, when I execute the query after the user has selected a facet field 
> (The facet fields are bought up from a seperate query) and execute the 
> following query:
> q=steve jobs&
> fq=storeid:527bd613e4b0564cc755460a&
> fq=tag:Person&
> sort=score desc&
> start=0&
> rows=50&
> fl=*,score&
> qt=/query&
> defType=edismax&
> pf=concept_name^15 note_text^5 file_text^2.5&
> pf3=1&
> pf2=1&
> ps=1&
> group=true&
> group.field=conceptid&
> group.limit=10&
> group.ngroups=true
> The phrase boosting does not work, even though the facet filtering does.  
> I'm not sure if this is a bug, but if it is not can someone point me to the 
> relevant documentation that will help me fix this issue?  All queries were 
> written using the SolrJ Library.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5919:


1 + 2 seem like a chicken and egg to me ... if we leave the control collection 
in the cloud (instead of making it it's own isolated solr instance running in 
legacy non-cloud mode) then how do you prevent it from participating in 
overseer election? we can't allow ChaosMonkey to shutdown the control 
collection or comparisons with the control collection won't be reliable, but if 
it's always up it will get elected overseer pretty quick, and then overseer is 
never at risk anymore.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5919:
---

Nothing in the single shard control collection really depends on the Overseer 
once it's running. It's simulating a non cloud collection in almost all 
respects. 

We don't want to shutdown the control collection. It's one server, it just 
runs.  

We simply want to make the overseer elected within collection1 sometimes. 

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5919:


{quote}
Nothing in the single shard control collection really depends on the Overseer 
once it's running. It's simulating a non cloud collection in almost all 
respects.

We don't want to shutdown the control collection. It's one server, it just runs.

We simply want to make the overseer elected within collection1 sometimes.
{quote}

I don't disagree with any of those statements -- but none of them really answer 
the crux of my question...

bq. if we leave the control collection in the cloud ... then how do you prevent 
it from participating in overseer election? ... it will get elected overseer 
pretty quick, and then overseer is never at risk anymore.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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-5919) AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, takes overseer role

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5919:
---

I don't know - depends on how whoever is solving this wants to tackle it.

You could look at starting control after the jetties - then it would end up 
last in line (these are horribly started sequentially after all) and 
chaosmonkey tests would get a bit more coverage.

You could use the new stuff that lets you prefer nodes as the overseer. That 
would increase coverage a bit. Randomly prefer all the collection1 jetties.

Or you could change things at a deeper level to create more separation. 
Probably that's ideal, but given I can't work on it soon, I'm just as +1 on 
simply getting some Overseer kills in a chaosmonkey run with whatever 
improvement.

> AbstractFullDistribZkTestBase: control server thinks it's part of the cloud, 
> takes overseer role
> 
>
> Key: SOLR-5919
> URL: https://issues.apache.org/jira/browse/SOLR-5919
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> I was banging my head trying to figure out why SOLR-5795 combined with 
> SOLR-5823 wasn't working when I noticed something interesting as a result of 
> some gratuituous logging:
> * the control server thinks it's in running in cloud mode, in a cluster 
> consisting solely of itself, and acts as overseer
> * none of the nodes in the actual cluster being tested think they are the 
> overseer
> ...i haven't dug in very deep, but i suspect that some combination of the 
> control server starting up first and thinking it's part of zk is leading to 
> it becoming the overseer, even thought it evidently never thinks it's one of 
> the leaders/replicas of the cloud cluster.
> It's hard to see this problem w/o SOLR-5823 -- i'll update the patch there 
> with a test showing hte problem, but i wanted to make sure it got tracked in 
> it's own bug.



--
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] (LUCENE-6042) CustomScoreQuery Explain differs from the actual score when topLevelBoost is used.

[Denis Lantsman (JIRA)]

Denis Lantsman created LUCENE-6042:
--

 Summary: CustomScoreQuery Explain differs from the actual score 
when topLevelBoost is used.
 Key: LUCENE-6042
 URL: https://issues.apache.org/jira/browse/LUCENE-6042
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/query/scoring
Affects Versions: 4.8
Reporter: Denis Lantsman
Priority: Minor


CustomScoreQuery.java, doExplain has the following line:

{code}
res.addDetail(new Explanation(getBoost(), "queryBoost"));
{code}

This multiplies the custom score query by just the boost of the current query, 
and not by

{code}
queryWeight=topLevelBoost*getBoost();
{code}

which is the value that's actually used during scoring. This leads to 
drastically different scores in the debug info, relative to the actual score, 
when the query is a subquery of another one, like a BooleanQuery clause, with a 
non-1 boost.



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

[JENKINS] Lucene-Solr-4.10-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 38 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.10-Linux/38/
Java: 64bit/jdk1.8.0_40-ea-b09 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
REGRESSION:  org.apache.solr.handler.TestReplicationHandler.testNoWriter

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([A78FA83E442ECA23:81A56D88DE9AFFF]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:437)
at sun.nio.ch.Net.bind(Net.java:429)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:187)
at 
org.eclipse.jetty.server.AbstractConnector.doStart(AbstractConnector.java:316)
at 
org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:265)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.Server.doStart(Server.java:291)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:418)
at 
org.apache.solr.handler.TestReplicationHandler.testNoWriter(TestReplicationHandler.java:355)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_67) - Build # 4402 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4402/
Java: 32bit/jdk1.7.0_67 -client -XX:+UseG1GC

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([F016A8752C909DAC]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([F016A8752C909DAC]:0)




Build Log:
[...truncated 11149 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ChaosMonkeySafeLeaderTest-F016A8752C909DAC-001\init-core-data-001
   [junit4]   2> 1429400 T3466 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2> 1429401 T3466 
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system 
property: /
   [junit4]   2> 1429408 T3466 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 1429410 T3466 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1429411 T3467 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 1429531 T3466 oasc.ZkTestServer.run start zk server on 
port:61389
   [junit4]   2> 1429531 T3466 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 1429534 T3466 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 1429543 T3473 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1d495c5 name:ZooKeeperConnection 
Watcher:127.0.0.1:61389 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1429544 T3466 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 1429544 T3466 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 1429544 T3466 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 1429554 T3466 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 1429557 T3466 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 1429561 T3475 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@2a9d4a name:ZooKeeperConnection 
Watcher:127.0.0.1:61389/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2> 1429561 T3466 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 1429562 T3466 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 1429562 T3466 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 1429569 T3466 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 1429576 T3466 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 1429580 T3466 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 1429586 T3466 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1429586 T3466 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 1429597 T3466 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1429597 T3466 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 1429605 T3466 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1429605 T3466 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1429614 T3466 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1429614 T3466 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 1429622 T3466 oasc.AbstractZkTestCase.putConfig put 
C:\U

[jira] [Updated] (SOLR-6351) Let Stats Hang off of Pivots (via 'tag')

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-6351:
---
Attachment: SOLR-6351.patch

review & some updates to the the latest tests Vitaliy added.

On monday i'll dig into how we're dealing with stas in pivot refinements (the 
last remaining "nocommit" ... i can't understand how/why 
DistributedFacetPivotSmallAdvancedTest.doTestTopStatsWithRefinement passes in 
this patch, and that scares me (the refinement call should pollute the top 
level stats, double counting at least one shard) so i really want to get to the 
bottom of it.

{panel:title=patch changes}
* FacetPivotSmallTest
** new testBogusStatsTag: check that a bogus stats tag is ignored
** new testStatsTagHasComma: check that comma causes error for now (SOLR-6663)

* SolrExampleTests
** swap two comments that were on the wrong asserts

* DistributedFacetPivotSmallAdvancedTest
** cleaned up some formatting
** doTestTopStats
*** beefed up the assertions
*** added sanity checks that refinement really was happening in these requests
*** suprisingly this test still passes ... based on the "nocommit" hack i put 
in StatsComponent, I was farily certain this was going to fail ... i need to 
dig in more and make sure i understand why it doesn't fail.
*** renamed to doTestTopStatsWithRefinement to make it a bit more clear what 
it's doing
** doTestDeepPivotStatsOnOverrequest
*** removed this test - i wasn't really clear on the purpose, and in asking 
Vitaliy about it on IRC we realized he had missunderstood some advice i'd given 
him on IRC a few days ago about how to "sanity check" that refinement was 
happening (ie: what i just added to doTestTopStatsWithRefinement) so it wasn't 
given us any value add.
{panel}

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

[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4947 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4947/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([BC4C4D4A60BD0F05]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([BC4C4D4A60BD0F05]:0)




Build Log:
[...truncated 12448 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest
   [junit4]   2> Creating dataDir: 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/build/solr-core/test/J3/temp/solr.cloud.ChaosMonkeySafeLeaderTest-BC4C4D4A60BD0F05-001/init-core-data-001
   [junit4]   2> 831484 T1927 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(true) and clientAuth (false)
   [junit4]   2> 831484 T1927 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /
   [junit4]   2> 831492 T1927 oas.SolrTestCaseJ4.setUp ###Starting 
testDistribSearch
   [junit4]   2> 831493 T1927 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   1> client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 831494 T1928 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2> 831594 T1927 oasc.ZkTestServer.run start zk server on 
port:64414
   [junit4]   2> 831595 T1927 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 831596 T1927 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 831601 T1934 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@448af90e 
name:ZooKeeperConnection Watcher:127.0.0.1:64414 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 831601 T1927 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 831601 T1927 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 831602 T1927 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2> 831605 T1927 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2> 831606 T1927 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2> 831607 T1936 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@38f79799 
name:ZooKeeperConnection Watcher:127.0.0.1:64414/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 831607 T1927 oascc.ConnectionManager.waitForConnected Client 
is connected to ZooKeeper
   [junit4]   2> 831608 T1927 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2> 831608 T1927 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2> 831611 T1927 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2> 831612 T1927 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2> 831614 T1927 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2> 831616 T1927 oasc.AbstractZkTestCase.putConfig put 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 831616 T1927 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2> 831619 T1927 oasc.AbstractZkTestCase.putConfig put 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 831620 T1927 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/schema.xml
   [junit4]   2> 831722 T1927 oasc.AbstractZkTestCase.putConfig put 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 831723 T1927 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 831725 T1927 oasc.AbstractZkTestCase.putConfig put 
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 831725 T1927 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/stopwords.txt
   [junit4]   2> 831727 T1927 oasc.AbstractZkTestCase.putConfig put 
/usr/

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-3619:
---

Commit 1635887 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1635887 ]

SOLR-3619: get the smoke tester working with the bin/solr script and server 
directory

> Rename 'example' dir to 'server' and pull examples into an 'examples' 
> directory
> ---
>
> Key: SOLR-3619
> URL: https://issues.apache.org/jira/browse/SOLR-3619
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Timothy Potter
> Fix For: 4.9, Trunk
>
> Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, 
> managed-schema, server-name-layout.png, solrconfig.xml
>
>




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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_40-ea-b09) - Build # 11548 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11548/
Java: 64bit/jdk1.8.0_40-ea-b09 -XX:-UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([BA49C4A8FDD9D7C2]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.cloud.HttpPartitionTest:
 1) Thread[id=10494, name=Thread-3836, state=RUNNABLE, 
group=TGRP-HttpPartitionTest] at 
java.net.SocketInputStream.socketRead0(Native Method) at 
java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at 
java.net.SocketInputStream.read(SocketInputStream.java:170) at 
java.net.SocketInputStream.read(SocketInputStream.java:141) at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
 at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) 
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
 at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
 at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
 at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
 at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
 at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
 at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
 at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
 at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
 at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682)
 at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
 at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
 at 
org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:465)
 at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215)
 at 
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211)
 at 
org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1639)
 at 
org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:430)
 at 
org.apache.solr.cloud.ZkController.access$100(ZkController.java:101) at 
org.apache.solr.cloud.ZkController$1.command(ZkController.java:269) at 
org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.HttpPartitionTest: 
   1) Thread[id=10494, name=Thread-3836, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
at 
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
at 
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.re