[jira] [Commented] (SOLR-8973) TX-frenzy on Zookeeper when collection is put to use

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8973:


+1 Scott!

> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Fix For: master, 6.1
>
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/459/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.TestSolrCloudWithKerberosAlt.testBasics

Error Message:
Address already in use

Stack Trace:
java.net.BindException: Address already in use
at 
__randomizedtesting.SeedInfo.seed([CAD607DC9BC14B87:F70EA9F0A32F15F7]:0)
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:252)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:49)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:525)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$200(AbstractPollingIoAcceptor.java:67)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:409)
at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:34379/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:34379/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([CAD607DC9BC14B87:42823806353D267F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[JENKINS] Lucene-Solr-Tests-master - Build # 1093 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1093/

3 tests failed.
FAILED:  org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 45 
seconds
at 
__randomizedtesting.SeedInfo.seed([CBAA28F765515BEF:43FE172DCBAD3617]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:173)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:858)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:73)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_72) - Build # 16546 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16546/
Java: 32bit/jdk1.8.0_72 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'null' for path 'response/params/y/p' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":4, "params":{   "x":{ "a":"A val", 
"b":"B val", "_appends_":{"add":"first"}, 
"_invariants_":{"fixed":"f"}, "":{"v":1}},   "y":{ "p":"P 
val", "q":"Q val", "":{"v":2},  from server:  
https://127.0.0.1:37695/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'null' for path 
'response/params/y/p' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":4,
"params":{
  "x":{
"a":"A val",
"b":"B val",
"_appends_":{"add":"first"},
"_invariants_":{"fixed":"f"},
"":{"v":1}},
  "y":{
"p":"P val",
"q":"Q val",
"":{"v":2},  from server:  https://127.0.0.1:37695/collection1
at 
__randomizedtesting.SeedInfo.seed([86C06251809C8839:E945D8B2E60E5C1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:457)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:259)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:62)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 469 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/469/

No tests ran.

Build Log:
[...truncated 40519 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (10.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 28.6 MB in 0.16 sec (175.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 62.9 MB in 0.05 sec (1186.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 73.5 MB in 0.06 sec (1189.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5997 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5997 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 218 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (211.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 37.7 MB in 0.33 sec (115.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 132.0 MB in 1.80 sec (73.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 140.5 MB in 2.51 sec (55.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]  

[jira] [Closed] (SOLR-8409) Complex q param in Streaming Expression results in a bad query

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-8409.
-
   Resolution: Fixed
 Assignee: Dennis Gove
Fix Version/s: 6.0
   master

> Complex q param in Streaming Expression results in a bad query
> --
>
> Key: SOLR-8409
> URL: https://issues.apache.org/jira/browse/SOLR-8409
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: master
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
>  Labels: streaming, streaming_api
> Fix For: master, 6.0
>
> Attachments: SOLR-8409.patch, SOLR-8409.patch
>
>
> When providing an expression like 
> {code}
> stream=search(people, fl="id,first", sort="first asc", 
> q="presentTitles:\"chief executive officer\" AND age:[36 TO *]")
> {code}
> the following error is seen.
> {code}
> no field name specified in query and no default specified via 'df' param
> {code}
> I believe the issue is related to the \" (escaped quotes) and the spaces in 
> the q field. If I remove the spaces then the query returns results as 
> expected (though I've yet to validate if those results are accurate).
> This requires some investigation to get down to the root cause. I would like 
> to fix it before Solr 6 is cut.



--
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-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8933:

Attachment: SOLR-8933.patch

I thought I got all of the test failures previously, looks like I missed two 
usages though. Pretty confident that I got them this time, thanks for verifying 
as well, [~markrmil...@gmail.com]

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/87/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.lucene.index.TestPointValues.testMergedStats

Error Message:
maxMBSortInHeap=4.262770313255057 only allows for maxPointsSortInHeap=1995, but 
this is less than maxPointsInLeafNode=2032; either increase maxMBSortInHeap or 
decrease maxPointsInLeafNode

Stack Trace:
java.lang.IllegalArgumentException: maxMBSortInHeap=4.262770313255057 only 
allows for maxPointsSortInHeap=1995, but this is less than 
maxPointsInLeafNode=2032; either increase maxMBSortInHeap or decrease 
maxPointsInLeafNode
at 
__randomizedtesting.SeedInfo.seed([B9F0908C1C66851C:80CA747CA06C9C09]:0)
at org.apache.lucene.util.bkd.BKDWriter.(BKDWriter.java:209)
at 
org.apache.lucene.index.RandomCodec$RandomlySplittingBKDWriter.(RandomCodec.java:280)
at 
org.apache.lucene.index.RandomCodec$1$1.writeField(RandomCodec.java:124)
at 
org.apache.lucene.codecs.asserting.AssertingPointsFormat$AssertingPointsWriter.writeField(AssertingPointsFormat.java:257)
at 
org.apache.lucene.index.PointValuesWriter.flush(PointValuesWriter.java:71)
at 
org.apache.lucene.index.DefaultIndexingChain.writePoints(DefaultIndexingChain.java:172)
at 
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:107)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:423)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
at 
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:428)
at 
org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79)
at 
org.apache.lucene.index.TestPointValues.doTestMergedStats(TestPointValues.java:685)
at 
org.apache.lucene.index.TestPointValues.testMergedStats(TestPointValues.java:658)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Resolved] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[Scott Blum (JIRA)]

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

Scott Blum resolved SOLR-8929.
--
Resolution: Fixed

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8929) Add an idea module for solr/server to enable launching start.jar

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8929:
-
Fix Version/s: 6.1
   master

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8970) SSLTestConfig behaves really stupid if keystore can't be found

[Hoss Man (JIRA)]

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

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

bq. It would be nice if the keystore blob was included in the test jar...

Agreed, but I think that would be a lot trickier? ... i'm pretty sure the way 
the keystore field is currently used in tests involves letting jetty load the 
file itself via a path specified in the jetty.xml test config?  in any case -- 
adding a sysprop to override seems like a good first step for now.

I'm attaching a patch with what i've got so far -- but i'm putting this on the 
back burner until i verify it's working sanely with clientAuth ... AFAICT at 
the moment, the clientAuth randomization isn't actually resulting in clientAuth 
being required anywhere!

> SSLTestConfig behaves really stupid if keystore can't be found
> --
>
> Key: SOLR-8970
> URL: https://issues.apache.org/jira/browse/SOLR-8970
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: SOLR-8970.patch
>
>
> The SSLTestConfig constructor lets the call (notable SolrTestCaseJ4) tell it 
> wether clientAuth should be used (note SolrTestCaseJ4 calls this boolean 
> "trySslClientAuth") but it has a hardcoded assumption that the keystore file 
> it can use (for both the keystore and the truststore) will exist at a fixed 
> path in the solr install.
> when this works, it works fine - but if end users subclass/reuse 
> SolrTestCaseJ4 in their own projects, they may do so in a way that prevents 
> the SSLTestConfig keystore assumptions from being true, and yet they won't 
> get any sort of clear error.



--
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.0-Linux (64bit/jdk1.8.0_72) - Build # 133 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.0-Linux/133/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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


FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

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([39D7393AEA88B085]:0)




Build Log:
[...truncated 12489 lines...]
   [junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
   [junit4]   2> 1918448 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1918448 INFO  (Thread-5125) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1918448 INFO  (Thread-5125) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1918548 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.ZkTestServer start zk server on port:44875
   [junit4]   2> 1918548 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1918549 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1918570 INFO  (zkCallback-2327-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@66d898b0 
name:ZooKeeperConnection Watcher:127.0.0.1:44875 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1918570 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1918570 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1918571 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[39D7393AEA88B085]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 1918624 INFO  (jetty-launcher-2326-thread-3) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1918624 INFO  (jetty-launcher-2326-thread-4) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1918624 INFO  (jetty-launcher-2326-thread-5) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1918624 INFO  (jetty-launcher-2326-thread-1) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1918624 INFO  (jetty-launcher-2326-thread-2) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 1918626 INFO  (jetty-launcher-2326-thread-3) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@15438be3{/solr,null,AVAILABLE}
   [junit4]   2> 1918626 INFO  (jetty-launcher-2326-thread-5) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@32861bfa{/solr,null,AVAILABLE}
   [junit4]   2> 1918626 INFO  (jetty-launcher-2326-thread-4) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@6d282482{/solr,null,AVAILABLE}
   [junit4]   2> 1918626 INFO  (jetty-launcher-2326-thread-5) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@6244313f{HTTP/1.1,[http/1.1]}{127.0.0.1:37802}
   [junit4]   2> 1918626 INFO  (jetty-launcher-2326-thread-3) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@2c07de2{HTTP/1.1,[http/1.1]}{127.0.0.1:35981}
   [junit4]   2> 1918628 INFO  (jetty-launcher-2326-thread-5) [] 
o.e.j.s.Server Started @1920665ms
   [junit4]   2> 1918628 INFO  (jetty-launcher-2326-thread-3) [] 
o.e.j.s.Server Started @1920666ms
   [junit4]   2> 1918628 INFO  (jetty-launcher-2326-thread-5) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=37802}
   [junit4]   2> 1918627 INFO  (jetty-launcher-2326-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@361337c7{/solr,null,AVAILABLE}
   [junit4]   2> 1918628 INFO  (jetty-launcher-2326-thread-4) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@74940fab{HTTP/1.1,[http/1.1]}{127.0.0.1:33309}
   [junit4]   2> 1918629 INFO  (jetty-launcher-2326-thread-5) [] 
o.a.s.s.SolrDispatchFilter SolrDispatchFilter.init(): 
sun.misc.Launcher$AppClassLoader@73d16e93
   [junit4]   2> 1918629 INFO  (jetty-launcher-2326-thread-4) [] 
o.e.j.s.Server Started @1920666ms
   [junit4]   2> 1918629 INFO  (jetty-launcher-2326-thread-5) [] 
o.a.s.c.SolrResourceLoader new SolrResourceLoader for directory: 

[jira] [Commented] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8929: Add an idea module for solr/server to enable launching start.jar


> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8929) Add an idea module for solr/server to enable launching start.jar

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8929: Add an idea module for solr/server to enable launching start.jar


> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8914:
-
Fix Version/s: 6.1
   master

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master, 6.0, 5.4.1
>Reporter: Hoss Man
>Assignee: Scott Blum
> Fix For: master, 6.1
>
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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-8973) TX-frenzy on Zookeeper when collection is put to use

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8973:
-
Fix Version/s: 6.1
   master

> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Fix For: master, 6.1
>
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-8973) TX-frenzy on Zookeeper when collection is put to use

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8973: Zookeeper frenzy when a core is first created.


> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-9015) Add SelectStream as a default function in the StreamHandler

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9015: Adds SelectStream as a default function in the StreamHandler


> Add SelectStream as a default function in the StreamHandler
> ---
>
> Key: SOLR-9015
> URL: https://issues.apache.org/jira/browse/SOLR-9015
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master, 6.1
>Reporter: Dennis Gove
>Priority: Trivial
> Fix For: master, 6.1
>
> Attachments: SOLR-9015.patch
>
>
> This adds the select(...) streaming expression as a default function in the 
> StreamHandler. This was always intended to be the case but for some reason I 
> neglected to ever add it.



--
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-9015) Add SelectStream as a default function in the StreamHandler

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-9015.
-
   Resolution: Fixed
 Assignee: Dennis Gove
Fix Version/s: 6.1
   master

> Add SelectStream as a default function in the StreamHandler
> ---
>
> Key: SOLR-9015
> URL: https://issues.apache.org/jira/browse/SOLR-9015
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master, 6.1
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Trivial
> Fix For: master, 6.1
>
> Attachments: SOLR-9015.patch
>
>
> This adds the select(...) streaming expression as a default function in the 
> StreamHandler. This was always intended to be the case but for some reason I 
> neglected to ever add it.



--
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-8694) DistributedMap/Queue simplifications and fixes.

