date:20150501


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

Timothy Potter updated SOLR-7102:
-
Attachment: SOLR-7102.patch

Simple fix to set SOLR_MODE=solrcloud if ZK_HOST is set.

 bin/solr should activate cloud mode if ZK_HOST is set
 -

 Key: SOLR-7102
 URL: https://issues.apache.org/jira/browse/SOLR-7102
 Project: Solr
  Issue Type: Improvement
Reporter: Timothy Potter
Assignee: Timothy Potter
 Attachments: SOLR-7102.patch


 you have to set SOLR_MODE=solrcloud in the /var/solr/solr.in.sh to get the 
 init.d/solr script to start Solr in cloud mode (since it doesn't pass -c). 
 What should happen is that the bin/solr script should assume cloud mode if 
 ZK_HOST is set.
 This mainly affects the /etc/init.d/solr script because it doesn't pass the 
 -c | -cloud option. If working with bin/solr directly, you can just pass the 
 -c explicitly to get cloud mode.



--
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-6926) ant example makes no sense anymore - should be ant server (or refactored into some other compilation realted target)


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

Timothy Potter updated SOLR-6926:
-
Assignee: (was: Timothy Potter)

 ant example makes no sense anymore - should be ant server (or refactored 
 into some other compilation realted target)
 

 Key: SOLR-6926
 URL: https://issues.apache.org/jira/browse/SOLR-6926
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man

 (filing as followup to a chat i had with tim offline the other day)
 the ant target ant example doesn't really make any sense anymore ... that 
 name was created way, way, back when ant compile built up the dist/solr.war 
 file that people were expected to install and ant example took care of 
 copying that war file into the example/jetty directory
 these days, it should probably be named something like ant server or 
 refactored inside an existing task like ant compile



--
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-6926) ant example makes no sense anymore - should be ant server (or refactored into some other compilation realted target)


[ 
https://issues.apache.org/jira/browse/SOLR-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524225#comment-14524225
 ] 

Timothy Potter commented on SOLR-6926:
--

I'm not working on this and am not sure what work remains so un-assigning ...

 ant example makes no sense anymore - should be ant server (or refactored 
 into some other compilation realted target)
 

 Key: SOLR-6926
 URL: https://issues.apache.org/jira/browse/SOLR-6926
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man

 (filing as followup to a chat i had with tim offline the other day)
 the ant target ant example doesn't really make any sense anymore ... that 
 name was created way, way, back when ant compile built up the dist/solr.war 
 file that people were expected to install and ant example took care of 
 copying that war file into the example/jetty directory
 these days, it should probably be named something like ant server or 
 refactored inside an existing task like ant compile



--
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-7096) The Solr service script doesn't like SOLR_HOME pointing to a path containing a symlink


[ 
https://issues.apache.org/jira/browse/SOLR-7096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524107#comment-14524107
 ] 

Timothy Potter commented on SOLR-7096:
--

Weird ... I'm not able to reproduce this now ... using SOLR_HOME=/var/solr/data 
where /var/solr looks like:

{code}
ubuntu@ip-172-30-1-64:~$ ls -ltr /var/solr
total 20
drwxr-xr-x 2 solr solr 4096 May  1 21:54 data_dir
-rwxr-xr-x 1 solr solr 4556 May  1 21:57 solr.in.sh
-rw-r--r-- 1 solr solr  962 May  1 21:57 log4j.properties
lrwxrwxrwx 1 solr solr8 May  1 22:00 data - data_dir
drwxr-xr-x 2 solr solr 4096 May  1 22:01 logs
{code}

Maybe it was a different OS I saw this error on previously?


 The Solr service script doesn't like SOLR_HOME pointing to a path containing 
 a symlink
 --

 Key: SOLR-7096
 URL: https://issues.apache.org/jira/browse/SOLR-7096
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0
Reporter: Timothy Potter
Assignee: Timothy Potter
 Fix For: Trunk, 5.2


 While documenting the process to upgrade a SolrCloud cluster from 4.x to 5.0, 
 I discovered that the init.d/solr script doesn't like the SOLR_HOME pointing 
 to a path that contains a symlink. Work-around is to use an absolute path



--
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-6952) Re-using data-driven configsets by default is not helpful


[ 
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524242#comment-14524242
 ] 

Timothy Potter commented on SOLR-6952:
--

bq. There should be a way to create a colection without creating a configset

I disagree with that requirement. If something special is needed for 
{{.system}} I think we shouldn't expose that at the user interface level (which 
bin/solr create is).

 Re-using data-driven configsets by default is not helpful
 -

 Key: SOLR-6952
 URL: https://issues.apache.org/jira/browse/SOLR-6952
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 5.0
Reporter: Grant Ingersoll
Assignee: Timothy Potter
 Fix For: 5.0, Trunk

 Attachments: SOLR-6952.patch, SOLR-6952.patch


 When creating collections (I'm using the bin/solr scripts), I think we should 
 automatically copy configsets, especially when running in getting started 
 mode or data driven mode.
 I did the following:
 {code}
 bin/solr create_collection -n foo
 bin/post foo some_data.csv
 {code}
 I then created a second collection with the intention of sending in the same 
 data, but this time run through a python script that changed a value from an 
 int to a string (since it was an enumerated type) and was surprised to see 
 that I got:
 {quote}
 Caused by: java.lang.NumberFormatException: For input string: NA
   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
   at java.lang.Long.parseLong(Long.java:441)
 {quote}
 for my new version of the data that passes in a string instead of an int, as 
 this new collection had only seen strings for that field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6878) solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)


[ 
https://issues.apache.org/jira/browse/SOLR-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14524298#comment-14524298
 ] 

Timothy Potter commented on SOLR-6878:
--

bq. why not let the new expand feature just be syntactic sugar on adding 
symetric sets of KEY=VALUE mappings via lists of lists?

Good idea! I'll start down that path as it seems pretty straight-forward to 
implement w/o all the state management issues as you mentioned. Thanks Hoss.


 solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)
 

 Key: SOLR-6878
 URL: https://issues.apache.org/jira/browse/SOLR-6878
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 4.10.2
Reporter: Tomasz Sulkowski
Assignee: Timothy Potter
  Labels: ManagedSynonymFilterFactory, REST, SOLR
 Attachments: SOLR-6878.patch


 Hi,
 After switching from SynonymFilterFactory to ManagedSynonymFilterFactory I 
 have found out that there is no way to set an all-to-all synonyms relation. 
 Basically (judgind from google search) there is a need for expand 
 functionality switch (known from SynonymFilterFactory) which will treat all 
 synonyms with its keyword as equal.
 For example: if we define a car:[wagen,ride] relation it would 
 translate a query that includes one of the synonyms or keyword to car or 
 wagen or ride independently of which word was used from those three.



--
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 # 3047 - Failure

2015-05-01 Thread Apache Jenkins Server

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

1 tests failed.
REGRESSION:  org.apache.solr.cloud.ShardSplitTest.test

Error Message:
Wrong doc count on shard1_0. See SOLR-5309 expected:199 but was:198

Stack Trace:
java.lang.AssertionError: Wrong doc count on shard1_0. See SOLR-5309 
expected:199 but was:198
at 
__randomizedtesting.SeedInfo.seed([87F734C916C0D13E:FA30B13B83CBCC6]: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:472)
at 
org.apache.solr.cloud.ShardSplitTest.checkDocCountsAndShardStates(ShardSplitTest.java:440)
at 
org.apache.solr.cloud.ShardSplitTest.splitByUniqueKeyTest(ShardSplitTest.java:222)
at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:84)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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

[jira] [Commented] (SOLR-7377) SOLR Streaming Expressions


[ 
https://issues.apache.org/jira/browse/SOLR-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523237#comment-14523237
 ] 

Yonik Seeley commented on SOLR-7377:


bq. 3) Add an ExpressionRunner that runs expressions from the command line.

Can you expand on this some?  Our command line in the past has essentially 
been curl, so I'm wondering what's different here that would make a command 
line tool specific to expressions make sense.


 SOLR Streaming Expressions
 --

 Key: SOLR-7377
 URL: https://issues.apache.org/jira/browse/SOLR-7377
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Dennis Gove
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch


 It would be beneficial to add an expression-based interface to Streaming API 
 described in SOLR-7082. Right now that API requires streaming requests to 
 come in from clients as serialized bytecode of the streaming classes. The 
 suggestion here is to support string expressions which describe the streaming 
 operations the client wishes to perform. 
 {code:java}
 search(collection1, q=*:*, fl=id,fieldA,fieldB, sort=fieldA asc)
 {code}
 With this syntax in mind, one can now express arbitrarily complex stream 
 queries with a single string.
 {code:java}
 // merge two distinct searches together on common fields
 merge(
   search(collection1, q=id:(0 3 4), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   search(collection2, q=id:(1 2), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   on=a_f asc, a_s asc)
 // find top 20 unique records of a search
 top(
   n=20,
   unique(
 search(collection1, q=*:*, fl=id,a_s,a_i,a_f, sort=a_f desc),
 over=a_f desc),
   sort=a_f desc)
 {code}
 The syntax would support
 1. Configurable expression names (eg. via solrconfig.xml one can map unique 
 to a class implementing a Unique stream class) This allows users to build 
 their own streams and use as they wish.
 2. Named parameters (of both simple and expression types)
 3. Unnamed, type-matched parameters (to support requiring N streams as 
 arguments to another stream)
 4. Positional parameters
 The main goal here is to make streaming as accessible as possible and define 
 a syntax for running complex queries across large distributed systems.



--
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-7485) replace shards.info with ShardParams.SHARDS_INFO in TestTolerantSearch.java and CloudSolrClientTest.java

2015-05-01 Thread Christine Poerschke (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523335#comment-14523335
 ] 

Christine Poerschke commented on SOLR-7485:
---

Hi [~shalinmangar] - good point about someone accidentally changing the 
constant's value.

Latest commit on the patch branch adds a 
[ShardParamsTest|https://github.com/bloomberg/lucene-solr/blob/trunk-shards.info/solr/solrj/src/test/org/apache/solr/common/params/ShardParamsTest.java]
 for back-compat breakages for shards.info as well as the other 
ShardParams.java parameters.

 replace shards.info with ShardParams.SHARDS_INFO in TestTolerantSearch.java 
 and CloudSolrClientTest.java
 --

 Key: SOLR-7485
 URL: https://issues.apache.org/jira/browse/SOLR-7485
 Project: Solr
  Issue Type: Improvement
Reporter: Christine Poerschke
Priority: Minor

 various other tests already use ShardParams.SHARDS_INFO e.g. 
 TestDistributedSearch.java



--
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-7490) Update by query feature

2015-05-01 Thread Praneeth (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523222#comment-14523222
 ] 

Praneeth commented on SOLR-7490:


Yes. I do understand that atomic updates require the fields to be stored. And 
ya, your conclusion in the above comment is what I basically meant. I do see 
your concern about the huge operation.

 Update by query feature
 ---

 Key: SOLR-7490
 URL: https://issues.apache.org/jira/browse/SOLR-7490
 Project: Solr
  Issue Type: New Feature
Reporter: Praneeth
Priority: Minor

 An update feature similar to the {{deleteByQuery}} would be very useful. Say, 
 the user wants to update a field of all documents in the index that match a 
 given criteria. I have encountered this use case in my project and it looks 
 like it could be a useful first class solr/lucene feature. I want to check if 
 this is something we would want to support in coming releases of Solr and 
 Lucene, are there scenarios that will prevent us from doing this, 
 feasibility, 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] [Created] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

