[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9910:
-

Can we add another line to the usage docs of the {{-j}} parameter to say that 
Solr does not support customization of jetty configs and such may break even in 
minor or bug fix releases? I'd hate for us to be tied into back compat concerns 
because of such hacks.

> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4072 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4072/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([97952758791C4EBF:1FC11882D7E02347]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:910)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-10885) NullPointerException when run collapse filter

[jefferyyuan (JIRA)]

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

jefferyyuan updated SOLR-10885:
---
Description: 
Solr collapse is a great function to collapse data that is related so we only 
show one in search result.

Just found one issue related with it - It throw NullPointerException in some 
cases.

To reproduce it, first ingest some data - AND commit multiple times.

1. When there is no data that matches the query:
http://localhost:8983/solr/thecollection/select?defType=edismax=non-existType:*={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

*2. When the data that matches the query doesn't have the collapse fields
- This is kind of a big problem as we may store different kinds of docs in one 
collection, one query may match different kinds of docs. 
If some docs (docType1) have same value for  field1, we want to collapse them, 
if other dosc(docType2) have some value for field2, do same things.*
- channel data doesn't have seriesId or programId
http://localhost:8983/solr/thecollection/select?defType=edismax=docType:channel={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

Exception from log:
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr/searchItems_shard1_replica3: 
java.lang.NullPointerException
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:617)
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:667)
at 
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:256)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1823)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1640)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:611)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:533)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)

int nextDocBase = currentContext + 1 < this.contexts.length ? 
this.contexts[(currentContext + 1)].docBase : this.maxDoc; - 617 from solr 
6.4.1 CollapsingQParserPlugin.java

Seems related with https://issues.apache.org/jira/browse/SOLR-8807
- But SOLR-8807 only fixes issue related with spell checker.

I may test this with latest solr 6.6.0 when I have time.

Updated:
Whether solr supports multiple collapse fields?
- Seems the query occasionally works (1/10 maybe), but othertimes it throws 
NullPointerException
http://localhost:18983/solr/thecollection/select?q=programId:* AND 
id:*=edismax={!collapse+field=id }={!collapse+field=programId }

  was:
Solr collapse is a great function to collapse data that is related so we only 
show one in 

[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9565:
--

bq.Instead of the magic -UpdateProcessorFactory suffix magic, can we perhaps 
let all URPs be named SPIs like 

Going forward, people will write their own URPs and how do you add these names 

bq.Why continue inventing dot-separated config options for complex stuff like 
this when we are moving towards JSON elsewhere? 

I like json , but using a full json in request parameter is a big problem. 
Users have to be careful about how to escape each character. Normal tools such 
as postman support typing json in payload , but not in parameters

Until we come up with a better format we can use the dot separated syntax. 
Whatever format we come up with has to be well thought out and should be a 
common syntax for all, no just URPs


> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>
> Now that we can 'construct' the URP chains through request parameters, we 
> should make all the URPs available automatically. The next challenge is to 
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be 
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is 
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just 
> configuration parameters e.g: 
> {{processor=HTMLStripField=}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7719) UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7719:
--

Ping [~mikemccand] since you've been involved with AutomatonQuery and automata 
in general. If you're too busy then I think the change to AutomatonQuery is 
innocent enough so I'm comfortable committing the patch as-is.

I'm not sure if this will make 7.0 or not but I don't think it matters -- no 
back-compat issue / API issue.

> UnifiedHighlighter doesn't handle some AutomatonQuery's with multi-byte chars
> -
>
> Key: LUCENE-7719
> URL: https://issues.apache.org/jira/browse/LUCENE-7719
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: LUCENE_7719.patch
>
>
> In MultiTermHighlighting, a CharacterRunAutomaton is being created that takes 
> the result of AutomatonQuery.getAutomaton that in turn is byte oriented, not 
> character oriented.  For ASCII terms, this is safe but it's not for 
> multi-byte characters.  This is most likely going to rear it's head with a 
> WildcardQuery, but due to special casing in MultiTermHighlighting, 
> PrefixQuery isn't affected.  Nonetheless it'd be nice to get a general fix in 
> so that MultiTermHighlighting can remove special cases for PrefixQuery and 
> TermRangeQuery (both subclass AutomatonQuery).
> AFAICT, this bug was likely in the PostingsHighlighter since inception.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7500) Remove LeafReader.fields()

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7500:
--

If there are no further comments then I'll commit the patch tomorrow.

> Remove LeafReader.fields()
> --
>
> Key: LUCENE-7500
> URL: https://issues.apache.org/jira/browse/LUCENE-7500
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7500_avoid_leafReader_fields.patch, 
> LUCENE_7500_avoid_leafReader_fields.patch, 
> LUCENE_7500_Remove_LeafReader_fields.patch, 
> LUCENE_7500_Remove_LeafReader_fields.patch, 
> LUCENE_7500_Remove_LeafReader_fields.patch
>
>
> {{Fields}} seems like a pointless intermediary between the {{LeafReader}} and 
> {{Terms}}. Why not have {{LeafReader.getTerms(fieldName)}} instead? One loses 
> the ability to get the count and iterate over indexed fields, but it's not 
> clear what real use-cases are for that and such rare needs could figure that 
> out with FieldInfos.
> [~mikemccand] pointed out that we'd probably need to re-introduce a 
> {{TermVectors}} class since TV's are row-oriented not column-oriented.  IMO 
> they should be column-oriented but that'd be a separate issue.
> _(p.s. I'm lacking time to do this w/i the next couple months so if someone 
> else wants to tackle it then great)_



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7876) Avoid needless calls to LeafReader.fields and MultiFields.getFields

[ASF subversion and git services (JIRA)]

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

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

Commit 8a7de414b3f58de6d25ce858cff9ef1bc366f5ad in lucene-solr's branch 
refs/heads/branch_6x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8a7de41 ]

LUCENE-7876: avoid LeafReader.fields and MultiFields.getFields

(cherry picked from commit f470bbc)


> Avoid needless calls to LeafReader.fields and MultiFields.getFields
> ---
>
> Key: LUCENE-7876
> URL: https://issues.apache.org/jira/browse/LUCENE-7876
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7876_avoid_leafReader_fields.patch
>
>
> In LUCENE-7500 we're removing LeafReader.fields for 7.x.  Here in this issue 
> for 6.x and 7.x we simply avoid calling this method (and also 
> MultiFields.getFields) when there is an obvious replacement for 
> LeafReader.terms(field) (and MultiFields.getTerms).  Any absolutely 
> non-trivial changes are occurring in LUCENE-7500.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7876) Avoid needless calls to LeafReader.fields and MultiFields.getFields

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-7876.
--
Resolution: Fixed

> Avoid needless calls to LeafReader.fields and MultiFields.getFields
> ---
>
> Key: LUCENE-7876
> URL: https://issues.apache.org/jira/browse/LUCENE-7876
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7876_avoid_leafReader_fields.patch
>
>
> In LUCENE-7500 we're removing LeafReader.fields for 7.x.  Here in this issue 
> for 6.x and 7.x we simply avoid calling this method (and also 
> MultiFields.getFields) when there is an obvious replacement for 
> LeafReader.terms(field) (and MultiFields.getTerms).  Any absolutely 
> non-trivial changes are occurring in LUCENE-7500.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7876) Avoid needless calls to LeafReader.fields and MultiFields.getFields

[ASF subversion and git services (JIRA)]

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

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

Commit f470bbcbdc930c24c3b1e301d529a26c046f195f in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f470bbc ]

LUCENE-7876 avoid leafReader.fields


> Avoid needless calls to LeafReader.fields and MultiFields.getFields
> ---
>
> Key: LUCENE-7876
> URL: https://issues.apache.org/jira/browse/LUCENE-7876
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7876_avoid_leafReader_fields.patch
>
>
> In LUCENE-7500 we're removing LeafReader.fields for 7.x.  Here in this issue 
> for 6.x and 7.x we simply avoid calling this method (and also 
> MultiFields.getFields) when there is an obvious replacement for 
> LeafReader.terms(field) (and MultiFields.getTerms).  Any absolutely 
> non-trivial changes are occurring in LUCENE-7500.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19861 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19861/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
Error from server at http://127.0.0.1:43921/solr: deleteshard the collection 
time out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:43921/solr: deleteshard the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([3B6349DA48860387:FE3DFDC6CE73C97A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:592)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:219)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1130)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:143)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+173) - Build # 6646 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6646/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([979F9904B739CBD9:52895D9FA78FF3B9]:0)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2487)
at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10834:
-


The current state of the branch is that all tests failures realted to numeric 
uniqueKeys seem to be fixed.

I am however still seeing some fairly consistent failure from SuggesterTest and 
it's subclasses -- which is odd because:
* none of these test classes have been modified on this branch
* none of the config files used by the tests have been modified on this branch
* no non-test code has been modified on this branch.
* these same tests don't seem to fail on master.

When a seed fails for one of these classes, the reproduce lines (to run that 
single method) never seem to relibly fail -- but running all tests in the class 
does fail, suggestion that it's a method ordering / test cleanup problem ... 
but if that's the case why don't see see any failures from these on master 
(from the same seed or any others?)

Example failure...

{noformat}
$ ant test  -Dtestcase=SuggesterTest -Dtests.slow=true -Dtests.asserts=true
...
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SuggesterTest 
-Dtests.method=testSuggestions -Dtests.seed=A25FEA75E3598F8C -Dtests.slow=true 
-Dtests.locale=he-IL -Dtests.timezone=Pacific/Gambier -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.20s | SuggesterTest.testSuggestions <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([A25FEA75E3598F8C:483D3802D6DD872]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:890)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:857)
   [junit4]>at 