[Scott Blum (JIRA)]

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

Scott Blum reassigned SOLR-8694:


Assignee: Scott Blum  (was: Mark Miller)

> DistributedMap/Queue simplifications and fixes.
> ---
>
> Key: SOLR-8694
> URL: https://issues.apache.org/jira/browse/SOLR-8694
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>  Labels: patch, reliability
> Fix For: master
>
> Attachments: SOLR-8694.patch
>
>
> Bugfix in DistributedQueue, it could add too many watchers since it assumed 
> the watcher was cleared on connection events.
> Huge simplification to DistributedMap; it implemented a lot of tricky stuff 
> that no one is actually using.



--
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-8973) TX-frenzy on Zookeeper when collection is put to use

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8973: Zookeeper frenzy when a core is first created.


> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-8694) DistributedMap/Queue simplifications and fixes.

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8694:
--

I have a compatible patch if you'd like me to take this one as well.

> DistributedMap/Queue simplifications and fixes.
> ---
>
> Key: SOLR-8694
> URL: https://issues.apache.org/jira/browse/SOLR-8694
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability
> Fix For: master
>
> Attachments: SOLR-8694.patch
>
>
> Bugfix in DistributedQueue, it could add too many watchers since it assumed 
> the watcher was cleared on connection events.
> Huge simplification to DistributedMap; it implemented a lot of tricky stuff 
> that no one is actually using.



--
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-8973) TX-frenzy on Zookeeper when collection is put to use

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8973:
--

[~anshumg] Landing this on master/6x now.  Another one to consider for 5.5.1 
backport (and I'll volunteer).

> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-9015) Add SelectStream as a default function in the StreamHandler

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9015: Adds SelectStream as a default function in the StreamHandler


> Add SelectStream as a default function in the StreamHandler
> ---
>
> Key: SOLR-9015
> URL: https://issues.apache.org/jira/browse/SOLR-9015
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master, 6.1
>Reporter: Dennis Gove
>Priority: Trivial
> Attachments: SOLR-9015.patch
>
>
> This adds the select(...) streaming expression as a default function in the 
> StreamHandler. This was always intended to be the case but for some reason I 
> neglected to ever add it.



--
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-8988) Improve facet.method=fcs performance in SolrCloud

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8988:


You've convinced me that i don't understand the point behind that existing 
{{TODO: we could change this to 1...}} comment, but I still want to review the 
code more thoroughly before i'm confident enough to concede your approach is 
better in all cases.

That said: If you updated your patch to make it optional based on a param 
w/some tests that randomly toggled the value (TestCloudPivotFacet, 
DistributedFacetPivotLongTailTest would be good ones) then i'd probably be game 
to commit even w/o being confident it's better in all cases, and we could worry 
about changing the default later.

bq. However I think this line block should also be changed.

Hmm, yeah ... that does smell like it could be optimized.

(FWIW: we have a TrackingShardHandlerFactory that can be used in tests to make 
assertions about what per-shard requests solr triggers. That can be used along 
with some carefully crafted shards/docs/requests to verify that no unnecessary 
refinement is done in cases where you don't expect it -- like with this 
{{initialMincount}} vs {{initialMincount-1}} situation)

> Improve facet.method=fcs performance in SolrCloud
> -
>
> Key: SOLR-8988
> URL: https://issues.apache.org/jira/browse/SOLR-8988
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8988.patch
>
>
> This relates to SOLR-8559 -- which improves the algorithm used by fcs 
> faceting when {{facet.mincount=1}}
> This patch allows {{facet.mincount}} to be sent as 1 for distributed queries. 
> As far as I can tell there is no reason to set {{facet.mincount=0}} for 
> refinement purposes . After trying to make sense of all the refinement logic, 
> I cant see how the difference between _no value_ and _value=0_ would have a 
> negative effect.
> *Test perf:*
> - ~15million unique terms
> - query matches ~3million documents
> *Params:*
> {code}
> facet.mincount=1
> facet.limit=500
> facet.method=fcs
> facet.sort=count
> {code}
> *Average Time Per Request:*
> - Before patch:  ~20seconds
> - After patch: <1 second
> *Note*: all tests pass and in my test, the output was identical before and 
> after patch.



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

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

[jira] [Updated] (SOLR-9015) Add SelectStream as a default function in the StreamHandler

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-9015:
--
Attachment: SOLR-9015.patch

Simple patch.

> Add SelectStream as a default function in the StreamHandler
> ---
>
> Key: SOLR-9015
> URL: https://issues.apache.org/jira/browse/SOLR-9015
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master, 6.1
>Reporter: Dennis Gove
>Priority: Trivial
> Attachments: SOLR-9015.patch
>
>
> This adds the select(...) streaming expression as a default function in the 
> StreamHandler. This was always intended to be the case but for some reason I 
> neglected to ever add it.



