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

[Policeman Jenkins Server]

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

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

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([8392609E3AE01633:7ADFF33106955BB9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+140) - Build # 18188 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18188/
Java: 64bit/jdk-9-ea+140 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([FDC1D793C68F9BD4:AB239CB00673432]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1329)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 

[jira] [Commented] (LUCENE-7531) Remove packing support from FST

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7531:


+1

> Remove packing support from FST
> ---
>
> Key: LUCENE-7531
> URL: https://issues.apache.org/jira/browse/LUCENE-7531
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7531.patch
>
>
> This seems to be only used for the kuromoji dictionaries, but we could easily 
> rebuild those dictionaries with packing disabled.



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 190 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/190/

4 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterWithThreads.testImmediateDiskFullWithThreads

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterWithThreads

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

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


FAILED:  
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Expected to see collection awhollynewcollection_0 null Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/2)={
   "replicationFactor":"3",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{}}},   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected to see collection awhollynewcollection_0
null
Last available state: 
DocCollection(awhollynewcollection_0//collections/awhollynewcollection_0/state.json/2)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{}}},
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([8DBDC023EAAA0C40:C5C8B497EC9923D5]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:236)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:496)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Updated] (SOLR-9708) Expose UnifiedHighlighter in Solr

[David Smiley (JIRA)]

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

David Smiley updated SOLR-9708:
---
 Assignee: David Smiley
 Priority: Major  (was: Minor)
Fix Version/s: 6.4
   Issue Type: New Feature  (was: Improvement)

> Expose UnifiedHighlighter in Solr
> -
>
> Key: SOLR-9708
> URL: https://issues.apache.org/jira/browse/SOLR-9708
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.4
>
>
> This ticket is for creating a Solr plugin that can utilize the new 
> UnifiedHighlighter which was initially committed in 
> https://issues.apache.org/jira/browse/LUCENE-7438



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

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

[jira] [Commented] (SOLR-9708) Expose UnifiedHighlighter in Solr

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9708:


To anyone following along: The code is the PostingsHighlighter's Solr adapter, 
with just a few changes to work with the UH instead.

> Expose UnifiedHighlighter in Solr
> -
>
> Key: SOLR-9708
> URL: https://issues.apache.org/jira/browse/SOLR-9708
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Timothy M. Rodriguez
>Priority: Minor
>
> This ticket is for creating a Solr plugin that can utilize the new 
> UnifiedHighlighter which was initially committed in 
> https://issues.apache.org/jira/browse/LUCENE-7438



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

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

[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9616:
--

[~timo.schmidt], in looking through the stack track trace and reviewing the 
code, it appears that the index you were searching on was empty. Was that the 
case?

> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2.1
>Reporter: Timo Hund
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set 
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse 
> field=pid}=true=10
> Produces:
>   "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat 
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat 
> java.util.ArrayList.get(ArrayList.java:429)\n\tat 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat 
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\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.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
>  
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
>  java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> Instead i would assume to get an empty result. 
> Is this a bug?



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

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

[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9665:


If the field is numeric (not a String that happens to contain a number), then 
the "JSON Facet API" will interpret the "index" sort order as the numeric sort 
of the field value.  I just verified it worked:

http://localhost:8983/solr/techproducts/select?json.facet.price.terms.field=price=index=on=*:*=1=json

(in that example, it's a coincidence of the example data that it's the same as 
count order)

Docs: https://cwiki.apache.org/confluence/display/solr/Faceted+Search

p.s. yes it's a shame we have multiple faceting modules, which is confusing to 
users.  In time I hope JSON Facet API takes over.

> Facet Values Sort Order: Add 3rd choice: Numeric Sort
> -
>
> Key: SOLR-9665
> URL: https://issues.apache.org/jira/browse/SOLR-9665
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Reporter: Luke P Warwick
>
> As a person, I need facet values to be in predictable, intuitive spots so 
> that I can quickly and easily find the values that are appropriate to me.
> Problem Statement: Today Solr has two default facet sort orders, neither of 
> which provides predictable, intuitive facet value orders for people when the 
> values start with numbers.  
> Goal: Address the problem where index sorts facet values how a computer would 
> rather than how a human would.  This is very problematic for E-commerce 
> facets like 'size' and 'tire width'
> Acceptance Criteria:
> 1. Sorts facet values numerically from lowest to highest
> 2. Works with both numeric and string fields (thus working on values that 
> include letters... 25 mm, 30 waist, 32 Waist, 4 Petite)
> 3. If facet values don't start with a number, they are sorted alphabetically, 
> after all values that do start with a number
> 4. If facet values are equal numerically, sort the numerically equal values 
> alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall
> 5. Integers and Floats are supported (even if string field)
> Examples:
> Women's Pants Sizes:
> 8
> 8 Tall
> 10
> 10 Petite
> 10 Tall
> 12
> 12 Tall
> 14 Petite
> 26 Waist
> 28 Waist
> 30 Waist
> One Size
> Bike Wheel Sizes:
> 20 Inches
> 24 Inches
> 26 Inches
> 27 Inches
> 27.5 Inches
> 27.5+ Inches
> 29 Inches
> 650c
> 700c



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

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

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[Timothy M. Rodriguez (JIRA)]

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

Timothy M. Rodriguez commented on LUCENE-7438:
--

Not yet, we have an initial general implementation, but it's lacking tests.  
(We have a customized extension internally that does have tests.)  I've created 
a new ticket https://issues.apache.org/jira/browse/SOLR-9708 with a PR 
containing the initial impl so folks can follow or help the work towards 
finishing it up.  Thanks for asking though, hopefully this gets the ball 
rolling faster.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, 
> LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

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

[jira] [Commented] (SOLR-9708) Expose UnifiedHighlighter in Solr

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9708:
--

GitHub user Timothy055 opened a pull request:

https://github.com/apache/lucene-solr/pull/107

SOLR-9708 UnifiedHighlighter Solr Plugin

An initial implementation of a solr plugin for the unified highlighter.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Timothy055/lucene-solr features/SOLR-9708

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/107.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #107


commit 669f94f27c73b9fd5190a980a089cff9d4df3015
Author: Timothy Rodriguez 
Date:   2016-10-31T21:05:47Z

initial commit of UnifiedSolrHighlighter adapter

commit 2cf4b2d35f1f535e8b8126b5dd685dc3bb663391
Author: Timothy Rodriguez 
Date:   2016-10-31T21:12:19Z

add license header




> Expose UnifiedHighlighter in Solr
> -
>
> Key: SOLR-9708
> URL: https://issues.apache.org/jira/browse/SOLR-9708
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Timothy M. Rodriguez
>Priority: Minor
>
> This ticket is for creating a Solr plugin that can utilize the new 
> UnifiedHighlighter which was initially committed in 
> https://issues.apache.org/jira/browse/LUCENE-7438



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

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

[GitHub] lucene-solr pull request #107: SOLR-9708 UnifiedHighlighter Solr Plugin

[Timothy055]

GitHub user Timothy055 opened a pull request:

https://github.com/apache/lucene-solr/pull/107

SOLR-9708 UnifiedHighlighter Solr Plugin

An initial implementation of a solr plugin for the unified highlighter.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Timothy055/lucene-solr features/SOLR-9708

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/107.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #107


commit 669f94f27c73b9fd5190a980a089cff9d4df3015
Author: Timothy Rodriguez 
Date:   2016-10-31T21:05:47Z

initial commit of UnifiedSolrHighlighter adapter

commit 2cf4b2d35f1f535e8b8126b5dd685dc3bb663391
Author: Timothy Rodriguez 
Date:   2016-10-31T21:12:19Z

add license header




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Comment Edited] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

Jan Høydahl edited comment on SOLR-9623 at 10/31/16 9:12 PM:
-

You mean to build EnvVar override support into the Java code for each config 
property instead of relying on solr.xml to have the config? Would be sweet if 
we had some kind of dot convention that would always work, like 
{{solr...}}, e.g. 
{{solr.config.request_parsers.enable_remote_streaming}}, here with a convention 
of inserting a "_" for camelCase.

Makes me think - we already have such a mepping convention for the Config REST 
API, don't we?


was (Author: janhoy):
You mean to build EnvVar override support into the Java code for each config 
property instead of relying on solr.xml to have the config? Would be sweet if 
we had some kind of dot convention that would always work, like 
{{solr...}}, e.g. 
{{solr.config.request_parsers.enable_remote_streaming}}, here with a convention 
of inserting a "_" for camelCase.

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: configset
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



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

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

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

You mean to build EnvVar override support into the Java code for each config 
property instead of relying on solr.xml to have the config? Would be sweet if 
we had some kind of dot convention that would always work, like 
{{solr...}}, e.g. 
{{solr.config.request_parsers.enable_remote_streaming}}, here with a convention 
of inserting a "_" for camelCase.

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: configset
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



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

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

[jira] [Created] (SOLR-9708) Expose UnifiedHighlighter in Solr

[Timothy M. Rodriguez (JIRA)]

Timothy M. Rodriguez created SOLR-9708:
--

 Summary: Expose UnifiedHighlighter in Solr
 Key: SOLR-9708
 URL: https://issues.apache.org/jira/browse/SOLR-9708
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: highlighter
Reporter: Timothy M. Rodriguez
Priority: Minor


This ticket is for creating a Solr plugin that can utilize the new 
UnifiedHighlighter which was initially committed in 
https://issues.apache.org/jira/browse/LUCENE-7438



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

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

[jira] [Comment Edited] (SOLR-9609) Change hard-coded keysize from 512 to 1024

[JIRA]

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

Jan Høydahl edited comment on SOLR-9609 at 10/31/16 9:00 PM:
-

My reasoning is that it is not likely something you ever need to change, so 
using solr.in for overriding looks better than needing to upload stuff to ZK 
config. And the risk of having different solr.in files is not unique to this 
setting. We already need SOLR_ZK_HOST to be synchronized as well as probably 
SSL settings. I think this is in the same neighborhood of deciding the basic 
wiring of how hosts will talk to eachother. That's why I also think urlScheme 
could move from being a clusterProp to becoming a sysProp in solr.in, or being 
auto-resolved from SSL props.