org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions(SuggesterTest.java:70)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//lst[@name='spellcheck']/lst[@name='suggestions']/lst[@name='ac']/int[@name='numFound'][.='2']
   [junit4]>xml response was: 
   [junit4]> 
   [junit4]> 00102actuallyactually
   [junit4]> 
   [junit4]>request 
was:q=ac=/suggest=true=2=xml
{noformat}

Try the repro line...

{noformat}
ant test  -Dtestcase=SuggesterTest -Dtests.method=testSuggestions 
-Dtests.seed=A25FEA75E3598F8C -Dtests.slow=true -Dtests.locale=he-IL 
-Dtests.timezone=Pacific/Gambier -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

...

BUILD SUCCESSFUL
{noformat}

Try seed with whole test class...

{noformat}
ant test  -Dtestcase=SuggesterTest -Dtests.seed=A25FEA75E3598F8C 
-Dtests.slow=true -Dtests.locale=he-IL -Dtests.timezone=Pacific/Gambier 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

...

   [junit4] Tests with failures [seed: A25FEA75E3598F8C]:
   [junit4]   - org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions
{noformat}

But if i hammer on that test on master (same seed, randomized seed, whatever) I 
can get it to pass 30+ times w/o fail.

I'll try to bisect this (on the branch) in the AM.




> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were 
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was 
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files 
> (just in solr/core!) that define the uniqueKey field using a Trie field 
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no 
> point have we ever recommended/encouraged people to use anything other then 
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from 
> some early experiments in SOLR-10807) are used in more then half the 
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point 
> fields, we're really going to update all of these test schemas to use a 
> StrField (we can't use PointFields as the uniqueKey due to the issues noted 
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of 
> work due to many of these tests making explicit/implicit assumptions about 
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids, 
> casting stored field values returned by solrj, xpath expressions, etc...)



--
This message was sent by 

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

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

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

Commit a18a4ce2450b33b0f03dc9882557fa48040f54c8 in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a18a4ce ]

SOLR-7452: convert bucket values in FacetStream from Integer to Long for 
calcite, make bucket labels in JSON Facet API consistent for facet refinement


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[ASF subversion and git services (JIRA)]

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

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

Commit 9a0d9e83f69e9e10e18621f7bebe08db90b2f3d4 in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a0d9e8 ]

SOLR-9910: Add solr/solr.cmd parameter to append jetty parameters to the start 
script.


> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10834:


Commit d333f7b1eee10893a81532ac2f5a77a46716d90b in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d333f7b ]

Merge branch 'master' into jira/SOLR-10834

Conflicts:
solr/core/src/test/org/apache/solr/search/TestSolrQueryParser.java


> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were 
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was 
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files 
> (just in solr/core!) that define the uniqueKey field using a Trie field 
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no 
> point have we ever recommended/encouraged people to use anything other then 
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from 
> some early experiments in SOLR-10807) are used in more then half the 
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point 
> fields, we're really going to update all of these test schemas to use a 
> StrField (we can't use PointFields as the uniqueKey due to the issues noted 
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of 
> work due to many of these tests making explicit/implicit assumptions about 
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids, 
> casting stored field values returned by solrj, xpath expressions, etc...)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 061a768d873b9c7c75b635beee3effef6e66bb2f in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=061a768 ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10834:


Commit fcf98132410ed247e451bb449a8337a09bd857ce in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fcf9813 ]

Merge branch 'master' into jira/SOLR-10834


> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were 
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was 
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files 
> (just in solr/core!) that define the uniqueKey field using a Trie field 
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no 
> point have we ever recommended/encouraged people to use anything other then 
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from 
> some early experiments in SOLR-10807) are used in more then half the 
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point 
> fields, we're really going to update all of these test schemas to use a 
> StrField (we can't use PointFields as the uniqueKey due to the issues noted 
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of 
> work due to many of these tests making explicit/implicit assumptions about 
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids, 
> casting stored field values returned by solrj, xpath expressions, etc...)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 061a768d873b9c7c75b635beee3effef6e66bb2f in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=061a768 ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[ASF subversion and git services (JIRA)]

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

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

Commit d1db5f7af9edb2125583c6c63fa322380ee57cf7 in lucene-solr's branch 
refs/heads/jira/SOLR-10834 from [~mdrob]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1db5f7 ]

Revert "SOLR-8392: Remove instanceof checks on return value of SolrParam::get"

This reverts commit 94220a01e14f53e0632bfbc1678661ad9c67320a.


> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10885) NullPointerException when run collapse filter

[jefferyyuan (JIRA)]

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

jefferyyuan updated SOLR-10885:
---
Description: 
Solr collapse is a great function to collapse data that is related so we only 
show one in search result.

Just found one issue related with it - It throw NullPointerException in some 
cases.

To reproduce it, first ingest some data - AND commit multiple times.

1. When there is no data that matches the query:
http://localhost:8983/solr/thecollection/select?defType=edismax=non-existType:*={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

*2. When the data that matches the query doesn't have the collapse fields
- This is kind of a big problem as we may store different kinds of docs in one 
collection, one query may match different kinds of docs. 
If some docs (docType1) have same value for  field1, we want to collapse them, 
if other dosc(docType2) have some value for field2, do same things.*
- channel data doesn't have seriesId or programId
http://localhost:8983/solr/thecollection/select?defType=edismax=docType:channel={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

Exception from log:
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr/searchItems_shard1_replica3: 
java.lang.NullPointerException
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:617)
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:667)
at 
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:256)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1823)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1640)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:611)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:533)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)

int nextDocBase = currentContext + 1 < this.contexts.length ? 
this.contexts[(currentContext + 1)].docBase : this.maxDoc; - 617 from solr 
6.4.1 CollapsingQParserPlugin.java

Seems related with https://issues.apache.org/jira/browse/SOLR-8807
- But SOLR-8807 only fixes issue related with spell checker.

I may test this with latest solr 6.6.0 when I have time.


  was:
Solr collapse is a great function to collapse data that is related so we only 
show one in search result.

Just found one issue related with it - It throw NullPointerException in some 
cases.

To reproduce it, first ingest some data - AND commit multiple times.

1. When there is no data that matches the query:

[jira] [Created] (SOLR-10885) NullPointerException when run collapse filter

[jefferyyuan (JIRA)]

jefferyyuan created SOLR-10885:
--

 Summary: NullPointerException when run collapse filter 
 Key: SOLR-10885
 URL: https://issues.apache.org/jira/browse/SOLR-10885
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Affects Versions: 6.4.1
Reporter: jefferyyuan
Priority: Critical


Solr collapse is a great function to collapse data that is related so we only 
show one in search result.

Just found one issue related with it - It throw NullPointerException in some 
cases.

To reproduce it, first ingest some data - AND commit multiple times.

1. When there is no data that matches the query:
http://localhost:8983/solr/thecollection/select?defType=edismax=non-existType:*={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

2. When the data that matches the query doesn't have the collapse fields
- channel data doesn't have seriesId or programId
http://localhost:8983/solr/thecollection/select?defType=edismax=docType:channel={!collapse
 field=seriesId nullPolicy=expand}={!collapse field=programId 
nullPolicy=expand}

- But the problem only happens if I use both collapse fqs, if I just use one of 
them, it would be fine.

Exception from log:
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://localhost:8983/solr/searchItems_shard1_replica3: 
java.lang.NullPointerException
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:617)
at 
org.apache.solr.search.CollapsingQParserPlugin$OrdScoreCollector.finish(CollapsingQParserPlugin.java:667)
at 
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:256)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1823)
at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1640)
at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:611)
at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:533)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:166)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2299)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:296)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)

int nextDocBase = currentContext + 1 < this.contexts.length ? 
this.contexts[(currentContext + 1)].docBase : this.maxDoc; - 617 from solr 
6.4.1 CollapsingQParserPlugin.java

Seems related with https://issues.apache.org/jira/browse/SOLR-8807
- But SOLR-8807 only fixes issue related with spell checker.

I may test this with latest solr 6.6.0 when I have time.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10760 at 6/13/17 11:33 PM:
-

WIP patch.  No testing done yet, but except for the TODOs below, I think it's 
complete.

TODO:

# Does PointField need Trie* fields?
# CurrencyField uses a Trie* field, so this issue is blocked by SOLR-10503 
(I'll link it that way in a sec)
# Does BBoxField need Trie* fields?


was (Author: steve_rowe):
WIP patch.

TODO:

# Does PointField need Trie* fields?
# CurrencyField uses a Trie* field, so this issue is blocked by SOLR-10503 
(I'll link it that way in a sec)
# Does BBoxField need Trie* fields?

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10760:
--
Attachment: SOLR-10760.patch

WIP patch.

TODO:

# Does PointField need Trie* fields?
# CurrencyField uses a Trie* field, so this issue is blocked by SOLR-10503 
(I'll link it that way in a sec)
# Does BBoxField need Trie* fields?

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10880) Support replica filtering by flavour

[JIRA]

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

Jan Høydahl commented on SOLR-10880:


Can you give a real-world example for what to use this feature for? Is it 
somehow connected to the new replication modes?

> Support replica filtering by flavour
> 
>
> Key: SOLR-10880
> URL: https://issues.apache.org/jira/browse/SOLR-10880
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Domenico Fabio Marino
>Priority: Minor
> Attachments: SOLR-10880.patch
>
>
> Add a mechanism to allow queries to use only a subset of replicas(by 
> specifying the wanted replica "flavour").
> Some replicas have to be marked as "flavoured" before running the query.
> A query can specify ShardParams.SHARDS_REQUIRED_FLAVOUR to specify the 
> flavour it wants to use (Only one flavour can be specified) together with  
> ShardParams.SHARDS_CONSIDER_FLAVOURS set to true.
> The property Replica.REPLICA_FLAVOUR can be used to give a flavour to a 
> replica, the parameter it takes is a pipe ('|') separated list of flavours 
> (e.g. "chocolate|vanilla").
> The mappings between flavours is only computed when 
> ShardParams.SHARDS_CONSIDER_FLAVOURS is true, and it is computed separately 
> for each request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly

[JIRA]

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

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

Great with added flexibility. Few comments:
* Remember that there is a difference between an URP class and an (named) URP 
instance. It must be possible to instantiate the same URP several times with 
different params (e.g. {{CloneFieldUpdateProcessorFactory}}).
* Instead of the magic -UpdateProcessorFactory suffix magic, can we perhaps let 
all URPs be [named 
SPIs|https://lucene.apache.org/core/6_6_0/core/org/apache/lucene/util/NamedSPILoader.NamedSPI.html]
 like tokenfilters and codecs, and use the short-name as key, e.g. 
{{processor=htmlstripfield}}?
* Why continue inventing dot-separated config options for complex stuff like 
this when we are moving towards JSON elsewhere? 
{{==...}}
 could instead be {code}/solr/update?processor={"name": "htmlstripfield", 
"fieldName": "foo"}={...}{code} or more complex example:
 {code}/solr/update?processor={"name": "clonefield", "source": {"fieldRegex": 
".*_price$", "exclude": ["list_price", "other"]}, "dest": "all_prices"}{code}

> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>
> Now that we can 'construct' the URP chains through request parameters, we 
> should make all the URPs available automatically. The next challenge is to 
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be 
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is 
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just 
> configuration parameters e.g: 
> {{processor=HTMLStripField=}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 931 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/931/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter

Error Message:
Collection not found: withShardField

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: withShardField
at 
__randomizedtesting.SeedInfo.seed([C8BDE9FDA5121868:9DED016F09EBD798]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1401)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1094)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForImplicitRouter(CustomCollectionTest.java:141)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Updated] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10795:
--
Attachment: SOLR-10795.patch

Patch fixing up the schema11.xml conflict.

> Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
> -
>
> Key: SOLR-10795
> URL: https://issues.apache.org/jira/browse/SOLR-10795
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-10795.patch, SOLR-10795.patch
>
>
> TestMinMaxOnMultiValuedField tests Trie types for this case, should also test 
> Points



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19859 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19859/
Java: 32bit/jdk-9-ea+173 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([E49A300F99B79AAA:5E485F771A9974BF]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:890)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:883)
... 39 more


FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY 

[jira] [Updated] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10760:
--
Fix Version/s: master (7.0)

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10760:
--
Priority: Blocker  (was: Major)

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10760:
---

bq. Also, if this is a community goal for 7.0, we should probably change the 
priority here so it's marked as a blocker for 7.0.

Done.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
> Fix For: master (7.0)
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10760:
---

bq. If we are agreed that we want to remove trie types/fields from example 
schemas for 7.0, then SOLR-9989 is a blocker for this issue

I'm not sure this is true - couldn't we remove all trie fields from example 
schemas, and then advise people to add trie field declarations to their schema 
before attempting to use JSON Facets?

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[ASF subversion and git services (JIRA)]

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

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

Commit a18a4ce2450b33b0f03dc9882557fa48040f54c8 in lucene-solr's branch 
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a18a4ce ]

SOLR-7452: convert bucket values in FacetStream from Integer to Long for 
calcite, make bucket labels in JSON Facet API consistent for facet refinement


> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10864:
---

+1, the idea seems sound to me.

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored
> -
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10795:
---

+1, LGTM, thanks Tomás!

> Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
> -
>
> Key: SOLR-10795
> URL: https://issues.apache.org/jira/browse/SOLR-10795
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-10795.patch
>
>
> TestMinMaxOnMultiValuedField tests Trie types for this case, should also test 
> Points



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[ASF subversion and git services (JIRA)]

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

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

Commit d1db5f7af9edb2125583c6c63fa322380ee57cf7 in lucene-solr's branch 
refs/heads/master from [~mdrob]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d1db5f7 ]

Revert "SOLR-8392: Remove instanceof checks on return value of SolrParam::get"

This reverts commit 94220a01e14f53e0632bfbc1678661ad9c67320a.


> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8392:
-

It looks like we use raw types somewhere to shove a {{String[]}} value into a 
map that we later claim is {{String, String}}. I'm not able to actually find 
the place where it happens to fix that, so I'll revert to make tests happier 
and come back to it later.

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4071 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4071/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":500, "QTime":0},   "error":{ 
"trace":"java.lang.ClassCastException\n", "code":500}},  from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":500,
"QTime":0},
  "error":{
"trace":"java.lang.ClassCastException\n",
"code":500}},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([799BD6302803D42B:EB7EE397F9050C6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestSolrConfigHandler.testReqParams(TestSolrConfigHandler.java:665)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1324 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1324/

9 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: 
{"error":{ "msg":"[Ljava.lang.String; cannot be cast to java.lang.String",  
   "trace":"java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to 
java.lang.String\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\n\tat
 org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:241)\n\tat 
org.apache.solr.api.V2HttpCall.execute(V2HttpCall.java:318)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\n\tat
 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:462)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
 java.lang.Thread.run(Thread.java:748)\n", "code":500}},  from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {"error":{
"msg":"[Ljava.lang.String; cannot be cast to java.lang.String",
"trace":"java.lang.ClassCastException: [Ljava.lang.String; cannot be cast 
to java.lang.String\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\n\tat
 org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:241)\n\tat 
org.apache.solr.api.V2HttpCall.execute(V2HttpCall.java:318)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)\n\tat
 

[jira] [Updated] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10883:
--
Attachment: SOLR-10883.patch

This iteration of the patch builds on the previous one to include {{.adoc}} 
file checks in the top-level {{ant validate}} build step (specifically 
{{-validate-source-patterns}}).  On a checkout without the {{.adoc}} file 
escaping in this patch, {{ant validate}} found all of the problems addressed in 
this patch, and on a checkout with this full patch, no problems are found.

The patch also substitutes tabs->spaces in an {{.adoc}} file, found by {{ant 
validate}}.

I think it's ready to go.

> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch, SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10866) Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10866:

Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-9565

> Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> 
>
> Key: SOLR-10866
> URL: https://issues.apache.org/jira/browse/SOLR-10866
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10866.patch, SOLR-10866.patch, SOLR-10866.patch, 
> SOLR-10866.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> TimestampUpdateProcessorFactory will be able to execute by sample curl like 
> below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=Timestamp=timestamp_tdt=true
>  --data-binary { "id" : "1" , "title_s" : "titleA" }
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10867) Make ClassificationUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10867:

Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-9565

> Make ClassificationUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> -
>
> Key: SOLR-10867
> URL: https://issues.apache.org/jira/browse/SOLR-10867
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: error_test, SOLR-10867.patch, SOLR-10867.patch, 
> SOLR-10867.patch, SOLR-10867.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> ClassificationUpdateProcessorFactory will be able to execute by sample curl 
> like below:
> {code}
> curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=Classification=url_s=training=true
>  --data-binary { "id" : "1" , "url_s" : "http://www.example.com/subroot; }
> {code}
> All the param(s) for this URP available can be passed as request handler 
> param(s).
> Configuration for ClassificationUpdateProcessorFactory in solrconfig.xml is 
> optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10869) Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10869:

Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-9565

> Make StatelessScriptUpdateProcessorFactory as Runtime URP; take params(s) 
> with request
> --
>
> Key: SOLR-10869
> URL: https://issues.apache.org/jira/browse/SOLR-10869
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> StatelessScriptUpdateProcessorFactory will be able to execute by sample curl 
> like below:
> {code}
> curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=StatelessScript=1.js=2.js=3.js=keyA:valueA=keyB:valueB=keyC:valueC=
>  rhino=true --data-binary { "id" : "1" , "title_s" : "title_random" }
> {code}
> All the param(s) for this URP available can be passed as request handler 
> param(s). The scripts will be executed in the order the parameters are 
> received.
> Configuration for StatelessScriptUpdateProcessorFactory in solrconfig.xml is 
> optional. Backcompat is intact.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10858) Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10858:

Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-9565

> Make UUIDUpdateProcessorFactory as Runtime URP; take params(s) with request
> ---
>
> Key: SOLR-10858
> URL: https://issues.apache.org/jira/browse/SOLR-10858
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch, 
> SOLR-10858.patch, SOLR-10858.patch, SOLR-10858.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> UUIDUpdateProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=true 
> --data-binary {"id":"1","title": "titleA"}
> {code}
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=UUID=id=true
>  --data-binary {"id":"1","title": "titleA"}
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10859) Make URLClassifyProcessor as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10859:

Issue Type: Sub-task  (was: Improvement)
Parent: SOLR-9565

> Make URLClassifyProcessor as Runtime URP; take params(s) with request
> -
>
> Key: SOLR-10859
> URL: https://issues.apache.org/jira/browse/SOLR-10859
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10859.patch, SOLR-10859.patch, SOLR-10859.patch, 
> SOLR-10859.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> URLClassifyProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=URLClassify=fieldA=fieldB=fieldC=fieldD=fieldE=fieldF=fieldG=true
>  --data-binary {"id" : "1", "fieldA" : "valueA"}
> {code}
> Configuration for URLClassifyProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[ASF subversion and git services (JIRA)]

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

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

Commit 8730f2f375d95851ad957bc88c45936a65428dc9 in lucene-solr's branch 
refs/heads/branch_6x from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8730f2f ]

SOLR-9910: Add solr/solr.cmd parameter to append jetty parameters to the start 
script.


> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-9910.
---
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-9910) Allow setting of additional jetty options in bin/solr and bin/solr.cmd

[ASF subversion and git services (JIRA)]

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

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

Commit 9a0d9e83f69e9e10e18621f7bebe08db90b2f3d4 in lucene-solr's branch 
refs/heads/master from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9a0d9e8 ]

SOLR-9910: Add solr/solr.cmd parameter to append jetty parameters to the start 
script.