--
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-9015) Add SelectStream as a default function in the StreamHandler

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-9015:
-

 Summary: Add SelectStream as a default function in the 
StreamHandler
 Key: SOLR-9015
 URL: https://issues.apache.org/jira/browse/SOLR-9015
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Affects Versions: master, 6.1
Reporter: Dennis Gove
Priority: Trivial


This adds the select(...) streaming expression as a default function in the 
StreamHandler. This was always intended to be the case but for some reason I 
neglected to ever add it.



--
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-8918) Add Streaming Expressions to the admin page

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8918: Corrects usage of a global variable in admin page's stream.js which 
was overriding the same variable in cloud.js


> Add Streaming Expressions to the admin page
> ---
>
> Key: SOLR-8918
> URL: https://issues.apache.org/jira/browse/SOLR-8918
> Project: Solr
>  Issue Type: New Feature
>  Components: UI, web gui
>Reporter: Dennis Gove
> Attachments: SOLR-8918.patch, SOLR-8918.patch, SOLR-8918.patch, 
> SOLR-8918.patch, SOLR-8918.patch, sample-display.png, sample-display.png
>
>
> Add to the admin page an ability to work with and view Streaming Expressions.
> This tab will appear under the Collection selection section and will work 
> similarly to the Query tab. On this page the user will be able to enter a 
> streaming expression for execution. The user can then execute the expression 
> against the collection and view all the results as they are returned from the 
> Stream handler. Along with this the user will be able to view the structure 
> of the expression in a graph-like layout. 
> If the user wishes to only view the expression structure without executing 
> the expression the user will be able to click an "Explain" button which will 
> show the structure. Included in the structure will be information about each 
> node (the expression for that node).



--
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-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8914:


+1 for back porting this and thanks for volunteering :)

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master, 6.0, 5.4.1
>Reporter: Hoss Man
>Assignee: Scott Blum
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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-8716) Upgrade to Apache Tika 1.12

[Lewis John McGibbney (JIRA)]

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

Lewis John McGibbney commented on SOLR-8716:


[~thetaphi] I managed to sort out the dependency stuff... I hope. Would 
appreciate peer review here again. Thanks. 

> Upgrade to Apache Tika 1.12
> ---
>
> Key: SOLR-8716
> URL: https://issues.apache.org/jira/browse/SOLR-8716
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Lewis John McGibbney
>Assignee: Uwe Schindler
> Fix For: master
>
> Attachments: LUCENE-7041.patch
>
>
> We recently released Apache Tika 1.12. In order to use the fixes provided 
> within the Tika.translate API I propose to upgrade Tika from 1.7 --> 1.12 in 
> lucene/ivy-versions.properties.
> Patch coming up.



--
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-8716) Upgrade to Apache Tika 1.12

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8716:
--

Github user lewismc commented on the pull request:

https://github.com/apache/lucene-solr/pull/10#issuecomment-212181537
  
This PR is superseded by #31 


> Upgrade to Apache Tika 1.12
> ---
>
> Key: SOLR-8716
> URL: https://issues.apache.org/jira/browse/SOLR-8716
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Lewis John McGibbney
>Assignee: Uwe Schindler
> Fix For: master
>
> Attachments: LUCENE-7041.patch
>
>
> We recently released Apache Tika 1.12. In order to use the fixes provided 
> within the Tika.translate API I propose to upgrade Tika from 1.7 --> 1.12 in 
> lucene/ivy-versions.properties.
> Patch coming up.



--
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-8716) Upgrade to Apache Tika 1.12

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8716:
--

Github user lewismc closed the pull request at:

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


> Upgrade to Apache Tika 1.12
> ---
>
> Key: SOLR-8716
> URL: https://issues.apache.org/jira/browse/SOLR-8716
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Lewis John McGibbney
>Assignee: Uwe Schindler
> Fix For: master
>
> Attachments: LUCENE-7041.patch
>
>
> We recently released Apache Tika 1.12. In order to use the fixes provided 
> within the Tika.translate API I propose to upgrade Tika from 1.7 --> 1.12 in 
> lucene/ivy-versions.properties.
> Patch coming up.



--
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-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8914:
--

[~anshumg] I think we should backport this to 5.5.1.  Happy to push a commit 
(i've already done the work locally to backport the test code.)

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master, 6.0, 5.4.1
>Reporter: Hoss Man
>Assignee: Scott Blum
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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-7226) Geo3d polygon data cleaning would be helpful

[ASF subversion and git services (JIRA)]

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

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

Commit 4e3d24710901719453a56e19ea642f9217b7787a in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4e3d247 ]

LUCENE-7226: Slight improvements to filtering and pole discovery operations.


> Geo3d polygon data cleaning would be helpful
> 
>
> Key: LUCENE-7226
> URL: https://issues.apache.org/jira/browse/LUCENE-7226
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7226.patch
>
>
> Some of the OpenStreetMap data has duplicate points, and edges that backtrack 
> upon themselves.  For most means of constructing polygons, it would be good 
> to "correct" the data and prune problematic points.



--
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: LUCENE-7041 Upgrade to Apache Tika 1.12

[lewismc]

Github user lewismc closed the pull request at:

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


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

[GitHub] lucene-solr pull request: LUCENE-7041 Upgrade to Apache Tika 1.12

[lewismc]

Github user lewismc commented on the pull request:

https://github.com/apache/lucene-solr/pull/10#issuecomment-212181537
  
This PR is superseded by #31 


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

[GitHub] lucene-solr pull request: SOLR-8716 Upgrade to Apache Tika 1.12

[lewismc]

GitHub user lewismc opened a pull request:

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

SOLR-8716 Upgrade to Apache Tika 1.12

This PR is an attempt to address 
https://issues.apache.org/jira/browse/SOLR-8716, I ran the test suite with no 
issues. Please let me know if there are additional issues I need to deal with 
here. 

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

$ git pull https://github.com/lewismc/lucene-solr SOLR-8716

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

https://github.com/apache/lucene-solr/pull/31.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 #31


commit 4557a3cc6c56b98420b2389a44b2b4fc3c133a5d
Author: Lewis John McGibbney 
Date:   2016-04-20T00:17:50Z

SOLR-8716 Upgrade to Apache Tika 1.12




---
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] [Commented] (SOLR-8716) Upgrade to Apache Tika 1.12

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8716:
--

GitHub user lewismc opened a pull request:

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

SOLR-8716 Upgrade to Apache Tika 1.12

This PR is an attempt to address 
https://issues.apache.org/jira/browse/SOLR-8716, I ran the test suite with no 
issues. Please let me know if there are additional issues I need to deal with 
here. 

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

$ git pull https://github.com/lewismc/lucene-solr SOLR-8716

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

https://github.com/apache/lucene-solr/pull/31.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 #31


commit 4557a3cc6c56b98420b2389a44b2b4fc3c133a5d
Author: Lewis John McGibbney 
Date:   2016-04-20T00:17:50Z

SOLR-8716 Upgrade to Apache Tika 1.12




> Upgrade to Apache Tika 1.12
> ---
>
> Key: SOLR-8716
> URL: https://issues.apache.org/jira/browse/SOLR-8716
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - Solr Cell (Tika extraction)
>Reporter: Lewis John McGibbney
>Assignee: Uwe Schindler
> Fix For: master
>
> Attachments: LUCENE-7041.patch
>
>
> We recently released Apache Tika 1.12. In order to use the fixes provided 
> within the Tika.translate API I propose to upgrade Tika from 1.7 --> 1.12 in 
> lucene/ivy-versions.properties.
> Patch coming up.



--
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-7226) Geo3d polygon data cleaning would be helpful

[ASF subversion and git services (JIRA)]

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

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

Commit 02215167164c57dc487ceeb73a0e91278162a49b in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0221516 ]

LUCENE-7226: Slight improvements to filtering and pole discovery operations.


> Geo3d polygon data cleaning would be helpful
> 
>
> Key: LUCENE-7226
> URL: https://issues.apache.org/jira/browse/LUCENE-7226
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7226.patch
>
>
> Some of the OpenStreetMap data has duplicate points, and edges that backtrack 
> upon themselves.  For most means of constructing polygons, it would be good 
> to "correct" the data and prune problematic points.



--
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-8918) Add Streaming Expressions to the admin page

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8918:
---