And SOLR-9481 is *only* in master so far btw...


was (Author: janhoy):
My reasoning is that it is not likely something you ever need to change, so 
using solr.in for overriding looks better than needing to upload stuff to ZK 
config. And the risk of having different solr.in files is not unique to this 
setting. We already need SOLR_ZK_HOST to be synchronized as well as probably 
SSL settings. I think this is in the same neighborhood of deciding the basic 
wiring of how hosts will talk to eachother. That's why I also think urlScheme 
could move from being a clusterProp to becoming a sysProp in solr.in, or being 
auto-resolved from SSL props.

> Change hard-coded keysize from 512 to 1024
> --
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jeremy Martini
>Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password 
> in the configuration file, we extended JdbcDataSource to create our own 
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
>  url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" 
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the 
> password. However, this seems to cause an issue when we try use Solr in a 
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and 
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the 
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
> keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt 
> it, and now everything seems to work great.



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

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

Solr Ref Guide for 6.3

[Cassandra Targett]

I'll volunteer to release manage the Ref Guide for Solr 6.3.

I've reviewed CHANGES.txt, cut some issues, and organized the rest by
where I'm guessing they should go:
https://cwiki.apache.org/confluence/display/solr/Internal+-+TODO+List.

Please think about what you worked on in 6.3 and try to make some time
to update the Ref Guide accordingly. I'm happy to review your content
or help you any way I can. We use the TODO list to tell us what needs
to be documented - put your initials next to or under an item if you
can work on it so we don't overlap efforts.

With luck, maybe next time we'll be able to use a new process. But we
aren't there yet so I ask for as much of your help as you can give.

I intend to make an RC of the Ref Guide by the end of the week (by
Friday, Nov 4). I'll update if I am delayed; if you'd like to work on
something but need more time than that, please let me know.

Thanks,
Cassandra

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

[jira] [Commented] (SOLR-9609) Change hard-coded keysize from 512 to 1024

[JIRA]

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

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

My reasoning is that it is not likely something you ever need to change, so 
using solr.in for overriding looks better than needing to upload stuff to ZK 
config. And the risk of having different solr.in files is not unique to this 
setting. We already need SOLR_ZK_HOST to be synchronized as well as probably 
SSL settings. I think this is in the same neighborhood of deciding the basic 
wiring of how hosts will talk to eachother. That's why I also think urlScheme 
could move from being a clusterProp to becoming a sysProp in solr.in, or being 
auto-resolved from SSL props.

> Change hard-coded keysize from 512 to 1024
> --
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jeremy Martini
>Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password 
> in the configuration file, we extended JdbcDataSource to create our own 
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
>  url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" 
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the 
> password. However, this seems to cause an issue when we try use Solr in a 
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and 
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the 
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
> keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt 
> it, and now everything seems to work great.



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[JIRA]

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

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

Yes, this is currently only on master, and has some intermittent test failures 
I'm trying to track down before backporting. I got no idea how the changes 
entry made it to 6.x though, sorry for that [~shalinmangar].

Kevin, thanks for testing!

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[JENKINS-EA] Lucene-Solr-6.3-Linux (64bit/jdk-9-ea+140) - Build # 1 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.3-Linux/1/
Java: 64bit/jdk-9-ea+140 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTaskQueueTest.testPeekElements

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([E3A3816B211942F8:1E8D3B4AF12016E5]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.cloud.DistributedQueueTest.testPeekElements(DistributedQueueTest.java:181)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)




Build Log:
[...truncated 11269 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerTaskQueueTest
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9077:
--

ParallelStream should be fine as it's just a bag of worker nodes. We may not 
want to support aliases for the FeatureSelectionStream, TextLogitStream and 
TopicStream. In particular the TopicStream relies on checkpoints which are 
specific to a physical collection. The FeatureSelectionStream and 
TextLogitStream probably don't need to support alias and may just complicate 
things.



> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, 
> SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option

[JIRA]

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

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

I can agree with you. Looks like the {{-d}} option is designed to work even if 
the solr/server dir is missing completely, which is not the case for neither 
bin/solr or bin/solr.cmd currently. bin/solr uses DEFAULT_SERVER_DIR for the 
run_tool stuff.

> Windows Start Script when Changing SOLR_SERVER_DIR via -d option
> 
>
> Key: SOLR-8384
> URL: https://issues.apache.org/jira/browse/SOLR-8384
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3.1
> Environment: Windows
>Reporter: Jeremy Anderson
>Priority: Trivial
>
> bin\solr.cmd Requires change of environment variables used in the " REM now 
> wait to see Solr come online ..." command.  Currently this call uses 
> DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a 
> different server directory using the -d command option.
> Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries 
> are able to be found when checking that SOLR started.
> There may be other uses in the script where this issue is present when 
> starting SOLR from a different directory other than 'server'.



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

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

[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9077:


Yea most of the changes are actually test variable changes (COLLECTION -> 
COLLECTIONORALIAS). Wasn't sure how else to make that change. The important 
section is confined to CloudSolrStream.getSlices(). The changes I'm concerned 
with are the FeaturesSectionStream, ParallelStream, TextLogitStream, and 
TopicStream. These all had getActiveSlices. Not sure the slices HAD to be for a 
specific collection. Now they should work with all slices from all collections 
in an alias.

Any easier way to view is here: 
https://github.com/apache/lucene-solr/commit/1e9a285d53ee1a57a0229c4eafdeb8f13c35

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, 
> SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Comment Edited] (SOLR-9077) Streaming expressions should support collection alias

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9077 at 10/31/16 8:33 PM:


Looks good from a quick review, but it's a pretty big patch. It will take a 
little time to take the whole thing in. If you're feeling comfortable with it 
feel free to commit, I'm sure this code will get exercised plenty before the 
6.4 release.


was (Author: joel.bernstein):
Looks good from a quick review, but it's a pretty big patch. It will take a 
little time to take the whole thing in. If you're feeling comfortable with feel 
free to commit, I'm sure this code will get exercised plenty before the 6.4 
release.

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, 
> SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (SOLR-9077) Streaming expressions should support collection alias

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9077:
--

Looks good from a quick review, but it's a pretty big patch. It will take a 
little time to take the whole thing in. If you're feeling comfortable with feel 
free to commit, I'm sure this code will get exercised plenty before the 6.4 
release.

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, 
> SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (SOLR-6962) bin/solr stop -a should complain about missing parameter

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-6962:
-

I did not (yet) test in and I know there were some script changes in others. 
Let's leave it for after 6.3 and I will test and commit it.

> bin/solr stop -a should complain about missing parameter
> 
>
> Key: SOLR-6962
> URL: https://issues.apache.org/jira/browse/SOLR-6962
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: SOLR-6962.patch, SOLR-6962v2.patch
>
>
> *bin/solr* has a *-a* option that expects a second parameter. If one is not 
> provided, it hangs.  It should complain and  exit just like *-e* option does.
> The most common time I hit this is when I try to do *bin/solr stop \-all* and 
> instead just type *bin/solr stop \-a* as I am more used to give full name 
> options with double-dash prefix (Unix conventions, I guess).



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/553/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=9344, 
name=SocketProxy-Response-53803:54368, state=RUNNABLE, 
group=TGRP-HttpPartitionTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=9344, name=SocketProxy-Response-53803:54368, 
state=RUNNABLE, group=TGRP-HttpPartitionTest]
at 
__randomizedtesting.SeedInfo.seed([2ABD62BCF6D9722A:A2E95D6658251FD2]:0)
Caused by: java.lang.RuntimeException: java.net.SocketException: Socket is 
closed
at __randomizedtesting.SeedInfo.seed([2ABD62BCF6D9722A]:0)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:347)
Caused by: java.net.SocketException: Socket is closed
at java.net.Socket.setSoTimeout(Socket.java:1137)
at 
org.apache.solr.cloud.SocketProxy$Bridge$Pump.run(SocketProxy.java:344)