> Allow setting of additional jetty options in bin/solr and bin/solr.cmd
> --
>
> Key: SOLR-9910
> URL: https://issues.apache.org/jira/browse/SOLR-9910
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-9910.patch, SOLR-9910.patch
>
>
> Command line tools allow the option {{-a}} to add JVM options to start 
> command. Proposing to add {{-j}} option to add additional config for jetty 
> (the part after {{start.jar}}).
> Motivation: jetty can be configured with start.ini in server directory. 
> Running multiple Solr instances, however, requires the configuration per 
> instance that cannot share the start.ini with other instances.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10866) Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10866:

Attachment: SOLR-10866.patch

> Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> 
>
> Key: SOLR-10866
> URL: https://issues.apache.org/jira/browse/SOLR-10866
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10866.patch, SOLR-10866.patch, SOLR-10866.patch, 
> SOLR-10866.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> TimestampUpdateProcessorFactory will be able to execute by sample curl like 
> below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=Timestamp=timestamp_tdt=true
>  --data-binary { "id" : "1" , "title_s" : "titleA" }
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10830) Solr needs to enforce that _root_ field has the same fieldType as the uniqueKey field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10830:


Commit 5835dcb3476b7355130e2eea2c485898232c56d0 in lucene-solr's branch 
refs/heads/branch_6x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5835dcb ]

SOLR-10833: Better exception handling of queries in numeric fields

Cherry picked 6396cb759f8c799f381b0730636fa412761030ce from master and manually 
removed code related to SOLR-10830


> Solr needs to enforce that _root_ field has the same fieldType as the 
> uniqueKey field
> -
>
> Key: SOLR-10830
> URL: https://issues.apache.org/jira/browse/SOLR-10830
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10830.patch, SOLR-10830.patch
>
>
> it's pretty important for correct childDocument behavior that the {{\_root_}} 
> field have the same {{}} as the uniqueKey field -- but nothing 
> seems to enforce that.
> (I realized this while working on SOLR-10807 where i was forcing all fields 
> to be Points based except for the uniqueKey field and got some weird errors 
> in PeerSync that only related to replacing child documents -- because the 
> {{schema.xml}} has a {{TrieIntField}} based "id" field, but {{\_root_}} was 
> using {{IntPointField}} -- but the same problem could affect any schema if 
> folks change the {{id}} from string to long, or int to string, and don't make 
> the corrisponding change to the definition of {{\_root_}})



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 5e438bbe2783f8fc16da41d660fde7c7d65d7e3e in lucene-solr's branch 
refs/heads/branch_6x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e438bb ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 5e438bbe2783f8fc16da41d660fde7c7d65d7e3e in lucene-solr's branch 
refs/heads/branch_6x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e438bb ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 5835dcb3476b7355130e2eea2c485898232c56d0 in lucene-solr's branch 
refs/heads/branch_6x from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5835dcb ]

SOLR-10833: Better exception handling of queries in numeric fields

Cherry picked 6396cb759f8c799f381b0730636fa412761030ce from master and manually 
removed code related to SOLR-10830


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10859) Make URLClassifyProcessor as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10859:

Attachment: SOLR-10859.patch

> Make URLClassifyProcessor as Runtime URP; take params(s) with request
> -
>
> Key: SOLR-10859
> URL: https://issues.apache.org/jira/browse/SOLR-10859
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10859.patch, SOLR-10859.patch, SOLR-10859.patch, 
> SOLR-10859.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> URLClassifyProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=URLClassify=fieldA=fieldB=fieldC=fieldD=fieldE=fieldF=fieldG=true
>  --data-binary {"id" : "1", "fieldA" : "valueA"}
> {code}
> Configuration for URLClassifyProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10859) Make URLClassifyProcessor as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10859:
-

In order to make this work, we have to rename the processor factory from: 
{{URLClassifyProcessorFactory}} to {{URLClassifyUpdateProcessorFactory}}.

> Make URLClassifyProcessor as Runtime URP; take params(s) with request
> -
>
> Key: SOLR-10859
> URL: https://issues.apache.org/jira/browse/SOLR-10859
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10859.patch, SOLR-10859.patch, SOLR-10859.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> URLClassifyProcessorFactory will be able to execute by sample curl like below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=URLClassify=fieldA=fieldB=fieldC=fieldD=fieldE=fieldF=fieldG=true
>  --data-binary {"id" : "1", "fieldA" : "valueA"}
> {code}
> Configuration for URLClassifyProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3739 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3739/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([4CE0E3C45C66755E:C7C730151D60DEDA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7452:


bq. Basically Calcite is expecting a long in this scenario because we map all 
integer types to longs in the SolrSchema.java class.
Ah, that's where that mapping is!

bq. I think the best way to deal with this is to have the FacetStream convert 
all Integers buckets to Longs.
Here's a quick patch that seems to get things working:
{code}
diff --git 
a/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java 
b/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
index c5bd56bcb9..fb53e8464b 100644
--- 
a/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
+++ 
b/solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/FacetStream.java
@@ -477,6 +477,9 @@ public class FacetStream extends TupleStream implements 
Expressible  {
 for(int b=0; b json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10531) JMX cache beans names / properties changed in 6.4

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-10531:
-

Finally got some time to open a case with New Relic. That is here:

https://discuss.newrelic.com/t/solr-cache-monitoring-not-working-with-solr-6-4-or-later/49658

Let's reopen this Jira so New Relic can help troubleshoot.

> JMX cache beans names / properties changed in 6.4
> -
>
> Key: SOLR-10531
> URL: https://issues.apache.org/jira/browse/SOLR-10531
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 6.4, 6.5
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: branch_6_3.png, branch_6x.png
>
>
> As reported by [~wunder]:
> {quote}
> New Relic displays the cache hit rate for each collection, showing the query 
> result cache, filter cache, and document cache.
> With 6.5.0, that page shows this message:
> New Relic recorded no Solr caches data for this application in the last 
> 24 hours
> If you think there should be Solr data here, first check to see that JMX 
> is enabled for your application server. If enabled, then please contact 
> support.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048226#comment-16048226
 ] 

Andi Vajda commented on PYLUCENE-37:


I have gotten to the same point as you - the Python side needs to be reworked 
to accomodate
multiple parents, the current static initializations don't work with multiple 
base classes.
It's work in progress...




> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
> Attachments: jcc.multiple.inheritance.patch, Test.zip
>
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_131) - Build # 6645 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6645/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi

Error Message:
Error from server at https://127.0.0.1:61572/solr: Expected mime type 
application/octet-stream but got text/html.Error 
400HTTP ERROR: 400 Problem accessing 
/solr/v2/c. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
 Illegal char ? at index 53: 
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core estJ1 
empsolr.handler.V2ApiIntegrationTest_C6037F055061104-001 
empDir-002,code=400} http://eclipse.org/jetty;>Powered 
by Jetty:// 9.3.14.v20161028   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:61572/solr: Expected mime type 
application/octet-stream but got text/html. 


Error 400 


HTTP ERROR: 400
Problem accessing /solr/v2/c. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
 Illegal char ? at index 53: 
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core   estJ1 
  empsolr.handler.V2ApiIntegrationTest_C6037F055061104-001
empDir-002,code=400}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([C6037F055061104:D0FED071ED1F75BA]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:219)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1130)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi(V2ApiIntegrationTest.java:99)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-5611) When documents are uniformly distributed over shards, enable returning approximated results in distributed query

[Justin Sarma (JIRA)]

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

Justin Sarma edited comment on SOLR-5611 at 6/13/17 6:39 PM:
-

I've created an open source tool which you can use to approximate appropriate 
shards.rows values through a Monte Carlo simulation. You can specify what 
percentage of the time you want the results to be 100% accurate, for different 
search depths, and different shard counts. We used this tool at Shutterstock to 
improve Solr latency and reduce heap pressure:

https://github.com/jsarma/solr-shards-rows-optimizer

There's also a blog entry here which explains it in more detail, along with 
some perf tests of the results:

https://tech.shutterstock.com/2017/05/09/efficiently-handling-deep-pagination-in-a-distributed-search-engine/


was (Author: jsarma):
I've created a tool which you can use to approximate appropriate shards.rows 
values through a Monte Carlo simulation. You can specify what percentage of the 
time you want the results to be 100% accurate, for different search depths, and 
different shard counts. We used this tool at Shutterstock to improve Solr 
latency and reduce heap pressure:

https://github.com/jsarma/solr-shards-rows-optimizer

There's also a blog entry here which explains it in more detail, along with 
some perf tests of the results:

https://tech.shutterstock.com/2017/05/09/efficiently-handling-deep-pagination-in-a-distributed-search-engine/

> When documents are uniformly distributed over shards, enable returning 
> approximated results in distributed query
> 
>
> Key: SOLR-5611
> URL: https://issues.apache.org/jira/browse/SOLR-5611
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Isaac Hebsh
>Priority: Minor
>  Labels: distributed_search, shard, solrcloud
> Fix For: 4.9, 6.0
>
> Attachments: lec5-distributedIndexing.pdf
>
>
> Query with rows=1000, which sent to a collection of 100 shards (shard key 
> behaviour is default - based on hash of the unique key), will generate 100 
> requests of rows=1000, on each shard.
> This results to total number of rows*numShards unique keys to be retrieved. 
> This behaviour is getting worst as numShards grows.
> If the documents are uniformly distributed over the shards, the expected 
> number of document should be ~ rows/numShards. Obviously, there might be 
> extreme cases, when all of the top X documents are in a specific shard.
> I suggest adding an optional parameter, say approxResults=true, which decides 
> whether we should limit the rows in the shard requests to rows/numShardsor 
> not. Moreover, we can add a numeric parameter which increases the limit, to 
> be more accurate.
> For example, the query {{approxResults=true=1.5}} will 
> retrieve 1.5*rows/numShards from each shard. In the case of 100 shards and 
> rows=1000, each shard will return 15 documents.
> Furthermore, this can reduce the problem of deep paging, because the same 
> thing can be applied there. when requested start=10, Solr creating shard 
> request with start=0 and rows=START+ROWS. In the approximated approach, start 
> parameter (in the shard requests) can be set to 10/numShards. The idea of 
> the approxResults.factor creates some difficulties here, though.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Andi Vajda]