I've found the problem and in doing so developed a slight dislike for angular 
(but really it was my own fault because I know all about javascript global 
states and what not).

stream.js was created from a copy of cloud.js. cloud.js created a global 
variable called graphSubController. When I was mucking around with stream.js I 
kept the graphSubController global variable but re-implemented it. Now, when 
angular runs it will process all the .js files and in doing so the 
stream.js::graphSubController replaced cloud.js::graphSubController so the 
correct sub controller was not being called from the cloud.js code page.

I'll have a patch to fix this in a little bit - after I go and cleanup all the 
alerts I added to figure out what in the world was going on.

(in reality though, it was pretty fun to learn-ish angular for this)

> Add Streaming Expressions to the admin page
> ---
>
> Key: SOLR-8918
> URL: https://issues.apache.org/jira/browse/SOLR-8918
> Project: Solr
>  Issue Type: New Feature
>  Components: UI, web gui
>Reporter: Dennis Gove
> Attachments: SOLR-8918.patch, SOLR-8918.patch, SOLR-8918.patch, 
> SOLR-8918.patch, SOLR-8918.patch, sample-display.png, sample-display.png
>
>
> Add to the admin page an ability to work with and view Streaming Expressions.
> This tab will appear under the Collection selection section and will work 
> similarly to the Query tab. On this page the user will be able to enter a 
> streaming expression for execution. The user can then execute the expression 
> against the collection and view all the results as they are returned from the 
> Stream handler. Along with this the user will be able to view the structure 
> of the expression in a graph-like layout. 
> If the user wishes to only view the expression structure without executing 
> the expression the user will be able to click an "Explain" button which will 
> show the structure. Included in the structure will be information about each 
> node (the expression for that node).



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/88/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 18 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to MacOSX VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor540.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy45.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:808)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3220/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 16 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to MacOSX VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor540.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy45.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:808)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:196)
at 

[jira] [Updated] (SOLR-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8914:
-
Affects Version/s: 6.0
   master
   5.5
   5.4.1

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, master, 6.0, 5.4.1
>Reporter: Hoss Man
>Assignee: Scott Blum
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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-8988) Improve facet.method=fcs performance in SolrCloud

[Keith Laban (JIRA)]

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

Keith Laban commented on SOLR-8988:
---

[~hossman] can I convince you that this should be the default behavior?

> Improve facet.method=fcs performance in SolrCloud
> -
>
> Key: SOLR-8988
> URL: https://issues.apache.org/jira/browse/SOLR-8988
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
> Attachments: SOLR-8988.patch
>
>
> This relates to SOLR-8559 -- which improves the algorithm used by fcs 
> faceting when {{facet.mincount=1}}
> This patch allows {{facet.mincount}} to be sent as 1 for distributed queries. 
> As far as I can tell there is no reason to set {{facet.mincount=0}} for 
> refinement purposes . After trying to make sense of all the refinement logic, 
> I cant see how the difference between _no value_ and _value=0_ would have a 
> negative effect.
> *Test perf:*
> - ~15million unique terms
> - query matches ~3million documents
> *Params:*
> {code}
> facet.mincount=1
> facet.limit=500
> facet.method=fcs
> facet.sort=count
> {code}
> *Average Time Per Request:*
> - Before patch:  ~20seconds
> - After patch: <1 second
> *Note*: all tests pass and in my test, the output was identical before and 
> after patch.



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

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

[jira] [Commented] (SOLR-8416) The collections create API should return after all replicas are active.

[ASF subversion and git services (JIRA)]

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

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

Commit 4c88ea5532c2e23d7b29ba88ce41e19f7c58e691 in lucene-solr's branch 
refs/heads/branch_5_5 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4c88ea5 ]

SOLR-8416: The collections create API should return after all replicas are 
active.


> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Fix For: master, 5.5.1
>
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



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

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

[jira] [Updated] (SOLR-8416) The collections create API should return after all replicas are active.

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8416:
---
Fix Version/s: 5.5.1

> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Fix For: master, 5.5.1
>
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



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

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

[jira] [Updated] (SOLR-8633) DistributedUpdateProcess processCommit/deleteByQuery call finish on DUP and SolrCmdDistributor, which violates the lifecycle and can cause bugs.

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8633:
---
Fix Version/s: 5.5.1

> DistributedUpdateProcess processCommit/deleteByQuery call finish on DUP and 
> SolrCmdDistributor, which violates the lifecycle and can cause bugs.
> 
>
> Key: SOLR-8633
> URL: https://issues.apache.org/jira/browse/SOLR-8633
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Mark Miller
> Fix For: master, 5.5.1
>
> Attachments: SOLR-8633.patch
>
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
> realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only 
> suppose to be called exactly once after processing any/all UpdateCommands) 
> and could potentially break any UpdateProcessors configured after DUP (or in 
> my case: processors configured _before_ DUP that expect to be in charge of 
> calling finish, and catching any resulting exceptions, as part of the normal 
> life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
> kind of expensive/dangerous to me since there is leader initiated recovery 
> involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means 
> {{StreamingSolrClients.shutdown()}} gets called twice, which means 
> {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
> we're just getting really lucky that (as configured by DUP) all of these 
> resources are still usable after being finished/shutdown/closed



--
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-8633) DistributedUpdateProcess processCommit/deleteByQuery call finish on DUP and SolrCmdDistributor, which violates the lifecycle and can cause bugs.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8633:


Reopening for 5.5.1

> DistributedUpdateProcess processCommit/deleteByQuery call finish on DUP and 
> SolrCmdDistributor, which violates the lifecycle and can cause bugs.
> 
>
> Key: SOLR-8633
> URL: https://issues.apache.org/jira/browse/SOLR-8633
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Mark Miller
> Fix For: master, 5.5.1
>
> Attachments: SOLR-8633.patch
>
>
> trying to wrap my head around a weird bug in my experiements with SOLR-445, i 
> realized that {{DUP.processDelete}} has a direct call to {{finish()}}.
> This violates the normal lifecycle of an UpdateProcessor (finish is only 
> suppose to be called exactly once after processing any/all UpdateCommands) 
> and could potentially break any UpdateProcessors configured after DUP (or in 
> my case: processors configured _before_ DUP that expect to be in charge of 
> calling finish, and catching any resulting exceptions, as part of the normal 
> life cycle)
> Independent of how it impacts other update processors, this also means that:
> # all the logic in {{DUP.doFinish}} is getting executed twice -- which seems 
> kind of expensive/dangerous to me since there is leader initiated recovery 
> involved in this method
> # {{SolrCmdDistributor.finish()}} gets called twice, which means 
> {{StreamingSolrClients.shutdown()}} gets called twice, which means 
> {{ConcurrentUpdateSolrClient.close()}} gets called twice ... it seems like 
> we're just getting really lucky that (as configured by DUP) all of these 
> resources are still usable after being finished/shutdown/closed



--
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-8694) DistributedMap/Queue simplifications and fixes.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8694:


Reopening to back port for 5.5.1

> DistributedMap/Queue simplifications and fixes.
> ---
>
> Key: SOLR-8694
> URL: https://issues.apache.org/jira/browse/SOLR-8694
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability
> Fix For: master
>
> Attachments: SOLR-8694.patch
>
>
> Bugfix in DistributedQueue, it could add too many watchers since it assumed 
> the watcher was cleared on connection events.
> Huge simplification to DistributedMap; it implemented a lot of tricky stuff 
> that no one is actually using.



--
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-8416) The collections create API should return after all replicas are active.

[ASF subversion and git services (JIRA)]

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

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

Commit a494ac95fc2c22004d89952f7262ceac8368b6c9 in lucene-solr's branch 
refs/heads/branch_5x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a494ac9 ]

SOLR-8416: The collections create API should return after all replicas are 
active.


> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



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

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

[jira] [Commented] (SOLR-8701) CloudSolrClient decides that there are no healthy nodes to handle a request too early.

[ASF subversion and git services (JIRA)]

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

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

Commit 607e91cdab50af1168f5bc8b8785cfa77f1e55ea in lucene-solr's branch 
refs/heads/branch_5_5 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=607e91c ]

SOLR-8701: CloudSolrClient decides that there are no healthy nodes to handle a 
request too early.