Build Log:
[...truncated 11506 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_2ABD62BCF6D9722A-001\init-core-data-001
   [junit4]   2> 1099310 INFO  
(SUITE-HttpPartitionTest-seed#[2ABD62BCF6D9722A]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 1099310 INFO  
(SUITE-HttpPartitionTest-seed#[2ABD62BCF6D9722A]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /i/c
   [junit4]   2> 1099312 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1099346 INFO  (Thread-1716) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1099346 INFO  (Thread-1716) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1099413 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.ZkTestServer start zk server on port:53764
   [junit4]   2> 1099772 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1099775 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1099777 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1099779 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1099781 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 1099783 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 1099784 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 1099787 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\open-exchange-rates.json
 to /configs/conf1/open-exchange-rates.json
   [junit4]   2> 1099788 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\core\src\test-files\solr\collection1\conf\mapping-ISOLatin1Accent.txt
 to /configs/conf1/mapping-ISOLatin1Accent.txt
   [junit4]   2> 1099791 INFO  
(TEST-HttpPartitionTest.test-seed#[2ABD62BCF6D9722A]) [] 
o.a.s.c.AbstractZkTestCase put 

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-9623:
-

bq. A. Remove this section from all solrconfig.xml and let the Java default of 
false be the new default
+1 on A. 

I am -0 on B, because each section in solrconfig.xml also contributes to the 
decision fatigue. My anecdotal survey indicates that many people don't even 
know that this section is there because they get tired of reading 
solrconfig.xml before that due to all other sections.

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: configset
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9481:


[~janhoy] - I tested with your steps through Docker and it works.

Details: https://gist.github.com/risdenk/bd2c48dea8a5c60d2b7746d8b96c7ac2

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[jira] [Commented] (SOLR-9665) Facet Values Sort Order: Add 3rd choice: Numeric Sort

[Luke P Warwick (JIRA)]

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

Luke P Warwick commented on SOLR-9665:
--

another example: We have a facet who's values go from the 70's to the 120s 
(width of skis).  The values end up looking like this:

Brake Width (mm)
100 (7)
110 (9)
115 (6)
120 (3)
74 (2)
80 (1)
85 (1)
90 (9)
93 (1)
95 (1)

Facets like this EnumField doesn't work well on since the values aren't always 
static and EnumField requires that.  


> Facet Values Sort Order: Add 3rd choice: Numeric Sort
> -
>
> Key: SOLR-9665
> URL: https://issues.apache.org/jira/browse/SOLR-9665
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: faceting
>Reporter: Luke P Warwick
>
> As a person, I need facet values to be in predictable, intuitive spots so 
> that I can quickly and easily find the values that are appropriate to me.
> Problem Statement: Today Solr has two default facet sort orders, neither of 
> which provides predictable, intuitive facet value orders for people when the 
> values start with numbers.  
> Goal: Address the problem where index sorts facet values how a computer would 
> rather than how a human would.  This is very problematic for E-commerce 
> facets like 'size' and 'tire width'
> Acceptance Criteria:
> 1. Sorts facet values numerically from lowest to highest
> 2. Works with both numeric and string fields (thus working on values that 
> include letters... 25 mm, 30 waist, 32 Waist, 4 Petite)
> 3. If facet values don't start with a number, they are sorted alphabetically, 
> after all values that do start with a number
> 4. If facet values are equal numerically, sort the numerically equal values 
> alphabetically. Example: 10,10 Petite,10 Tall,12, Petite, 12 Tall
> 5. Integers and Floats are supported (even if string field)
> Examples:
> Women's Pants Sizes:
> 8
> 8 Tall
> 10
> 10 Petite
> 10 Tall
> 12
> 12 Tall
> 14 Petite
> 26 Waist
> 28 Waist
> 30 Waist
> One Size
> Bike Wheel Sizes:
> 20 Inches
> 24 Inches
> 26 Inches
> 27 Inches
> 27.5 Inches
> 27.5+ Inches
> 29 Inches
> 650c
> 700c



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

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

[jira] [Commented] (SOLR-1485) PayloadTermQuery support

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-1485:
-

This is indeed the case but there is still no PayloadQParserPlugin, probably 
for the reason that there is also no Similarity implementation taking care of 
payload scoring.

We have and use such a plugin and can provide it, and a BM25 similarity where 
the payload is directly used for scoring in the basic cases. But payloads can 
be used for much fancier applications, so would would Solr want to support? 
Without a similarity, the parser is useless.

> PayloadTermQuery support
> 
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Fix For: 6.0
>
> Attachments: PayloadTermQueryPlugin.java
>
>
> Solr currently has no support for Lucene's PayloadTermQuery, yet it has 
> support for indexing payloads. 



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

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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC2

[Steve Rowe]

+1

Smoke tester is happy: SUCCESS! [0:24:53.709200]

Docs, changes and javadocs look good.

--
Steve
www.lucidworks.com

> On Oct 31, 2016, at 2:28 PM, Shalin Shekhar Mangar  wrote:
> 
> Please vote for the second release candidate for Lucene/Solr 6.3.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> 
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/
> 
> Smoke tester passed for me:
> SUCCESS! [0:35:05.847870]
> 
> Here's my +1 to release.
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> 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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6217/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth

Error Message:
Invalid jsonError 401   
 HTTP ERROR: 401 Problem accessing 
/solr/admin/authentication. Reason: Bad credentials http://eclipse.org/jetty;>Powered by Jetty:// 9.3.8.v20160314 
  

Stack Trace:
java.lang.AssertionError: Invalid json 


Error 401 


HTTP ERROR: 401
Problem accessing /solr/admin/authentication. Reason:
Bad credentials
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.8.v20160314



at 
__randomizedtesting.SeedInfo.seed([B77EE5D7571E82C6:B1093C5F34D01BC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:256)
at 
org.apache.solr.security.BasicAuthIntegrationTest.verifySecurityStatus(BasicAuthIntegrationTest.java:237)
at 
org.apache.solr.security.BasicAuthStandaloneTest.testBasicAuth(BasicAuthStandaloneTest.java:106)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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 

[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9077:
---
Attachment: SOLR-9077.patch

Remove some unused imports

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch, 
> SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[VOTE] Release Lucene/Solr 6.3.0 RC2

[Shalin Shekhar Mangar]

Please vote for the second release candidate for Lucene/Solr 6.3.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/

You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC2-rev1fe1a54db32b8c27bfae81887cd4d75242090613/

Smoke tester passed for me:
SUCCESS! [0:35:05.847870]

Here's my +1 to release.

-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-7438:
--

Is this usable from Solr yet, or should a new issue be opened for that?
A quick grep suggests there's nothing yet:
{code}
find solr -type f | xargs grep -i UnifiedHighlighter
{code}

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: LUCENE-7438.patch, LUCENE_7438_UH_benchmark.patch, 
> LUCENE_7438_UH_benchmark.patch, LUCENE_7438_UH_small_changes.patch
>
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

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

[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9077:
---
Attachment: SOLR-9077.patch

Fixed issue w/ StatementImpl for JDBC when using alias.

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch, SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9077:
---
Attachment: SOLR-9077.patch

Attaching patch with randomized alias vs collection for JdbcTest, 
StreamingTest, StreamExpressionTest, and JDBCStreamTest. Tests seem to be 
passing for me locally.

[~joel.bernstein] or [~dpgove] - Can you take a look and see if this is sane?

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch, SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9616:
--

Ah just read the above comments, looks like the bug was introduced in 6.1?

> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2.1
>Reporter: Timo Hund
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set 
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse 
> field=pid}=true=10
> Produces:
>   "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat 
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat 
> java.util.ArrayList.get(ArrayList.java:429)\n\tat 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat 
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\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.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
>  
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
>  java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> Instead i would assume to get an empty result. 
> Is this a bug?



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

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

[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9616:
--

This is quite a nasty bug. Wondering if this is a recent regression, as the 
expand component has been around quite a long time in Solr 4.

> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2.1
>Reporter: Timo Hund
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set 
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse 
> field=pid}=true=10
> Produces:
>   "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat 
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat 
> java.util.ArrayList.get(ArrayList.java:429)\n\tat 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat 
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\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.produceAndRun(ExecuteProduceConsume.java:246)\n\tat
>  
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)\n\tat
>  
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)\n\tat
>  java.lang.Thread.run(Thread.java:745)\n",
> "code":500}}
> Instead i would assume to get an empty result. 
> Is this a bug?



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9481:


This looks like it was only committed to master. The last commit was from 
Shalin for the release and only affected CHANGES.txt.

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[jira] [Updated] (SOLR-9707) DeleteByQuery forward requests to down replicas and set it in LiR

[Jessica Cheng Mallet (JIRA)]

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

Jessica Cheng Mallet updated SOLR-9707:
---
Attachment: SOLR-9707.diff

> DeleteByQuery forward requests to down replicas and set it in LiR
> -
>
> Key: SOLR-9707
> URL: https://issues.apache.org/jira/browse/SOLR-9707
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Jessica Cheng Mallet
>  Labels: solrcloud
> Attachments: SOLR-9707.diff
>
>
> DeleteByQuery, unlike other requests, does not filter out the down replicas. 
> Thus, the update is still forwarded to the down replica and fails, and the 
> leader then sets the replica in LiR. In a cluster where there are lots of 
> deleteByQuery requests, this can flood the /overseer/queue.



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

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

[jira] [Commented] (SOLR-9609) Change hard-coded keysize from 512 to 1024

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9609:
--

[~janhoy] As a sysprop every solr.in.sh file (or whatever) would have to be 
modified, leaving the chance of one of your N nodes not getting the update. 
Putting it up on Zookeeper in security.json makes that much less likely.

Hmmm, but what about sequencing here? In order to pull it from security.json, 
we need to be able to connect to Zookeeper. I'm assuming that this is 
irrelevant for fetching the security.json file from Zookeeper? You see where 
this is going, if we have to have this value correctly set in order to get data 
from Zookeeper, then it must go in solr.in.sh..

That said, I don't have a strong opinion here although I slightly lean towards 
putting this in the security.json file unless that'd be a problem.

NOTE: SOLR-9481 appears to have been committed to 6x, so if we choose to put 
this in security.json we can go forward with this ticket.

I've assigned it to myself to not lose track of it, but anyone else who wants 
to pick it up please feel free.

Erick

> Change hard-coded keysize from 512 to 1024
> --
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jeremy Martini
>Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password 
> in the configuration file, we extended JdbcDataSource to create our own 
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
>  url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" 
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the 
> password. However, this seems to cause an issue when we try use Solr in a 
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and 
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the 
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
> keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt 
> it, and now everything seems to work great.



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

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

[jira] [Created] (SOLR-9707) DeleteByQuery forward requests to down replicas and set it in LiR

[Jessica Cheng Mallet (JIRA)]

Jessica Cheng Mallet created SOLR-9707:
--

 Summary: DeleteByQuery forward requests to down replicas and set 
it in LiR
 Key: SOLR-9707
 URL: https://issues.apache.org/jira/browse/SOLR-9707
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Reporter: Jessica Cheng Mallet


DeleteByQuery, unlike other requests, does not filter out the down replicas. 
Thus, the update is still forwarded to the down replica and fails, and the 
leader then sets the replica in LiR. In a cluster where there are lots of 
deleteByQuery requests, this can flood the /overseer/queue.



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

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Erik Hatcher (JIRA)]

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

Erik Hatcher commented on SOLR-9623:


bq. ... because it's then easy to enable it with a System property.

Maybe this could be generalized, such that all settings can correspond to a 
"solr.some.key" system property override?   [maybe with a 
solr.system.property.resolver=off setting too]  Just thinking outloud...

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: configset
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



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

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

[jira] [Assigned] (SOLR-9609) Change hard-coded keysize from 512 to 1024

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-9609:


Assignee: Erick Erickson

> Change hard-coded keysize from 512 to 1024
> --
>
> Key: SOLR-9609
> URL: https://issues.apache.org/jira/browse/SOLR-9609
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jeremy Martini
>Assignee: Erick Erickson
> Attachments: SOLR-9609.patch, SOLR-9609.patch, solr.log
>
>
> In order to configure our dataSource without requiring a plaintext password 
> in the configuration file, we extended JdbcDataSource to create our own 
> custom implementation. Our dataSource config now looks something like this:
> {code:xml}
>  url="jdbc:oracle:thin:@db-host-machine:1521:tst1" user="testuser" 
> password="{ENC}{1.1}1ePOfWcbOIU056gKiLTrLw=="/>
> {code}
> We are using the RSA JSAFE Crypto-J libraries for encrypting/decrypting the 
> password. However, this seems to cause an issue when we try use Solr in a 
> Cloud Configuration (using Zookeeper). The error is "Strong key gen and 
> multiprime gen require at least 1024-bit keysize." Full log attached.
> This seems to be due to the hard-coded value of 512 in the 
> org.apache.solr.util.CryptoKeys$RSAKeyPair class:
> {code:java}
> public RSAKeyPair() {
>   KeyPairGenerator keyGen = null;
>   try {
> keyGen = KeyPairGenerator.getInstance("RSA");
>   } catch (NoSuchAlgorithmException e) {
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, e);
>   }
>   keyGen.initialize(512);
> {code}
> I pulled down the Solr code, changed the hard-coded value to 1024, rebuilt 
> it, and now everything seems to work great.



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9481:
--

Hmmm, can this one be closed now since it's been committed back to 6.3 and 6.x?

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[jira] [Updated] (SOLR-9077) Streaming expressions should support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-9077:
---
Attachment: SOLR-9077.patch

First pass at trying to make aliases work. There are no tests yet but existing 
tests pass. This is an approach of refactoring getting slices.

> Streaming expressions should support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
> Attachments: SOLR-9077.patch
>
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Updated] (SOLR-9433) SolrCore clean-up logic uses incorrect path to delete dataDir on failure to create a core

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9433:

Attachment: SOLR-9433.patch

Patch with a fix and test. The data directory needed to be resolved against the 
coreRootDirectory.

> SolrCore clean-up logic uses incorrect path to delete dataDir on failure to 
> create a core
> -
>
> Key: SOLR-9433
> URL: https://issues.apache.org/jira/browse/SOLR-9433
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.2
>Reporter: Evan Sayer
> Attachments: SOLR-9433.patch
>
>
> When a core fails to be created for some reason (errant schema or solrconfig 
> etc.), {{SolrCore.deleteUnloadedCore()}} is called from {{unload()}} in 
> CoreContainer in order to clean-up the possibly left-over {{dataDir}} and 
> {{instanceDir}}.  The problem is that the CoreDescriptor passed to 
> {{SolrCore.deleteUnloadedCore()}} will have its value for {{dataDir}} set to 
> just "data/" unless an explicit {{dataDir}} was specified by the user in the 
> request to create the core, leading to an attempt to delete simply 
> {{"data/"}}, which presumably resolves to a non-existent directory under 
> Solr's home directory or some such.
> https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L974
> https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/java/org/apache/solr/core/SolrCore.java#L2537



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

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

[jira] [Created] (SOLR-9706) fetchIndex blocks incoming queries when issued on a replica in SolrCloud

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-9706:


 Summary: fetchIndex blocks incoming queries when issued on a 
replica in SolrCloud
 Key: SOLR-9706
 URL: https://issues.apache.org/jira/browse/SOLR-9706
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.3, trunk
Reporter: Erick Erickson


This is something of an edge case, but it's perfectly possible to issue a 
fetchIndex command through the core admin API to a replica in SolrCloud. While 
the fetch is going on, incoming queries are blocked. Then when the fetch 
completes, all the queued-up queries execute.

In the normal case, this is probably the proper behavior as a fetchIndex during 
"normal" SolrCloud operation indicates that the replica's index is too far out 
of date and _shouldn't_ serve queries, this is a special case.

Why would one want to do this? Well, in _extremely_ high indexing throughput 
situations, the additional time taken for the leader forwarding the query on to 
a follower is too high. So there is an indexing cluster and a search cluster 
and an external process that issues a fetchIndex to each replica in the search 
cluster periodiclally.

What do people think about an "expert" option for fetchIndex that would cause a 
replica to behave like the old master/slave days and continue serving queries 
while the fetchindex was going on? Or another solution?

FWIW, here's the stack traces where the blocking is going on (6.3 about). This 
is not hard to reproduce if you introduce an artificial delay in the fetch 
command then submit a fetchIndex and try to query.

Blocked query thread(s)
DefaultSolrCoreState.loci(159)
DefaultSolrCoreState.getIndexWriter (104)
SolrCore.openNewSearcher(1781)
SolrCore.getSearcher(1931)
SolrCore.getSearchers(1677)
SolrCore.getSearcher(1577)
SolrQueryRequestBase.getSearcher(115)
QueryComponent.process(308).

The stack trace that releases this is
DefaultSolrCoreState.createMainIndexWriter(240)
DefaultSolrCoreState.changeWriter(203)
DefaultSolrCoreState.openIndexWriter(228) // LOCK RELEASED 2 lines later
IndexFetcher.fetchLatestIndex(493) (approx, I have debugging code in there. 
It's in the "finally" clause anyway.)
IndexFetcher.fetchLatestIndex(251).



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

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

[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7135:


Woops, thanks [~shalinmangar], I fixed it.

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 5.5.4, 6.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8593:
--

Github user risdenk commented on the issue:

https://github.com/apache/lucene-solr/pull/104
  
@joel-bernstein if you push to the `jira/solr-8593` branch it should update 
this PR.


> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



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

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

[jira] [Updated] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7135:
---
Fix Version/s: (was: 6.3)
   6.4

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 5.5.4, 6.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[GitHub] lucene-solr issue #104: SOLR-8593 - WIP

[risdenk]

Github user risdenk commented on the issue:

https://github.com/apache/lucene-solr/pull/104
  
@joel-bernstein if you push to the `jira/solr-8593` branch it should update 
this PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1143 - Still Unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget

Error Message:
Timeout while trying to assert number of documents @ target_collection

Stack Trace:
java.lang.AssertionError: Timeout while trying to assert number of documents @ 
target_collection
at 
__randomizedtesting.SeedInfo.seed([1C85DE39FCF2EECC:BCE74CA32CAB2B89]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.assertNumDocs(BaseCdcrDistributedZkTest.java:273)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testResilienceWithDeleteByQueryOnTarget(CdcrReplicationDistributedZkTest.java:595)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on LUCENE-7135:
---

This issue is marked for 6.3 but it was not backported to branch_6_3. So the 
fix version should be 6.4

> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[jira] [Commented] (SOLR-9311) solrcloud so many connections

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9311:
--

Kent:

Ran across this kind of at random. I know there have been a number of 
improvements in this area in the 5.5.3 and 6.2 time-frames, with at least one 
additional improvement coming in the 6.3 (soon to be released) time frame.

At any rate, there is very little chance that any fixes would be back-ported to 
4.x as development has long been stopped on that branch.

So what do you think about closing this ticket?

Best,
Erick

> solrcloud so many connections
> -
>
> Key: SOLR-9311
> URL: https://issues.apache.org/jira/browse/SOLR-9311
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 4.9
>Reporter: Junfeng Mu
> Attachments: CPU.png, connections.png, shards.png
>
>
> firstly, I do not know wether it is a bug or a wrong usage. if this is a 
> wrong usage, I will opligize to disturb you, and tell me what the wrong usage 
> is.
> We are using Solrj 4.9.1 to connect to a Zookeeper. and the solr server 
> version is 4.9.0 We are currently using CloudSolrServer as a singleton to 
> operate index data, and I believe that solrj to zookeeper is a TCP 
> connection, and zookeeper to solrcloud internal is actually a httpconnection.
> we use the zabbix to monitor the solrcloud status, and we deploy solr in 
> Wildfly(JBOSS), for example the http port is 8180, we find the number that 
> connecting with solr on port 8180 is so high. for now  we find the number can 
> be around 4000, that is too large.and we find that with the increasing 
> connections, the query speed become slow. the CPU of the solr sever is 
> unstable, and the speed to commit new index data becomes slow as well.
> besides, the JDK version is 1.7.25 to running solr server.
> on the other hand, we have 3 cores with 5 shards, and each shard with one 
> leader and one replication. now the data account goes to be 100 million, and 
> it is still growing up.
> please see the screenshot of Zabbix in the attachments.
> please help me, and looking forward to your reply.
> Thanks.
> Kent



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[ASF subversion and git services (JIRA)]

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

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

Commit 1fe1a54db32b8c27bfae81887cd4d75242090613 in lucene-solr's branch 
refs/heads/branch_6_3 from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1fe1a54 ]

Removing 7.0.0 release section and SOLR-9481 from the CHANGES.txt

(cherry picked from commit 2175f6f)


> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[jira] [Commented] (SOLR-9481) BasicAuthPlugin should support standalone mode

[ASF subversion and git services (JIRA)]

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

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

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

Removing 7.0.0 release section and SOLR-9481 from the CHANGES.txt


> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Fix For: 6.x, master (7.0)
>
> Attachments: SOLR-9481.patch, SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC1

[Shalin Shekhar Mangar]

Not good, I'll fix. I added the 7.0 changes to branch_6x by mistake
which is why they ended up in branch_6_3 as well. I'll respin and put
up another RC for a vote.

On Mon, Oct 31, 2016 at 8:24 PM, Steve Rowe  wrote:
> Smoke tester is happy: SUCCESS! [0:24:04.909195]
>
> Docs, javadocs and changes look good, except: Solr CHANGES.txt/Changes.html 
> includes Solr 7.0.0 release notes.  Relatively trivial, but I think worthy of 
> respin, because of the confusion it will cause if left as-is.
>
> --
> Steve
> www.lucidworks.com
>
>> On Oct 31, 2016, at 10:04 AM, Shalin Shekhar Mangar  
>> wrote:
>>
>> Please vote for the first release candidate for Lucene/Solr 6.3.0
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/
>>
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/
>>
>> Smoke tester passed for me:
>> SUCCESS! [0:34:49.638780]
>>
>> Here's my +1 to release.
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>> -
>> 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
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit f9e2f0c5b65b389e330a16657396a922e47fce1d in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f9e2f0c ]

LUCENE-7135: add issue number in CHANGES.txt


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[jira] [Commented] (LUCENE-7135) Constants check for JRE bitness causes SecurityException under WebStart

[ASF subversion and git services (JIRA)]

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

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

Commit 2baad4c22d05a1fcc4a09044eae868b6a5bfe1cf in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2baad4c ]