I have gotten to the same point as you - the Python side needs to be reworked 
to accomodate
multiple parents, the current static initializations don't work with multiple 
base classes.
It's work in progress...

> On Jun 13, 2017, at 18:31, Jesper Mattsson (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048084#comment-16048084
>  ] 
> 
> Jesper Mattsson commented on PYLUCENE-37:
> -
> 
> I am currently unable to work any more on this beyond the patch that I sent.
> 
>> Extended interfaces beyond first are ignored
>> 
>> 
>>Key: PYLUCENE-37
>>URL: https://issues.apache.org/jira/browse/PYLUCENE-37
>>Project: PyLucene
>> Issue Type: Bug
>>   Reporter: Jesper Mattsson
>>Attachments: jcc.multiple.inheritance.patch, Test.zip
>> 
>> 
>> When generating wrapper for a Java interface that extends more than one 
>> other interface, then only the first extended interface is used when 
>> generating the C++ class.
>> In cpp.header(), the code snippets:
>> {code}
>>if cls.isInterface():
>>if interfaces:
>>superCls = interfaces.pop(0)
>> {code}
>> and:
>> {code}
>>line(out, indent, 'class %s%s : public %s {',
>> _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
>> {code}
>> are likely responsible.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)

[jira] [Comment Edited] (SOLR-5611) When documents are uniformly distributed over shards, enable returning approximated results in distributed query

[Justin Sarma (JIRA)]

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

Justin Sarma edited comment on SOLR-5611 at 6/13/17 6:38 PM:
-

I've created a tool which you can use to approximate appropriate shards.rows 
values through a Monte Carlo simulation. You can specify what percentage of the 
time you want the results to be 100% accurate, for different search depths, and 
different shard counts. We used this tool at Shutterstock to improve Solr 
latency and reduce heap pressure:

https://github.com/jsarma/solr-shards-rows-optimizer

There's also a blog entry here which explains it in more detail, along with 
some perf tests of the results:

https://tech.shutterstock.com/2017/05/09/efficiently-handling-deep-pagination-in-a-distributed-search-engine/


was (Author: jsarma):
I've created a tool which you can use to approximate appropriate shards.rows 
values through repeated event simulation. We used this tool at Shutterstock to 
improve Solr latency and reduce heap pressure:

https://github.com/jsarma/solr-shards-rows-optimizer

There's also a blog entry here which explains it in more detail, along with 
some perf tests of the results:

https://tech.shutterstock.com/2017/05/09/efficiently-handling-deep-pagination-in-a-distributed-search-engine/

> When documents are uniformly distributed over shards, enable returning 
> approximated results in distributed query
> 
>
> Key: SOLR-5611
> URL: https://issues.apache.org/jira/browse/SOLR-5611
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Isaac Hebsh
>Priority: Minor
>  Labels: distributed_search, shard, solrcloud
> Fix For: 4.9, 6.0
>
> Attachments: lec5-distributedIndexing.pdf
>
>
> Query with rows=1000, which sent to a collection of 100 shards (shard key 
> behaviour is default - based on hash of the unique key), will generate 100 
> requests of rows=1000, on each shard.
> This results to total number of rows*numShards unique keys to be retrieved. 
> This behaviour is getting worst as numShards grows.
> If the documents are uniformly distributed over the shards, the expected 
> number of document should be ~ rows/numShards. Obviously, there might be 
> extreme cases, when all of the top X documents are in a specific shard.
> I suggest adding an optional parameter, say approxResults=true, which decides 
> whether we should limit the rows in the shard requests to rows/numShardsor 
> not. Moreover, we can add a numeric parameter which increases the limit, to 
> be more accurate.
> For example, the query {{approxResults=true=1.5}} will 
> retrieve 1.5*rows/numShards from each shard. In the case of 100 shards and 
> rows=1000, each shard will return 15 documents.
> Furthermore, this can reduce the problem of deep paging, because the same 
> thing can be applied there. when requested start=10, Solr creating shard 
> request with start=0 and rows=START+ROWS. In the approximated approach, start 
> parameter (in the shard requests) can be set to 10/numShards. The idea of 
> the approxResults.factor creates some difficulties here, though.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-5611) When documents are uniformly distributed over shards, enable returning approximated results in distributed query

[Justin Sarma (JIRA)]

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

Justin Sarma commented on SOLR-5611:


I've created a tool which you can use to approximate appropriate shards.rows 
values through repeated event simulation. We used this tool at Shutterstock to 
improve Solr latency and reduce heap pressure:

https://github.com/jsarma/solr-shards-rows-optimizer

There's also a blog entry here which explains it in more detail, along with 
some perf tests of the results:

https://tech.shutterstock.com/2017/05/09/efficiently-handling-deep-pagination-in-a-distributed-search-engine/

> When documents are uniformly distributed over shards, enable returning 
> approximated results in distributed query
> 
>
> Key: SOLR-5611
> URL: https://issues.apache.org/jira/browse/SOLR-5611
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Isaac Hebsh
>Priority: Minor
>  Labels: distributed_search, shard, solrcloud
> Fix For: 4.9, 6.0
>
> Attachments: lec5-distributedIndexing.pdf
>
>
> Query with rows=1000, which sent to a collection of 100 shards (shard key 
> behaviour is default - based on hash of the unique key), will generate 100 
> requests of rows=1000, on each shard.
> This results to total number of rows*numShards unique keys to be retrieved. 
> This behaviour is getting worst as numShards grows.
> If the documents are uniformly distributed over the shards, the expected 
> number of document should be ~ rows/numShards. Obviously, there might be 
> extreme cases, when all of the top X documents are in a specific shard.
> I suggest adding an optional parameter, say approxResults=true, which decides 
> whether we should limit the rows in the shard requests to rows/numShardsor 
> not. Moreover, we can add a numeric parameter which increases the limit, to 
> be more accurate.
> For example, the query {{approxResults=true=1.5}} will 
> retrieve 1.5*rows/numShards from each shard. In the case of 100 shards and 
> rows=1000, each shard will return 15 documents.
> Furthermore, this can reduce the problem of deep paging, because the same 
> thing can be applied there. when requested start=10, Solr creating shard 
> request with start=0 and rows=START+ROWS. In the approximated approach, start 
> parameter (in the shard requests) can be set to 10/numShards. The idea of 
> the approxResults.factor creates some difficulties here, though.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_131) - Build # 19858 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19858/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:480)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:328) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$12(ReplicationHandler.java:1183)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:490)  
at org.apache.solr.core.SolrCore.(SolrCore.java:942)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:855)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:979)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:914)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 061a768d873b9c7c75b635beee3effef6e66bb2f in lucene-solr's branch 
refs/heads/master from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=061a768 ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10833:


Commit 061a768d873b9c7c75b635beee3effef6e66bb2f in lucene-solr's branch 
refs/heads/master from [~tomasflobbe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=061a768 ]

SOLR-10833: Updated CHANGES to include SOLR-10833


> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10833:
-

NOTE for posterity:

after reviewing tomas's patch, i inadvertantly committed it to master in 
6396cb759f8c799f381b0730636fa412761030ce as part of SOLR-10830 (and issue i 
don't plan on backporting)

In conversation with tomas on irc about whether or not to revert, he said not 
to worry about it and he'll take over and do a partial backport.

> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10879) DELETEREPLICA and DELETENODE commands should prevent data loss when replicationFactor==1

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10879:
--

OK, I see that this validation is only done when you delete replicas by count, 
not if you delete replicas by name (which is what {{DeleteNodeCmd}} does)

> DELETEREPLICA and DELETENODE commands should prevent data loss when 
> replicationFactor==1
> 
>
> Key: SOLR-10879
> URL: https://issues.apache.org/jira/browse/SOLR-10879
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, master (7.0), 6.7
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>
> There should be some level of protection against inadvertent data loss when 
> issuing these commands when replicationFactor is 1 - deleting a node or a 
> replica in this case will be equivalent to completely deleting some shards.
> This is further complicated by the replica types - there could be still 
> remaining replicas after the operation, but if they are all of PULL type then 
> none of them will ever become a shard leader.
> We could require that  the command should fail in such case unless a boolean 
> option "force==true" is specified.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10830) Solr needs to enforce that _root_ field has the same fieldType as the uniqueKey field

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10830.
-
   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: master (7.0)

NOTE: even though this is a "bug fix" i've made the choice to only commit it to 
master and not backport...

* if folks are using child docs with 6.x and their schema has a mismatch they 
have probably already noticed 
* if folks are *not* using child docs with 6.x, they may still have a schema 
missmatch they don't care about (ie: at some point htye changed the "id" 
definition from the sample configs but didn't change {{\_root\_}}) so i don't 
wnat to suddenly break things for them in a bug fix release.

I am -0 on anyone else making the choose to backport ... but I don't plan on 
doing it.

> Solr needs to enforce that _root_ field has the same fieldType as the 
> uniqueKey field
> -
>
> Key: SOLR-10830
> URL: https://issues.apache.org/jira/browse/SOLR-10830
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10830.patch, SOLR-10830.patch
>
>
> it's pretty important for correct childDocument behavior that the {{\_root_}} 
> field have the same {{}} as the uniqueKey field -- but nothing 
> seems to enforce that.
> (I realized this while working on SOLR-10807 where i was forcing all fields 
> to be Points based except for the uniqueKey field and got some weird errors 
> in PeerSync that only related to replacing child documents -- because the 
> {{schema.xml}} has a {{TrieIntField}} based "id" field, but {{\_root_}} was 
> using {{IntPointField}} -- but the same problem could affect any schema if 
> folks change the {{id}} from string to long, or int to string, and don't make 
> the corrisponding change to the definition of {{\_root_}})



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10830) Solr needs to enforce that _root_ field has the same fieldType as the uniqueKey field

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10830:


Commit 6396cb759f8c799f381b0730636fa412761030ce in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6396cb7 ]

SOLR-10830: Solr now correctly enforces that the '_root_' field has the same 
fieldType as the uniqueKey field


> Solr needs to enforce that _root_ field has the same fieldType as the 
> uniqueKey field
> -
>
> Key: SOLR-10830
> URL: https://issues.apache.org/jira/browse/SOLR-10830
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10830.patch, SOLR-10830.patch
>
>
> it's pretty important for correct childDocument behavior that the {{\_root_}} 
> field have the same {{}} as the uniqueKey field -- but nothing 
> seems to enforce that.
> (I realized this while working on SOLR-10807 where i was forcing all fields 
> to be Points based except for the uniqueKey field and got some weird errors 
> in PeerSync that only related to replacing child documents -- because the 
> {{schema.xml}} has a {{TrieIntField}} based "id" field, but {{\_root_}} was 
> using {{IntPointField}} -- but the same problem could affect any schema if 
> folks change the {{id}} from string to long, or int to string, and don't make 
> the corrisponding change to the definition of {{\_root_}})



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10879) DELETEREPLICA and DELETENODE commands should prevent data loss when replicationFactor==1

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10879:
--

Isn't this what {{DeleteReplicaCmd#validateReplicaAvailability(...)}} is doing?

{code:java}
  if (allReplicasForShard.size() == 1) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "There is 
only one replica available in shard/collection: " +
shard + "/" + collectionName + ". Cannot delete that.");
  }
{code}

> DELETEREPLICA and DELETENODE commands should prevent data loss when 
> replicationFactor==1
> 
>
> Key: SOLR-10879
> URL: https://issues.apache.org/jira/browse/SOLR-10879
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, master (7.0), 6.7
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>
> There should be some level of protection against inadvertent data loss when 
> issuing these commands when replicationFactor is 1 - deleting a node or a 
> replica in this case will be equivalent to completely deleting some shards.
> This is further complicated by the replica types - there could be still 
> remaining replicas after the operation, but if they are all of PULL type then 
> none of them will ever become a shard leader.
> We could require that  the command should fail in such case unless a boolean 
> option "force==true" is specified.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10565) SolrJmxReporterTest.testEnabled() failure

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10565 at 6/13/17 5:10 PM:


Another reproducing branch_6x failure from my Jenkins:

{noformat}
Checking out Revision 5191462046c3db29acf6bb814d12577dd66d250f 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrJmxReporterTest 
-Dtests.method=testEnabled -Dtests.seed=B6C47FEA3B704891 -Dtests.slow=true 
-Dtests.locale=sl-SI -Dtests.timezone=America/Winnipeg -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.98s J8  | SolrJmxReporterTest.testEnabled <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<98> but 
was:<100>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B6C47FEA3B704891:8105DE347AD538E1]:0)
   [junit4]>at 
org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=false,coord=crazy): {}, locale=sl-SI, 
timezone=America/Winnipeg
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=346467904,total=530579456
{noformat}


was (Author: steve_rowe):
Another reproducing branch_6x from my Jenkins:

{noformat}
Checking out Revision 5191462046c3db29acf6bb814d12577dd66d250f 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrJmxReporterTest 
-Dtests.method=testEnabled -Dtests.seed=B6C47FEA3B704891 -Dtests.slow=true 
-Dtests.locale=sl-SI -Dtests.timezone=America/Winnipeg -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.98s J8  | SolrJmxReporterTest.testEnabled <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<98> but 
was:<100>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B6C47FEA3B704891:8105DE347AD538E1]:0)
   [junit4]>at 
org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=false,coord=crazy): {}, locale=sl-SI, 
timezone=America/Winnipeg
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=346467904,total=530579456
{noformat}

> SolrJmxReporterTest.testEnabled() failure
> -
>
> Key: SOLR-10565
> URL: https://issues.apache.org/jira/browse/SOLR-10565
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
>
> My Jenkins found a reproducing branch_6x seed:
> {noformat}
> Checking out Revision ea3f9bb87d1e6c3cf812122c3a6f9160a8b49a19 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> 86968 INFO  
> (TEST-SolrJmxReporterTest.testEnabled-seed#[79BD33EADDE24AC0]) [
> x:collection1] o.a.s.SolrTestCaseJ4 ###Ending testEnabled
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testEnabled 
> -Dtests.seed=79BD33EADDE24AC0 -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.82s J6  | SolrJmxReporterTest.testEnabled <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([79BD33EADDE24AC0:4E7C92349C473AB0]:0)
>[junit4]>  at 
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
> docValues:{}, maxPointsInLeafNode=1415, maxMBSortInHeap=6.528209197753226, 
> sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=cs, 
> timezone=Europe/Amsterdam
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=154074736,total=443023360
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10704:


Commit 9612e318568e48ea187700accc1f6e88b1afea43 in lucene-solr's branch 
refs/heads/branch_6x from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9612e31 ]

SOLR-10704 Update the ref guide.


> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10565) SolrJmxReporterTest.testEnabled() failure

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10565:
---

Another reproducing branch_6x from my Jenkins:

{noformat}
Checking out Revision 5191462046c3db29acf6bb814d12577dd66d250f 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrJmxReporterTest 
-Dtests.method=testEnabled -Dtests.seed=B6C47FEA3B704891 -Dtests.slow=true 
-Dtests.locale=sl-SI -Dtests.timezone=America/Winnipeg -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.98s J8  | SolrJmxReporterTest.testEnabled <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<98> but 
was:<100>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([B6C47FEA3B704891:8105DE347AD538E1]:0)
   [junit4]>at 
org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=false,coord=crazy): {}, locale=sl-SI, 
timezone=America/Winnipeg
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=346467904,total=530579456
{noformat}

> SolrJmxReporterTest.testEnabled() failure
> -
>
> Key: SOLR-10565
> URL: https://issues.apache.org/jira/browse/SOLR-10565
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Steve Rowe
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
>
> My Jenkins found a reproducing branch_6x seed:
> {noformat}
> Checking out Revision ea3f9bb87d1e6c3cf812122c3a6f9160a8b49a19 
> (refs/remotes/origin/branch_6x)
> [...]
>[junit4]   2> 86968 INFO  
> (TEST-SolrJmxReporterTest.testEnabled-seed#[79BD33EADDE24AC0]) [
> x:collection1] o.a.s.SolrTestCaseJ4 ###Ending testEnabled
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=SolrJmxReporterTest -Dtests.method=testEnabled 
> -Dtests.seed=79BD33EADDE24AC0 -Dtests.slow=true -Dtests.locale=cs 
> -Dtests.timezone=Europe/Amsterdam -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.82s J6  | SolrJmxReporterTest.testEnabled <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([79BD33EADDE24AC0:4E7C92349C473AB0]:0)
>[junit4]>  at 
> org.apache.solr.metrics.reporters.SolrJmxReporterTest.testEnabled(SolrJmxReporterTest.java:197)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene62): {}, 
> docValues:{}, maxPointsInLeafNode=1415, maxMBSortInHeap=6.528209197753226, 
> sim=RandomSimilarity(queryNorm=false,coord=yes): {}, locale=cs, 
> timezone=Europe/Amsterdam
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=154074736,total=443023360
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10704:


Commit cdccbfb92f30cc70a3fee4c1b3655b1aaf1acb7a in lucene-solr's branch 
refs/heads/master from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cdccbfb ]

SOLR-10704 Update the ref guide.


> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (PYLUCENE-37) Extended interfaces beyond first are ignored

[Jesper Mattsson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PYLUCENE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048084#comment-16048084
 ] 

Jesper Mattsson commented on PYLUCENE-37:
-

I am currently unable to work any more on this beyond the patch that I sent.

> Extended interfaces beyond first are ignored
> 
>
> Key: PYLUCENE-37
> URL: https://issues.apache.org/jira/browse/PYLUCENE-37
> Project: PyLucene
>  Issue Type: Bug
>Reporter: Jesper Mattsson
> Attachments: jcc.multiple.inheritance.patch, Test.zip
>
>
> When generating wrapper for a Java interface that extends more than one other 
> interface, then only the first extended interface is used when generating the 
> C++ class.
> In cpp.header(), the code snippets:
> {code}
> if cls.isInterface():
> if interfaces:
> superCls = interfaces.pop(0)
> {code}
> and:
> {code}
> line(out, indent, 'class %s%s : public %s {',
>  _dll_export, cppname(names[-1]), absname(cppnames(superNames)))
> {code}
> are likely responsible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19857 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19857/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: 
{"error":{ "msg":"[Ljava.lang.String; cannot be cast to java.lang.String",  
   "trace":"java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to 
java.lang.String\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\n\tat
 org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:241)\n\tat 
org.apache.solr.api.V2HttpCall.execute(V2HttpCall.java:318)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:528)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:374)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:318)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\n\tat
 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:462)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)\n\tat 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)\n\tat
 org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)\n\tat 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
 java.lang.Thread.run(Thread.java:748)\n", "code":500}},  from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {"error":{
"msg":"[Ljava.lang.String; cannot be cast to java.lang.String",
"trace":"java.lang.ClassCastException: [Ljava.lang.String; cannot be cast 
to java.lang.String\n\tat 
org.apache.solr.common.params.MapSolrParams.getParams(MapSolrParams.java:39)\n\tat
 