> CloudSolrClient decides that there are no healthy nodes to handle a request 
> too early.
> --
>
> Key: SOLR-8701
> URL: https://issues.apache.org/jira/browse/SOLR-8701
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8701.patch
>
>
> CloudSolrClient bails when it finds no leaders before trying replicas. We 
> should try all nodes before declaring we cannot serve the 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-8578) Successful or not, requests are not always fully consumed by Solrj clients and we count on HttpClient or the JVM.

[ASF subversion and git services (JIRA)]

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

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

Commit 50ae1fff7c0a18576c59ec672eb3b6b6ad921781 in lucene-solr's branch 
refs/heads/branch_5_5 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=50ae1ff ]

SOLR-8578: Successful or not, requests are not always fully consumed by Solrj 
clients and we count on HttpClient or the JVM.


> Successful or not, requests are not always fully consumed by Solrj clients 
> and we count on HttpClient or the JVM.
> -
>
> Key: SOLR-8578
> URL: https://issues.apache.org/jira/browse/SOLR-8578
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8578.patch, SOLR-8578.patch
>
>
> Does not seem to happen with XML response parser.
> Not the largest deal because HttpClient appears to consume unread bytes from 
> the stream for us, but something seems off.



--
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-8683) Always consume the full request on the server, not just in the case of an error.

[ASF subversion and git services (JIRA)]

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

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

Commit 39c53331490ed60b90d9e78441d0be65221c319e in lucene-solr's branch 
refs/heads/branch_5_5 from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39c5333 ]

SOLR-8683: Always consume the full request on the server, not just in the case 
of an error.


> Always consume the full request on the server, not just in the case of an 
> error.
> 
>
> Key: SOLR-8683
> URL: https://issues.apache.org/jira/browse/SOLR-8683
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8683.patch
>
>
> I tried upgrading to Jetty 9.3 again and started hitting connection resets in 
> the tests again. This change necessary to resolve.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 154 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/154/

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([741C9E1A4C4F68BE:1F533E673540B584]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:135)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy(ZkStateReaderTest.java:46)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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(Thread.java:745)




Build Log:
[...truncated 11124 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_72) - Build # 16545 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16545/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:43267/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:43267/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([BC2B963C785D6051:347FA9E6D6A10DA9]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8933:
---

I see some tests now fail due to the new assert. Seems there are some closes we 
don't shield still.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



--
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-8847) SolrJ JDBC - Implement "Select *"

[Kevin Risden (JIRA)]

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

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

Update patch based on changes from updating SOLR-8823 to master. Need to review 
more

> SolrJ JDBC - Implement "Select *" 
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Trey Cahill
>Assignee: Kevin Risden
> Attachments: SOLR-8847.patch, SOLR-8847.patch
>
>
> The sql query "Select *" is commonly used, but currently all fields need to 
> be specified.  This can cause some troubles as "Select *" has been used to 
> pull back column metadata in some JDBC clients.



--
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-7729) ConcurrentUpdateSolrClient ignoring the collection parameter in some methods

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-7729.
---
   Resolution: Fixed
Fix Version/s: 6.1
   master

> ConcurrentUpdateSolrClient ignoring the collection parameter in some methods
> 
>
> Key: SOLR-7729
> URL: https://issues.apache.org/jira/browse/SOLR-7729
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.1
>Reporter: Jorge Luis Betancourt Gonzalez
>Assignee: Mark Miller
>  Labels: client, solrj
> Fix For: master, 6.1
>
> Attachments: SOLR-7729-ConcurrentUpdateSolrClient-collection.patch, 
> SOLR-7729.patch
>
>
> Some of the methods in {{ConcurrentUpdateSolrClient}} accept an aditional 
> {{collection}} parameter, some of this methods are: {{add(String collection, 
> SolrInputDocument doc)}} and {{request(SolrRequest, String collection)}}. 
> This collection parameter is being ignored in this cases but works for others 
> like {{commit(String collection)}}.
> [~elyograg] noted that:
> {quote} 
> Looking into how an update request actually gets added to the background
> queue in ConcurrentUpdateSolrClient, it appears that the "collection"
> information is ignored before the request is added to the queue.
> {quote}
> From the source, when a commit is issued or the 
> {{UpdateParams.WAIT_SEARCHER}} is set in the request params the collection 
> parameter is used, otherwise the request {{UpdateRequest req}} is queued 
> without any regarding of the 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] [Resolved] (SOLR-8983) Failed Collection CREATE call should cleanup the cluster state before returning

[Anshum Gupta (JIRA)]

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

Anshum Gupta resolved SOLR-8983.

Resolution: Fixed

> Failed Collection CREATE call should cleanup the cluster state before 
> returning
> ---
>
> Key: SOLR-8983
> URL: https://issues.apache.org/jira/browse/SOLR-8983
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: 5.5.1, 6.1
>
> Attachments: SOLR-8983-test.patch, SOLR-8983.patch, SOLR-8983.patch, 
> SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch
>
>
> In case of a failed collection creation call, the cluster state is updated 
> leaving an entry for the failed collection. This is also returned by the LIST 
> command, allowing the users to believe that the collection exists.
> CREATE call should cleanup in case of a failed attempt at creating the 
> 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-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)

[Kevin Risden (JIRA)]

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

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

New patch based on master. Need to review more.

> Implement DatabaseMetaDataImpl.getColumns(String catalog, String 
> schemaPattern, String tableNamePattern, String columnNamePattern)
> --
>
> Key: SOLR-8823
> URL: https://issues.apache.org/jira/browse/SOLR-8823
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-8823.patch, SOLR-8823.patch
>
>




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

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

[jira] [Resolved] (SOLR-8971) ShardHandlerFactory error handling throws away exception details

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8971.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 6.1
   master

> ShardHandlerFactory error handling throws away exception details
> 
>
> Key: SOLR-8971
> URL: https://issues.apache.org/jira/browse/SOLR-8971
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master, 6.1
>
>
> ShardHandlerFactory.newInstance catches any Exception from initializing the 
> configured ShardHandlerFactory class as a plugin, and then throws a new 
> SolrException w/o wrapping hte original excpetion - losing all useful context 
> of why the plugin couldn't be loaded.



--
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-8971) ShardHandlerFactory error handling throws away exception details

[ASF subversion and git services (JIRA)]

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

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

Commit fdcd17bef27c4527e5bf5aa7da7510d8f1d24768 in lucene-solr's branch 
refs/heads/branch_6x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fdcd17b ]

SOLR-8971: Preserve root cause when wrapping exceptions


> ShardHandlerFactory error handling throws away exception details
> 
>
> Key: SOLR-8971
> URL: https://issues.apache.org/jira/browse/SOLR-8971
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> ShardHandlerFactory.newInstance catches any Exception from initializing the 
> configured ShardHandlerFactory class as a plugin, and then throws a new 
> SolrException w/o wrapping hte original excpetion - losing all useful context 
> of why the plugin couldn't be loaded.



--
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-8971) ShardHandlerFactory error handling throws away exception details

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8971: Preserve root cause when wrapping exceptions


> ShardHandlerFactory error handling throws away exception details
> 
>
> Key: SOLR-8971
> URL: https://issues.apache.org/jira/browse/SOLR-8971
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> ShardHandlerFactory.newInstance catches any Exception from initializing the 
> configured ShardHandlerFactory class as a plugin, and then throws a new 
> SolrException w/o wrapping hte original excpetion - losing all useful context 
> of why the plugin couldn't be loaded.



--
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-8847) SolrJ JDBC - Implement "Select *"

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8847:
---
Affects Version/s: 6.0

> SolrJ JDBC - Implement "Select *" 
> --
>
> Key: SOLR-8847
> URL: https://issues.apache.org/jira/browse/SOLR-8847
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Trey Cahill
>Assignee: Kevin Risden
> Attachments: SOLR-8847.patch
>
>
> The sql query "Select *" is commonly used, but currently all fields need to 
> be specified.  This can cause some troubles as "Select *" has been used to 
> pull back column metadata in some JDBC clients.



--
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-8823) Implement DatabaseMetaDataImpl.getColumns(String catalog, String schemaPattern, String tableNamePattern, String columnNamePattern)

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8823:
---
Affects Version/s: 6.0

> Implement DatabaseMetaDataImpl.getColumns(String catalog, String 
> schemaPattern, String tableNamePattern, String columnNamePattern)
> --
>
> Key: SOLR-8823
> URL: https://issues.apache.org/jira/browse/SOLR-8823
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-8823.patch
>
>




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

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

[jira] [Commented] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8929:
--