LUCENE-7135: add issue number in CHANGES.txt


> Constants check for JRE bitness causes SecurityException under WebStart
> ---
>
> Key: LUCENE-7135
> URL: https://issues.apache.org/jira/browse/LUCENE-7135
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/other
>Affects Versions: 5.5
> Environment: OS X 10.11.4, Java 1.8.0_77-b03 (under WebStart)
>Reporter: Aaron Madlon-Kay
> Fix For: master (7.0), 6.3, 5.5.4
>
> Attachments: LUCENE-7135.diff
>
>
> I have an app that I deploy via WebStart that uses Lucene 5.2.1 (we are 
> locked to 5.2.1 because that's what [LanguageTool|https://languagetool.org/] 
> uses).
> When running under the WebStart security manager, there are two locations 
> where exceptions are thrown and prevent pretty much all Lucene classes from 
> initializing. This is true even when we sign everything and specify 
> {{}}.
> # In {{RamUsageEstimator}}, fixed by LUCENE-6923
> # In {{Constants}}, caused by the call 
> {{System.getProperty("sun.arch.data.model")}} (stack trace below).
> {code}
> Error: Caused by: java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "sun.arch.data.model" "read") 
> Error:at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  
> Error:at 
> java.security.AccessController.checkPermission(AccessController.java:884) 
> Error:at 
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549) 
> Error:at 
> com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source) 
> Error:at 
> java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) 
> Error:at java.lang.System.getProperty(System.java:717) 
> Error:at org.apache.lucene.util.Constants.(Constants.java:71) 
> Error:... 34 more 
> {code}
> The latter is still present in the latest version. My patch illustrates one 
> solution that appears to be working for us.
> (This patch, together with a backport of the fix to LUCENE-6923, seems to fix 
> the issue for our purposes. However if you really wanted to make my day you 
> could put out a maintenance release of 5.2 with both fixes included.)



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

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

[jira] [Commented] (SOLR-9681) add filter to any facet

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9681:


OK, unless there are objections, I'll move "filter" to be within "domain".

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Reopened] (SOLR-9681) add filter to any facet

[Yonik Seeley (JIRA)]

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

Yonik Seeley reopened SOLR-9681:


> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option

[Jeremy Anderson (JIRA)]

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

Jeremy Anderson commented on SOLR-8384:
---

It's been a while since I was messing with this.  Essentially I believe I had 
all the binaries in a different path and was starting SOLR.cmd with the -d 
command option to direct it to that directory.  (I may have been doing this so 
that I could package SOLR into a different Jetty instance for a prod style 
deploy) SOLR starts up fine, however the secondary checks performed assume 
those binaries reside in the Default path which they no longer did.  By 
changing them to use the proper new path of SOLR_SERVER_DIR (set by the -d 
option if I recall) everything ran fine and as expected.

Take a look at :set_server_dir which is what is called when starting with the 
-d option.  Here is where SOLR_SERVER_DIR is set. It may be best to also change 
the value of DEFAULT_SERVER_DIR here as well.



> Windows Start Script when Changing SOLR_SERVER_DIR via -d option
> 
>
> Key: SOLR-8384
> URL: https://issues.apache.org/jira/browse/SOLR-8384
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3.1
> Environment: Windows
>Reporter: Jeremy Anderson
>Priority: Trivial
>
> bin\solr.cmd Requires change of environment variables used in the " REM now 
> wait to see Solr come online ..." command.  Currently this call uses 
> DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a 
> different server directory using the -d command option.
> Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries 
> are able to be found when checking that SOLR started.
> There may be other uses in the script where this issue is present when 
> starting SOLR from a different directory other than 'server'.



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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:40456 within 3 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:40456 within 3 ms
at 
__randomizedtesting.SeedInfo.seed([6A8EFB4ACCF3C879:1CB0E4398DC46556]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:182)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:111)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:98)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.waitForAllNodes(MiniSolrCloudCluster.java:233)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:227)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:112)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.createMiniSolrCloudCluster(TestMiniSolrCloudCluster.java:90)
at 
org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:276)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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)

[jira] [Commented] (SOLR-9616) Solr throws exception when expand=true on empty result

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9616:
--

GitHub user timohund opened a pull request:

https://github.com/apache/lucene-solr/pull/106

SOLR-9616 Return empty result, when expand component is used with empty 
result set.

This pull request:

* Add's early return in expand component, when there is nothing to expand
* Add's a regression test for SOLR-9616

Since i am very new to the code i am not sure if this has any other side 
effects, by checking the other tests it looks good for me, but help is 
appreciated.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timohund/lucene-solr SOLR-9616

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/106.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #106


commit 692dec547d22b366099fc328507a847f1e0cf2c8
Author: Timo Schmidt 
Date:   2016-10-31T13:53:52Z

SOLR-9616 Return empty result, when expand component is used with empty 
result set.

* Add's early return in expand component, when there is nothing to expand
* Add's a regression test for SOLR-9616




> Solr throws exception when expand=true on empty result
> --
>
> Key: SOLR-9616
> URL: https://issues.apache.org/jira/browse/SOLR-9616
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2.1
>Reporter: Timo Hund
>Priority: Critical
> Fix For: 6.2.1
>
>
> When i run a query with expand=true with field collapsing and the result set 
> is empty an exception is thrown:
> solr:8984/solr/core_en/select?={!collapse 
> field=pid}=true=10
> Produces:
>   "error":{
> "msg":"Index: 0, Size: 0",
> "trace":"java.lang.IndexOutOfBoundsException: Index: 0, Size: 0\n\tat 
> java.util.ArrayList.rangeCheck(ArrayList.java:653)\n\tat 
> java.util.ArrayList.get(ArrayList.java:429)\n\tat 
> java.util.Collections$UnmodifiableList.get(Collections.java:1309)\n\tat 
> org.apache.solr.handler.component.ExpandComponent.process(ExpandComponent.java:269)\n\tat
>  
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:293)\n\tat
>  
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)\n\tat
>  org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:518)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)\n\tat 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)\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
>  
> 

[GitHub] lucene-solr pull request #106: SOLR-9616 Return empty result, when expand co...

[timohund]

GitHub user timohund opened a pull request:

https://github.com/apache/lucene-solr/pull/106

SOLR-9616 Return empty result, when expand component is used with empty 
result set.

This pull request:

* Add's early return in expand component, when there is nothing to expand
* Add's a regression test for SOLR-9616

Since i am very new to the code i am not sure if this has any other side 
effects, by checking the other tests it looks good for me, but help is 
appreciated.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/timohund/lucene-solr SOLR-9616

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/106.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #106


commit 692dec547d22b366099fc328507a847f1e0cf2c8
Author: Timo Schmidt 
Date:   2016-10-31T13:53:52Z

SOLR-9616 Return empty result, when expand component is used with empty 
result set.

* Add's early return in expand component, when there is nothing to expand
* Add's a regression test for SOLR-9616




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [VOTE] Release Lucene/Solr 6.3.0 RC1

[Steve Rowe]

Smoke tester is happy: SUCCESS! [0:24:04.909195]

Docs, javadocs and changes look good, except: Solr CHANGES.txt/Changes.html 
includes Solr 7.0.0 release notes.  Relatively trivial, but I think worthy of 
respin, because of the confusion it will cause if left as-is.

--
Steve
www.lucidworks.com

> On Oct 31, 2016, at 10:04 AM, Shalin Shekhar Mangar  wrote:
> 
> Please vote for the first release candidate for Lucene/Solr 6.3.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/
> 
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/
> 
> Smoke tester passed for me:
> SUCCESS! [0:34:49.638780]
> 
> Here's my +1 to release.
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> 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-8593) Integrate Apache Calcite into the SQLHandler

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8593:


Avatica 1.9 (and Calcite 1.11) is because this needs avatica-core that doesn't 
do shading. The shading was causing problems integrating into Solr (forget the 
exact errors now). I saw that Calcite 1.10 requires Avatica 1.8 so just copied 
the one offending file for now. Since Avatica 1.9 was just released, I'll 
switch from the SNAPSHOT to the release and should be able to use 1.11 SNAPSHOT 
since the compatibility fixes for 1.9 were included for Calcite now.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



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

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9623:


bq. B. Leave the tag in XML files, but change the variable default from 
true->false

+1 to 'B' because it's then easy to enable it with a System property.  I think 
this better supports some people getting started with Solr, so that they don't 
have to go mucking with solrconfig.xml.

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: configset
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



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

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

[jira] [Commented] (SOLR-8332) factor HttpShardHandler[Factory]'s url shuffling out into a ReplicaListTransformer class

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8332:
---

bq. Creating a new instance of {{ReplicaListTransformer}} for each request is 
wasteful. That is why added the request object as a parameter to each call. 
This way you can manage with a singleton