2015-05-01 Thread Fabio Batista da Silva (JIRA)

Fabio Batista da Silva created SOLR-7495:


 Summary: Unexpected docvalues type NUMERIC when grouping by a int 
facet
 Key: SOLR-7495
 URL: https://issues.apache.org/jira/browse/SOLR-7495
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Fabio Batista da Silva


Hey All,
After upgrading to solr 4.10 to 5.1 with solr could
I'm getting a IllegalStateException when i try to facet a int field.

IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
(expected=SORTED). Use UninvertingReader or index with docvalues.



schema.xml
{code}
?xml version=1.0 ?
schema name=schema version=1.2
fields
!-- solar cloud version field --
field name=_version_ type=long indexed=true stored=true/

!-- Common fields --
field name=id type=string indexed=true stored=true  
multiValued=false required=true/
field name=index_type type=string indexed=true  stored=true  
multiValued=false required=true/

field name=year type=int indexed=true stored=true/
field name=model type=string indexed=true stored=true/
field name=year_make_model type=string indexed=true 
stored=true/
/fields

!-- Field Types --
types
fieldType name=string class=solr.StrField sortMissingLast=true /
fieldType name=boolean class=solr.BoolField 
sortMissingLast=true/
fieldType name=int class=solr.TrieIntField precisionStep=0 
positionIncrementGap=0/
fieldType name=float class=solr.TrieFloatField precisionStep=0 
positionIncrementGap=0/
fieldType name=long class=solr.TrieLongField precisionStep=0 
positionIncrementGap=0/
fieldType name=double class=solr.TrieDoubleField precisionStep=0 
positionIncrementGap=0/
fieldType name=date class=solr.TrieDateField precisionStep=0 
positionIncrementGap=0/
fieldType name=text_ngram class=solr.TextField 
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2 
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=text_general class=solr.TextField 
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2 
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType

fieldType name=location_rpt 
class=solr.SpatialRecursivePrefixTreeFieldType geo=true distErrPct=0.025 
maxDistErr=0.09 units=degrees /
/types

uniqueKeyid/uniqueKey

defaultSearchFieldname/defaultSearchField

solrQueryParser defaultOperator=OR/
/schema
{code}


query :

{code}
http://solr.dev:8983/solr/my_collection/select?wt=jsonfl=idfq=index_type:foobargroup=truegroup.field=year_make_modelgroup.facet=truefacet=truefacet.field=year
{code}



Exception :

{code}
ull:org.apache.solr.common.SolrException: Exception during facet.field: year
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
at 
org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
at 
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
at

[jira] [Updated] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

2015-05-01 Thread Fabio Batista da Silva (JIRA)


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

Fabio Batista da Silva updated SOLR-7495:
-
Description: 
Hey All,
After upgrading from solr 4.10 to 5.1 with solr could
I'm getting a IllegalStateException when i try to facet a int field.

IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
(expected=SORTED). Use UninvertingReader or index with docvalues.



schema.xml
{code}
?xml version=1.0 ?
schema name=schema version=1.2
fields
!-- solar cloud version field --
field name=_version_ type=long indexed=true stored=true/

!-- Common fields --
field name=id type=string indexed=true stored=true  
multiValued=false required=true/
field name=index_type type=string indexed=true  stored=true  
multiValued=false required=true/

field name=year type=int indexed=true stored=true/
field name=model type=string indexed=true stored=true/
field name=year_make_model type=string indexed=true 
stored=true/
/fields

!-- Field Types --
types
fieldType name=string class=solr.StrField sortMissingLast=true /
fieldType name=boolean class=solr.BoolField 
sortMissingLast=true/
fieldType name=int class=solr.TrieIntField precisionStep=0 
positionIncrementGap=0/
fieldType name=float class=solr.TrieFloatField precisionStep=0 
positionIncrementGap=0/
fieldType name=long class=solr.TrieLongField precisionStep=0 
positionIncrementGap=0/
fieldType name=double class=solr.TrieDoubleField precisionStep=0 
positionIncrementGap=0/
fieldType name=date class=solr.TrieDateField precisionStep=0 
positionIncrementGap=0/
fieldType name=text_ngram class=solr.TextField 
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2 
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
fieldType name=text_general class=solr.TextField 
positionIncrementGap=100
analyzer type=index
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.LowerCaseFilterFactory/
filter class=solr.EdgeNGramFilterFactory minGramSize=2 
maxGramSize=15/
/analyzer
analyzer type=query
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StopFilterFactory ignoreCase=true 
words=stopwords.txt /
filter class=solr.SynonymFilterFactory 
synonyms=synonyms.txt ignoreCase=true expand=true/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType

fieldType name=location_rpt 
class=solr.SpatialRecursivePrefixTreeFieldType geo=true distErrPct=0.025 
maxDistErr=0.09 units=degrees /
/types

uniqueKeyid/uniqueKey

defaultSearchFieldname/defaultSearchField

solrQueryParser defaultOperator=OR/
/schema
{code}


query :

{code}
http://solr.dev:8983/solr/my_collection/select?wt=jsonfl=idfq=index_type:foobargroup=truegroup.field=year_make_modelgroup.facet=truefacet=truefacet.field=year
{code}



Exception :

{code}
ull:org.apache.solr.common.SolrException: Exception during facet.field: year
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
at 
org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
at 
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
at 
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)

[jira] [Assigned] (SOLR-7477) multi-select support for facet module


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

Yonik Seeley reassigned SOLR-7477:
--

Assignee: Yonik Seeley

 multi-select support for facet module
 -

 Key: SOLR-7477
 URL: https://issues.apache.org/jira/browse/SOLR-7477
 Project: Solr
  Issue Type: New Feature
  Components: Facet Module
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 5.2

 Attachments: SOLR-7477.patch


 Multi-select support essentially means (at a minimum) support for excluding 
 tagged filters.



--
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] (SOLR-7494) Distributed unique() facet function is incorrect for higher cardinality fields.


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

Yonik Seeley reassigned SOLR-7494:
--

Assignee: Yonik Seeley

 Distributed unique() facet function is incorrect for higher cardinality 
 fields.
 ---

 Key: SOLR-7494
 URL: https://issues.apache.org/jira/browse/SOLR-7494
 Project: Solr
  Issue Type: Bug
  Components: Facet Module
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 5.2

 Attachments: SOLR-7494.patch


 As described in SOLR-7214, the unique function seems wildly off, but only if 
 you have enough values.



--
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-7379) CompositeSpatialStrategy FieldType

2015-05-01 Thread David Smiley (JIRA)

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

David Smiley updated SOLR-7379:
---
Attachment: SOLR-7379__RptWithGeometrySpatialField.patch

Here's a patch. Notes:
* I chose the name RptWithGeometrySpatialField; feedback welcome. It inherits
the same schema attribute options as the RPT field but strictly speaking
doesn't subclass that field type.
** I overrode the default distErrPct at indexing time to be 0.15.
* Compatibility with heatmaps.
* Uses a SolrCache if you define one in solrconfig.xml.
* Includes some getters on Lucene spatial's CompositeSpatialStrategy.

I was tempted, and attempted to subclass the Rpt field type which would have
made the initialization less error prone simple, and would have made heatmap
compatibility work without issue. But it started becoming an ugly hack. The
approach in this patch is perhaps a hack in that it contains another fieldType
and deals with some initialization quirks in init(); but there isn't much to
it. Another option is to do like BBoxField's component numeric fields...
though I don't love that it requires more definitions for the user to make in
the schema. But maybe that's a better trade-off, all things considered (it
wouldn't have required the modification to heatmap here).

The cache is very interesting. Typically, a SolrCache gets blown away on every
commit. But using a NoOpRegenerator, it will effectively get re-instated. But
that can only be used for caching certain types of things and may require the
code using the cache to facilitate this working -- so don't expect it to work
on the FilterCache, for example. The trick I do here is a special key to the
cache that is comprised of a weak reference to a LeafReader segment core key,
plus the segment-local docId. Unfortunately these cache entries won't eagerly
clean themselves up if the segment becomes unreachable; however, it shouldn't
stick around long if an LRU cache is used, since those entries won't be used
again. The cache should be configured similar to the following, assuming a
hypothetical field named geom:
{code:xml}
cache name=perSegSpatialFieldCache_geom
class=solr.LRUCache
size=256
initialSize=0
autowarmCount=100%
regenerator=solr.NoOpRegenerator/
{code}
The 2nd and subsequent successful cache lookups will be the fastest for
polygons in particular, since on the 1st cache hit, JtsGeometry.index() is
called on it (if it is of that type).

CompositeSpatialStrategy FieldType
--

Key: SOLR-7379
URL: https://issues.apache.org/jira/browse/SOLR-7379
Project: Solr
Issue Type: New Feature
Components: spatial
Reporter: David Smiley
Assignee: David Smiley
Fix For: 5.2

Attachments: SOLR-7379__RptWithGeometrySpatialField.patch

We should add a Solr spatial FieldType that uses the new
CompositeSpatialStrategy. Essentially this enabled geometry backed shapes for
accuracy combined with the grid indexes of RPT for speed.

--
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-7377) SOLR Streaming Expressions

2015-05-01 Thread Joel Bernstein (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523284#comment-14523284
 ] 

Joel Bernstein commented on SOLR-7377:
--

I was thinking about having a local client (ExpressionRunner) that could run 
the expression and be used as part of a unix pipeline. 