+1 to commit as-is and make a follow-on JIRA to improve.

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8929) Add an idea module for solr/server to enable launching start.jar

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8929:
--

You're correct, it pulls the binaries from WEB-INF/lib.  In this formulation 
the only real advantage is being able to run the debugger very easily.  I'd 
needed the ant build, as you mentioned, to get `server/solr-webapp/webapp` to 
exist at all.

What would you think if we committed this in basically it's current state, but 
added a JIRA to improve it?  I would like to circle back on making this better, 
but I have a bunch of other stuff on my plate and I'm a little concerned that 
getting Jetty to run exactly the right way without WEB-INF/lib, and otherwise 
setting up an IntelliJ specific webapp directory will be a bit of a time sink.

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8683) Always consume the full request on the server, not just in the case of an error.

[ASF subversion and git services (JIRA)]

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

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

Commit 64c85394cb174669f8cf809d0a13a96bc5a92001 in lucene-solr's branch 
refs/heads/branch_5x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=64c8539 ]

SOLR-8683: Always consume the full request on the server, not just in the case 
of an error.


> Always consume the full request on the server, not just in the case of an 
> error.
> 
>
> Key: SOLR-8683
> URL: https://issues.apache.org/jira/browse/SOLR-8683
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8683.patch
>
>
> I tried upgrading to Jetty 9.3 again and started hitting connection resets in 
> the tests again. This change necessary to resolve.



--
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-8578) Successful or not, requests are not always fully consumed by Solrj clients and we count on HttpClient or the JVM.

[ASF subversion and git services (JIRA)]

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

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

Commit dab4c81b03e51d9c8a11d60c41d916da50052dde in lucene-solr's branch 
refs/heads/branch_5x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dab4c81 ]

SOLR-8578: Successful or not, requests are not always fully consumed by Solrj 
clients and we count on HttpClient or the JVM.


> Successful or not, requests are not always fully consumed by Solrj clients 
> and we count on HttpClient or the JVM.
> -
>
> Key: SOLR-8578
> URL: https://issues.apache.org/jira/browse/SOLR-8578
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8578.patch, SOLR-8578.patch
>
>
> Does not seem to happen with XML response parser.
> Not the largest deal because HttpClient appears to consume unread bytes from 
> the stream for us, but something seems off.



--
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-8701) CloudSolrClient decides that there are no healthy nodes to handle a request too early.

[ASF subversion and git services (JIRA)]

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

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

Commit 6ddf2c977161ccf17e8b3c1fbeaa4c4bdc6473f5 in lucene-solr's branch 
refs/heads/branch_5x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6ddf2c9 ]

SOLR-8701: CloudSolrClient decides that there are no healthy nodes to handle a 
request too early.


> CloudSolrClient decides that there are no healthy nodes to handle a request 
> too early.
> --
>
> Key: SOLR-8701
> URL: https://issues.apache.org/jira/browse/SOLR-8701
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8701.patch
>
>
> CloudSolrClient bails when it finds no leaders before trying replicas. We 
> should try all nodes before declaring we cannot serve the 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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 43 - Still Failing

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterThreadsToSegments.testSegmentCountOnFlushRandom

Error Message:
Captured an uncaught exception in thread: Thread[id=259, name=Thread-179, 
state=RUNNABLE, group=TGRP-TestIndexWriterThreadsToSegments]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=259, name=Thread-179, state=RUNNABLE, 
group=TGRP-TestIndexWriterThreadsToSegments]
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at __randomizedtesting.SeedInfo.seed([11A92BEEB7FC60E]:0)
at java.util.HashMap.newNode(HashMap.java:1734)
at java.util.HashMap.putVal(HashMap.java:630)
at java.util.HashMap.put(HashMap.java:611)
at java.util.HashSet.add(HashSet.java:219)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.noDups(IndexWriter.java:689)
at 
org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:678)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:100)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:444)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenFromWriter(StandardDirectoryReader.java:291)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:266)
at 
org.apache.lucene.index.StandardDirectoryReader.doOpenIfChanged(StandardDirectoryReader.java:256)
at 
org.apache.lucene.index.DirectoryReader.openIfChanged(DirectoryReader.java:140)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$CheckSegmentCount.run(TestIndexWriterThreadsToSegments.java:130)
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:220)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:362)
at 
org.apache.lucene.index.TestIndexWriterThreadsToSegments$2.run(TestIndexWriterThreadsToSegments.java:215)


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

Error Message:
The test or suite printed 18030 bytes to stdout and stderr, even though the 
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it 
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true

Stack Trace:
java.lang.AssertionError: The test or suite printed 18030 bytes to stdout and 
stderr, even though the limit was set to 8192 bytes. Increase the limit with 
@Limit, ignore it completely with @SuppressSysoutChecks or run with 
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([11A92BEEB7FC60E]:0)
at 
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:211)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
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(Thread.java:745)




Build Log:
[...truncated 690 lines...]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterThreadsToSegments
   [junit4]   2> Nis 20, 2016 1:55:55 AM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-179,5,TGRP-TestIndexWriterThreadsToSegments]
   [junit4]   2> java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([11A92BEEB7FC60E]:0)
   [junit4]   2>at java.util.HashMap.newNode(HashMap.java:1734)
   [junit4]   2>at java.util.HashMap.putVal(HashMap.java:630)
   [junit4]   2>at java.util.HashMap.put(HashMap.java:611)
   [junit4]   2>at java.util.HashSet.add(HashSet.java:219)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter$ReaderPool.noDups(IndexWriter.java:689)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter$ReaderPool.get(IndexWriter.java:678)
   [junit4]   2>at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:100)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:444)
   [junit4]   2>at 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_72) - Build # 5789 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5789/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 12 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at ..remote call to Windows VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor540.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy45.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:808)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at 

[jira] [Reopened] (SOLR-8416) The collections create API should return after all replicas are active.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8416:


Opening to back port for 5.5.1.

> The collections create API should return after all replicas are active. 
> 
>
> Key: SOLR-8416
> URL: https://issues.apache.org/jira/browse/SOLR-8416
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Michael Sun
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch, 
> SOLR-8416.patch, SOLR-8416.patch, SOLR-8416.patch
>
>
> Currently the collection creation API returns once all cores are created. In 
> large cluster the cores may not be alive for some period of time after cores 
> are created. For any thing requested during that period, Solr appears 
> unstable and can return failure. Therefore it's better  the collection 
> creation API waits for all cores to become alive and returns after that.



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

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

[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 86 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/86/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 36 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:639)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to Solaris VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor540.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy45.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:808)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:139)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:637)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:182)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1138)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:209)
at 

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 533 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/533/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.update.processor.TestNamedUpdateProcessors.test

Error Message:
Could not find collection:.system

Stack Trace:
java.lang.AssertionError: Could not find collection:.system
at 
__randomizedtesting.SeedInfo.seed([BAFC563BE4925AE5:32A869E14A6E371D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:150)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:130)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:852)
at 
org.apache.solr.update.processor.TestNamedUpdateProcessors.test(TestNamedUpdateProcessors.java:78)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-8701) CloudSolrClient decides that there are no healthy nodes to handle a request too early.

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8701:
---
Fix Version/s: 5.5.1

> CloudSolrClient decides that there are no healthy nodes to handle a request 
> too early.
> --
>
> Key: SOLR-8701
> URL: https://issues.apache.org/jira/browse/SOLR-8701
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8701.patch
>
>
> CloudSolrClient bails when it finds no leaders before trying replicas. We 
> should try all nodes before declaring we cannot serve the 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] [Reopened] (SOLR-8701) CloudSolrClient decides that there are no healthy nodes to handle a request too early.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8701:


Reopening to back porting for 5.5.1.

> CloudSolrClient decides that there are no healthy nodes to handle a request 
> too early.
> --
>
> Key: SOLR-8701
> URL: https://issues.apache.org/jira/browse/SOLR-8701
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8701.patch
>
>
> CloudSolrClient bails when it finds no leaders before trying replicas. We 
> should try all nodes before declaring we cannot serve the 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-8929) Add an idea module for solr/server to enable launching start.jar

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8929:
--

bq.  If you have the right classpath setup in IntelliJ

Looks like the included run configuration only includes the new {{server}} 
module's classpath, which doesn't have any dependencies other than 
{{start.jar}}?