org.apache.solr.common.params.DefaultSolrParams.getParams(DefaultSolrParams.java:44)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:103)\n\tat
 
org.apache.solr.common.params.MultiMapSolrParams.asMultiMap(MultiMapSolrParams.java:81)\n\tat
 
org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:119)\n\tat
 
org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:177)\n\tat
 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:175)\n\tat
 org.apache.solr.api.ApiBag$ReqHandlerToApi.call(ApiBag.java:241)\n\tat 

Re: VOTE: Apache Solr Reference Guide for 6.6 (RC1)

[Steve Rowe]

+1

I filed an issue for invisible arrow characters in the PDF: 
.  I don’t think a respin is 
required.  I plan on looking into whether we can automatically flag this 
problem in the future via precommit check(s).

Another no-respin-indicated change I committed: some `monospace` syntax 
cleanup. There were some conflicts with `something`’s , where Asciidoc renders 
the "`’" as a curly apostrophe, and the monospace region extends beyond where 
it should to the next encountered backtick on the line.  Also usages of /“`/ 
and /‘`/ were not rendering as expected (non-monospace quotes around monospaced 
text), since Asciidoc interprets those as curly quotes; as a result, monospace 
wasn’t applied.  (I committed this change to branch_6_6 in case there is a 
respin.)

--
Steve
www.lucidworks.com

> On Jun 9, 2017, at 3:51 PM, Cassandra Targett  wrote:
> 
> Please vote for the release of the Apache Solr Reference Guide for 6.6.
> 
> The artifacts can be downloaded from
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.6-RC1/
> 
> $ cat apache-solr-ref-guide-6.6.pdf.sha1
> 1463d3297f9c5eeef6651bd6989f4c5a8ece5a3e  apache-solr-ref-guide-6.6.pdf
> 
> The HTML files have also been updated: 
> https://lucene.apache.org/solr/guide/6_6/
> 
> Steve Rowe gave me several comments to improve the PDF, so there are
> several things different about this RC (besides several typos and
> formatting issues he also found):
> 
> * replaced small sun logo on title page with full Solr logo
> * added some additional metadata to the title page for authorship and
> publication date
> * cut back # of items listed in Table of Contents, saving about 10 or so pages
> * increased monospace font size so it's more the same size as "normal" text
> 
> Here's my +1.
> 
> Cassandra
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (SOLR-10874) FloatPayloadValueSource throws assertion error if debug=true

[Michael Kosten (JIRA)]

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

Michael Kosten commented on SOLR-10874:
---

It's an assertion error in AssertingLeafReader, so if the code performs 
correctly if assertions are disabled, then perhaps the assertion is unnecessary?

If you skip that assertion, then it fails an assertion in 
Lucene50PostingsReader. The crux is that the postings reader doesn't like 
nextPosition being called for a document more than the term frequency, which is 
what happens if floatVal in FloatPayloadValueSource is called sequentially for 
the same document.

Maybe this scenario only happens in very specific circumstances?



> FloatPayloadValueSource throws assertion error if debug=true
> 
>
> Key: SOLR-10874
> URL: https://issues.apache.org/jira/browse/SOLR-10874
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Michael Kosten
>Priority: Minor
> Attachments: SOLR-10874.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Using the new payload function will fail with an assertion error if the debug 
> parameter is included in the query. This is caused by the floatValue method 
> in FloatPayloadValueSource being called for the same doc id twice in a row.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10833) Numeric FooPointField classes inconsistent with TrieFooFields on malformed input: throw NumberFormatException

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10833:
-

bq. Here is a new patch.

+1 ... my only nitpicks would be that maybe the {{if (val == null)}} logic 
could be refactored into a {{private static}} helper method?  ... allthough i 
guess in theory even the try/catch/rethrow could be refactored into private 
helper that used a closure? ... not sure how far down the rabbit hole of 
refactoring we can go before less duplication is more confusing.

(just to be clear: totally happy with committing as is)

bq. For some QParsers Points maybe should work (raw, simple...), but I think 
they deserve their own Jiras/discussion if they don't have one already.

yeah, that seems out of scope from the focus here: making the behavior _inside_ 
these FieldTypes classess/methods consistent on bad input

> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -
>
> Key: SOLR-10833
> URL: https://issues.apache.org/jira/browse/SOLR-10833
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-10704.
--
Resolution: Fixed

Fix it so that we wait until the new replica completes recovery in case of 
leader replicas.

> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10704:


Commit ccd1f45b3ba3fbb862cae5d0ab0ce821b966026a in lucene-solr's branch 
refs/heads/branch_6x from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ccd1f45 ]

SOLR-10704 Wait until all leader replicas are recovered before deleting
the originals.


> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8392:
-

Sigh. Sorry about that, guys. I'll take care of this today.

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10704) REPLACENODE can make the collection lost data which replicaFactor is 1

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10704:


Commit 232eff0893bccb93d01042f26a00e50870be2f29 in lucene-solr's branch 
refs/heads/master from [~ab]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=232eff0 ]

SOLR-10704 Wait until all leader replicas are recovered before deleting
the originals.


> REPLACENODE can make the collection lost data which replicaFactor is 1 
> ---
>
> Key: SOLR-10704
> URL: https://issues.apache.org/jira/browse/SOLR-10704
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.2
> Environment: Red Hat 4.8.3-9, JDK 1.8.0_121
>Reporter: Daisy.Yuan
>Assignee: Andrzej Bialecki 
> Fix For: master (7.0), 6.7
>
> Attachments: 219.log, SOLR-10704.patch, SOLR-10704.patch
>
>
> When some replicas which the relative collection's replicaFactor is 1, it 
> will lost data after executing the REPLACENODE cmd. 
> It may be the new replica on the target node does not complete revovering, 
> but the old replica on the source node  was already be deleted.
> At last the target revocery failed for the following exception:
> 2017-05-18 17:08:48,587 | ERROR | 
> recoveryExecutor-3-thread-2-processing-n:192.168.229.137:21103_solr 
> x:replace-hdfs-coll1_shard1_replica2 s:shard1 c:replace-hdfs-coll1 
> r:core_node3 | Error while trying to recover. 
> core=replace-hdfs-coll1_shard1_replica2:java.lang.NullPointerException
> at org.apache.solr.update.PeerSync.alreadyInSync(PeerSync.java:339)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10818) backup-collection V2 API doesn't parse params correctly

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-10818:
-

Yeah, the test is inside testCollectionsApi() method.

> backup-collection V2 API doesn't parse params correctly
> ---
>
> Key: SOLR-10818
> URL: https://issues.apache.org/jira/browse/SOLR-10818
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Varun Thacker
>Assignee: Cao Manh Dat
>
>  tried the backup-collection command and I got an error which seems to 
> indicate that the location param is getting escaped? Also didn't see any 
> tests for backup-collection
> {code}
> ~/solr-6.5.0$ curl -X POST -d '{backup-collection:{name: backup_test, 
> collection: gettingstarted , location: '/Users/varunthacker/solr-6.5.0' }}' 
> http://localhost:8983/v2/c
> 
> 
> 
> Error 400 
> {metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.noggit.JSONParser$ParseException},msg=org.noggit.JSONParser$ParseException:
>  Invalid comment: expected //, /*, or #: char=U,position=79 
> BEFORE={name: backup_test, collection: gettingstarted , location: 
> /U AFTER=sers/varunthacker/solr-6.5.0 }},code=400}
> 
> HTTP ERROR 400
> Problem accessing /solr/v2/c. Reason:
> 
> {metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.noggit.JSONParser$ParseException},msg=org.noggit.JSONParser$ParseException:
>  Invalid comment: expected //, /*, or #: char=U,position=79 
> BEFORE={name: backup_test, collection: gettingstarted , location: 
> /U AFTER=sers/varunthacker/solr-6.5.0 }},code=400}
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1364 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1364/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: 
{"error":{ "trace":"java.lang.ClassCastException\n", "code":500}},  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {"error":{
"trace":"java.lang.ClassCastException\n",
"code":500}},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([947CFB81CFA416DF:E350C38898379232]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestSolrConfigHandler.testReqParams(TestSolrConfigHandler.java:665)
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:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-10884) Add nodeVectors Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Description: The *nodeVectors* Stream Evaluator vectorizes the connections 
in a node set returned by a gatherNodes expression. The nodeVectors can then be 
clustered. This will cluster nodes based on their connections in a graph.  
(was: The nodeVectors Stream Evaluator vectorizes the connections in a node set 
returned by a gatherNodes expression. The nodeVectors can then be clustered. 
This will nodes based on their connections in a graph.)

> Add nodeVectors Stream Evaluator
> 
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The *nodeVectors* Stream Evaluator vectorizes the connections in a node set 
> returned by a gatherNodes expression. The nodeVectors can then be clustered. 
> This will cluster nodes based on their connections in a graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10884) Add nodeVectors Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10884:
-

 Summary: Add nodeVectors Stream Evaluator
 Key: SOLR-10884
 URL: https://issues.apache.org/jira/browse/SOLR-10884
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The nodeVectors Stream Evaluator vectorizes the connections in a node set 
returned by a gatherNodes expression. The nodeVectors can then be clustered. 
This will cluster nodes based on their connections in a graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10818) backup-collection V2 API doesn't parse params correctly

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-10818:
--

Hi Dat,

Thanks for looking into it. I should have tried testing it with double quotes.

Should the test be part of TestCollectionAPIs . though?