Also a local client can save a hop in the case of a parallel stream. The local 
client can directly push the Expression to the workers nodes. 

 SOLR Streaming Expressions
 --

 Key: SOLR-7377
 URL: https://issues.apache.org/jira/browse/SOLR-7377
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Dennis Gove
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch


 It would be beneficial to add an expression-based interface to Streaming API 
 described in SOLR-7082. Right now that API requires streaming requests to 
 come in from clients as serialized bytecode of the streaming classes. The 
 suggestion here is to support string expressions which describe the streaming 
 operations the client wishes to perform. 
 {code:java}
 search(collection1, q=*:*, fl=id,fieldA,fieldB, sort=fieldA asc)
 {code}
 With this syntax in mind, one can now express arbitrarily complex stream 
 queries with a single string.
 {code:java}
 // merge two distinct searches together on common fields
 merge(
   search(collection1, q=id:(0 3 4), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   search(collection2, q=id:(1 2), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   on=a_f asc, a_s asc)
 // find top 20 unique records of a search
 top(
   n=20,
   unique(
 search(collection1, q=*:*, fl=id,a_s,a_i,a_f, sort=a_f desc),
 over=a_f desc),
   sort=a_f desc)
 {code}
 The syntax would support
 1. Configurable expression names (eg. via solrconfig.xml one can map unique 
 to a class implementing a Unique stream class) This allows users to build 
 their own streams and use as they wish.
 2. Named parameters (of both simple and expression types)
 3. Unnamed, type-matched parameters (to support requiring N streams as 
 arguments to another stream)
 4. Positional parameters
 The main goal here is to make streaming as accessible as possible and define 
 a syntax for running complex queries across large distributed systems.



--
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-7214) JSON Facet API

2015-05-01 Thread Crawdaddy (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523224#comment-14523224
 ] 

Crawdaddy commented on SOLR-7214:
-

Wow, that was fast. Thanks Yonik.


 JSON Facet API
 --

 Key: SOLR-7214
 URL: https://issues.apache.org/jira/browse/SOLR-7214
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Yonik Seeley
 Fix For: 5.1

 Attachments: SOLR-7214.patch


 Overview is here: http://yonik.com/json-facet-api/
 The structured nature of nested sub-facets are more naturally expressed in a 
 nested structure like JSON rather than the flat structure that normal query 
 parameters provide.
 Goals:
 - First class JSON support
 - Easier programmatic construction of complex nested facet commands
 - Support a much more canonical response format that is easier for clients to 
 parse
 - First class analytics support
 - Support a cleaner way to do distributed faceting
 - Support better integration with other search features



--
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-7458) Expose HDFS Block Locality Metrics

[
https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523270#comment-14523270
]

Mark Miller commented on SOLR-7458:
---

bq. Not at all sure. I'm open to suggestions.

I'm not yet sure myself. My main concern is that whatever this host property
gets assigned ends up matching what hdfs returns as the host. This seems tricky
to ensure offhand.

bq. I saw the property in solr.xml, but could not figure out how to access it.
A pointer here would be helpful.

It's SolrXmlConfig or something along those lines, accessible at the
CoreContainer level. I've been noodling how you might make this CoreContainer
level scope rather than static scope so you have access to that host config.
Again, looks a bit tricky.

bq. I guess there could be a JMX call happening while a new shard is being
created? Do I need to plan for multiple concurrent JMX calls?

Right, SolrCores can be created at any time and will use new directories. I'm
not so worried about staleness, but gets on a hashmap with concurrent
get/updates can also hang or other bad stuff. Prob best to just use a
ConcurrentHashMap.

Expose HDFS Block Locality Metrics
--

Key: SOLR-7458
URL: https://issues.apache.org/jira/browse/SOLR-7458
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Mike Drob
Assignee: Mark Miller
Labels: metrics
Attachments: SOLR-7458.patch, SOLR-7458.patch

We should publish block locality metrics when using HDFS.

--
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-7485) replace shards.info with ShardParams.SHARDS_INFO in TestTolerantSearch.java and CloudSolrClientTest.java, add ShardParamsTest.java

2015-05-01 Thread Christine Poerschke (JIRA)


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

Christine Poerschke updated SOLR-7485:
--
Summary: replace shards.info with ShardParams.SHARDS_INFO in 
TestTolerantSearch.java and CloudSolrClientTest.java, add ShardParamsTest.java  
(was: replace shards.info with ShardParams.SHARDS_INFO in 
TestTolerantSearch.java and CloudSolrClientTest.java)

 replace shards.info with ShardParams.SHARDS_INFO in TestTolerantSearch.java 
 and CloudSolrClientTest.java, add ShardParamsTest.java
 

 Key: SOLR-7485
 URL: https://issues.apache.org/jira/browse/SOLR-7485
 Project: Solr
  Issue Type: Improvement
Reporter: Christine Poerschke
Priority: Minor

 various other tests already use ShardParams.SHARDS_INFO e.g. 
 TestDistributedSearch.java



--
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-7121) Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion


[ 
https://issues.apache.org/jira/browse/SOLR-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523312#comment-14523312
 ] 

Mark Miller commented on SOLR-7121:
---

{code}
+if (cc.isZooKeeperAware()  isUnderHeavyLoad(false)) {
+  try {
+log.info(Bringing {} down due to heavy load, cd.getName());
+cc.getZkController().publish(cd, Replica.State.DOWN);
+startHealthPoller(core);
+  } catch (KeeperException | InterruptedException e) {
+log.error(e.getMessage(), e);
+  }
{code}

What if we are the leader and publish a down state due to overload? Shouldn't 
we also give up our leader position?

 Solr nodes should go down based on configurable thresholds and not rely on 
 resource exhaustion
 --

 Key: SOLR-7121
 URL: https://issues.apache.org/jira/browse/SOLR-7121
 Project: Solr
  Issue Type: New Feature
Reporter: Sachin Goyal
 Attachments: SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, 
 SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch


 Currently, there is no way to control when a Solr node goes down.
 If the server is having high GC pauses or too many threads or is just getting 
 too many queries due to some bad load-balancer, the cores in the machine keep 
 on serving unless they exhaust the machine's resources and everything comes 
 to a stall.
 Such a slow-dying core can affect other cores as well by taking huge time to 
 serve their distributed queries.
 There should be a way to specify some threshold values beyond which the 
 targeted core can its ill-health and proactively go down to recover.
 When the load improves, the core should come up automatically.



--
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-Windows (32bit/jdk1.8.0_45) - Build # 4753 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4753/
Java: 32bit/jdk1.8.0_45 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.client.solrj.impl.CloudSolrClientTest.test

Error Message:
There should be 3 documents because there should be two id=1 docs due to 
overwrite=false expected:3 but was:1

Stack Trace:
java.lang.AssertionError: There should be 3 documents because there should be 
two id=1 docs due to overwrite=false expected:3 but was:1
at 
__randomizedtesting.SeedInfo.seed([E21F46439C45CF82:6A4B799932B9A27A]: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:472)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testOverwriteOption(CloudSolrClientTest.java:171)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:129)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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)

[jira] [Created] (SOLR-7496) Empty buckets when faceting with JSON API over EnumField and TrieIntField

Alfonso Muñoz-Pomer Fuentes created SOLR-7496:
-

 Summary: Empty buckets when faceting with JSON API over EnumField 
and TrieIntField
 Key: SOLR-7496
 URL: https://issues.apache.org/jira/browse/SOLR-7496
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
$ java -version
java version 1.8.0_31
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes


When using facets with the new JSON API over an EnumFiled or a TrieIntField, I 
get a list of empty buckets.



--
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-7496) Empty buckets when faceting with JSON API over EnumField and TrieIntField


[ 
https://issues.apache.org/jira/browse/SOLR-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523487#comment-14523487
 ] 

Yonik Seeley commented on SOLR-7496:


Thanks for the report Alfonso, enum fields aren't supported yet.
They will also need some special support for distrib search since sorting is 
not by the text labels but the underlying numeric values.

 Empty buckets when faceting with JSON API over EnumField and TrieIntField
 -

 Key: SOLR-7496
 URL: https://issues.apache.org/jira/browse/SOLR-7496
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
 $ java -version
 java version 1.8.0_31
 Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
 Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes
  Labels: patch

 When using facets with the new JSON API over an EnumFiled or a TrieIntField, 
 I get a list of empty buckets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7496) Empty buckets when faceting with JSON API over EnumField and TrieIntField


[ 
https://issues.apache.org/jira/browse/SOLR-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523487#comment-14523487
 ] 

Yonik Seeley edited comment on SOLR-7496 at 5/1/15 5:27 PM:


Thanks for the report Alfonso, enum fields (and numeric fields) aren't 
supported yet.  Hopefully soon!
Enum fields will also need some special support for distrib search since 
sorting is not by the text labels but the underlying numeric values.


was (Author: ysee...@gmail.com):
Thanks for the report Alfonso, enum fields aren't supported yet.
They will also need some special support for distrib search since sorting is 
not by the text labels but the underlying numeric values.

 Empty buckets when faceting with JSON API over EnumField and TrieIntField
 -

 Key: SOLR-7496
 URL: https://issues.apache.org/jira/browse/SOLR-7496
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
 $ java -version
 java version 1.8.0_31
 Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
 Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes
  Labels: patch

 When using facets with the new JSON API over an EnumFiled or a TrieIntField, 
 I get a list of empty buckets.



--
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-Linux (32bit/jdk1.8.0_45) - Build # 12357 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12357/
Java: 32bit/jdk1.8.0_45 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=631, name=collection0, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=631, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:45008/z: Could not find collection : 
awholynewstresscollection_collection0_0
at __randomizedtesting.SeedInfo.seed([95D1D7A17DFDA3B7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1074)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:846)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:789)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:884)