[#102|https://github.com/apache/lucene-solr/pull/102] supports use of a 
singleton where possible e.g. {{HttpShardHandlerFactory}}'s shuffling 
transformer:
{code}
private final ReplicaListTransformer shufflingReplicaListTransformer = new 
ShufflingReplicaListTransformer(r);
...
ReplicaListTransformer getReplicaListTransformer(final SolrQueryRequest req)
{
  return shufflingReplicaListTransformer;
}
{code}

[#102|https://github.com/apache/lucene-solr/pull/102] also supports use of 
per-request transformers where required (e.g. 
[ReplicaListTransformerTest.java#L96-L111|https://github.com/bloomberg/lucene-solr/blob/master-solr-8332/solr/core/src/test/org/apache/solr/handler/component/ReplicaListTransformerTest.java#L96-L111])
 so that request param deciphering happens only once per prepDistributed call 
rather than repeatedly in each transform call.

> factor HttpShardHandler[Factory]'s url shuffling out into a 
> ReplicaListTransformer class
> 
>
> Key: SOLR-8332
> URL: https://issues.apache.org/jira/browse/SOLR-8332
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8332.patch, SOLR-8332.patch, SOLR-8332.patch
>
>
> Proposed patch against trunk to follow. No change in behaviour intended. This 
> would be as a step towards SOLR-6730.



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

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

[jira] [Commented] (SOLR-9681) add filter to any facet

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9681:


I think I like "filter" underneath "domain".  It's clearer *what* is being 
filtered -- the domain.  Granted that raises the question to users as to what 
the "domain" is but it's something.

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Updated] (LUCENE-7531) Remove packing support from FST

[Adrien Grand (JIRA)]

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

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

Here is a patch.

> Remove packing support from FST
> ---
>
> Key: LUCENE-7531
> URL: https://issues.apache.org/jira/browse/LUCENE-7531
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7531.patch
>
>
> This seems to be only used for the kuromoji dictionaries, but we could easily 
> rebuild those dictionaries with packing disabled.



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

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

[VOTE] Release Lucene/Solr 6.3.0 RC1

[Shalin Shekhar Mangar]

Please vote for the first release candidate for Lucene/Solr 6.3.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/

You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.3.0-RC1-rev11e7e356e15ad5f9e3cfe26966c9dd5f666ece61/

Smoke tester passed for me:
SUCCESS! [0:34:49.638780]

Here's my +1 to release.

-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (SOLR-9681) add filter to any facet

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9681:


Now that you've made me think about it... I'm definitely on the fence, and 
perhaps closer to the "just put it in domain" side.  Anyone else have thoughts? 
 This is the right time to think about this minor API stuff, and then stick to 
it for the long haul!

"domain" is only for non-narrowing domain changes:
- If filtering will be used a lot by itself, then it's simpler not to have to 
enclose it in an extra "domain"

"domain" is for *all* domain changes prior to faceting:
- If filtering will primarily be used with things like blockChildren, "domain" 
will already exist, and it's natural for the additional child filters to go 
right there.
- The *only* "narrowing" way to change the domain (other than faceting itself), 
is "filter".  There are unlikely to be others in the future, and thus having a 
separate class/distinction at the syntactic level does not seem important.

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Comment Edited] (SOLR-9681) add filter to any facet

[Yonik Seeley (JIRA)]

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

Yonik Seeley edited comment on SOLR-9681 at 10/31/16 1:58 PM:
--

Now that you've made me think about it... I'm definitely on the fence, and 
perhaps closer to the "just put it in domain" side.  Anyone else have thoughts? 
 This is the right time to think about this minor API stuff, and then stick to 
it for the long haul!

Thoughts about both sides:
"domain" is only for non-narrowing domain changes:
- If filtering will be used a lot by itself, then it's simpler not to have to 
enclose it in an extra "domain"

"domain" is for *all* domain changes prior to faceting:
- If filtering will primarily be used with things like blockChildren, "domain" 
will already exist, and it's natural for the additional child filters to go 
right there.
- The *only* "narrowing" way to change the domain (other than faceting itself), 
is "filter".  There are unlikely to be others in the future, and thus having a 
separate class/distinction at the syntactic level does not seem important.


was (Author: ysee...@gmail.com):
Now that you've made me think about it... I'm definitely on the fence, and 
perhaps closer to the "just put it in domain" side.  Anyone else have thoughts? 
 This is the right time to think about this minor API stuff, and then stick to 
it for the long haul!

"domain" is only for non-narrowing domain changes:
- If filtering will be used a lot by itself, then it's simpler not to have to 
enclose it in an extra "domain"

"domain" is for *all* domain changes prior to faceting:
- If filtering will primarily be used with things like blockChildren, "domain" 
will already exist, and it's natural for the additional child filters to go 
right there.
- The *only* "narrowing" way to change the domain (other than faceting itself), 
is "filter".  There are unlikely to be others in the future, and thus having a 
separate class/distinction at the syntactic level does not seem important.

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Commented] (SOLR-1691) Deal with deleting old index files in Windows auto-magicly

[JIRA]

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

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

Is this a practical problem anymore? I have not seen evidence that people 
suffer from this, and noone have proiritized working on it last 4 years. 
CLOSE-candidate?

> Deal with deleting old index files in Windows auto-magicly
> --
>
> Key: SOLR-1691
> URL: https://issues.apache.org/jira/browse/SOLR-1691
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> Windows users are frequently confused/frustrated by the size of an index 
> after making lots of changes/commits because of the way Windows prevents 
> files with open handles from being deleted.
> In Lucene-Java, IndexWriter will attempt to delete any old files whenever it 
> can, but only on a subsequent change -- we should see if we could add 
> something to Solr to try and be more proactive about this...
> http://old.nabble.com/Delete%2C-commit%2C-optimize-doesn%27t-reduce-index-file-size-to26958067.html



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

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

[jira] [Created] (LUCENE-7531) Remove packing support from FST

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7531:


 Summary: Remove packing support from FST
 Key: LUCENE-7531
 URL: https://issues.apache.org/jira/browse/LUCENE-7531
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand
Priority: Minor


This seems to be only used for the kuromoji dictionaries, but we could easily 
rebuild those dictionaries with packing disabled.



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

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

[jira] [Commented] (SOLR-8998) JSON Facet API child roll-ups

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8998:


[~ysee...@gmail.com], is it possible to implement {{rollup(type_s:parent)}} 
which does what {{unique(_root_)}} in a way how 
{{o.a.s.s.join.BlockJoinFieldFacetAccumulator}} enumerating docset once, 
without running through per value docsets one by one as it happens with 
{{unique()}} now?

> JSON Facet API child roll-ups
> -
>
> Key: SOLR-8998
> URL: https://issues.apache.org/jira/browse/SOLR-8998
> Project: Solr
>  Issue Type: New Feature
>  Components: Facet Module
>Reporter: Yonik Seeley
>
> The JSON Facet API currently has the ability to map between parents and 
> children ( see http://yonik.com/solr-nested-objects/ )
> This issue is about adding a true rollup ability where parents would take on 
> derived values from their children.  The most important part (and the most 
> difficult part) will be the external API.



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

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

[jira] [Commented] (SOLR-8384) Windows Start Script when Changing SOLR_SERVER_DIR via -d option

[JIRA]

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

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

As I can see that command is correct, it only uses DEFAULT_SERVER_DIR to find 
the SolrCLI tool, which is then looking for a running Solr over HTTP.
Please detail exactly what caused you problems? Did you delete the solr/server 
directory so the binary could not be found?

> Windows Start Script when Changing SOLR_SERVER_DIR via -d option
> 
>
> Key: SOLR-8384
> URL: https://issues.apache.org/jira/browse/SOLR-8384
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.3.1
> Environment: Windows
>Reporter: Jeremy Anderson
>Priority: Trivial
>
> bin\solr.cmd Requires change of environment variables used in the " REM now 
> wait to see Solr come online ..." command.  Currently this call uses 
> DEFAULT_SERVER_DIR which is no longer correct when starting SOLR with a 
> different server directory using the -d command option.
> Replace DEFAULT_SERVER_DIR with SOLR_SERVER_DIR so that the proper libraries 
> are able to be found when checking that SOLR started.
> There may be other uses in the script where this issue is present when 
> starting SOLR from a different directory other than 'server'.



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

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

[jira] [Commented] (SOLR-9246) Errors for Streaming Expressions using JDBC (Oracle) stream source

[Aaron Danielson (JIRA)]

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

Aaron Danielson commented on SOLR-9246:
---

The 'Caused by: ...' portion of the error message was never printed for me.  My 
column was using type DECIMAL, but JDBC only understands FLOAT or DOUBLE, so 
this took some serious time to figure out the issue without a more explicit 
error message.  For what it's worth, it would be really nice if the driver 
could automatically map column types of DECIMAL to FLOAT.

> Errors for Streaming Expressions using JDBC (Oracle) stream source
> --
>
> Key: SOLR-9246
> URL: https://issues.apache.org/jira/browse/SOLR-9246
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0.1
> Environment: Windows 7
>Reporter: Hui Liu
>Assignee: Dennis Gove
> Fix For: 6.0.2, 6.1.1, 6.2, master (7.0)
>
> Attachments: Re Errors for Streaming Expressions using JDBC (Oracle) 
> stream source.txt, SOLR-9246.patch
>
>
> I have Solr 6.0.0 installed on my PC (windows 7), I was experimenting with 
> ‘Streaming Expression’ by using Oracle jdbc as the 
> stream source, but got 'null pointer' errors, below is the details on how to 
> reproduce this error:
> 1. create a collection 'document6' which only contain long and string data 
> type, 
> schema.xml for Solr collection 'document6': (newly created empty collections 
> with 2 shards) 
> ===
> 
>   
>  
>  
>   docValues="true" />
>   precisionStep="0" positionIncrementGap="0"/>
>  
> 
>
> 
>   
>omitNorms="true"/>
>
>
>   multiValued="false"/>
>   docValues="true"/>
>   docValues="true"/>
>   docValues="true"/>
>   docValues="true"/>
>   docValues="true"/>
>
>   document_id
>   document_id
> 
> 2. create a new Oracle (version 11.2.0.3) table 'document6' that only contain 
> columns whose jdbc type is long and string, 
> create table document6 
> (document_id number(12) not null,
>  sender_msg_dest varchar2(256),
>  recip_msg_dest  varchar2(256),
>  document_type   varchar2(20),
>  document_keyvarchar2(100));
> loaded 9 records;
> Oracle table 'document6': (newly created Oracle table with 9 records) 
> =
> QA_DOCREP@qlgdb1 > desc document6
>  Name  Null?Type
>  -  
> 
>  DOCUMENT_ID   NOT NULL NUMBER(12)
>  SENDER_MSG_DESTVARCHAR2(256)
>  RECIP_MSG_DEST VARCHAR2(256)
>  DOCUMENT_TYPE  VARCHAR2(20)
>  DOCUMENT_KEY   VARCHAR2(100)
> 3. tried this jdbc streaming expression in my browser, getting the error 
> stack (see below)
> http://localhost:8988/solr/document6/stream?expr=jdbc(connection="jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql="SELECT
>  document_id,sender_msg_dest,recip_msg_dest,document_type,document_key FROM 
> document6",sort="document_id asc",driver="oracle.jdbc.driver.OracleDriver")
> errors in solr.log
> ==
> 2016-06-23 14:07:02.833 INFO  (qtp1389647288-139) [c:document6 s:shard2 
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.S.Request 
> [document6_shard2_replica1]  webapp=/solr path=/stream 
> params={expr=jdbc(connection%3D"jdbc:oracle:thin:qa_docrep/abc...@lit-racq01-scan.qa.gxsonline.net:1521/qlgdb",sql%3D"SELECT+document_id,sender_msg_dest,recip_msg_dest,document_type,document_key+FROM+document6",sort%3D"document_id+asc",driver%3D"oracle.jdbc.driver.OracleDriver")}
>  status=0 QTime=1
> 2016-06-23 14:07:05.282 ERROR (qtp1389647288-139) [c:document6 s:shard2 
> r:core_node1 x:document6_shard2_replica1] o.a.s.c.s.i.s.ExceptionStream 
> java.lang.NullPointerException
>   at 
> org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:305)
>   at 
> org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:64)
>   at 
> org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:374)
>   at 
> org.apache.solr.response.TextResponseWriter.writeTupleStream(TextResponseWriter.java:305)
>   at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:167)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:183)
>   at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:299)
>   at 
> 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail

Error Message:
expected:<200> but was:<404>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<404>
at 
__randomizedtesting.SeedInfo.seed([73D32783679D0714:1B6C12A9B70715F8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.cancelDelegationToken(TestSolrCloudWithDelegationTokens.java:140)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenCancelFail(TestSolrCloudWithDelegationTokens.java:294)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
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] [Commented] (SOLR-9681) add filter to any facet

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9681:


ok. Agree. Now it can be seen as {{domain}} executed strictly before filtering 
and faceting.  

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Commented] (SOLR-7105) Running Solr as a windows service

[JIRA]

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

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

Also check out SOLR-5176 for an attractive alternative for providing Windows 
installer support. Chocolatey is like apt-get and keeps a central registry of 
installer scripts, typically Powershell, and will install unattended.

> Running Solr as a windows service
> -
>
> Key: SOLR-7105
> URL: https://issues.apache.org/jira/browse/SOLR-7105
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
> Fix For: 6.0
>
>
> Since we moved away from shipping a war, it's useful to have scripts to start 
> Solr as a service.
> In 5.0 we already added a script for unix systems, we should also add one for 
> windows.
> The Commons Daemon project seems like a good way to implement it - 
> http://commons.apache.org/proper/commons-daemon/procrun.html



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

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

[jira] [Closed] (SOLR-8986) Windows solr.cmd seems to require -p 8983

[JIRA]

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

Jan Høydahl closed SOLR-8986.
-
Resolution: Won't Fix

Closing this as it is for an old version of Solr, and people are encouraged to 
upgrade to 6.x. If anyone feel strongly about including a fix for a potential 
5.5.x bugfix-release, then feel free to re-open :-) 

> Windows solr.cmd seems to require -p 8983
> -
>
> Key: SOLR-8986
> URL: https://issues.apache.org/jira/browse/SOLR-8986
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
> Attachments: start-solr-on-windows.png
>
>




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

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

[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983

[JIRA]

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

Jan Høydahl updated SOLR-8986:
--
Comment: was deleted

(was: The CHANGES.txt commits were actually for SOLR-8996. Sorry for noise on 
this ticket.)

> Windows solr.cmd seems to require -p 8983
> -
>
> Key: SOLR-8986
> URL: https://issues.apache.org/jira/browse/SOLR-8986
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
> Attachments: start-solr-on-windows.png
>
>




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

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

[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983

[JIRA]

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

Jan Høydahl updated SOLR-8986:
--
Comment: was deleted

(was: Commit df72df1c58a5884774d003eec2f71c27a4737896 in lucene-solr's branch 
refs/heads/branch_6x from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df72df1 ]

SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt

Conflicts:
solr/CHANGES.txt
)

> Windows solr.cmd seems to require -p 8983
> -
>
> Key: SOLR-8986
> URL: https://issues.apache.org/jira/browse/SOLR-8986
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
> Attachments: start-solr-on-windows.png
>
>




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

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

[jira] [Issue Comment Deleted] (SOLR-8986) Windows solr.cmd seems to require -p 8983

[JIRA]

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

Jan Høydahl updated SOLR-8986:
--
Comment: was deleted

(was: Commit 62a28dd0c7dc8f41e43d5c37e28c968556b8e9d2 in lucene-solr's branch 
refs/heads/master from jbernste
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=62a28dd ]

SOLR-8986, SOLR-8925, SOLR-9027: Update CHANGES.txt
)

> Windows solr.cmd seems to require -p 8983
> -
>
> Key: SOLR-8986
> URL: https://issues.apache.org/jira/browse/SOLR-8986
> Project: Solr
>  Issue Type: Bug
>Reporter: Bill Bell
> Attachments: start-solr-on-windows.png
>
>




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

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

[jira] [Commented] (SOLR-9681) add filter to any facet

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9681:


I could go either way...
I was sort of viewing "domain" to be just about non-narrowing domain switches 
(filter exclusions, parent/child, block join)