When I run the {{solrcloud}} run configuration, I get 
{{java.io.FileNotFoundException: 
/Users/sarowe/git/lucene-solr/solr/server/solr-webapp/webapp}} - so I'm not 
sure what the benefit of this over {{bin/solr}} is?  That is, you still have to 
use the ant build to populate {{server/solr-webapp/webapp}}.

Are you planning to flesh this out more?  I think it's possible, with the right 
module dependencies, and maybe also making the build/run location under 
{{idea-build/solr/server/}}, to get a setup that will use IntelliJ's build 
artifacts.

bq. I'm not sure how to create collections... I think I need to get the 
configset examples into ZK somehow?

Maybe a bootstrapping task to run SolrCLI's ZK upconfig?


> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8973) TX-frenzy on Zookeeper when collection is put to use

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8973:
--

Scott:

As it happens, I may be interested in this patch Real Soon Now and have access 
to a dev environment that would stress this a _lot_. How close do you think 
this is to being committable?  Or, more precisely, testable? The "dev 
environment" is expensive to run in this case, so when there's a patch you're 
satisfied with the patch I might be able to give a it a spin; it doesn't have 
to be committed.  Dev environment is 5x, do you think that matters?

Thanks!
Erick

> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-9014) Audit all usages of ClusterState methods which may make calls to ZK via the lazy collection reference

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9014:

Description: 
ClusterState has a bunch of methods such as getSlice and getReplica which 
internally call getCollectionOrNull that ends up making a call to ZK via the 
lazy collection reference. Many classes use these methods even though a 
DocCollection object is available. In such cases, multiple redundant calls to 
ZooKeeper can happen if the collection is not watched locally. This is 
especially true for Overseer classes which operate on all collections.

We should audit all usages of these methods and replace them with calls to 
appropriate DocCollection methods.

  was:
ClusterState has a bunch of methods such as getSlice and getReplica which 
internally call getCollectionOrNull that ends up making a call to ZK via the 
lazy collection reference. Many classes use these methods even though a 
DocCollection object is available. In such cases, multiple redundant calls to 
ZooKeeper are made.

We should audit all usages of these methods and replace them with calls to 
appropriate DocCollection methods.


> Audit all usages of ClusterState methods which may make calls to ZK via the 
> lazy collection reference
> -
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: master, 6.1
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-9014) Audit all usages of ClusterState methods which may make calls to ZK via the lazy collection reference

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-9014:
---

 Summary: Audit all usages of ClusterState methods which may make 
calls to ZK via the lazy collection reference
 Key: SOLR-9014
 URL: https://issues.apache.org/jira/browse/SOLR-9014
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
 Fix For: master, 6.1


ClusterState has a bunch of methods such as getSlice and getReplica which 
internally call getCollectionOrNull that ends up making a call to ZK via the 
lazy collection reference. Many classes use these methods even though a 
DocCollection object is available. In such cases, multiple redundant calls to 
ZooKeeper are made.

We should audit all usages of these methods and replace them with calls to 
appropriate DocCollection methods.



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1092 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1092/

All tests passed

Build Log:
[...truncated 51821 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj701800235
 [ecj-lint] Compiling 81 source files to /tmp/ecj701800235
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
 (at line 144)
 [ecj-lint] * @param start with input list of points
 [ecj-lint]  ^
 [ecj-lint] Javadoc: Parameter start is not declared
 [ecj-lint] --
 [ecj-lint] 1 problem (1 error)

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:740: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:101: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build.xml:204:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2187:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2005:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:2044:
 Compile failed; see the compiler error output for details.

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




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

[jira] [Reopened] (SOLR-8578) Successful or not, requests are not always fully consumed by Solrj clients and we count on HttpClient or the JVM.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8578:


Reopening to back-port for 5.5.

> Successful or not, requests are not always fully consumed by Solrj clients 
> and we count on HttpClient or the JVM.
> -
>
> Key: SOLR-8578
> URL: https://issues.apache.org/jira/browse/SOLR-8578
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8578.patch, SOLR-8578.patch
>
>
> Does not seem to happen with XML response parser.
> Not the largest deal because HttpClient appears to consume unread bytes from 
> the stream for us, but something seems off.



--
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-8683) Always consume the full request on the server, not just in the case of an error.

[Anshum Gupta (JIRA)]

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

Anshum Gupta reopened SOLR-8683:


Reopening to back-port for 5.5.

> Always consume the full request on the server, not just in the case of an 
> error.
> 
>
> Key: SOLR-8683
> URL: https://issues.apache.org/jira/browse/SOLR-8683
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8683.patch
>
>
> I tried upgrading to Jetty 9.3 again and started hitting connection resets in 
> the tests again. This change necessary to resolve.



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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 51713 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1512281948
 [ecj-lint] Compiling 81 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1512281948
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoPolygonFactory.java
 (at line 144)
 [ecj-lint] * @param start with input list of points
 [ecj-lint]  ^
 [ecj-lint] Javadoc: Parameter start is not declared
 [ecj-lint] --
 [ecj-lint] 1 problem (1 error)

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:740: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/build.xml:204: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2187: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2005: 
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/lucene/common-build.xml:2044: 
Compile failed; see the compiler error output for details.

Total time: 100 minutes 38 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Assigned] (SOLR-8929) Add an idea module for solr/server to enable launching start.jar

[Scott Blum (JIRA)]

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

Scott Blum reassigned SOLR-8929:


Assignee: Scott Blum

> Add an idea module for solr/server to enable launching start.jar
> 
>
> Key: SOLR-8929
> URL: https://issues.apache.org/jira/browse/SOLR-8929
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Scott Blum
>Priority: Minor
> Attachments: SOLR-8929-bin-solr-run-configuration.patch, 
> SOLR-8929.patch, SOLR-8929.patch
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently in IntelliJ, it's difficult to create a launch config to run Solr 
> in the same way that the bin/solr script would, because there aren't any 
> modules that reference the jetty start.jar that it uses.
> I want to create a simple solr/server IJ module that can be referenced from a 
> launch config.  I've created it manually in the past, but then I always lose 
> it when I have to regenerate idea on branch switch.



--
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-8983) Failed Collection CREATE call should cleanup the cluster state before returning

[ASF subversion and git services (JIRA)]

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

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

Commit b727111732417871050c80fd7f598f78e1729a2e in lucene-solr's branch 
refs/heads/branch_5_5 from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b727111 ]

SOLR-8983: Cleanup clusterstate in case of a failed CREATE collection call


> Failed Collection CREATE call should cleanup the cluster state before 
> returning
> ---
>
> Key: SOLR-8983
> URL: https://issues.apache.org/jira/browse/SOLR-8983
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: 5.5.1, 6.1
>
> Attachments: SOLR-8983-test.patch, SOLR-8983.patch, SOLR-8983.patch, 
> SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch
>
>
> In case of a failed collection creation call, the cluster state is updated 
> leaving an entry for the failed collection. This is also returned by the LIST 
> command, allowing the users to believe that the collection exists.
> CREATE call should cleanup in case of a failed attempt at creating the 
> 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-8983) Failed Collection CREATE call should cleanup the cluster state before returning

[ASF subversion and git services (JIRA)]

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

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

Commit f5d84b6fce82df87c8bb8a0d585ff32e5a9fcd66 in lucene-solr's branch 
refs/heads/branch_5x from anshum
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f5d84b6 ]

SOLR-8983: Cleanup clusterstate in case of a failed CREATE collection call


> Failed Collection CREATE call should cleanup the cluster state before 
> returning
> ---
>
> Key: SOLR-8983
> URL: https://issues.apache.org/jira/browse/SOLR-8983
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.5, 6.0
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: 5.5.1, 6.1
>
> Attachments: SOLR-8983-test.patch, SOLR-8983.patch, SOLR-8983.patch, 
> SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch, SOLR-8983.patch
>
>
> In case of a failed collection creation call, the cluster state is updated 
> leaving an entry for the failed collection. This is also returned by the LIST 
> command, allowing the users to believe that the collection exists.
> CREATE call should cleanup in case of a failed attempt at creating the 
> 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-8809) Implement Connection.prepareStatement

[Kevin Risden (JIRA)]

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

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

Patch that implements ConnectionprepareStatement. Adds PreparedStatementImpl 
and tests to JdbcTest