Build Log:
[...truncated 9956 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2 Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.CollectionsAPIDistributedZkTest
 95D1D7A17DFDA3B7-001/init-core-data-001
   [junit4]   2 48287 T412 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(true) and clientAuth (true)
   [junit4]   2 48287 T412 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /z/
   [junit4]   2 48291 T412 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   2 48292 T413 oasc.ZkTestServer$2$1.setClientPort client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2 48292 T413 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2 48392 T412 oasc.ZkTestServer.run start zk server on port:51782
   [junit4]   2 48392 T412 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 48393 T412 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2 48407 T420 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@1924225 name:ZooKeeperConnection 
Watcher:127.0.0.1:51782 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2 48407 T412 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2 48408 T412 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 48408 T412 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2 48411 T412 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 48412 T412 oascc.ConnectionManager.waitForConnected Waiting 
for client to connect to ZooKeeper
   [junit4]   2 48413 T423 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@102d3b8 name:ZooKeeperConnection 
Watcher:127.0.0.1:51782/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2 48413 T412 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2 48414 T412 oascc.SolrZkClient.createZkACLProvider Using 
default ZkACLProvider
   [junit4]   2 48417 T412 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2 48424 T412 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2 48427 T412 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2 48429 T412 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2 48431 T412 oasc.AbstractZkTestCase.putConfig put 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2 48432 T412 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2 48443 T412 oasc.AbstractZkTestCase.putConfig put

[jira] [Updated] (SOLR-6968) add hyperloglog in statscomponent as an approximate count

2015-05-01 Thread Hoss Man (JIRA)


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

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

Updated patch with more tests.

My current TODO list...

{noformat}
 - 6  regwidth makes no sense? 
   - even at (min) log2m==4, isn't regwidth==6 big enough for all possible 
(hashed) long values?

 - prehashed support
   - need to sanity/error check that the field is a long
   - add an update processor to make this easy to do at index time
 - tunning knobs
   - memory vs accuracy (log2m)
 - idea: (least ram) 0  accuracy  1 (most accurate)
   - scale 
   - max cardinality estimatable (regwidth)
 - perhaps hardcode regwidth==6 ? expert only option to adjust?
 - pick regwidth based on field type? (int/enum have fewer in general)
 - pick regwidth based on index stats? max out based on total terms in 
field?
   - or for single valued fields: max out based on numDocs
   - HLL must use same hash seed, but does it support union when log2m and 
regwidth are diff?
 - convinience equivilence with countDistinct in solrj response obj ?
{noformat}

 add hyperloglog in statscomponent as an approximate count
 -

 Key: SOLR-6968
 URL: https://issues.apache.org/jira/browse/SOLR-6968
 Project: Solr
  Issue Type: Sub-task
Reporter: Hoss Man
 Attachments: SOLR-6968.patch, SOLR-6968.patch, SOLR-6968.patch


 stats component currently supports calcDistinct but it's terribly 
 inefficient -- especially in distib mode.
 we should add support for using hyperloglog to compute an approximate count 
 of distinct values (using localparams via SOLR-6349 to control the precision 
 of the approximation)



--
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 (32bit/jdk1.7.0_80) - Build # 4633 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4633/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.MultiThreadedOCPTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=377, 
name=parallelCoreAdminExecutor-25-thread-15, state=RUNNABLE, 
group=TGRP-MultiThreadedOCPTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=377, 
name=parallelCoreAdminExecutor-25-thread-15, state=RUNNABLE, 
group=TGRP-MultiThreadedOCPTest]
at 
__randomizedtesting.SeedInfo.seed([884543DEADA0FB0:80D06BE744266248]:0)
Caused by: java.lang.AssertionError: Too many closes on SolrCore
at __randomizedtesting.SeedInfo.seed([884543DEADA0FB0]:0)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1138)
at org.apache.solr.common.util.IOUtils.closeQuietly(IOUtils.java:31)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:535)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:494)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleCreateAction(CoreAdminHandler.java:598)
at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:212)
at 
org.apache.solr.handler.admin.CoreAdminHandler$ParallelCoreAdminHandlerThread.run(CoreAdminHandler.java:1219)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9677 lines...]
   [junit4] Suite: org.apache.solr.cloud.MultiThreadedOCPTest
   [junit4]   2 Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.MultiThreadedOCPTest
 884543DEADA0FB0-001\init-core-data-001
   [junit4]   2 17252 T59 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl 
(false) and clientAuth (false)
   [junit4]   2 17253 T59 oas.BaseDistributedSearchTestCase.initHostContext 
Setting hostContext system property: /
   [junit4]   2 17258 T59 oasc.ZkTestServer.run STARTING ZK TEST SERVER
   [junit4]   2 17259 T60 oasc.ZkTestServer$2$1.setClientPort client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2 17259 T60 oasc.ZkTestServer$ZKServerMain.runFromConfig 
Starting server
   [junit4]   2 17331 T59 oasc.ZkTestServer.run start zk server on port:62637
   [junit4]   2 17331 T59 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 17332 T59 oascc.ConnectionManager.waitForConnected Waiting for 
client to connect to ZooKeeper
   [junit4]   2 17336 T67 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@14adde7 name:ZooKeeperConnection 
Watcher:127.0.0.1:62637 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2 17336 T59 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2 17336 T59 oascc.SolrZkClient.createZkACLProvider Using default 
ZkACLProvider
   [junit4]   2 17336 T59 oascc.SolrZkClient.makePath makePath: /solr
   [junit4]   2 17341 T59 
oascc.SolrZkClient.createZkCredentialsToAddAutomatically Using default 
ZkCredentialsProvider
   [junit4]   2 17342 T59 oascc.ConnectionManager.waitForConnected Waiting for 
client to connect to ZooKeeper
   [junit4]   2 17343 T70 oascc.ConnectionManager.process Watcher 
org.apache.solr.common.cloud.ConnectionManager@151f26d name:ZooKeeperConnection 
Watcher:127.0.0.1:62637/solr got event WatchedEvent state:SyncConnected 
type:None path:null path:null type:None
   [junit4]   2 17343 T59 oascc.ConnectionManager.waitForConnected Client is 
connected to ZooKeeper
   [junit4]   2 17343 T59 oascc.SolrZkClient.createZkACLProvider Using default 
ZkACLProvider
   [junit4]   2 17344 T59 oascc.SolrZkClient.makePath makePath: 
/collections/collection1
   [junit4]   2 17348 T59 oascc.SolrZkClient.makePath makePath: 
/collections/collection1/shards
   [junit4]   2 17351 T59 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection
   [junit4]   2 17353 T59 oascc.SolrZkClient.makePath makePath: 
/collections/control_collection/shards
   [junit4]   2 17357 T59 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 17370 T59 oascc.SolrZkClient.makePath makePath: 
/configs/conf1/solrconfig.xml
   [junit4]   2 17376 T59 oasc.AbstractZkTestCase.putConfig put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
 to /configs/conf1/schema.xml

[jira] [Commented] (SOLR-6878) solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)


[ 
https://issues.apache.org/jira/browse/SOLR-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523482#comment-14523482
 ] 

Timothy Potter commented on SOLR-6878:
--

I started going through this patch and I have some questions about how to 
support the equivalent synonyms feature for managed synonyms.

NOTE: I'm using the term equivalent synonyms based on the doc here:
https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory

Specifically, here are a couple of issues I see with supporting equivalent 
synonyms lists at the managed API level:

1) The default value for expand is true (in the patch), but what if the user 
changes it to false after already having added equivalent synonym lists? Or 
vice-versa. What do we do about existing equivalent mappings? We could store 
the equivalent lists in a separate data structure and then apply the correct 
behavior depending on the expand flag when the managed data is viewed, i.e. 
either a GET request from the API or when updating the data used to initialize 
the underlying SynonymMap. This is similar to what we do with ignoreCase, 
however the ignoreCase was easily handled but I think allowing expand to be 
changed by the API is much more complicated.

Of course we could punt on this issue altogether and just make the expand flag 
immutable, i.e. you can set it initially to true or false, but cannot change it 
with the API. If we make it immutable, then we can apply the mapping on update 
and not have to maintain any additional data structures to remember the raw 
state of equiv lists.

2) Let's say we allow users to send in equivalent synonym lists to the API, 
such as:

{code}
curl -v -X PUT \
  -H 'Content-type:application/json' \
  --data-binary '[funny,entertaining,whimsical,jocular]' \
  'http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english'
{code}