> add filter to any facet
> ---
>
> Key: SOLR-9681
> URL: https://issues.apache.org/jira/browse/SOLR-9681
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9681.patch
>
>
> For the JSON Facet API, we should be able to add a list of filters to any 
> facet.  These would be applied after any domain changes, hence useful for 
> parent->child mapping that would otherwise match all children of any parent 
> (SOLR-9510)
> The API should also be consistent with "filter" at the top level of the JSON 
> Request API (examples at http://yonik.com/solr-json-request-api/ )



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

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

[jira] [Closed] (SOLR-3421) Distributed Search doesn't allow for HTTP Authentication

[JIRA]

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

Jan Høydahl closed SOLR-3421.
-
Resolution: Implemented

Closing as implemented, as we got built-in Auth with support for SolrCloud in 
5.3. We'll also get Auth support for plain old master/slave search with 
SOLR-9640.

> Distributed Search doesn't allow for HTTP Authentication
> 
>
> Key: SOLR-3421
> URL: https://issues.apache.org/jira/browse/SOLR-3421
> Project: Solr
>  Issue Type: New Feature
>  Components: SearchComponents - other
>Affects Versions: 3.6, 4.0-ALPHA
> Environment: Sharded solr cluster
>Reporter: Michael Della Bitta
>Priority: Minor
>  Labels: auth, distributed_search, ssl
>
> The distributed search feature allows one to configure the list of shards the 
> SearchHandler should query and aggregate results from using the "shards" 
> parameter. Unfortunately, there is no way to configure any sort of 
> authentication between shards and a distributed search-enabled SearchHandler. 
> It'd be good to be able to specify an authentication type, auth credentials, 
> and transport security to allow installations that don't have the benefit of 
> being protected by a firewall some measure of security.



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

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

[jira] [Commented] (SOLR-2240) Basic authentication for stream.url

[JIRA]

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

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

Is this still something that is desired? This issue is pretty old and without 
much activity, so if noone steps up, I'll close it as Won't fix.

> Basic authentication for stream.url
> ---
>
> Key: SOLR-2240
> URL: https://issues.apache.org/jira/browse/SOLR-2240
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 4.0-ALPHA
>Reporter: Jayendra Patil
>Priority: Minor
> Attachments: SOLR-2240.patch
>
>
> We intend to use stream.url for indexing documents from remote locations 
> exposed through http.
> However, the remote urls are secured and would need basic authentication to 
> be able access the documents.
> The current implementation for stream.url in ContentStreamBase.URLStream does 
> not support authentication.
> The implementation with stream.file would mean to download the files to a 
> local box and would cause duplicity, whereas stream.body would have indexing 
> performance issues with the hugh data being transferred over the network.
> An approach would be :-
> 1. Passing additional authentication parameter e.g. stream.url.auth with the 
> encoded authentication value - SolrRequestParsers
> 2. Setting Authorization request property for the Connection - 
> ContentStreamBase.URLStream
> this.conn.setRequestProperty("Authorization", "Basic " + 
> encodedauthentication);
> Any thoughts ??



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

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

[jira] [Commented] (SOLR-608) scripts using curl should support authentication params

[JIRA]

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

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

Could we not instead simply delete the whole {{scripts/}} folder ?

> scripts using curl should support authentication params
> ---
>
> Key: SOLR-608
> URL: https://issues.apache.org/jira/browse/SOLR-608
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (scripts)
>Reporter: Hoss Man
>
> All scripts that utilize "curl" should be enhanced such that user 
> authentication based params can be specified and used by curl.  This would 
> make it possible for people to "secure" their Solr servers using Servlet 
> Container authentication features, but still interact with those Solr 
> instances using the scripts out of the box.
> The most straight forward approach would probably be to add a new "curl_args" 
> option in scripts.conf that could could contain any legal curl command line 
> options and would be prepended to the args for all usages of curl in the Solr 
> scripts.
>  



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

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

[jira] [Resolved] (SOLR-9370) Add sample code snippet to confluence documentaion for Basic Authentication

[JIRA]

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

Jan Høydahl resolved SOLR-9370.
---
Resolution: Fixed

Updated RefGuide for 5.3.

> Add sample code snippet to confluence documentaion for Basic Authentication
> ---
>
> Key: SOLR-9370
> URL: https://issues.apache.org/jira/browse/SOLR-9370
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Susheel Kumar
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 6.3
>
>
> Please add below code snippet to under "Using BasicAuth with SolrJ"  as 
> current code "snippet" doesn't give visibility on how basic authentication 
> can be set when querying
> How to set credentials when querying using SolrJ - Basic Authentication
> =
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> // Do any other query setup needed.
> SolrRequest req = new QueryRequest(query);
> req.setBasicAuthCredentials(userName, password); 
> QueryResponse rsp = req.process(solrClient, collection);



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

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

[jira] [Assigned] (SOLR-9370) Add sample code snippet to confluence documentaion for Basic Authentication

[JIRA]

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

Jan Høydahl reassigned SOLR-9370:
-

Assignee: Jan Høydahl

> Add sample code snippet to confluence documentaion for Basic Authentication
> ---
>
> Key: SOLR-9370
> URL: https://issues.apache.org/jira/browse/SOLR-9370
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Susheel Kumar
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 6.3
>
>
> Please add below code snippet to under "Using BasicAuth with SolrJ"  as 
> current code "snippet" doesn't give visibility on how basic authentication 
> can be set when querying
> How to set credentials when querying using SolrJ - Basic Authentication
> =
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> // Do any other query setup needed.
> SolrRequest req = new QueryRequest(query);
> req.setBasicAuthCredentials(userName, password); 
> QueryResponse rsp = req.process(solrClient, collection);



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

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

[jira] [Updated] (SOLR-9370) Add sample code snippet to confluence documentaion for Basic Authentication

[JIRA]

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

Jan Høydahl updated SOLR-9370:
--
Fix Version/s: 6.3

> Add sample code snippet to confluence documentaion for Basic Authentication
> ---
>
> Key: SOLR-9370
> URL: https://issues.apache.org/jira/browse/SOLR-9370
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Susheel Kumar
>Assignee: Jan Høydahl
>Priority: Minor
> Fix For: 6.3
>
>
> Please add below code snippet to under "Using BasicAuth with SolrJ"  as 
> current code "snippet" doesn't give visibility on how basic authentication 
> can be set when querying
> How to set credentials when querying using SolrJ - Basic Authentication
> =
> SolrQuery query = new SolrQuery();
> query.setQuery("*:*");
> // Do any other query setup needed.
> SolrRequest req = new QueryRequest(query);
> req.setBasicAuthCredentials(userName, password); 
> QueryResponse rsp = req.process(solrClient, collection);



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

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

[jira] [Commented] (SOLR-9399) Delete requests do not send credentials & fails for Basic Authentication

[JIRA]

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

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

I think this won't make it for 6.3 unless someone can get the unit test straight

> Delete requests do not send credentials & fails for Basic Authentication
> 
>
> Key: SOLR-9399
> URL: https://issues.apache.org/jira/browse/SOLR-9399
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.0, 6.0.1, 6.x
>Reporter: Susheel Kumar
>  Labels: security
>
> The getRoutes(..) func of UpdateRequest do not pass credentials to 
> LBHttpSolrClient when deleteById is set while for updates it passes the 
> credentials.  See below code snippet
>   if (deleteById != null) {
>   
>   Iterator>> entries = 
> deleteById.entrySet()
>   .iterator();
>   while (entries.hasNext()) {
> 
> Map.Entry> entry = entries.next();
> 
> String deleteId = entry.getKey();
> Map map = entry.getValue();
> Long version = null;
> if (map != null) {
>   version = (Long) map.get(VER);
> }
> Slice slice = router.getTargetSlice(deleteId, null, null, null, col);
> if (slice == null) {
>   return null;
> }
> List urls = urlMap.get(slice.getName());
> if (urls == null) {
>   return null;
> }
> String leaderUrl = urls.get(0);
> LBHttpSolrClient.Req request = routes.get(leaderUrl);
> if (request != null) {
>   UpdateRequest urequest = (UpdateRequest) request.getRequest();
>   urequest.deleteById(deleteId, version);
> } else {
>   UpdateRequest urequest = new UpdateRequest();
>   urequest.setParams(params);
>   urequest.deleteById(deleteId, version);
>   urequest.setCommitWithin(getCommitWithin());
>   request = new LBHttpSolrClient.Req(urequest, urls);
>   routes.put(leaderUrl, request);
> }
>   }
> }



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

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

[jira] [Commented] (SOLR-9342) Solr GC logging not respecting user timezone

[JIRA]

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

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

Do we even control the GC logging? It is the JVM that owns that log. 
Have you tried the answer in this thread, setting TZ=PST in the shell where you 
start Solr? 
http://stackoverflow.com/questions/36338364/how-to-specify-time-zone-for-javas-gc-log

> Solr GC logging not respecting user timezone 
> -
>
> Key: SOLR-9342
> URL: https://issues.apache.org/jira/browse/SOLR-9342
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> When I start Solr with say {{-Duser.timezone=PST}} the solr logging correctly 
> logs in the specified timezone.
> However the solr gc logging is still using my machines default timezone. This 
> can be very confusing and make debugging very tough.



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

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

[jira] [Closed] (SOLR-7025) bin/solr.cmd: Improve java detection and error messages

[JIRA]

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

Jan Høydahl closed SOLR-7025.
-
Resolution: Not A Problem

I think this is not a problem anymore and Java detection on Windows has been 
improved since January 2015.

Please re-open this issue if you feel there is still a problem that should be 
solved.

> bin/solr.cmd: Improve java detection and error messages
> ---
>
> Key: SOLR-7025
> URL: https://issues.apache.org/jira/browse/SOLR-7025
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
> Fix For: 5.0
>
>
> Similar to SOLR-7024, java detection needs an overhaul for Windows as well.



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

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

[jira] [Commented] (SOLR-9442) Add json.nl=arrnvp (array of NamedValuePair) style in JSONResponseWriter

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9442: Adds Array of NamedValuePair (json.nl=arrnvp) style to 
JSONResponseWriter. (Jonny Marks, Christine Poerschke)


> Add json.nl=arrnvp (array of NamedValuePair) style in JSONResponseWriter
> 
>
> Key: SOLR-9442
> URL: https://issues.apache.org/jira/browse/SOLR-9442
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9442.patch, SOLR-9442.patch, SOLR-9442.patch
>
>
> The JSONResponseWriter class currently supports several styles of NamedList 
> output format, documented on the wiki at http://wiki.apache.org/solr/SolJSON 
> and in the code at 
> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/response/JSONResponseWriter.java#L71-L76.
> For example the 'arrmap' style:
> {code}NamedList("a"=1,"b"=2,null=3) => [{"a":1},{"b":2},3]
> NamedList("a"=1,"bar”=“foo",null=3.4f) => [{"a":1},{"bar”:”foo"},{3.4}]{code}
> This patch creates a new style ‘arrnvp’ which is an array of named value 
> pairs. For example:
> {code}NamedList("a"=1,"b"=2,null=3) => 
> [{"name":"a","int":1},{"name":"b","int":2},{"int":3}]
> NamedList("a"=1,"bar”=“foo",null=3.4f) => 
> [{"name":"a","int":1},{"name":"b","str":"foo"},{"float":3.4}]{code}
> This style maintains the type information of the values, similar to the xml 
> format:
> {code:xml}
>   1
>   foo
>   3.4
> {code}



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

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

[jira] [Closed] (SOLR-7460) bin/solr start command shows an error when used with Java 1.7.0 - bin/solr: line 1290: [[: .0: syntax error: operand expected (error token is ".0")

[JIRA]

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

Jan Høydahl closed SOLR-7460.
-
Resolution: Won't Fix

The script has been rewritten and now Java8 is a requirement for both master 
and 6.x, so the minor version tests are gone.

We won't fix this for the end-of-life 5.x series. Closing.


> bin/solr start command shows an error when used with Java 1.7.0 - bin/solr: 
> line 1290: [[: .0: syntax error: operand expected (error token is ".0")
> ---
>
> Key: SOLR-7460
> URL: https://issues.apache.org/jira/browse/SOLR-7460
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.1
>Reporter: Prasanta Behera
>Priority: Trivial
>  Labels: easyfix, easytest
> Attachments: screenshot-1.png, screenshot.png
>
>
> I am trying to start Solr 5.1.0 using Java 1.7.0, Solr does start but I see 
> this error:
> $ bin/solr start
> bin/solr: line 1290: [[: .0: syntax error: operand expected (error token is 
> ".0")
> Waiting to see Solr listening on port 8983 [/]  
> Started Solr server on port 8983 (pid=13627). Happy searching!
> Digging further, I saw in solr script:
> 1285   JAVA_VERSION=`echo "$("$JAVA" -version 2>&1)" | grep "java version" | 
> awk '{ print substr($3, 2, length($3)-2); }'`
> 1286   if [ "${JAVA_VERSION:0:3}" == "1.7" ]; then
> 1287 # Specific Java version hacking
> 1288 #GC_TUNE+=('-XX:CMSFullGCsBeforeCompaction=1' 
> '-XX:CMSTriggerPermRatio=80')
> 1289 JAVA_MINOR_VERSION=${JAVA_VERSION:(-2)}
> 1290 if [[ $JAVA_MINOR_VERSION -ge 40 && $JAVA_MINOR_VERSION -le 51 ]]; 
> then
> 1291   GC_TUNE+=('-XX:-UseSuperWord')
> 1292   echo -e "\nWARNING: Java version $JAVA_VERSION has known bugs with 
> Lucene and requires the -XX:-UseSuperWord flag. Please consider upgrading 
> your JVM.\n"
> When JAVA_VERSION is 1.7.0 to 1.7.9 the line (#1289):
> JAVA_MINOR_VERSION=${JAVA_VERSION:(-2)}
> will evaluate JAVA_MINOR_VERSION as .0 hence the if check that follows fails.
> The above code would work fine for Java versions 1.7.10 and above
> This line should be changed to (chop the string 4 positions from start to get 
> the minor version, instead of chopping 2 positions from the end)
> JAVA_MINOR_VERSION=${JAVA_VERSION:(4)}



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

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