> Implement Connection.prepareStatement
> -
>
> Key: SOLR-8809
> URL: https://issues.apache.org/jira/browse/SOLR-8809
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-8809.patch, SOLR-8809.patch, SOLR-8809.patch
>
>
> There are multiple JDBC clients that require a PreparedStatement to 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] (SOLR-8809) Implement Connection.prepareStatement

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8809:
---
Description: There are multiple JDBC clients that require a 
PreparedStatement to work.  (was: ODBC-JDBC bridge requires that 
Connection.prepareStatement be implemented.)

> Implement Connection.prepareStatement
> -
>
> Key: SOLR-8809
> URL: https://issues.apache.org/jira/browse/SOLR-8809
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-8809.patch, SOLR-8809.patch
>
>
> There are multiple JDBC clients that require a PreparedStatement to 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] [Assigned] (SOLR-8973) TX-frenzy on Zookeeper when collection is put to use

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-8973:
---

Assignee: Scott Blum  (was: Shalin Shekhar Mangar)

This is all yours Scott. Commit away!

> TX-frenzy on Zookeeper when collection is put to use
> 
>
> Key: SOLR-8973
> URL: https://issues.apache.org/jira/browse/SOLR-8973
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, master, 5.6
>Reporter: Janmejay Singh
>Assignee: Scott Blum
>  Labels: collections, patch-available, solrcloud, zookeeper
> Attachments: SOLR-8973-ZkStateReader.patch, SOLR-8973.patch, 
> SOLR-8973.patch, SOLR-8973.patch
>
>
> This is to do with a distributed data-race. Core-creation happens at a time 
> when collection is not yet visible to the node. In this case a fallback 
> code-path is used which de-references collection-state lazily (on demand) as 
> opposed to setting a watch and keeping it cached locally.
> Due to this, as requests towards the core mount, it generates ZK fetch for 
> collection proportionately. On a large solr-cloud cluster, this generates 
> several Gbps of TX traffic on ZK nodes. This affects indexing 
> throughput(which floors) in addition to running ZK node out of network 
> bandwidth. 
> On smaller solr-cloud clusters its hard to run into, because probability of 
> this race materializing reduces.



--
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-8809) Implement Connection.prepareStatement

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-8809:
---
Summary: Implement Connection.prepareStatement  (was: Implement 
Connection.prepareStatement and make Statement implement PreparedStatement)

> Implement Connection.prepareStatement
> -
>
> Key: SOLR-8809
> URL: https://issues.apache.org/jira/browse/SOLR-8809
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Affects Versions: master, 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: SOLR-8809.patch, SOLR-8809.patch
>
>
> ODBC-JDBC bridge requires that Connection.prepareStatement be implemented.



--
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-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-8990.

   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 6.1
   master

> UI: query links from the "Top Terms" table on the Schema Browser page should 
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master, 6.1
>
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then 
> it's very possible your indexed terms will include white space.
> But the links created  by the Schema Browser UI screen to serach for a term 
> in the "Top Terms" list assume that just prepending hte term with the 
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they 
> don't match the correct term.
> 
> Example: 
> Load the {{example/films}} data into a "films" collection, and then load the 
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on 
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default 
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film



--
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-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8990: Fix top term links from schema browser page to use {!term} parser


> UI: query links from the "Top Terms" table on the Schema Browser page should 
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Hoss Man
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then 
> it's very possible your indexed terms will include white space.
> But the links created  by the Schema Browser UI screen to serach for a term 
> in the "Top Terms" list assume that just prepending hte term with the 
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they 
> don't match the correct term.
> 
> Example: 
> Load the {{example/films}} data into a "films" collection, and then load the 
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on 
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default 
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film



--
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-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser

[ASF subversion and git services (JIRA)]

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

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

Commit 10338a934fafe0ce597651d220da1d2adfc2eab1 in lucene-solr's branch 
refs/heads/branch_6x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=10338a9 ]

SOLR-8990: Fix top term links from schema browser page to use {!term} parser


> UI: query links from the "Top Terms" table on the Schema Browser page should 
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Hoss Man
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then 
> it's very possible your indexed terms will include white space.
> But the links created  by the Schema Browser UI screen to serach for a term 
> in the "Top Terms" list assume that just prepending hte term with the 
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they 
> don't match the correct term.
> 
> Example: 
> Load the {{example/films}} data into a "films" collection, and then load the 
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on 
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default 
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film



--
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-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum reassigned SOLR-8914:


Assignee: Scott Blum  (was: Mark Miller)

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Scott Blum
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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-8914) ZkStateReader's refreshLiveNodes(Watcher) is not thread safe

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8914:
--

I think it's definitely work backporting, and I'm happy to do it.  I already 
backported it to our own 5.4.1 fork; the live code merges pretty clean but I 
had to do a little work on the test code as some test infra has changed.

[~markrmil...@gmail.com] Should I just do the backports and push commits?

> ZkStateReader's refreshLiveNodes(Watcher) is not thread safe
> 
>
> Key: SOLR-8914
> URL: https://issues.apache.org/jira/browse/SOLR-8914
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Mark Miller
> Attachments: SOLR-8914.patch, SOLR-8914.patch, SOLR-8914.patch, 
> SOLR-8914.patch, jenkins.thetaphi.de_Lucene-Solr-6.x-Solaris_32.log.txt, 
> live_node_mentions_port56361_with_threadIds.log.txt, 
> live_nodes_mentions.log.txt
>
>
> Jenkin's encountered a failure in TestTolerantUpdateProcessorCloud over the 
> weekend
> {noformat}
> http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/32/consoleText
> Checking out Revision c46d7686643e7503304cb35dfe546bce9c6684e7 
> (refs/remotes/origin/branch_6x)
> Using Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
> {noformat}
> The failure happened during the static setup of the test, when a 
> MiniSolrCloudCluster & several clients are initialized -- before any code 
> related to TolerantUpdateProcessor is ever used.
> I can't reproduce this, or really make sense of what i'm (not) seeing here in 
> the logs, so i'm filing this jira with my analysis in the hopes that someone 
> else can help make sense of it.



--
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: Welcome Scott Blum as a Lucene/Solr committer!

[Scott Blum]

Thanks everyone!

I'm currently an engineer at FullStory , where
search is one of the foundational aspects of what we do.  Among other
things, I try to keep our Solr cluster fast and reliable as we scale it up
and up. :)

Prior to this, I was at Google where I worked on Google Web Toolkit
focusing on compiler work, and then at Square where I worked on making our
distributed auth/identity/session service extremely fast, reliable, and
consistent.

Scott

[jira] [Commented] (SOLR-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8990:
-

[~hossman_luc...@fucit.org] heck, you're getting good at this! :-) Patch looks 
good to me

> UI: query links from the "Top Terms" table on the Schema Browser page should 
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Hoss Man
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then 
> it's very possible your indexed terms will include white space.
> But the links created  by the Schema Browser UI screen to serach for a term 
> in the "Top Terms" list assume that just prepending hte term with the 
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they 
> don't match the correct term.
> 
> Example: 
> Load the {{example/films}} data into a "films" collection, and then load the 
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on 
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default 
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film



--
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-8918) Add Streaming Expressions to the admin page

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8918:
---

I've confirmed that it's definitely this patch that caused the graph on the 
cloud tab to disappear but I've yet to figure out why it's disappeared. I 
suspect angular is doing something I didn't expect, particularly with the 
directive at 
https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/controllers/stream.js#L146

Am continuing to investigate.

> Add Streaming Expressions to the admin page
> ---
>
> Key: SOLR-8918
> URL: https://issues.apache.org/jira/browse/SOLR-8918
> Project: Solr
>  Issue Type: New Feature
>  Components: UI, web gui
>Reporter: Dennis Gove
> Attachments: SOLR-8918.patch, SOLR-8918.patch, SOLR-8918.patch, 
> SOLR-8918.patch, SOLR-8918.patch, sample-display.png, sample-display.png
>
>
> Add to the admin page an ability to work with and view Streaming Expressions.
> This tab will appear under the Collection selection section and will work 
> similarly to the Query tab. On this page the user will be able to enter a 
> streaming expression for execution. The user can then execute the expression 
> against the collection and view all the results as they are returned from the 
> Stream handler. Along with this the user will be able to view the structure 
> of the expression in a graph-like layout. 
> If the user wishes to only view the expression structure without executing 
> the expression the user will be able to click an "Explain" button which will 
> show the structure. Included in the structure will be information about each 
> node (the expression for that node).



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