If expand is true, then you end up with the following mappings (pardon the Java 
code syntax as I didn't want to clean that up for this example):
{code}
assertJQ(endpoint + /funny,
/funny==['entertaining','jocular','whimiscal']);
assertJQ(endpoint + /entertaining,
/entertaining==['funny','jocular','whimiscal']);
assertJQ(endpoint + /jocular,
/jocular==['entertaining','funny','whimiscal']);
assertJQ(endpoint + /whimiscal,
/whimiscal==['entertaining','funny','jocular']);
{code}

What should the API do if the user then decides to update the specific mappings 
for funny by sending in a request such as:

{code}
curl -v -X PUT \
  -H 'Content-type:application/json' \
  --data-binary '{funny:[hilarious]}' \
  'http://localhost:8983/solr/techproducts/schema/analysis/synonyms/english'
{code}

Does the API treat explicit mappings as having precedence over equivalent 
lists? Or does it fail with some weird error most users won't understand? Seems 
to get complicated pretty fast ...

I didn't go too far down the path of implementing this so there are probably 
more questions that will come up. To reiterate my original design assumption 
for managed synonyms, the API was not intended for humans to interact with 
directly, rather there should be some sort of UI layer on top of this API that 
translates synonym mappings into low-level API calls. For me, it's much more 
clear to send in explicit mappings for each synonym than it is to send some 
flat list and then interpret that list differently based on some flag.

The only advantage I can see is if the synonym list is huge, then expanding 
that out in the request makes the request larger. Other than that are there 
other use cases that require this expand functionality that cannot be achieved 
with the current implementation? If so, we need to decide if expand should be 
immutable and what the API should do if an explicit mapping is received for a 
term that is already used in an equivalent synonym list. [~Soolek] your 
thoughts on this?

 solr.ManagedSynonymFilterFactory all-to-all synonym switch (aka. expand)
 

 Key: SOLR-6878
 URL: https://issues.apache.org/jira/browse/SOLR-6878
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Affects Versions: 4.10.2
Reporter: Tomasz Sulkowski
Assignee: Timothy Potter
  Labels: ManagedSynonymFilterFactory, REST, SOLR
 Attachments: SOLR-6878.patch


 Hi,
 After switching from SynonymFilterFactory to ManagedSynonymFilterFactory I 
 have found out that there is no way to set an all-to-all synonyms relation. 
 Basically (judgind from google search) there is a need for expand 
 functionality switch (known from SynonymFilterFactory) which will treat all 
 synonyms with its keyword as equal.
 For example: if we define a car:[wagen,ride] relation it would

[jira] [Commented] (SOLR-7496) Empty buckets when faceting with JSON API over EnumField and TrieIntField


[ 
https://issues.apache.org/jira/browse/SOLR-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523510#comment-14523510
 ] 

Alfonso Muñoz-Pomer Fuentes commented on SOLR-7496:
---

My browser got a bit wonky while reporting this issue, and I thought it didn’t 
go through. This is a duplicate of 
https://issues.apache.org/jira/browse/SOLR-7497.

 Empty buckets when faceting with JSON API over EnumField and TrieIntField
 -

 Key: SOLR-7496
 URL: https://issues.apache.org/jira/browse/SOLR-7496
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
 $ java -version
 java version 1.8.0_31
 Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
 Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes
  Labels: patch

 When using facets with the new JSON API over an EnumFiled or a TrieIntField, 
 I get a list of empty buckets.



--
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-NightlyTests-5.x - Build # 834 - Still Failing

2015-05-01 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/834/

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

Error Message:
expected:[{indexVersion=1430496108028,generation=2,filelist=[_0.cfe, _0.cfs, 
_0.si, _1.cfe, _1.cfs, _1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, 
_4.cfe, _4.cfs, _4.si, _5.cfe, _5.cfs, _5.si, segments_2]}] but 
was:[{indexVersion=1430496108028,generation=3,filelist=[_3.cfe, _3.cfs, _3.si, 
_6.cfe, _6.cfs, _6.si, segments_3]}, 
{indexVersion=1430496108028,generation=2,filelist=[_0.cfe, _0.cfs, _0.si, 
_1.cfe, _1.cfs, _1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, 
_4.cfs, _4.si, _5.cfe, _5.cfs, _5.si, segments_2]}]

Stack Trace:
java.lang.AssertionError: 
expected:[{indexVersion=1430496108028,generation=2,filelist=[_0.cfe, _0.cfs, 
_0.si, _1.cfe, _1.cfs, _1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, 
_4.cfe, _4.cfs, _4.si, _5.cfe, _5.cfs, _5.si, segments_2]}] but 
was:[{indexVersion=1430496108028,generation=3,filelist=[_3.cfe, _3.cfs, _3.si, 
_6.cfe, _6.cfs, _6.si, segments_3]}, 
{indexVersion=1430496108028,generation=2,filelist=[_0.cfe, _0.cfs, _0.si, 
_1.cfe, _1.cfs, _1.si, _2.cfe, _2.cfs, _2.si, _3.cfe, _3.cfs, _3.si, _4.cfe, 
_4.cfs, _4.si, _5.cfe, _5.cfs, _5.si, segments_2]}]
at 
__randomizedtesting.SeedInfo.seed([C2588EF05E1A8FF6:E78F95C02E5281F5]: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:1138)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12531 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12531/
Java: 64bit/jdk1.8.0_60-ea-b12 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 45388 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] Traceback (most recent call last):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 384, in module
 [exec] if checkPackageSummaries(sys.argv[1], level):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 364, in checkPackageSummaries
 [exec] if checkClassSummaries(fullPath):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 225, in checkClassSummaries
 [exec] raise RuntimeError('failed to locate javadoc item in %s, line 
%d? last line: %s' % (fullPath, lineCount, line.rstrip()))
 [exec] RuntimeError: failed to locate javadoc item in 
build/docs/classification/org/apache/lucene/classification/KNearestNeighborClassifier.html,
 line 150? last line: /tr

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:90: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:135: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:165: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2476: 
exec returned: 1

Total time: 47 minutes 55 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Created] (SOLR-7497) Empty buckets when faceting with JSON API on EnumField or TrieIntField

Alfonso Muñoz-Pomer Fuentes created SOLR-7497:
-

 Summary: Empty buckets when faceting with JSON API on EnumField or 
TrieIntField
 Key: SOLR-7497
 URL: https://issues.apache.org/jira/browse/SOLR-7497
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
$ java -version
java version 1.8.0_31
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes


When using the JSON API, faceting on an EnumField or TrieIntField returns an 
empty list of buckets.

Steps to reproduce:
1. Define an EnumField.
schema.xml:
field name=kingdom type=kingdomEnum indexed=true stored=true 
required=true / 
fieldType name=kingdomEnum class=solr.EnumField 
enumsConfig=enumsConfig.xml enumName=kingdom/ 

enumsConfig.xml:
?xml version=1.0 ?
enumsConfig
enum name=kingdom
valueplants/value
valuemetazoa/value
valuefungi/value
/enum
/enumsConfig 

2. Add documents to core.

3. Faceting over the EnumField returns an empty list of buckets:
$ curl http://localhost:8983/solr/myCore/query -d '
{
  query: *:*,
  facet : {
kingdom : {terms : kingdom}
  }
}'
{ ...
  facets:{
count:17,
kingdom:{
  buckets:[]}}}

The same issue happens with TrieIntField. Using old-style facets works, this 
only happens with the new JSON API.

I tested changing the field to a string and I get the expected results.



--
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-7497) Empty buckets when faceting with JSON API on EnumField or TrieIntField


[ 
https://issues.apache.org/jira/browse/SOLR-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523481#comment-14523481
 ] 

Alfonso Muñoz-Pomer Fuentes commented on SOLR-7497:
---

This worked in Heliosearch 0.09.

 Empty buckets when faceting with JSON API on EnumField or TrieIntField
 --

 Key: SOLR-7497
 URL: https://issues.apache.org/jira/browse/SOLR-7497
 Project: Solr
  Issue Type: Bug
  Components: faceting
Affects Versions: 5.1, 5.2
 Environment: OS X 10.10.3
 $ java -version
 java version 1.8.0_31
 Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
 Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
Reporter: Alfonso Muñoz-Pomer Fuentes

 When using the JSON API, faceting on an EnumField or TrieIntField returns an 
 empty list of buckets.
 Steps to reproduce:
 1. Define an EnumField.
 schema.xml:
 field name=kingdom type=kingdomEnum indexed=true stored=true 
 required=true / 
 fieldType name=kingdomEnum class=solr.EnumField 
 enumsConfig=enumsConfig.xml enumName=kingdom/ 
 enumsConfig.xml:
 ?xml version=1.0 ?
 enumsConfig
 enum name=kingdom
 valueplants/value
 valuemetazoa/value
 valuefungi/value
 /enum
 /enumsConfig 
 2. Add documents to core.
 3. Faceting over the EnumField returns an empty list of buckets:
 $ curl http://localhost:8983/solr/myCore/query -d '
 {
   query: *:*,
   facet : {
 kingdom : {terms : kingdom}
   }
 }'
 { ...
   facets:{
 count:17,
 kingdom:{
   buckets:[]}}}
 The same issue happens with TrieIntField. Using old-style facets works, this 
 only happens with the new JSON API.
 I tested changing the field to a string and I get the expected results.



--
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-7377) SOLR Streaming Expressions

2015-05-01 Thread Joel Bernstein (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523320#comment-14523320
 ] 

Joel Bernstein commented on SOLR-7377:
--

The main use case that I have in mind for the unix pipeline is piping data from 
a Streaming Expression to R.

But there could be all kinds of fun stuff that could be cooked up with piping 
Streaming Expression output.

 SOLR Streaming Expressions
 --

 Key: SOLR-7377
 URL: https://issues.apache.org/jira/browse/SOLR-7377
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Dennis Gove
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch


 It would be beneficial to add an expression-based interface to Streaming API 
 described in SOLR-7082. Right now that API requires streaming requests to 
 come in from clients as serialized bytecode of the streaming classes. The 
 suggestion here is to support string expressions which describe the streaming 
 operations the client wishes to perform. 
 {code:java}
 search(collection1, q=*:*, fl=id,fieldA,fieldB, sort=fieldA asc)
 {code}
 With this syntax in mind, one can now express arbitrarily complex stream 
 queries with a single string.
 {code:java}
 // merge two distinct searches together on common fields
 merge(
   search(collection1, q=id:(0 3 4), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   search(collection2, q=id:(1 2), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   on=a_f asc, a_s asc)
 // find top 20 unique records of a search
 top(
   n=20,
   unique(
 search(collection1, q=*:*, fl=id,a_s,a_i,a_f, sort=a_f desc),
 over=a_f desc),
   sort=a_f desc)
 {code}
 The syntax would support
 1. Configurable expression names (eg. via solrconfig.xml one can map unique 
 to a class implementing a Unique stream class) This allows users to build 
 their own streams and use as they wish.
 2. Named parameters (of both simple and expression types)
 3. Unnamed, type-matched parameters (to support requiring N streams as 
 arguments to another stream)
 4. Positional parameters
 The main goal here is to make streaming as accessible as possible and define 
 a syntax for running complex queries across large distributed systems.



--
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-7275) Pluggable authorization module in Solr

2015-05-01 Thread Anshum Gupta (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523859#comment-14523859
 ] 

Anshum Gupta commented on SOLR-7275:


Thanks for that input Don and Ishan, I read up a bit more and it certainly now 
makes more sense to use 403 for authorization and 401 for authentication. I'm 
changing things a bit to have the SolrAuthrorizationReponse contain an int 
HttpStatus code and Solr would just return that back if it's not an SC_OK or 
SC_ACCEPTED. That would allow the authorization plugin to act independently and 
decide what to return. I'll just put up the patch with that update in a bit.

 Pluggable authorization module in Solr
 --

 Key: SOLR-7275
 URL: https://issues.apache.org/jira/browse/SOLR-7275
 Project: Solr
  Issue Type: Sub-task
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch


 Solr needs an interface that makes it easy for different authorization 
 systems to be plugged into it. Here's what I plan on doing:
 Define an interface {{SolrAuthorizationPlugin}} with one single method 
 {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
 return an {{SolrAuthorizationResponse}} object. The object as of now would 
 only contain a single boolean value but in the future could contain more 
 information e.g. ACL for document filtering etc.
 The reason why we need a context object is so that the plugin doesn't need to 
 understand Solr's capabilities e.g. how to extract the name of the collection 
 or other information from the incoming request as there are multiple ways to 
 specify the target collection for a request. Similarly request type can be 
 specified by {{qt}} or {{/handler_name}}.
 Flow:
 Request - SolrDispatchFilter - isAuthorized(context) - Process/Return.
 {code}
 public interface SolrAuthorizationPlugin {
   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
 }
 {code}
 {code}
 public  class SolrRequestContext {
   UserInfo; // Will contain user context from the authentication layer.
   HTTPRequest request;
   Enum OperationType; // Correlated with user roles.
   String[] CollectionsAccessed;
   String[] FieldsAccessed;
   String Resource;
 }
 {code}
 {code}
 public class SolrAuthorizationResponse {
   boolean authorized;
   public boolean isAuthorized();
 }
 {code}
 User Roles: 
 * Admin
 * Collection Level:
   * Query
   * Update
   * Admin
 Using this framework, an implementation could be written for specific 
 security systems e.g. Apache Ranger or Sentry. It would keep all the security 
 system specific code out of Solr.



--
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-7487) check-example-lucene-match-version is looking in the wrong place - luceneMatchVersion incorrect in 5.1 sample configs

2015-05-01 Thread ASF subversion and git services (JIRA)


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

Timothy Potter updated SOLR-7487:
-
Attachment: SOLR-7487.patch

Minor typo in python ... committing this now.

 check-example-lucene-match-version is looking in the wrong place - 
 luceneMatchVersion incorrect in 5.1 sample configs
 -

 Key: SOLR-7487
 URL: https://issues.apache.org/jira/browse/SOLR-7487
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Hoss Man
Assignee: Timothy Potter
Priority: Blocker
 Fix For: 5.2

 Attachments: SOLR-7487.patch, SOLR-7487.patch, SOLR-7487.patch, 
 SOLR-7487.patch


 As noted by Scott Dawson on the mailing list, the luceneMatchVersion in the 
 5.1 sample configs all still lists 5.0.0.
 The root cause seems to be because the check-example-lucene-match-version 
 task in solr/build.xml is looking in the wrong place -- it's still scaning 
 for instances of luceneMatchVersion in the {{example}} directory instead of 
 the {{server/solr/configset}}
 TODO:
 * fix the luceneMatchVersion value in all sample configsets on 5x
 * update the check to look in the correct directory
 * update the check to fail to be smarter know that we have a more predictable 
 directory structure
 ** fail if no subdirs found
 ** fail if any subdir doesn't contain conf/solrconfig.xml
 ** fail if any conf/solrconfig.xml doesn't contain a luceneMatchVersion
 ** fail if any luceneMatchVersion doesn't have the expected value



--
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-7275) Pluggable authorization module in Solr