> backup-collection V2 API doesn't parse params correctly
> ---
>
> Key: SOLR-10818
> URL: https://issues.apache.org/jira/browse/SOLR-10818
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Varun Thacker
>Assignee: Cao Manh Dat
>
>  tried the backup-collection command and I got an error which seems to 
> indicate that the location param is getting escaped? Also didn't see any 
> tests for backup-collection
> {code}
> ~/solr-6.5.0$ curl -X POST -d '{backup-collection:{name: backup_test, 
> collection: gettingstarted , location: '/Users/varunthacker/solr-6.5.0' }}' 
> http://localhost:8983/v2/c
> 
> 
> 
> Error 400 
> {metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.noggit.JSONParser$ParseException},msg=org.noggit.JSONParser$ParseException:
>  Invalid comment: expected //, /*, or #: char=U,position=79 
> BEFORE={name: backup_test, collection: gettingstarted , location: 
> /U AFTER=sers/varunthacker/solr-6.5.0 }},code=400}
> 
> HTTP ERROR 400
> Problem accessing /solr/v2/c. Reason:
> 
> {metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.noggit.JSONParser$ParseException},msg=org.noggit.JSONParser$ParseException:
>  Invalid comment: expected //, /*, or #: char=U,position=79 
> BEFORE={name: backup_test, collection: gettingstarted , location: 
> /U AFTER=sers/varunthacker/solr-6.5.0 }},code=400}
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10884) Add nodeVectors Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10884:
--
Description: The nodeVectors Stream Evaluator vectorizes the connections in 
a node set returned by a gatherNodes expression. The nodeVectors can then be 
clustered. This will nodes based on their connections in a graph.  (was: The 
nodeVectors Stream Evaluator vectorizes the connections in a node set returned 
by a gatherNodes expression. The nodeVectors can then be clustered. This will 
cluster nodes based on their connections in a graph.)

> Add nodeVectors Stream Evaluator
> 
>
> Key: SOLR-10884
> URL: https://issues.apache.org/jira/browse/SOLR-10884
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The nodeVectors Stream Evaluator vectorizes the connections in a node set 
> returned by a gatherNodes expression. The nodeVectors can then be clustered. 
> This will nodes based on their connections in a graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Noble Paul (JIRA)]

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

Noble Paul reopened SOLR-8392:
--

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8392) SolrParam.get(String) returns String and shouldn't be used in other instanceof checks

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8392:
--

Reopened because of test failures

> SolrParam.get(String) returns String and shouldn't be used in other 
> instanceof checks
> -
>
> Key: SOLR-8392
> URL: https://issues.apache.org/jira/browse/SOLR-8392
> Project: Solr
>  Issue Type: Bug
>Reporter: Mike Drob
>Assignee: Mike Drob
> Fix For: master (7.0)
>
> Attachments: SOLR-8392.patch, SOLR-8392.patch
>
>
> There's a couple of places where we declare the return type of 
> solrParams.get() as an Object and then do instanceof checks for other types. 
> Since we know it will be a String, we can simplify this logic in several 
> places.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 930 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/930/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

38 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.TestCrossCoreJoin

Error Message:
org.apache.solr.TestCrossCoreJoin

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.TestCrossCoreJoin
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:273)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:233)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/TestCrossCoreJoin.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


FAILED:  junit.framework.TestSuite.org.apache.solr.TestSolrCoreProperties

Error Message:
org.apache.solr.TestSolrCoreProperties

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.TestSolrCoreProperties
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:273)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:233)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/TestSolrCoreProperties.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


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

Error Message:
org.apache.solr.cloud.BasicZkTest

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.cloud.BasicZkTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:273)
at 

[jira] [Comment Edited] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10883 at 6/13/17 1:50 PM:


Patch, backslash escapes {{=>}}, {{<=}}, {{\->}} and {{<\-}}.  (Even though 
{{\->}} renders properly in the PDF, I think it's better to be consistent.)

I found that some of the other substitutions (for {{...}}, {{--}}, {{'}}) 
looked fine in the PDF, and the others weren't present outside of code blocks: 
{{(C)}}, {{(R)}}, {{(TM)}}.

I went the individual escaping route after determining that there is no way to 
globally turn off this kind of substitution - there is an open feature request 
for this: [https://github.com/asciidoctor/asciidoctor/issues/1061].


was (Author: steve_rowe):
Patch, backslash escapes {{=>}}, {{<=}}, {{->}} and {{<-}}.  (Even though 
{{->}} renders properly in the PDF, I think it's better to be consistent.)

I found that some of the other substitutions (for {{...}}, {{--}}, {{'}}) 
looked fine in the PDF, and the others weren't present outside of code blocks: 
{{(C)}}, {{(R)}}, {{(TM)}}.

I went the individual escaping route after determining that there is no way to 
globally turn off this kind of substitution - there is an open feature request 
for this: [https://github.com/asciidoctor/asciidoctor/issues/1061].

> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10883:
--
Description: 
{{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
“replacement substitutions” aka “textual symbol replacements” ( 
http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
invisible characters in the PDF, though they are visible in the HTML format, 
when substitution is in effect.

This is only a problem outside of code blocks (e.g. {{-->}} close comment 
syntax in XML is never improperly substituted).

In the screenshot below, a table from the 
CharFilterFactories|solr.MappingCharFilterFactory section is shown in the HTML 
format on the left, and in PDF format to the right; in the PDF format the 
{{=>}} is invisible.

!Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!

  was:
{{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
“replacement substitutions” aka “textual symbol replacements” ( 
http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
invisible characters in the PDF, though they are visible in the HTML format, 
when substitution is in effect.

This is only a problem outside of code blocks (e.g. {{-->}} close comment 
syntax in XML is never improperly substituted).

In the screenshot below, a table from the 
CharFilterFactories|solr.MappingCharFilterFactory section is shown in the HTML 
format on the left, and in PDF format to the right; in the PDF format the 
{{=>}} is invisible.

!Screen Shot 2017-06-12 at 7.23.07 PM.png!


> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10883:
--
Attachment: SOLR-10883.patch

Patch, backslash escapes {{=>}}, {{<=}}, {{->}} and {{<-}}.  (Even though 
{{->}} renders properly in the PDF, I think it's better to be consistent.)

I found that some of the other substitutions (for {{...}}, {{--}}, {{'}}) 
looked fine in the PDF, and the others weren't present outside of code blocks: 
{{(C)}}, {{(R)}}, {{(TM)}}.

I went the individual escaping route after determining that there is no way to 
globally turn off this kind of substitution - there is an open feature request 
for this: [https://github.com/asciidoctor/asciidoctor/issues/1061].

> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7452:
--

The root of the exception is:

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
   [junit4]   2>at 
org.apache.calcite.avatica.util.AbstractCursor$LongAccessor.getLong(AbstractCursor.java:540)
   [junit4]   2>at 
org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305)
   [junit4]   2>at 
org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393)
   [junit4]   2>at 
org.apache.solr.client.solrj.io.stream.JDBCStream$1.selectValue(JDBCStream.java:314)
   [junit4]   2>at 
org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:506)
   [junit4]   2>at 
org.apache.solr.handler.SQLHandler$SqlHandlerStream.read(SQLHandler.java:186)
   [junit4]   2>at 
org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:68)


Basically Calcite is expecting a long in this scenario because we map all 
integer types to longs in the SolrSchema.java class. I think the best way to 
deal with this is to have the FacetStream convert all Integers buckets to Longs.

The Streaming API really only deals with Longs and Doubles.

[~ysee...@gmail.com], let's create branch for this so we can collaborate. If 
you create a branch with this patch I'll fix up the FacetStream. Then you can 
take a final look and commit to master.




> json facet api returning inconsistent counts in cloud set up
> 
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
>  Issue Type: Bug
>  Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>  Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api 
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent 
> returns of counts of faceted value ( Note I am running on a cloud mode of 
> solr). For example consider that i have txns_id(unique field or key), 
> consumer_number and amount. Now for a 10 million such records , lets say i 
> query for 
> q=*:*=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
>   "numBuckets":3112708,
>   "buckets":[{
>   "val":"surya",
>   "count":4,
>   "y":2.264506},
>   {
>   "val":"raghu",
>   "COUNT":3,   // capitalised for recognition 
>   "y":1.8},
> {
>   "val":"malli",
>   "count":4,
>   "y":1.78}]}}}
> but if i restrict the query to 
> q=consumer_number:raghu=0&
>  json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
>   sort : {y:desc},
>   numBuckets : true,
>   facet:{
>y : "sum(amount)"
>}
>}
>  }
> i get :
>   "facets":{
> "count":4,
> "biskatoo":{
>   "numBuckets":1,
>   "buckets":[{
>   "val":"raghu",
>   "COUNT":4,
>   "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions 
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but 
> still the issue seems not resolved



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10883:
--
Description: 
{{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
“replacement substitutions” aka “textual symbol replacements” ( 
http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
invisible characters in the PDF, though they are visible in the HTML format, 
when substitution is in effect.

This is only a problem outside of code blocks (e.g. {{-->}} close comment 
syntax in XML is never improperly substituted).

In the screenshot below, a table from the 
CharFilterFactories|solr.MappingCharFilterFactory section is shown in the HTML 
format on the left, and in PDF format to the right; in the PDF format the 
{{=>}} is invisible.

!Screen Shot 2017-06-12 at 7.23.07 PM.png!

  was:
{{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
“replacement substitutions” aka “textual symbol replacements” ( 
http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
invisible characters in the PDF, though they are visible in the HTML format, 
when substitution is in effect.

This is only a problem outside of code blocks (e.g. {{-->}} close comment 
syntax in XML is never improperly substituted).



> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19856 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19856/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.core.TestSolrConfigHandler.testReqParams

Error Message:
Could not get expected value  'CY val' for path 'params/c' full output: {   
"responseHeader":{ "status":500, "QTime":0},   "error":{ 
"trace":"java.lang.ClassCastException\n", "code":500}},  from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'params/c' full output: {
  "responseHeader":{
"status":500,
"QTime":0},
  "error":{
"trace":"java.lang.ClassCastException\n",
"code":500}},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([F31EAE2545A23D24:8432962C1231B9C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestSolrConfigHandler.testReqParams(TestSolrConfigHandler.java:665)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at