2015-05-01 Thread Don Bosco Durai (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523851#comment-14523851
 ] 

Don Bosco Durai commented on SOLR-7275:
---

Yes, for authorization, we should return 403 (post authentication). 401 is more 
appropriate for authentication flow

 Pluggable authorization module in Solr
 --

 Key: SOLR-7275
 URL: https://issues.apache.org/jira/browse/SOLR-7275
 Project: Solr
  Issue Type: Sub-task
Reporter: Anshum Gupta
Assignee: Anshum Gupta
 Attachments: SOLR-7275.patch, SOLR-7275.patch, SOLR-7275.patch


 Solr needs an interface that makes it easy for different authorization 
 systems to be plugged into it. Here's what I plan on doing:
 Define an interface {{SolrAuthorizationPlugin}} with one single method 
 {{isAuthorized}}. This would take in a {{SolrRequestContext}} object and 
 return an {{SolrAuthorizationResponse}} object. The object as of now would 
 only contain a single boolean value but in the future could contain more 
 information e.g. ACL for document filtering etc.
 The reason why we need a context object is so that the plugin doesn't need to 
 understand Solr's capabilities e.g. how to extract the name of the collection 
 or other information from the incoming request as there are multiple ways to 
 specify the target collection for a request. Similarly request type can be 
 specified by {{qt}} or {{/handler_name}}.
 Flow:
 Request - SolrDispatchFilter - isAuthorized(context) - Process/Return.
 {code}
 public interface SolrAuthorizationPlugin {
   public SolrAuthorizationResponse isAuthorized(SolrRequestContext context);
 }
 {code}
 {code}
 public  class SolrRequestContext {
   UserInfo; // Will contain user context from the authentication layer.
   HTTPRequest request;
   Enum OperationType; // Correlated with user roles.
   String[] CollectionsAccessed;
   String[] FieldsAccessed;
   String Resource;
 }
 {code}
 {code}
 public class SolrAuthorizationResponse {
   boolean authorized;
   public boolean isAuthorized();
 }
 {code}
 User Roles: 
 * Admin
 * Collection Level:
   * Query
   * Update
   * Admin
 Using this framework, an implementation could be written for specific 
 security systems e.g. Apache Ranger or Sentry. It would keep all the security 
 system specific code out of Solr.



--
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-7462) ArrayIndexOutOfBoundsException in RecordingJSONParser.java

2015-05-01 Thread Scott Dawson (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523645#comment-14523645
 ] 

Scott Dawson commented on SOLR-7462:


I've attached a JSON file which can be used to reproduce the bug. I'm posting 
it to Solr like this:
curl 
'http://localhost:8983/solr/struct-json/update/json/docs?split=/f=/**srcField=display_json'
 -H 'Content-Type:application/json' --data-binary @SOLR-7462.test.json

This causes the ArrayIndexOutOfBoundsException with out-of-the-box Solr 5.1 but 
works fine with my patched version.

 ArrayIndexOutOfBoundsException in RecordingJSONParser.java
 --

 Key: SOLR-7462
 URL: https://issues.apache.org/jira/browse/SOLR-7462
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Scott Dawson
 Attachments: SOLR-7462.patch, SOLR-7462.test.json


 With Solr 5.1 I'm getting an occasional fatal exception during indexing. It's 
 an ArrayIndexOutOfBoundsException at line 61 of 
 org/apache/solr/util/RecordingJSONParser.java. Looking at the code (see 
 below), it seems obvious that the if-statement at line 60 should use a 
 greater-than sign instead of greater-than-or-equals.
   @Override
   public CharArr getStringChars() throws IOException {
 CharArr chars = super.getStringChars();
 recordStr(chars.toString());
 position = getPosition();
 // if reading a String , the getStringChars do not return the closing 
 single quote or double quote
 //so, try to capture that
 if(chars.getArray().length =chars.getStart()+chars.size()) { // line 
 60
   char next = chars.getArray()[chars.getStart() + chars.size()]; // line 
 61
   if(next =='' || next == '\'') {
 recordChar(next);
   }
 }
 return chars;
   }



--
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-7462) ArrayIndexOutOfBoundsException in RecordingJSONParser.java

2015-05-01 Thread Scott Dawson (JIRA)


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

Scott Dawson updated SOLR-7462:
---
Attachment: SOLR-7462.test.json

 ArrayIndexOutOfBoundsException in RecordingJSONParser.java
 --

 Key: SOLR-7462
 URL: https://issues.apache.org/jira/browse/SOLR-7462
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Scott Dawson
 Attachments: SOLR-7462.patch, SOLR-7462.test.json


 With Solr 5.1 I'm getting an occasional fatal exception during indexing. It's 
 an ArrayIndexOutOfBoundsException at line 61 of 
 org/apache/solr/util/RecordingJSONParser.java. Looking at the code (see 
 below), it seems obvious that the if-statement at line 60 should use a 
 greater-than sign instead of greater-than-or-equals.
   @Override
   public CharArr getStringChars() throws IOException {
 CharArr chars = super.getStringChars();
 recordStr(chars.toString());
 position = getPosition();
 // if reading a String , the getStringChars do not return the closing 
 single quote or double quote
 //so, try to capture that
 if(chars.getArray().length =chars.getStart()+chars.size()) { // line 
 60
   char next = chars.getArray()[chars.getStart() + chars.size()]; // line 
 61
   if(next =='' || next == '\'') {
 recordChar(next);
   }
 }
 return chars;
   }



--
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-6196) Include geo3d package, along with Lucene integration to make it useful


[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523660#comment-14523660
 ] 

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

Commit 1677205 from [~dsmiley] in branch 'dev/branches/lucene6196'
[ https://svn.apache.org/r1677205 ]

LUCENE-6196: committing Karl's latest patch
https://reviews.apache.org/r/33509/ (diff #6)

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: LUCENE-6196-additions.patch, LUCENE-6196-fixes.patch, 
 LUCENE-6196_Geo3d.patch, ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-Windows (64bit/jdk1.8.0_45) - Build # 4752 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4752/
Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 45440 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] Traceback (most recent call last):
 [exec]   File 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 384, in module
 [exec] if checkPackageSummaries(sys.argv[1], level):
 [exec]   File 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 364, in checkPackageSummaries
 [exec] if checkClassSummaries(fullPath):
 [exec]   File 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 225, in checkClassSummaries
 [exec] raise RuntimeError('failed to locate javadoc item in %s, line 
%d? last line: %s' % (fullPath, lineCount, line.rstrip()))
 [exec] RuntimeError: failed to locate javadoc item in 
build/docs/classification\org\apache\lucene\classification/BooleanPerceptronClassifier.html,
 line 153? last line: /tr

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:526: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:90: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:135: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:165: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2476:
 exec returned: 1

Total time: 76 minutes 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
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_45) - Build # 12526 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/12526/
Java: 64bit/jdk1.8.0_45 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 45388 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] Traceback (most recent call last):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 384, in module
 [exec] if checkPackageSummaries(sys.argv[1], level):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 364, in checkPackageSummaries
 [exec] if checkClassSummaries(fullPath):
 [exec]   File 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/dev-tools/scripts/checkJavaDocs.py,
 line 225, in checkClassSummaries
 [exec] raise RuntimeError('failed to locate javadoc item in %s, line 
%d? last line: %s' % (fullPath, lineCount, line.rstrip()))
 [exec] RuntimeError: failed to locate javadoc item in 
build/docs/classification/org/apache/lucene/classification/KNearestNeighborClassifier.html,
 line 150? last line: /tr

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:526: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:90: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:135: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:165: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2476: 
exec returned: 1

Total time: 49 minutes 25 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



-
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 # 2246 - Still Failing!

2015-05-01 Thread ASF subversion and git services (JIRA)

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

All tests passed

Build Log:
[...truncated 45342 lines...]
-documentation-lint:
 [echo] checking for broken html...
[jtidy] Checking for broken html (such as invalid tags)...
   [delete] Deleting directory 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp
 [echo] Checking for broken links...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [echo] Checking for missing docs...
 [exec] Traceback (most recent call last):
 [exec]   File 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/dev-tools/scripts/checkJavaDocs.py,
 line 384, in module
 [exec] if checkPackageSummaries(sys.argv[1], level):
 [exec]   File 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/dev-tools/scripts/checkJavaDocs.py,
 line 364, in checkPackageSummaries
 [exec] if checkClassSummaries(fullPath):
 [exec]   File 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/dev-tools/scripts/checkJavaDocs.py,
 line 225, in checkClassSummaries
 [exec] raise RuntimeError('failed to locate javadoc item in %s, line 
%d? last line: %s' % (fullPath, lineCount, line.rstrip()))
 [exec] RuntimeError: failed to locate javadoc item in 
build/docs/classification/org/apache/lucene/classification/BooleanPerceptronClassifier.html,
 line 153? last line: /tr

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:526: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:90: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:135: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:165: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2476: 
exec returned: 1

Total time: 89 minutes 21 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-7487) check-example-lucene-match-version is looking in the wrong place - luceneMatchVersion incorrect in 5.1 sample configs


[ 
https://issues.apache.org/jira/browse/SOLR-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523941#comment-14523941
 ] 

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

Commit 1677232 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1677232 ]

SOLR-7487: update luceneMatchVersion to 5.2.0 so that precommit passes

 check-example-lucene-match-version is looking in the wrong place - 
 luceneMatchVersion incorrect in 5.1 sample configs
 -

 Key: SOLR-7487
 URL: https://issues.apache.org/jira/browse/SOLR-7487
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Hoss Man
Assignee: Timothy Potter
Priority: Blocker
 Fix For: 5.2

 Attachments: SOLR-7487.patch, SOLR-7487.patch, SOLR-7487.patch, 
 SOLR-7487.patch


 As noted by Scott Dawson on the mailing list, the luceneMatchVersion in the 
 5.1 sample configs all still lists 5.0.0.
 The root cause seems to be because the check-example-lucene-match-version 
 task in solr/build.xml is looking in the wrong place -- it's still scaning 
 for instances of luceneMatchVersion in the {{example}} directory instead of 
 the {{server/solr/configset}}
 TODO:
 * fix the luceneMatchVersion value in all sample configsets on 5x
 * update the check to look in the correct directory
 * update the check to fail to be smarter know that we have a more predictable 
 directory structure
 ** fail if no subdirs found
 ** fail if any subdir doesn't contain conf/solrconfig.xml
 ** fail if any conf/solrconfig.xml doesn't contain a luceneMatchVersion
 ** fail if any luceneMatchVersion doesn't have the expected value



--
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-7487) check-example-lucene-match-version is looking in the wrong place - luceneMatchVersion incorrect in 5.1 sample configs

2015-05-01 Thread ASF subversion and git services (JIRA)


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

Timothy Potter resolved SOLR-7487.
--
   Resolution: Fixed
Fix Version/s: Trunk

 check-example-lucene-match-version is looking in the wrong place - 
 luceneMatchVersion incorrect in 5.1 sample configs
 -

 Key: SOLR-7487
 URL: https://issues.apache.org/jira/browse/SOLR-7487
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Hoss Man
Assignee: Timothy Potter
Priority: Blocker
 Fix For: Trunk, 5.2

 Attachments: SOLR-7487.patch, SOLR-7487.patch, SOLR-7487.patch, 
 SOLR-7487.patch


 As noted by Scott Dawson on the mailing list, the luceneMatchVersion in the 
 5.1 sample configs all still lists 5.0.0.
 The root cause seems to be because the check-example-lucene-match-version 
 task in solr/build.xml is looking in the wrong place -- it's still scaning 
 for instances of luceneMatchVersion in the {{example}} directory instead of 
 the {{server/solr/configset}}
 TODO:
 * fix the luceneMatchVersion value in all sample configsets on 5x
 * update the check to look in the correct directory
 * update the check to fail to be smarter know that we have a more predictable 
 directory structure
 ** fail if no subdirs found
 ** fail if any subdir doesn't contain conf/solrconfig.xml
 ** fail if any conf/solrconfig.xml doesn't contain a luceneMatchVersion
 ** fail if any luceneMatchVersion doesn't have the expected value



--
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 # 3045 - Failure

2015-05-01 Thread Apache Jenkins Server

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

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerConcurrent

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.TestSolrConfigHandlerConcurrent: 1) Thread[id=4578, 
name=httpUriRequest-649-thread-1-processing-{core=collection1, 
replica=core_node3, collection=collection1, shard=shard1, 
node_name=127.0.0.1:31199_, 
HttpSolrClient.url=https:127.0.0.1:31161//collection1}, state=RUNNABLE, 
group=TGRP-TestSolrConfigHandlerConcurrent] at 
java.net.PlainSocketImpl.socketConnect(Native Method) at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
 at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
 at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)  
   at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at 
java.net.Socket.connect(Socket.java:579) at 
sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618) at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532)
 at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
 at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
 at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
 at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
 at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
 at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
 at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
 at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:466)
 at 
org.apache.solr.client.solrj.impl.HttpSolrClient$1.call(HttpSolrClient.java:271)
 at 
org.apache.solr.client.solrj.impl.HttpSolrClient$1.call(HttpSolrClient.java:267)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:148)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSolrConfigHandlerConcurrent: 
   1) Thread[id=4578, 
name=httpUriRequest-649-thread-1-processing-{core=collection1, 
replica=core_node3, collection=collection1, shard=shard1, 
node_name=127.0.0.1:31199_, 
HttpSolrClient.url=https:127.0.0.1:31161//collection1}, state=RUNNABLE, 
group=TGRP-TestSolrConfigHandlerConcurrent]
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618)
at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532)
at 
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
at 
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at 
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:466)
at

[jira] [Commented] (SOLR-7487) check-example-lucene-match-version is looking in the wrong place - luceneMatchVersion incorrect in 5.1 sample configs


[ 
https://issues.apache.org/jira/browse/SOLR-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523918#comment-14523918
 ] 

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

Commit 1677230 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1677230 ]

SOLR-7487: Fix check-example-lucene-match-version Ant task to check 
luceneMatchVersion in solr/server/solr/configsets instead of example and harden 
error checking / validation logic.

 check-example-lucene-match-version is looking in the wrong place - 
 luceneMatchVersion incorrect in 5.1 sample configs
 -

 Key: SOLR-7487
 URL: https://issues.apache.org/jira/browse/SOLR-7487
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Hoss Man
Assignee: Timothy Potter
Priority: Blocker
 Fix For: 5.2

 Attachments: SOLR-7487.patch, SOLR-7487.patch, SOLR-7487.patch, 
 SOLR-7487.patch


 As noted by Scott Dawson on the mailing list, the luceneMatchVersion in the 
 5.1 sample configs all still lists 5.0.0.
 The root cause seems to be because the check-example-lucene-match-version 
 task in solr/build.xml is looking in the wrong place -- it's still scaning 
 for instances of luceneMatchVersion in the {{example}} directory instead of 
 the {{server/solr/configset}}
 TODO:
 * fix the luceneMatchVersion value in all sample configsets on 5x
 * update the check to look in the correct directory
 * update the check to fail to be smarter know that we have a more predictable 
 directory structure
 ** fail if no subdirs found
 ** fail if any subdir doesn't contain conf/solrconfig.xml
 ** fail if any conf/solrconfig.xml doesn't contain a luceneMatchVersion
 ** fail if any luceneMatchVersion doesn't have the expected value



--
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-7487) check-example-lucene-match-version is looking in the wrong place - luceneMatchVersion incorrect in 5.1 sample configs

2015-05-01 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523916#comment-14523916
 ] 

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

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

SOLR-7487: Fix check-example-lucene-match-version Ant task to check 
luceneMatchVersion in solr/server/solr/configsets instead of example and harden 
error checking / validation logic.

 check-example-lucene-match-version is looking in the wrong place - 
 luceneMatchVersion incorrect in 5.1 sample configs
 -

 Key: SOLR-7487
 URL: https://issues.apache.org/jira/browse/SOLR-7487
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.1
Reporter: Hoss Man
Assignee: Timothy Potter
Priority: Blocker
 Fix For: 5.2

 Attachments: SOLR-7487.patch, SOLR-7487.patch, SOLR-7487.patch, 
 SOLR-7487.patch


 As noted by Scott Dawson on the mailing list, the luceneMatchVersion in the 
 5.1 sample configs all still lists 5.0.0.
 The root cause seems to be because the check-example-lucene-match-version 
 task in solr/build.xml is looking in the wrong place -- it's still scaning 
 for instances of luceneMatchVersion in the {{example}} directory instead of 
 the {{server/solr/configset}}
 TODO:
 * fix the luceneMatchVersion value in all sample configsets on 5x
 * update the check to look in the correct directory
 * update the check to fail to be smarter know that we have a more predictable 
 directory structure
 ** fail if no subdirs found
 ** fail if any subdir doesn't contain conf/solrconfig.xml
 ** fail if any conf/solrconfig.xml doesn't contain a luceneMatchVersion
 ** fail if any luceneMatchVersion doesn't have the expected value



--
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-7274) Pluggable authentication module in Solr

2015-05-01 Thread Don Bosco Durai (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523901#comment-14523901
 ] 

Don Bosco Durai commented on SOLR-7274:
---

[~ichattopadhyaya], I had some issues running with the above syntax. The code 
is expecting that -Dsolr.hdfs.security.kerberos.keytabfile passed. I have not 
yet traced through the code, but maybe some other defaults are kicking in and 
expecting the above property.

My working syntax is below. I think, -Dkerberos.keytab is not getting into 
affect. 

bin/solr -c -z localhost:2181 -a 
-Djava.security.auth.login.config=$HOME/conf/jaas-client.conf 
-Dcookie.domain=`hostname -f` -Dkerberos.principal=HTTP/`hostname 
-f`@EXAMPLE.COM -Dkerberos.keytab=/keytabs/http.keytab 
-DauthcPlugin=org.apache.solr.security.KerberosPlugin 
-Dsolr.hdfs.security.kerberos.keytabfile=/keytabs/http.keytab



 Pluggable authentication module in Solr
 ---

 Key: SOLR-7274
 URL: https://issues.apache.org/jira/browse/SOLR-7274
 Project: Solr
  Issue Type: Sub-task
Reporter: Anshum Gupta
 Attachments: SOLR-7274.patch, SOLR-7274.patch, SOLR-7274.patch, 
 SOLR-7274.patch, SOLR-7274.patch


 It would be good to have Solr support different authentication protocols.
 To begin with, it'd be good to have support for kerberos and basic auth.



--
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-7121) Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion


[ 
https://issues.apache.org/jira/browse/SOLR-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523055#comment-14523055
 ] 

Mark Miller commented on SOLR-7121:
---

I think we want to look at making these new tests much faster. The test suite 
with this patch doesn't yet fully pass for me either.

What is the motivation behind the core regex matching and multiple config 
entries? Do you really need to configure different healthcheck thresholds per 
core in a collection?

 Solr nodes should go down based on configurable thresholds and not rely on 
 resource exhaustion
 --

 Key: SOLR-7121
 URL: https://issues.apache.org/jira/browse/SOLR-7121
 Project: Solr
  Issue Type: New Feature
Reporter: Sachin Goyal
 Attachments: SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, 
 SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch


 Currently, there is no way to control when a Solr node goes down.
 If the server is having high GC pauses or too many threads or is just getting 
 too many queries due to some bad load-balancer, the cores in the machine keep 
 on serving unless they exhaust the machine's resources and everything comes 
 to a stall.
 Such a slow-dying core can affect other cores as well by taking huge time to 
 serve their distributed queries.
 There should be a way to specify some threshold values beyond which the 
 targeted core can its ill-health and proactively go down to recover.
 When the load improves, the core should come up automatically.



--
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-7121) Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion


[ 
https://issues.apache.org/jira/browse/SOLR-7121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523059#comment-14523059
 ] 

Mark Miller commented on SOLR-7121:
---

We also want to make it clear this functionality only works with SolrCloud and 
think about how that should best be expressed in the code - this bleeds a bit 
of SolrCloud specific code out of ZkController and into SolrCore in a way we 
have not really done yet I think.

 Solr nodes should go down based on configurable thresholds and not rely on 
 resource exhaustion
 --

 Key: SOLR-7121
 URL: https://issues.apache.org/jira/browse/SOLR-7121
 Project: Solr
  Issue Type: New Feature
Reporter: Sachin Goyal
 Attachments: SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, 
 SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch


 Currently, there is no way to control when a Solr node goes down.
 If the server is having high GC pauses or too many threads or is just getting 
 too many queries due to some bad load-balancer, the cores in the machine keep 
 on serving unless they exhaust the machine's resources and everything comes 
 to a stall.
 Such a slow-dying core can affect other cores as well by taking huge time to 
 serve their distributed queries.
 There should be a way to specify some threshold values beyond which the 
 targeted core can its ill-health and proactively go down to recover.
 When the load improves, the core should come up automatically.



--
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-7363) Expand component throws an Exception when the results have been collapsed and grouped

2015-05-01 Thread Brandon Chapman (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523140#comment-14523140
 ] 

Brandon Chapman commented on SOLR-7363:
---

Thanks, I take a look at the highlighting component when I get a chance. 

 Expand component throws an Exception when the results have been collapsed and 
 grouped
 -

 Key: SOLR-7363
 URL: https://issues.apache.org/jira/browse/SOLR-7363
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.10.3
Reporter: Brandon Chapman

 The expand component does not work when used on a result that has been both 
 collapsed and grouped. This is counter-intuitive as collapsing and grouping 
 work together with no issues.
 {code}
 {
   responseHeader:{
 status:500,
 QTime:1198,
 params:{
   fl:psid,
   indent:true,
   q:*:*,
   expand:true,
   group.field:merchant,
   group:true,
   wt:json,
   fq:{!collapse field=groupId},
   rows:1}},
   grouped:{
 merchant:{
   matches:71652,
   groups:[{
   groupValue:sears,
   doclist:{numFound:30672,start:0,docs:[
   {
 psid:3047500675628000}]
   }}]}},
   error:{
 trace:java.lang.NullPointerException\n\tat 
 org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:193)\n\tat
  
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)\n\tat
  
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
  org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)\n\tat 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)\n\tat
  
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)\n\tat
  
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)\n\tat
  
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)\n\tat
  
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)\n\tat
  
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)\n\tat
  
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)\n\tat
  
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)\n\tat
  
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)\n\tat
  
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)\n\tat
  
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)\n\tat
  
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)\n\tat
  
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)\n\tat
  
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)\n\tat
  
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)\n\tat
  
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat
  
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
  java.lang.Thread.run(Thread.java:744)\n,
 code: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

Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_45) - Build # 4752 - Still Failing!

2015-05-01 Thread Mark Miller

 [exec] RuntimeError: failed to locate javadoc item in
build/docs/classification\org\apache\lucene\classification/BooleanPerceptronClassifier.html,
line 153? last line: /tr


This is failing ant precommit as well.


- Mark


On Fri, May 1, 2015 at 6:35 AM Policeman Jenkins Server jenk...@thetaphi.de
wrote:

 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4752/
 Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

 All tests passed

 Build Log:
 [...truncated 45440 lines...]
 -documentation-lint:
  [echo] checking for broken html...
 [jtidy] Checking for broken html (such as invalid tags)...
[delete] Deleting directory
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\jtidy_tmp
  [echo] Checking for broken links...
  [exec]
  [exec] Crawl/parse...
  [exec]
  [exec] Verify...
  [echo] Checking for missing docs...
  [exec] Traceback (most recent call last):
  [exec]   File
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 384, in module
  [exec] if checkPackageSummaries(sys.argv[1], level):
  [exec]   File
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 364, in checkPackageSummaries
  [exec] if checkClassSummaries(fullPath):
  [exec]   File
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\dev-tools/scripts/checkJavaDocs.py,
 line 225, in checkClassSummaries
  [exec] raise RuntimeError('failed to locate javadoc item in %s,
 line %d? last line: %s' % (fullPath, lineCount, line.rstrip()))
  [exec] RuntimeError: failed to locate javadoc item in
 build/docs/classification\org\apache\lucene\classification/BooleanPerceptronClassifier.html,
 line 153? last line: /tr

 BUILD FAILED
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:526:
 The following error occurred while executing this line:
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:90:
 The following error occurred while executing this line:
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:135:
 The following error occurred while executing this line:
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:165:
 The following error occurred while executing this line:
 C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2476:
 exec returned: 1

 Total time: 76 minutes 7 seconds
 Build step 'Invoke Ant' marked build as failure
 Archiving artifacts
 Recording test results
 Email was triggered for: Failure - Any
 Sending email for trigger: Failure - Any



 -
 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 # 2247 - Still Failing!

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls

Error Message:
Shard split did not complete. Last recorded state: running 
expected:[completed] but was:[running]

Stack Trace:
org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: 
running expected:[completed] but was:[running]
at 
__randomizedtesting.SeedInfo.seed([6C4EE8531FF12691:342A6432199B8E45]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:101)
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:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
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:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
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

[jira] [Updated] (SOLR-7121) Solr nodes should go down based on configurable thresholds and not rely on resource exhaustion


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

Mark Miller updated SOLR-7121:
--
Attachment: SOLR-7121.patch

 Solr nodes should go down based on configurable thresholds and not rely on 
 resource exhaustion
 --

 Key: SOLR-7121
 URL: https://issues.apache.org/jira/browse/SOLR-7121
 Project: Solr
  Issue Type: New Feature
Reporter: Sachin Goyal
 Attachments: SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, 
 SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch, SOLR-7121.patch


 Currently, there is no way to control when a Solr node goes down.
 If the server is having high GC pauses or too many threads or is just getting 
 too many queries due to some bad load-balancer, the cores in the machine keep 
 on serving unless they exhaust the machine's resources and everything comes 
 to a stall.
 Such a slow-dying core can affect other cores as well by taking huge time to 
 serve their distributed queries.
 There should be a way to specify some threshold values beyond which the 
 targeted core can its ill-health and proactively go down to recover.
 When the load improves, the core should come up automatically.



--
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-7377) SOLR Streaming Expressions

2015-05-01 Thread Joel Bernstein (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523097#comment-14523097
 ] 

Joel Bernstein commented on SOLR-7377:
--

This patch looks really good. I'm planning on making only three changes:

1) Allowing the ParallelStream to either use object serialization or Streaming 
Expressions as transport mechanism. There will be use cases where people will 
want to use the Streaming API directly and not bother with Streaming 
Expressions constructs.  

2) Add some tests for StreamingExpressions that use the ParallelStream.

3) Add an ExpressionRunner that runs expressions from the command line. The 
initial version of this will only support built-in expressions. We should 
decide if we want to break out the name-to-class mapping in an external 
properties file so it can be used both by Solr and the ExpressionRunner.

 SOLR Streaming Expressions
 --

 Key: SOLR-7377
 URL: https://issues.apache.org/jira/browse/SOLR-7377
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Dennis Gove
Priority: Minor
 Fix For: Trunk

 Attachments: SOLR-7377.patch, SOLR-7377.patch, SOLR-7377.patch, 
 SOLR-7377.patch


 It would be beneficial to add an expression-based interface to Streaming API 
 described in SOLR-7082. Right now that API requires streaming requests to 
 come in from clients as serialized bytecode of the streaming classes. The 
 suggestion here is to support string expressions which describe the streaming 
 operations the client wishes to perform. 
 {code:java}
 search(collection1, q=*:*, fl=id,fieldA,fieldB, sort=fieldA asc)
 {code}
 With this syntax in mind, one can now express arbitrarily complex stream 
 queries with a single string.
 {code:java}
 // merge two distinct searches together on common fields
 merge(
   search(collection1, q=id:(0 3 4), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   search(collection2, q=id:(1 2), fl=id,a_s,a_i,a_f, sort=a_f asc, a_s 
 asc),
   on=a_f asc, a_s asc)
 // find top 20 unique records of a search
 top(
   n=20,
   unique(
 search(collection1, q=*:*, fl=id,a_s,a_i,a_f, sort=a_f desc),
 over=a_f desc),
   sort=a_f desc)
 {code}
 The syntax would support
 1. Configurable expression names (eg. via solrconfig.xml one can map unique 
 to a class implementing a Unique stream class) This allows users to build 
 their own streams and use as they wish.
 2. Named parameters (of both simple and expression types)
 3. Unnamed, type-matched parameters (to support requiring N streams as 
 arguments to another stream)
 4. Positional parameters
 The main goal here is to make streaming as accessible as possible and define 
 a syntax for running complex queries across large distributed systems.



--
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-7458) Expose HDFS Block Locality Metrics


[ 
https://issues.apache.org/jira/browse/SOLR-7458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523102#comment-14523102
 ] 

Mark Miller commented on SOLR-7458:
---

This looks like a good approach.

bq. localhost = System.getProperty(solr.host, localhost);

This looks off to me. For one, I'm wary of using 'localhost' vs 127.0.0.1. Are 
we sure that is the right approach?

Also, 'solr.host' is not any kind of official system property. There is a host 
property in solr.xml.

bq. private final MapHdfsDirectory,MapFileStatus,BlockLocation[] cache

This cache needs to be thread safe.

 Expose HDFS Block Locality Metrics
 --

 Key: SOLR-7458
 URL: https://issues.apache.org/jira/browse/SOLR-7458
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mike Drob
Assignee: Mark Miller
  Labels: metrics
 Attachments: SOLR-7458.patch, SOLR-7458.patch


 We should publish block locality metrics when using HDFS.



--
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-7493) Requests aren't distributed evenly if the collection isn't present locally