[jira] [Commented] (SOLR-9103) Restore ability for users to add custom Streaming Expressions

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9103:


Why not solrconfig.xml?  It's a known config file used for a variety of 
miscellaneous configuration and hooks to be updated via HTTP APIs (with added 
work, granted).  Unless there's a good reason to add another config file, it 
seems clearer to users to use an existing known spot.

> Restore ability for users to add custom Streaming Expressions
> -
>
> Key: SOLR-9103
> URL: https://issues.apache.org/jira/browse/SOLR-9103
> Project: Solr
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
> Attachments: HelloStream.class, SOLR-9103.PATCH, SOLR-9103.PATCH
>
>
> StreamHandler is an implicit handler. So to make it extensible, we can 
> introduce the below syntax in solrconfig.xml. 
> {code}
> 
> {code}
> This will add hello function to streamFactory of StreamHandler.



--
This message was sent by Atlassian 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-2605) queryparser parses on whitespace

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-2605:
--

[~jpountz] Indeed you are right!  I didn't think to look in the operator list, 
and didn't notice a test for it.  I just tried it out using Solr.

> queryparser parses on whitespace
> 
>
> Key: LUCENE-2605
> URL: https://issues.apache.org/jira/browse/LUCENE-2605
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/queryparser
>Reporter: Robert Muir
>Assignee: Steve Rowe
> Fix For: 6.2
>
> Attachments: LUCENE-2605-dont-split-by-default.patch, 
> LUCENE-2605.patch, LUCENE-2605.patch, LUCENE-2605.patch, LUCENE-2605.patch, 
> LUCENE-2605.patch, LUCENE-2605.patch
>
>
> The queryparser parses input on whitespace, and sends each whitespace 
> separated term to its own independent token stream.
> This breaks the following at query-time, because they can't see across 
> whitespace boundaries:
> * n-gram analysis
> * shingles 
> * synonyms (especially multi-word for whitespace-separated languages)
> * languages where a 'word' can contain whitespace (e.g. vietnamese)
> Its also rather unexpected, as users think their 
> charfilters/tokenizers/tokenfilters will do the same thing at index and 
> querytime, but
> in many cases they can't. Instead, preferably the queryparser would parse 
> around only real 'operators'.



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

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

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

[Julian Hyde (JIRA)]

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

Julian Hyde commented on SOLR-8593:
---

You should probably model your join and aggregate operators as sub-classes of 
Join and Aggregate that understand the "distribution" trait. If you are doing, 
say, "group by x" then you will need your input either to be singleton (i.e. 
only one input stream) or partitioned on x. Calcite will be able to ensure that 
the input is partitioned appropriately, either because it is stored in 
partitions, or by applying a shuffle/exchange. 

There is the regular Exchange operator that changes the distribution (i.e. 
re-partitions) and there is SortExchange that changes the distribution and also 
sorts within each partition. SortExchange models what the shuffle does in 
MapReduce.

After you have a plan like

{noformat}
MyJoin[left.a = right.b]
  Exchange[a]
MyAggregate
  Exchange
Scan[T1]
  Exchange[b]
Scan[T2]
{noformat}

you can turn into map-reduce by making the consumer of each Exchange into a 
reduce task, and the input to each Exchange a map task.

I asked [~ashutoshc] how he would generate Hive MapReduce plans in Calcite 
(most Hive plans these days are Tez) and he said you should consider writing a 
CoGroup operator (like the one in Pig). CoGroup is powerful enough to implement 
both join and aggregate, so it might save you some effort.

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



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17244/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:46101/solr/testSolrCloudCollection_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:46101/solr/testSolrCloudCollection_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([B3B89DF322430F01:8E6033DF1AAD5171]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:739)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1

Error Message:
CollectionStateWatcher not notified of stateformat=1 collection creation

Stack Trace:
java.lang.AssertionError: CollectionStateWatcher not notified of stateformat=1 
collection creation
at 
__randomizedtesting.SeedInfo.seed([D7368A9DB48CE4C0:B0F196734034C061]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWatchesWorkForStateFormat1(TestCollectionStateWatchers.java:267)
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 12951 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating 

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

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=129652, 
name=searcherExecutor-10776-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 
   1) Thread[id=129652, name=searcherExecutor-10776-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([6B5B6BE8129AB0E6]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=129652, name=searcherExecutor-10776-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=129652, name=searcherExecutor-10776-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([6B5B6BE8129AB0E6]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.overseer.ZkStateWriterTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.overseer.ZkStateWriterTest: 1) Thread[id=10159, 
name=watches-1642-thread-1, state=TIMED_WAITING, group=TGRP-ZkStateWriterTest]  
   at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+126) - Build # 1148 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1148/
Java: 32bit/jdk-9-ea+126 -server -XX:+UseG1GC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38403/c8n_1x3_lf_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:38403/c8n_1x3_lf_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([5B3F85BF237078E1:D36BBA658D8C1519]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:753)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java: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-6.x-Windows (32bit/jdk1.8.0_92) - Build # 321 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/321/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 1372 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\temp\junit4-J1-20160714_015251_070.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.security.PrivilegedActionException: java.io.IOException: There is not 
enough space on the disk
   [junit4] at java.security.AccessController.doPrivileged(Native Method)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:96)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:81)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain$3$2.write(SlaveMain.java:456)
   [junit4] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
   [junit4] at 
java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
   [junit4] at java.io.PrintStream.flush(PrintStream.java:338)
   [junit4] at java.io.FilterOutputStream.flush(FilterOutputStream.java:140)
   [junit4] at java.io.PrintStream.write(PrintStream.java:482)
   [junit4] at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
   [junit4] at 
sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
   [junit4] at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
   [junit4] at 
java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
   [junit4] at java.io.PrintStream.write(PrintStream.java:527)
   [junit4] at java.io.PrintStream.print(PrintStream.java:669)
   [junit4] at java.io.PrintStream.println(PrintStream.java:806)
   [junit4] at 
org.apache.lucene.util.RunListenerPrintReproduceInfo.printDebuggingInformation(RunListenerPrintReproduceInfo.java:144)
   [junit4] at 
org.apache.lucene.util.RunListenerPrintReproduceInfo.testRunFinished(RunListenerPrintReproduceInfo.java:118)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:706)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:140)
   [junit4] at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:591)
   [junit4] Caused by: java.io.IOException: There is not enough space on the 
disk
   [junit4] at java.io.FileOutputStream.writeBytes(Native Method)
   [junit4] at java.io.FileOutputStream.write(FileOutputStream.java:326)
   [junit4] at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
   [junit4] at java.io.BufferedOutputStream.
   [junit4] write(BufferedOutputStream.java:121)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.EventsOutputStream.write(EventsOutputStream.java:28)
   [junit4] at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
   [junit4] at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)
   [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
   [junit4] at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:135)
   [junit4] at java.io.OutputStreamWriter.write(OutputStreamWriter.java:220)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.gson.stream.JsonWriter.string(JsonWriter.java:571)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.gson.stream.JsonWriter.value(JsonWriter.java:414)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.AbstractEvent.writeBinaryProperty(AbstractEvent.java:36)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.AppendStdErrEvent.serialize(AppendStdErrEvent.java:30)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$2.run(Serializer.java:101)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer$2.run(Serializer.java:96)
   [junit4] ... 21 more
   [junit4] <<< JVM J1: EOF 

[...truncated 16 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\temp\junit4-J0-20160714_015251_070.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.security.PrivilegedActionException: java.io.IOException: There is not 
enough space on the disk
   [junit4] at java.security.AccessController.doPrivileged(Native Method)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.flushQueue(Serializer.java:96)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.events.Serializer.serialize(Serializer.java:81)
   [junit4] at 
com.carrotsearch.ant.tasks.junit4.slave.RunListenerEmitter.testAssumptionFailure(RunListenerEmitter.java:68)
   [junit4] at 

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

[Policeman Jenkins Server]

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

12 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testDoubleAssignment

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

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:59251/solr within 3 ms
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:181)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:115)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:110)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:97)
at 
org.apache.solr.cloud.OverseerTest.testDoubleAssignment(OverseerTest.java:880)
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)
Caused by: 

[jira] [Commented] (SOLR-9269) Ability to create/delete/list snapshots for a solr core

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9269:


[~dsmiley] sorry for late reply. Let me address your latest comment and submit 
a pull request in a day or two.

> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Attachments: SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



--
This message was sent by Atlassian 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-9106) Cache cluster properties in ZkStateReader

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9106:


We found a scenario where the ZK watch was not fired in a timely fashion 
resulting in the unit test failure (SOLR-9242). The changes made to fix that 
failure are exactly opposite to the intent of this JIRA (i.e. it brings back 
the old behavior).

https://github.com/apache/lucene-solr/commit/eefdc62c997f7936b6db203111d8149dc934b243

I agree with Nobel here. [~romseygeek] is reading cluster properties every-time 
a serious performance problem? 

CC [~varunthacker]

> Cache cluster properties in ZkStateReader
> -
>
> Key: SOLR-9106
> URL: https://issues.apache.org/jira/browse/SOLR-9106
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1
>
> Attachments: SOLR-9106.patch, SOLR-9106.patch
>
>
> ZkStateReader currently makes calls into ZK every time getClusterProps() is 
> called.  Instead we should keep the data locally and use a Watcher to update 
> 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-9242) Collection level backup/restore should provide a param for specifying the repository implementation it should use

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9242:


[~varunthacker] Sorry for late reply. It seems like the changes committed 
regarding the force loading the cluster properties are in direct contradiction 
with SOLR-9106. Since this is unrelated to backup/restore, I think we should 
have handled it separately.

Regarding windows failure -
I don't have the windows setup. But let me figure something out and provide a 
fix...


> Collection level backup/restore should provide a param for specifying the 
> repository implementation it should use
> -
>
> Key: SOLR-9242
> URL: https://issues.apache.org/jira/browse/SOLR-9242
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hrishikesh Gadre
>Assignee: Varun Thacker
> Fix For: 6.2
>
> Attachments: SOLR-9242.patch, SOLR-9242.patch, SOLR-9242.patch, 
> SOLR-9242.patch, SOLR-9242.patch, SOLR-9242_followup.patch
>
>
> SOLR-7374 provides BackupRepository interface to enable storing Solr index 
> data to a configured file-system (e.g. HDFS, local file-system etc.). This 
> JIRA is to track the work required to extend this functionality at the 
> collection level.



--
This message was sent by Atlassian 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 # 268 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud

Error Message:
Could not find collection:test_col

Stack Trace:
java.lang.AssertionError: Could not find collection:test_col
at __randomizedtesting.SeedInfo.seed([2ED2F4DE3FCC393]: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:154)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud.createMiniSolrCloudCluster(TestTolerantUpdateProcessorRandomCloud.java:120)
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$6.evaluate(RandomizedRunner.java:811)
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 12117 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J0/temp/solr.cloud.TestTolerantUpdateProcessorRandomCloud_2ED2F4DE3FCC393-001/init-core-data-001
   [junit4]   2> 2831767 WARN  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[2ED2F4DE3FCC393]-worker) [  
  ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 2831769 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[2ED2F4DE3FCC393]-worker) [  
  ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-9182
 - causes OOM)
   [junit4]   2> 2831769 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[2ED2F4DE3FCC393]-worker) [  
  ] o.a.s.c.TestTolerantUpdateProcessorRandomCloud Configuring cluster: 
servers=7, shards=2, repfactor=3
   [junit4]   2> 2831770 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[2ED2F4DE3FCC393]-worker) [  
  ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2831770 INFO  (Thread-5061) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2831770 INFO  (Thread-5061) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2831870 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[2ED2F4DE3FCC393]-worker) [  
  ] o.a.s.c.ZkTestServer start zk server on port:52809
   [junit4]   2> 2831870 INFO  

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:42732/solr/testSolrCloudCollection_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:42732/solr/testSolrCloudCollection_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([55EAC0E3C4E6865C:68326ECFFC08D82C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:739)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+126) - Build # 17242 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17242/
Java: 32bit/jdk-9-ea+126 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34157/c8n_1x3_lf_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34157/c8n_1x3_lf_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([7C61C8EE6708353A:F435F734C9F458C2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:753)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:178)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:533)
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 

[jira] [Commented] (SOLR-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9290:


Somebody sanity check my understanding / summary description of the root 
issue...

* Solr's use of HttpClient for intra-node communication has historically always 
had the potential to result in connections sitting "idle" (ie: in a CLOSE_WAIT 
state) for possible re-use later -- but these connections are kept open 
indefinitely. 
** For reasons I don't understand, 'idle' connections are more likely to 
(exist? | be kept around indefinitely?) when  the intra-node communication is 
over SSL.
* {{maxUpdateConnections}} and {{maxUpdateConnectionsPerHost}} have always set 
hard upper limits on the number of connections that could ever be created -- 
let alone in sitting idle in a CLOSE_WAIT state.
* Prior to SOLR-8533, the default values for these limits was relatively low, 
making it unlikely that users could ever observe an extreme # of idle / 
CLOSE_WAIT threads -- you were more likely to have your Solr cluster crash from 
deadlocks then notice any serious OS level problem with too many idle 
connections
* After SOLR-8533, the increased default values of these limits made the 
problem much more noticeable
* SOLR-4509's changes included use of a new option which results in a 
background thread checking for an existing idle connections on the master branch
* This issue address the problem for branch_6x (and older) branches via a 
similar background thread

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-SmokeRelease-6.x - Build # 110 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/110/

No tests ran.

Build Log:
[...truncated 40568 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/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-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (14.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.2.0-src.tgz...
   [smoker] 29.9 MB in 0.03 sec (903.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.2.0.tgz...
   [smoker] 64.5 MB in 0.07 sec (924.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.2.0.zip...
   [smoker] 75.1 MB in 0.08 sec (906.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6038 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.2.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6038 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.2.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 224 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 (33.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.2.0-src.tgz...
   [smoker] 39.3 MB in 0.38 sec (102.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.2.0.tgz...
   [smoker] 137.3 MB in 1.09 sec (125.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.2.0.zip...
   [smoker] 146.0 MB in 1.01 sec (144.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.2.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.2.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.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-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.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-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.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-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.2.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] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-7452:
--

Please make it optional... inaccurate-but-fast is a legit use case a lot of the 
time.

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



--
This message was sent by Atlassian JIRA
(v6.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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9290:


I'm no expert but...

bq. I don't understand why the preferred approach here is to just have a thread 
that is trying to close connections. Is the problem that these connections 
would never otherwise be closed? ...

...my understanding is yes: In a situation where indexing load spikes up, you 
can get a lot of connections which are never completely closed. (even if they 
are never needed anymore)

bq. ...If that is the case, why can't we solve the problem of them not being 
closed as a part of their normal usage? ...

again, IIUC: because they are pooled connections maintained by the HTTP layer.  
Per the docs shalin quoted, clients are required to call 
ClientConnectionManager#closeExpiredConnections() if they (ie: "we") want to 
ensure those connections get closed properly.

bq. It sounds like master doesn't have this problem because of different client 
settings? ... Why not backport that and avoid the problem entirely? Is it a 
different client version in master or something that makes it not that easy?

master & branch_6x (and earlier) use completely diff http client APIs (see 
SOLR-4509) ... the {{HttpClientBuilder.evictIdleConnections}} method shalin 
refered to being used on master is on a class ({{HttpClientBuilder}}) that is 
not used at all in branch_6x.

The docs of that method describe it doing virtually the same exact same thing 
on the (private connection pool for the) HttpClient as what Shalin's patch does 
(on the pool in the shared ClientConnectionManager) ...

{noformat}
Makes this instance of HttpClient proactively evict idle connections from the 
connection pool using a background thread. 
{noformat}

Which makes me wonder...

[~shalinmangar]: why not just re-use the {{IdleConnectionEvictor}} class 
provided by httpcomponents (getting the exact same underlying impl as what 
master gets from  {{HttpClientBuilder.evictIdleConnections}}) ?

https://hc.apache.org/httpcomponents-client-4.4.x/httpclient/apidocs/org/apache/http/impl/client/IdleConnectionEvictor.html

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9306) give solr/contrib/analysis-extras's test classes access to lucene/analysis's test classes

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9306:
--

bq. Is it okay to add the proof-of-concept test or would it be preferable to 
(in the end) only commit the build and pom xml changes?

I think the POC test is fine.

bq. Would it make sense to add the test-jar goal for all of lucene/analysis/* 
to be consistent with ant or should goals only be added as and when needed?

I think we should only add test-jar where needed.

> give solr/contrib/analysis-extras's test classes access to lucene/analysis's 
> test classes
> -
>
> Key: SOLR-9306
> URL: https://issues.apache.org/jira/browse/SOLR-9306
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9306.patch
>
>
> patch summary:
> added proof-of-concept test:
>  * made ICUCollationField's private {{createFromRules}} static with package 
> visibility
>  * added createFromRules test to {{TestICUCollationField}} (which sometimes 
> uses {{lucene/analysis/util}}'s {{StringMockResourceLoader}} class)
> build xml files (ant):
>  * added -compile-test-lucene-analysis dependency to compile-test target in 
> solr/contrib/analysis-extras
>  * defined -compile-test-lucene-analysis target in solr/common-build.xml
> pom xml templates (maven):
>  * added test-jar goal to pom.xml.template in lucene/analysis/common
>  * added lucene-analyzers-common dependency to pom.xml.template in 
> solr/contrib/analysis-extras



--
This message was sent by Atlassian 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-9306) give solr/contrib/analysis-extras's test classes access to lucene/analysis's test classes

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9306:
--

+1, ant and maven analysis-extras tests work for me with the patch; IntelliJ 
also works, no adjustment required.

> give solr/contrib/analysis-extras's test classes access to lucene/analysis's 
> test classes
> -
>
> Key: SOLR-9306
> URL: https://issues.apache.org/jira/browse/SOLR-9306
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9306.patch
>
>
> patch summary:
> added proof-of-concept test:
>  * made ICUCollationField's private {{createFromRules}} static with package 
> visibility
>  * added createFromRules test to {{TestICUCollationField}} (which sometimes 
> uses {{lucene/analysis/util}}'s {{StringMockResourceLoader}} class)
> build xml files (ant):
>  * added -compile-test-lucene-analysis dependency to compile-test target in 
> solr/contrib/analysis-extras
>  * defined -compile-test-lucene-analysis target in solr/common-build.xml
> pom xml templates (maven):
>  * added test-jar goal to pom.xml.template in lucene/analysis/common
>  * added lucene-analyzers-common dependency to pom.xml.template in 
> solr/contrib/analysis-extras



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Scott Lindner (JIRA)]

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

Scott Lindner commented on SOLR-9290:
-

I would like to add something, too.  The problem must stem from some sort of 
OS-level setting.  In our environment I've noticed that when a given IP+PORT 
combo reaches ~28k connections in a CLOSE_WAIT state that the OS, itself, 
cannot allow any more connections to that IP+PORT combo (i.e. even curl fails 
to that combo - but to other combos, including other ports on that same host - 
it works just fine).  I mention this because the problem seems related here to 
whatever settings we configure solr to use and you really must change these 
things in combination for it to ultimately make sense or you risk hitting this 
problem at some point - though admittedly with the bg thread it wouldn't be 
permanent like it is for us today.


> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17241/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC

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:36417/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:36417/collection1
at 
__randomizedtesting.SeedInfo.seed([758F230F35F9B8F2:FDDB1CD59B05D50A]: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:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:258)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
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 

[jira] [Commented] (SOLR-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[JIRA]

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

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

Have you validated that this is the only necessary change?

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



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

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

[jira] [Commented] (SOLR-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[David A. Bradley (JIRA)]

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

David A. Bradley commented on SOLR-9290:


I don't understand why the preferred approach here is to just have a thread 
that is trying to close connections. Is the problem that these connections 
would never otherwise be closed? If that is the case, why can't we solve the 
problem of them not being closed as a part of their normal usage? It sounds 
like master doesn't have this problem because of different client settings? :
"Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle connections by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit."

Why not backport that and avoid the problem entirely? Is it a different client 
version in master or something that makes it not that easy?

"So we must periodically close such connections once they're idle to avoid the 
number of such connections increasing to absurd limits." It seems from the 
discussion here that the problem is hitting a high number of connections, which 
is only allowed to be so high because we asked for it. What if this thread lags 
behind enough that the connections get too high? It sounds like the purpose of 
this thread is to race to prevent Solr from doing what we asked it to do.

The idea of having a thread to deal with any connections that end up in a bad 
state unexpectedly makes sense, but is the cause of all these CLOSE_WAIT 
connections really from unexpected behavior?

I feel like I must be missing something.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9306) give solr/contrib/analysis-extras's test classes access to lucene/analysis's test classes

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-9306:
---

got some questions:
 * Is it okay to add the proof-of-concept test or would it be preferable to (in 
the end) only commit the build and pom xml changes?
 * The {{-compile-test-lucene-analysis}} ant target is for all 
{{lucene/analysis/\*}} code whereas the test-jar maven goal is so far only 
added for the {{lucene/analysis/common}} code. Would it make sense to add the 
test-jar goal for all of {{lucene/analysis/\*}} to be consistent with ant or 
should goals only be added as and when needed?


> give solr/contrib/analysis-extras's test classes access to lucene/analysis's 
> test classes
> -
>
> Key: SOLR-9306
> URL: https://issues.apache.org/jira/browse/SOLR-9306
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9306.patch
>
>
> patch summary:
> added proof-of-concept test:
>  * made ICUCollationField's private {{createFromRules}} static with package 
> visibility
>  * added createFromRules test to {{TestICUCollationField}} (which sometimes 
> uses {{lucene/analysis/util}}'s {{StringMockResourceLoader}} class)
> build xml files (ant):
>  * added -compile-test-lucene-analysis dependency to compile-test target in 
> solr/contrib/analysis-extras
>  * defined -compile-test-lucene-analysis target in solr/common-build.xml
> pom xml templates (maven):
>  * added test-jar goal to pom.xml.template in lucene/analysis/common
>  * added lucene-analyzers-common dependency to pom.xml.template in 
> solr/contrib/analysis-extras



--
This message was sent by Atlassian 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-9306) give solr/contrib/analysis-extras's test classes access to lucene/analysis's test classes

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-9306:
--
Attachment: SOLR-9306.patch

> give solr/contrib/analysis-extras's test classes access to lucene/analysis's 
> test classes
> -
>
> Key: SOLR-9306
> URL: https://issues.apache.org/jira/browse/SOLR-9306
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9306.patch
>
>
> patch summary:
> added proof-of-concept test:
>  * made ICUCollationField's private {{createFromRules}} static with package 
> visibility
>  * added createFromRules test to {{TestICUCollationField}} (which sometimes 
> uses {{lucene/analysis/util}}'s {{StringMockResourceLoader}} class)
> build xml files (ant):
>  * added -compile-test-lucene-analysis dependency to compile-test target in 
> solr/contrib/analysis-extras
>  * defined -compile-test-lucene-analysis target in solr/common-build.xml
> pom xml templates (maven):
>  * added test-jar goal to pom.xml.template in lucene/analysis/common
>  * added lucene-analyzers-common dependency to pom.xml.template in 
> solr/contrib/analysis-extras



--
This message was sent by Atlassian 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-9306) give solr/contrib/analysis-extras's test classes access to lucene/analysis's test classes

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-9306:
-

 Summary: give solr/contrib/analysis-extras's test classes access 
to lucene/analysis's test classes
 Key: SOLR-9306
 URL: https://issues.apache.org/jira/browse/SOLR-9306
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
 Attachments: SOLR-9306.patch

patch summary:

added proof-of-concept test:
 * made ICUCollationField's private {{createFromRules}} static with package 
visibility
 * added createFromRules test to {{TestICUCollationField}} (which sometimes 
uses {{lucene/analysis/util}}'s {{StringMockResourceLoader}} class)

build xml files (ant):
 * added -compile-test-lucene-analysis dependency to compile-test target in 
solr/contrib/analysis-extras
 * defined -compile-test-lucene-analysis target in solr/common-build.xml

pom xml templates (maven):
 * added test-jar goal to pom.xml.template in lucene/analysis/common
 * added lucene-analyzers-common dependency to pom.xml.template in 
solr/contrib/analysis-extras



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Oh I see. So we didn't experience the problem because we run w/ 2 replicas (and 
one shard currently) and with 5.4.1's settings the math for us results in a low 
number of connections. But someone running a larger Solr deployment could 
already hit that problem prior to 5.5. Thanks for the clarification!

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9290:
-

bq. I was asking about 5.3.2 – how could CLOSE_WAITs get high in 5.3.2 when 
maxConnectionsPerHost was the same as in 5.4.1?

5.3.2 has maxConnectionsPerHost=100 for updates and maxConnectionsPerHost=20 
for queries. So on a leader you may have 
100*replicationFactor+20*numShards*replicationFactor connections. For a large 
cluster with many shards and replicas, the overall number of such connections 
can be quite high.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Regarding the patch, the monitor looks good. Few comments:

* I prefer that we name it {{IdleConnectionsMonitor}} (w/ 's', plural 
connections). It goes for the class, field and thread name.
* Do you intend to keep all the log statements around?
* Do you think we should make the polling interval (10s) and 
idle-connections-time (50s) configurable? Perhaps through system properties?

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

bq. Do you have only two replicas? Perhaps the maxConnectionsPerHost limit of 
100 is kicking in?

Yes, we do have only 2 replicas and I get why the CLOSE_WAITs stop at 100. I 
was asking about 5.3.2 -- how could CLOSE_WAITs get high in 5.3.2 when 
maxConnectionsPerHost was the same as in 5.4.1?

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

[jira] [Resolved] (LUCENE-7372) factor out a org.apache.lucene.search.FilterWeight class

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved LUCENE-7372.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.x
   5.x

> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.x, 6.x, master (7.0)
>
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



--
This message was sent by Atlassian 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-9305) ForceLeaderTest.testReplicasInLIRNoLeader(): connection refused

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9305:
-
Description: 
I saw the following while doing other testing on latest master, reproduces for 
me:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=ForceLeaderTest 
-Dtests.method=testReplicasInLIRNoLeader -Dtests.seed=64E138BA51B16ACE 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=de-LU -Dtests.timezone=America/Indiana/Winamac 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   32.9s | ForceLeaderTest.testReplicasInLIRNoLeader <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([64E138BA51B16ACE:82760C7A683393AF]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:753)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
No live SolrServers available to handle this 
request:[http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1]
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:393)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:747)
   [junit4]>... 49 more
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
Server refused connection at: 
http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:613)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:382)
   [junit4]>... 50 more
   [junit4]> Caused by: org.apache.http.conn.HttpHostConnectException: 
Connect to 127.0.0.1:59064 [/127.0.0.1] failed: Connection refused
   [junit4]>at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
   [junit4]>at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
   [junit4]>at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
   [junit4]>at 
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
   [junit4]>at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
   [junit4]>at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
   [junit4]>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
   [junit4] 

[jira] [Commented] (LUCENE-7372) factor out a org.apache.lucene.search.FilterWeight class

[ASF subversion and git services (JIRA)]

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

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

Commit 5c178196184f2bd0e57da510869e44d3177ac679 in lucene-solr's branch 
refs/heads/branch_5x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c17819 ]

LUCENE-7372: Add org.apache.lucene.search.FilterWeight class + test.

(This adds the class and test only, as a partial cherry-pick of the branch_5x 
commit.)


> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



--
This message was sent by Atlassian 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-9305) ForceLeaderTest.testReplicasInLIRNoLeader(): connection refused

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-9305:


 Summary: ForceLeaderTest.testReplicasInLIRNoLeader(): connection 
refused
 Key: SOLR-9305
 URL: https://issues.apache.org/jira/browse/SOLR-9305
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


I saw the following while doing other testing on latest master, reproduces for 
me:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=ForceLeaderTest 
-Dtests.method=testReplicasInLIRNoLeader -Dtests.seed=64E138BA51B16ACE 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=de-LU -Dtests.timezone=America/Indiana/Winamac 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   32.9s | ForceLeaderTest.testReplicasInLIRNoLeader <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([64E138BA51B16ACE:82760C7A683393AF]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:753)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
   [junit4]>at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
   [junit4]>at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
No live SolrServers available to handle this 
request:[http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1]
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:393)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:747)
   [junit4]>... 49 more
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
Server refused connection at: 
http://127.0.0.1:59064/forceleader_test_collection_shard1_replica1
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:613)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:382)
   [junit4]>... 50 more
   [junit4]> Caused by: org.apache.http.conn.HttpHostConnectException: 
Connect to 127.0.0.1:59064 [/127.0.0.1] failed: Connection refused
   [junit4]>at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:151)
   [junit4]>at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
   [junit4]>at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
   [junit4]>at 
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
   [junit4]>at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
   [junit4]>at 

[jira] [Created] (SOLR-9304) -Dsolr.ssl.checkPeerName=false ignored on master

[Hoss Man (JIRA)]

Hoss Man created SOLR-9304:
--

 Summary: -Dsolr.ssl.checkPeerName=false ignored on master
 Key: SOLR-9304
 URL: https://issues.apache.org/jira/browse/SOLR-9304
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (7.0)
Reporter: Hoss Man


{{-Dsolr.ssl.checkPeerName=false}} is completely ignored on master...

{noformat}
hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep 
checkPeerName
./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:  public 
static final String SYS_PROP_CHECK_PEER_NAME = "solr.ssl.checkPeerName";
hossman@tray:~/lucene/dev/solr [master] $ find -name \*.java | xargs grep 
SYS_PROP_CHECK_PEER_NAME
./test-framework/src/java/org/apache/solr/util/SSLTestConfig.java:  boolean 
sslCheckPeerName = 
toBooleanDefaultIfNull(toBooleanObject(System.getProperty(HttpClientUtil.SYS_PROP_CHECK_PEER_NAME)),
 true);
./solrj/src/java/org/apache/solr/client/solrj/impl/HttpClientUtil.java:  public 
static final String SYS_PROP_CHECK_PEER_NAME = "solr.ssl.checkPeerName";
{noformat}



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9290:
-

bq. I didn't see the monitor in the latest patch, only the log printouts. Did 
you forget to add it?

Sorry [~shaie], I noticed that after uploaded. I have uploaded the right patch 
now. Please review.

bq. (1) Can/Should we have a similar monitor for HttpShardHandlerFactory?

I think so. This patch was only for my tests.

bq. Any reason why the two don't share the same HttpClient instance?

Hmm. I think originally the idea was to keep the pools for indexing and 
querying separate but now that the limit (for updates) is so high, I wonder if 
it still makes sense. I mean, yes you can deadlock a distributed search because 
of high indexing and vice-versa if you share the pool but if you ever reach the 
high limit of 100,000 connections, you have more serious problems in the 
cluster anyway.

bq. I wonder why we don't see the problem with 5.4.1. I mean, we do see 
CLOSE_WAITs piling, but stop at ~100 (200 for the leader)

Do you have only two replicas? Perhaps the maxConnectionsPerHost limit of 100 
is kicking in?

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-7452) json facet api returning inconsistent counts in cloud set up

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-7452:


I actually just found some time to make a little progress on this today.
I'm going to be traveling for the next 3 weeks, starting this weekend.
I'll try to put up a patch with whatever I've got before that point.

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



--
This message was sent by Atlassian JIRA
(v6.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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

bq. I thought that hypothesis holds only after SOLR-8533. Are you saying you 
also saw it on 5.3.2? If so, what are the values that are set for these 
properties there? We definitely do not see the problem with 5.4.1, but we 
didn't test prior versions.

We posted at the same time, I read your answer above. I wonder why we don't see 
the problem with 5.4.1. I mean, we do see CLOSE_WAITs piling, but stop at ~100 
(200 for the leader).

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Thanks [~shalinmangar]. Few questions:

bq. Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle threads by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.

Is this something we can apply to 5x/6x too?

bq. This patch adds a monitor thread for the pool created in UpdateShardHandler 
and with this applied

I didn't see the monitor in the latest patch, only the log printouts. Did you 
forget to add it?

bq. There are still a few connections in CLOSE_WAIT at steady state but I 
verified that they belong to a different HttpClient instance in 
HttpShardHandlerFactory and other places.

(1) Can/Should we have a similar monitor for HttpShardHandlerFactory?
(2) Any reason why the two don't share the same HttpClient instance?

bq. This patch applies on 5.3.2
bq. We have a large limit for maxConnections and maxConnectionsPerHost

I thought that hypothesis holds only after SOLR-8533. Are you saying you also 
saw it on 5.3.2? If so, what are the values that are set for these properties 
there? We definitely *do not* see the problem with 5.4.1, but we didn't test 
prior versions.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9290:

Attachment: SOLR-9290-debug.patch

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9290:

Attachment: (was: SOLR-9290-debug.patch)

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

[jira] [Comment Edited] (SOLR-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar edited comment on SOLR-9290 at 7/13/16 7:02 PM:
--

This patch applies on 5.3.2. This patch adds a monitor thread for the pool 
created in UpdateShardHandler and with this applied, I cannot reproduce this 
problem anymore. There are still a few connections in CLOSE_WAIT at steady 
state but I verified that they belong to a different HttpClient instance in 
HttpShardHandlerFactory and other places.

My hypothesis is that: We have a large limit for maxConnections and 
maxConnectionsPerHost. As long as the limit isn't met and the servers are 
decently busy, new connections will continue to be created from the pool. In 
5.x and 6.x, we do not have a policy of closing idle connections so httpclient 
will keep these connections in CLOSE_WAIT for reuse. So we must periodically 
close such connections once they're idle to avoid the number of such 
connections increasing to absurd limits.

Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle connections by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.


was (Author: shalinmangar):
This patch applies on 5.3.2. This patch adds a monitor thread for the pool 
created in UpdateShardHandler and with this applied, I cannot reproduce this 
problem anymore. There are still a few connections in CLOSE_WAIT at steady 
state but I verified that they belong to a different HttpClient instance in 
HttpShardHandlerFactory and other places.

My hypothesis is that: We have a large limit for maxConnections and 
maxConnectionsPerHost. As long as the limit isn't met and the servers are 
decently busy, new connections will continue to be created from the pool. In 
5.x and 6.x, we do not have a policy of closing idle connections so httpclient 
will keep these connections in CLOSE_WAIT for reuse. So we must periodically 
close such connections once they're idle to avoid the number of such 
connections increasing to absurd limits.

Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle threads by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9290:
-

{quote}
Shalin Shekhar Mangar mentioned that he's able to reproduce this in 5.3.2 as 
well, which was without SOLR-8533 so we certainly need to look at this more.

Shalin, can you confirm if you were running your tests in stock Solr ?
{quote}

Actually it is 5.3.2 with some kerberos patches but the client which originally 
reported the issue was using stock 5.3.2. I don't think the changes are 
relevant.

I believe this was a problem all along. It just got amplified with SOLR-8533 in 
5.5.x because now the limit is higher.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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 (64bit/jdk1.8.0_92) - Build # 1145 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 9899 lines...]
[javac] Compiling 938 source files to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/core/src/java/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.java:112:
 error: cannot find symbol
[javac] LeafReader leafReader = req.getSearcher().getLeafReader();
[javac] ^
[javac]   symbol:   class LeafReader
[javac]   location: class ClassificationUpdateProcessorFactory
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:763: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:707: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build.xml:233: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:530: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:478: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/common-build.xml:385: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/lucene/common-build.xml:1955: 
Compile failed; see the compiler error output for details.

Total time: 25 minutes 13 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] [Comment Edited] (SOLR-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar edited comment on SOLR-9290 at 7/13/16 6:59 PM:
--

This patch applies on 5.3.2. This patch adds a monitor thread for the pool 
created in UpdateShardHandler and with this applied, I cannot reproduce this 
problem anymore. There are still a few connections in CLOSE_WAIT at steady 
state but I verified that they belong to a different HttpClient instance in 
HttpShardHandlerFactory and other places.

My hypothesis is that: We have a large limit for maxConnections and 
maxConnectionsPerHost. As long as the limit isn't met and the servers are 
decently busy, new connections will continue to be created from the pool. In 
5.x and 6.x, we do not have a policy of closing idle connections so httpclient 
will keep these connections in CLOSE_WAIT for reuse. So we must periodically 
close such connections once they're idle to avoid the number of such 
connections increasing to absurd limits.

Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle threads by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.


was (Author: shalinmangar):
This patch applies on 5.3.2. This patch adds a monitor thread for the pool 
created in UpdateShardHandler and with this applied, I cannot reproduce this 
problem anymore.

My hypothesis is that: We have a large limit for maxConnections and 
maxConnectionsPerHost. As long as the limit isn't met and the servers are 
decently busy, new connections will continue to be created from the pool. In 
5.x and 6.x, we do not have a policy of closing idle connections so httpclient 
will keep these connections in CLOSE_WAIT for reuse. So we must periodically 
close such connections once they're idle to avoid the number of such 
connections increasing to absurd limits.

Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle threads by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9290:

Attachment: SOLR-9290-debug.patch

This patch applies on 5.3.2. This patch adds a monitor thread for the pool 
created in UpdateShardHandler and with this applied, I cannot reproduce this 
problem anymore.

My hypothesis is that: We have a large limit for maxConnections and 
maxConnectionsPerHost. As long as the limit isn't met and the servers are 
decently busy, new connections will continue to be created from the pool. In 
5.x and 6.x, we do not have a policy of closing idle connections so httpclient 
will keep these connections in CLOSE_WAIT for reuse. So we must periodically 
close such connections once they're idle to avoid the number of such 
connections increasing to absurd limits.

Also, I think the reason this wasn't reproducible on master is because 
SOLR-4509 enabled eviction of idle threads by calling 
HttpClientBuilder#evictIdleConnections with a 50 second limit.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, SOLR-9290-debug.patch, 
> setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-9290:


[~shalinmangar] mentioned that he's able to reproduce this in 5.3.2 as well, 
which was without SOLR-8533 so we certainly need to look at this more.

Shalin, can you confirm if you were running your tests in stock Solr ?

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-7372) factor out a org.apache.lucene.search.FilterWeight class

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7372: Factor out an org.apache.lucene.search.FilterWeight class.


> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



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

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

Re: [JENKINS] Solr-Artifacts-6.x - Build # 111 - Failure

[Steve Rowe]

I pushed a fix.

--
Steve
www.lucidworks.com

> On Jul 13, 2016, at 2:33 PM, Steve Rowe  wrote:
> 
> I think this may be my fault (LUCENE-7013), tracking it down now.
> 
>> On Jul 13, 2016, at 2:07 PM, Apache Jenkins Server 
>>  wrote:
>> 
>> Build: https://builds.apache.org/job/Solr-Artifacts-6.x/111/
>> 
>> No tests ran.
>> 
>> Build Log:
>> [...truncated 1959 lines...]
>>   [javac] Compiling 938 source files to 
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build/solr-core/classes/java
>>   [javac] 
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/core/src/java/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.java:112:
>>  error: cannot find symbol
>>   [javac] LeafReader leafReader = req.getSearcher().getLeafReader();
>>   [javac] ^
>>   [javac]   symbol:   class LeafReader
>>   [javac]   location: class ClassificationUpdateProcessorFactory
>>   [javac] Note: Some input files use or override a deprecated API.
>>   [javac] Note: Recompile with -Xlint:deprecation for details.
>>   [javac] Note: Some input files use unchecked or unsafe operations.
>>   [javac] Note: Recompile with -Xlint:unchecked for details.
>>   [javac] 1 error
>> 
>> BUILD FAILED
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build.xml:520: 
>> The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/common-build.xml:398:
>>  The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:501:
>>  The following error occurred while executing this line:
>> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:1955:
>>  Compile failed; see the compiler error output for details.
>> 
>> Total time: 1 minute 12 seconds
>> Build step 'Invoke Ant' marked build as failure
>> Archiving artifacts
>> Publishing Javadoc
>> 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
> 


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

[jira] [Commented] (LUCENE-7013) Move license header before package declaration in all *.java files

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7013: ClassificationUpdateProcessorFactory.java: fix bad merge (merged 
master import into branch_6x)


> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

Re: [JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 320 - Still Failing!

[Steve Rowe]

Uwe, Policeman Jenkins's hard disk is full.

--
Steve
www.lucidworks.com

> On Jul 13, 2016, at 2:10 PM, Policeman Jenkins Server  
> wrote:
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/320/
> Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC
> 
> No tests ran.
> 
> Build Log:
> [...truncated 14 lines...]
> FATAL: Exception caught during execution of reset command. {0}
> org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during 
> execution of reset command. {0}
>   at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:230)
>   at 
> org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at java.lang.reflect.Method.invoke(Unknown Source)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
>   at 
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:818)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:153)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:50)
>   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:253)
>   at hudson.remoting.Channel.call(Channel.java:781)
>   at 
> hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:249)
>   at com.sun.proxy.$Proxy54.clean(Unknown Source)
>   at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:453)
>   at 
> hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:32)
>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795)
>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055)
>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
>   at hudson.scm.SCM.checkout(SCM.java:495)
>   at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
>   at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
>   at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
>   at hudson.model.Run.execute(Run.java:1720)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
>   at hudson.model.ResourceController.execute(ResourceController.java:98)
>   at hudson.model.Executor.run(Executor.java:404)
> Caused by: java.io.IOException: There is not enough space on the disk
>   at java.io.FileOutputStream.writeBytes(Native Method)
>   at java.io.FileOutputStream.write(Unknown Source)
>   at 
> org.eclipse.jgit.internal.storage.file.LockFile$2.write(LockFile.java:327)
>   at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
>   at java.io.BufferedOutputStream.write(Unknown Source)
>   at java.security.DigestOutputStream.write(Unknown Source)
>   at org.eclipse.jgit.dircache.DirCacheEntry.write(DirCacheEntry.java:299)
>   at org.eclipse.jgit.dircache.DirCache.writeTo(DirCache.java:670)
>   at org.eclipse.jgit.dircache.DirCache.write(DirCache.java:610)
>   at 
> org.eclipse.jgit.dircache.BaseDirCacheEditor.commit(BaseDirCacheEditor.java:198)
>   at 
> org.eclipse.jgit.dircache.DirCacheBuilder.commit(DirCacheBuilder.java:72)
>   at 
> org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:455)
>   at 
> org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:396)
>   at 
> org.eclipse.jgit.api.ResetCommand.checkoutIndex(ResetCommand.java:396)
>   at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:203)
>   at 
> org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>   at java.lang.reflect.Method.invoke(Unknown Source)
>   at 
> 

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-6.x #113: POMs out of sync

[Steve Rowe]

Christine,

“POMs out of sync” is how the Jenkins Maven builds say “something went wrong”, 
e.g. (as in this case) compilation failure (you can see this if you go look at 
the console output on Jenkins) - this is almost certainly not caused by 
SOLR-9298 or SOLR-9300.

--
Steve
www.lucidworks.com

> On Jul 13, 2016, at 2:29 PM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Hello.
> 
> "POMs out of sync" - will it get synced up automatically somehow or is some 
> sort of human intervention needed?
> 
> In SOLR-9298 and SOLR-9300 I made some small maven/pom related changes today 
> but am quite new to maven.
> 
> Thanks,
> 
> Christine
> 
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: 07/13/16 19:12:33
> 
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/113/
> 
> No tests ran.
> 
> Build Log:
> [...truncated 9206 lines...]
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:779: The 
> following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:319: The 
> following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:65:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:60:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/build.xml:520: 
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:398:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:501:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:1955:
>  Compile failed; see the compiler error output for details.
> 
> Total time: 4 minutes 18 seconds
> Build step 'Invoke Ant' marked build as failure
> 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
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateChecksCurrentState

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([412F3FB4C25A6BE4:97C3506C920316B1]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1233)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:630)
at 
org.apache.solr.common.cloud.TestCollectionStateWatchers.testWaitForStateChecksCurrentState(TestCollectionStateWatchers.java:158)
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 13213 lines...]
   [junit4] Suite: org.apache.solr.common.cloud.TestCollectionStateWatchers
   [junit4]   2> Creating dataDir: 

Re: [JENKINS] Solr-Artifacts-6.x - Build # 111 - Failure

[Steve Rowe]

I think this may be my fault (LUCENE-7013), tracking it down now.

> On Jul 13, 2016, at 2:07 PM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Solr-Artifacts-6.x/111/
> 
> No tests ran.
> 
> Build Log:
> [...truncated 1959 lines...]
>[javac] Compiling 938 source files to 
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build/solr-core/classes/java
>[javac] 
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/core/src/java/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.java:112:
>  error: cannot find symbol
>[javac] LeafReader leafReader = req.getSearcher().getLeafReader();
>[javac] ^
>[javac]   symbol:   class LeafReader
>[javac]   location: class ClassificationUpdateProcessorFactory
>[javac] Note: Some input files use or override a deprecated API.
>[javac] Note: Recompile with -Xlint:deprecation for details.
>[javac] Note: Some input files use unchecked or unsafe operations.
>[javac] Note: Recompile with -Xlint:unchecked for details.
>[javac] 1 error
> 
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build.xml:520: 
> The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/common-build.xml:398:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:501:
>  The following error occurred while executing this line:
> /x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:1955:
>  Compile failed; see the compiler error output for details.
> 
> Total time: 1 minute 12 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving artifacts
> Publishing Javadoc
> 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


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

[jira] [Commented] (SOLR-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Thanks [~yo...@apache.org], I'll read the issue.

I agree with what you write in general, but we do hit an issue with these 
settings. That that it reproduces easily with SSL enabled suggests that the 
issue may not be in Solr code at all, but I wonder if we shouldn't perhaps pick 
smaller default values if SSL is enabled? (Our guess at the moment is that HC 
keeps more connections in the pool when SSL is enabled because they are more 
expensive to initiate, but it's just a guess).

And maybe the proper solution would be what [~shalinmangar] wrote above -- have 
a bg monitor which closes idle/expired connections. I actually wonder why it 
can't be a property of {{ClientConnectionManager}} that you can set to auto 
close idle/expired connections after a period of time. We can potentially have 
that monitor act only if SSL is enabled (or at least until non-SSL exhibits the 
same problems too).

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

Re:[JENKINS-MAVEN] Lucene-Solr-Maven-6.x #113: POMs out of sync

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hello.

"POMs out of sync" - will it get synced up automatically somehow or is some 
sort of human intervention needed?

In SOLR-9298 and SOLR-9300 I made some small maven/pom related changes today 
but am quite new to maven.

Thanks,

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: 07/13/16 19:12:33

Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/113/

No tests ran.

Build Log:
[...truncated 9206 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:779: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:319: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:65:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:60:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/build.xml:520: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:501:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:1955:
 Compile failed; see the compiler error output for details.

Total time: 4 minutes 18 seconds
Build step 'Invoke Ant' marked build as failure
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] [Updated] (SOLR-7036) Faster method for group.facet

[md (JIRA)]

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

md updated SOLR-7036:
-
Attachment: performance.txt
SOLR-7036.patch

> Faster method for group.facet
> -
>
> Key: SOLR-7036
> URL: https://issues.apache.org/jira/browse/SOLR-7036
> Project: Solr
>  Issue Type: Improvement
>  Components: faceting
>Affects Versions: 4.10.3
>Reporter: Jim Musil
>Assignee: Erick Erickson
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7036.patch, SOLR-7036.patch, SOLR-7036.patch, 
> performance.txt
>
>
> This is a patch that speeds up the performance of requests made with 
> group.facet=true. The original code that collects and counts unique facet 
> values for each group does not use the same improved field cache methods that 
> have been added for normal faceting in recent versions.
> Specifically, this approach leverages the UninvertedField class which 
> provides a much faster way to look up docs that contain a term. I've also 
> added a simple grouping map so that when a term is found for a doc, it can 
> quickly look up the group to which it belongs.
> Group faceting was very slow for our data set and when the number of docs or 
> terms was high, the latency spiked to multiple second requests. This solution 
> provides better overall performance -- from an average of 54ms to 32ms. It 
> also dropped our slowest performing queries way down -- from 6012ms to 991ms.
> I also added a few tests.
> I added an additional parameter so that you can choose to use this method or 
> the original. Add group.facet.method=fc to use the improved method or 
> group.facet.method=original which is the default if not specified.



--
This message was sent by Atlassian 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-MAVEN] Lucene-Solr-Maven-6.x #113: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/113/

No tests ran.

Build Log:
[...truncated 9206 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:779: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:319: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:65:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:60:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/build.xml:520: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:501:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:1955:
 Compile failed; see the compiler error output for details.

Total time: 4 minutes 18 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 320 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/320/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 14 lines...]
FATAL: Exception caught during execution of reset command. {0}
org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during 
execution of reset command. {0}
at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:230)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:818)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
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:253)
at hudson.remoting.Channel.call(Channel.java:781)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:249)
at com.sun.proxy.$Proxy54.clean(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:453)
at 
hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:32)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1720)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Caused by: java.io.IOException: There is not enough space on the disk
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(Unknown Source)
at 
org.eclipse.jgit.internal.storage.file.LockFile$2.write(LockFile.java:327)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.write(Unknown Source)
at java.security.DigestOutputStream.write(Unknown Source)
at org.eclipse.jgit.dircache.DirCacheEntry.write(DirCacheEntry.java:299)
at org.eclipse.jgit.dircache.DirCache.writeTo(DirCache.java:670)
at org.eclipse.jgit.dircache.DirCache.write(DirCache.java:610)
at 
org.eclipse.jgit.dircache.BaseDirCacheEditor.commit(BaseDirCacheEditor.java:198)
at 
org.eclipse.jgit.dircache.DirCacheBuilder.commit(DirCacheBuilder.java:72)
at 
org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:455)
at 
org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:396)
at 
org.eclipse.jgit.api.ResetCommand.checkoutIndex(ResetCommand.java:396)
at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:203)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5983 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5983/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseSerialGC

No tests ran.

Build Log:
[...truncated 12 lines...]
FATAL: Exception caught during execution of reset command. {0}
org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during 
execution of reset command. {0}
at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:230)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:818)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
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:253)
at hudson.remoting.Channel.call(Channel.java:781)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:249)
at com.sun.proxy.$Proxy54.clean(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:453)
at 
hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:32)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1055)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1720)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:404)
Caused by: java.io.IOException: There is not enough space on the disk
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(Unknown Source)
at 
org.eclipse.jgit.internal.storage.file.LockFile$2.write(LockFile.java:327)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.write(Unknown Source)
at java.security.DigestOutputStream.write(Unknown Source)
at org.eclipse.jgit.dircache.DirCacheEntry.write(DirCacheEntry.java:299)
at org.eclipse.jgit.dircache.DirCache.writeTo(DirCache.java:670)
at org.eclipse.jgit.dircache.DirCache.write(DirCache.java:610)
at 
org.eclipse.jgit.dircache.BaseDirCacheEditor.commit(BaseDirCacheEditor.java:198)
at 
org.eclipse.jgit.dircache.DirCacheBuilder.commit(DirCacheBuilder.java:72)
at 
org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:455)
at 
org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:396)
at 
org.eclipse.jgit.api.ResetCommand.checkoutIndex(ResetCommand.java:396)
at org.eclipse.jgit.api.ResetCommand.call(ResetCommand.java:203)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 

[JENKINS] Solr-Artifacts-6.x - Build # 111 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-6.x/111/

No tests ran.

Build Log:
[...truncated 1959 lines...]
[javac] Compiling 938 source files to 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build/solr-core/classes/java
[javac] 
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/core/src/java/org/apache/solr/update/processor/ClassificationUpdateProcessorFactory.java:112:
 error: cannot find symbol
[javac] LeafReader leafReader = req.getSearcher().getLeafReader();
[javac] ^
[javac]   symbol:   class LeafReader
[javac]   location: class ClassificationUpdateProcessorFactory
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/build.xml:520: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/solr/common-build.xml:398:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:501:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Solr-Artifacts-6.x/lucene/common-build.xml:1955:
 Compile failed; see the compiler error output for details.

Total time: 1 minute 12 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

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

[Apache Jenkins Server]

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

10 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:36041/_mgl/y

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:36041/_mgl/y
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:617)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:516)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:180)
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] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up

[Otis Gospodnetic (JIRA)]

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

Otis Gospodnetic commented on SOLR-7452:


[~yo...@apache.org] We've gotten inquiries about this bug/patch/fix at 
Sematext, but if you're working on this then maybe it's better for us not to 
meddle, so like a few others above, I'm curious about the status of this.

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



--
This message was sent by Atlassian JIRA
(v6.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-7013) Move license header before package declaration in all *.java files

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7013: move license header before package declaration


> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

[jira] [Resolved] (LUCENE-7013) Move license header before package declaration in all *.java files

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-7013.

Resolution: Fixed

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: trunk, 5.5
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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-7013) Move license header before package declaration in all *.java files

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7013: add licence header position checker to -validate-source-patterns, 
and fix the violations it found


> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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 # 267 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:37425/rabe/jj/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:37425/rabe/jj/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([A3BEBFC138E7A44A:45298B0101655D2B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:739)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1151)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1040)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:976)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java: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 

[jira] [Commented] (LUCENE-7013) Move license header before package declaration in all *.java files

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7013: add licence header position checker to -validate-source-patterns, 
and fix the violations it found


> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

[jira] [Updated] (LUCENE-7013) Move license header before package declaration in all *.java files

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7013:
---
Attachment: LUCENE-7013-precommit.patch

oops, patch was missing {{UnicodeProps.java}} fix, included now.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

[jira] [Updated] (LUCENE-7013) Move license header before package declaration in all *.java files

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7013:
---
Attachment: LUCENE-7013-precommit.patch

Patch with all violations fixed, includes Uwe's last version of the checker 
unchanged.

Other changes:

* fixed the {{unicode-data}} generator to put the package in the right place in 
its generated {{UnicodeProps.java}},
* put a blank line between the license header and the package in all {{.jflex}} 
files, and in the {{.java}} files they generate.

Running precommit and all tests now, will commit if no problems.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013.patch, mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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-9298) solr/contrib/analysis-extras tests fail with maven (SSLTestConfig)

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9298.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2
   5.6

> solr/contrib/analysis-extras tests fail with maven (SSLTestConfig)
> --
>
> Key: SOLR-9298
> URL: https://issues.apache.org/jira/browse/SOLR-9298
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.2, master (7.0)
>
> Attachments: SOLR-9298.patch, SOLR-9298.patch
>
>
> The error/exception concerned is
> {code}
> java.lang.IllegalStateException: Unable to locate keystore resource file in 
> classpath: SSLTestConfig.testing.keystore
> {code}
> and it seems something similar to the [dev-tools/idea 
> commit|https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6942fe2] 
> in SOLR-8970 is also needed for 
> [dev-tools/maven|https://github.com/apache/lucene-solr/tree/master/dev-tools/maven]'s
>  
> [solr/test-framework/pom.xml.template|https://github.com/apache/lucene-solr/blob/master/dev-tools/maven/solr/test-framework/pom.xml.template#L61]
>  file.
> Attached patch seems to work but I am new to maven and so would very much 
> appreciate additional input on this. Thank you.



--
This message was sent by Atlassian 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-9090) solrj CloudSolrClient: add directUpdatesToLeadersOnly support

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9090.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2

> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> -
>
> Key: SOLR-9090
> URL: https://issues.apache.org/jira/browse/SOLR-9090
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9090.patch, SOLR-9090.patch
>
>
> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> (Marvin Justice, Christine Poerschke)
> Proposed change:
> * Addition of a {{directUpdatesToLeadersOnly}} flag to allow clients to 
> request that direct updates be sent to the shard leaders and only to the 
> shard leaders.
> Motivation:
> * In a scenario where there is temporarily no shard leader the update request 
> will 'fail fast' allowing the client to handle retry logic.
> Related tickets:
> * SOLR-6312 concerns the ((currently) no longer used) {{updatesToLeaders}} 
> flag. The updatesToLeaders logic however appears to be slightly different 
> from the proposed directUpdatesToLeadersOnly logic: {{updatesToLeaders}} 
> indicates that sending to leaders is preferred but not mandatory whereas 
> {{directUpdatesToLeadersOnly}} mandates sending to leaders only.



--
This message was sent by Atlassian 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-9300) fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId method.

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-9300.
---
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.2
   5.6

> fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method.
> ---
>
> Key: SOLR-9300
> URL: https://issues.apache.org/jira/browse/SOLR-9300
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 5.6, 6.2, master (7.0)
>
> Attachments: SOLR-9300.patch
>
>
> Fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method. (Christine Poerschke, Daniel Collins)
> One line {{replace}} vs. {{replaceAll}} in 
> [GetMavenDependenciesTask.java|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L643]
>  since [String 
> replace|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-]
>  takes the CharSequence (or char) literally and [String 
> replaceAll|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String-]
>  (or replaceFirst) takes a regular expression such a 
> {{"(? (As an aside, in case anyone else is also wondering about the meaning of 
> {{(? [Pattern|https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html]
>  javadocs list a special construct {{(? bq.X, via zero-width negative lookbehind
> and the [Lookahead and Lookbehind Zero-Length 
> Assertions|http://www.regular-expressions.info/lookaround.html] tutorial 
> helped us understand the meaning of that list entry.)



--
This message was sent by Atlassian 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-9300) fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId method.

[ASF subversion and git services (JIRA)]

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

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

Commit 5f698bb96682383e4fd9a2f5e906867ffeb63755 in lucene-solr's branch 
refs/heads/branch_5x from [~cpoerschke]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5f698bb ]

SOLR-9300: fix replace expression in GetMavenDependenciesTask's 
dependencyToArtifactId (Christine Poerschke, Daniel Collins)


> fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method.
> ---
>
> Key: SOLR-9300
> URL: https://issues.apache.org/jira/browse/SOLR-9300
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9300.patch
>
>
> Fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method. (Christine Poerschke, Daniel Collins)
> One line {{replace}} vs. {{replaceAll}} in 
> [GetMavenDependenciesTask.java|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L643]
>  since [String 
> replace|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-]
>  takes the CharSequence (or char) literally and [String 
> replaceAll|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String-]
>  (or replaceFirst) takes a regular expression such a 
> {{"(? (As an aside, in case anyone else is also wondering about the meaning of 
> {{(? [Pattern|https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html]
>  javadocs list a special construct {{(? bq.X, via zero-width negative lookbehind
> and the [Lookahead and Lookbehind Zero-Length 
> Assertions|http://www.regular-expressions.info/lookaround.html] tutorial 
> helped us understand the meaning of that list entry.)



--
This message was sent by Atlassian 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-9300) fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId method.

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9300: fix replace expression in GetMavenDependenciesTask's 
dependencyToArtifactId (Christine Poerschke, Daniel Collins)


> fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method.
> ---
>
> Key: SOLR-9300
> URL: https://issues.apache.org/jira/browse/SOLR-9300
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9300.patch
>
>
> Fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method. (Christine Poerschke, Daniel Collins)
> One line {{replace}} vs. {{replaceAll}} in 
> [GetMavenDependenciesTask.java|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L643]
>  since [String 
> replace|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-]
>  takes the CharSequence (or char) literally and [String 
> replaceAll|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String-]
>  (or replaceFirst) takes a regular expression such a 
> {{"(? (As an aside, in case anyone else is also wondering about the meaning of 
> {{(? [Pattern|https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html]
>  javadocs list a special construct {{(? bq.X, via zero-width negative lookbehind
> and the [Lookahead and Lookbehind Zero-Length 
> Assertions|http://www.regular-expressions.info/lookaround.html] tutorial 
> helped us understand the meaning of that list entry.)



--
This message was sent by Atlassian 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-9300) fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId method.

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9300: fix replace expression in GetMavenDependenciesTask's 
dependencyToArtifactId (Christine Poerschke, Daniel Collins)


> fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method.
> ---
>
> Key: SOLR-9300
> URL: https://issues.apache.org/jira/browse/SOLR-9300
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9300.patch
>
>
> Fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method. (Christine Poerschke, Daniel Collins)
> One line {{replace}} vs. {{replaceAll}} in 
> [GetMavenDependenciesTask.java|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L643]
>  since [String 
> replace|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-]
>  takes the CharSequence (or char) literally and [String 
> replaceAll|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String-]
>  (or replaceFirst) takes a regular expression such a 
> {{"(? (As an aside, in case anyone else is also wondering about the meaning of 
> {{(? [Pattern|https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html]
>  javadocs list a special construct {{(? bq.X, via zero-width negative lookbehind
> and the [Lookahead and Lookbehind Zero-Length 
> Assertions|http://www.regular-expressions.info/lookaround.html] tutorial 
> helped us understand the meaning of that list entry.)



--
This message was sent by Atlassian 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-7372) factor out a org.apache.lucene.search.FilterWeight class

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7372: Factor out an org.apache.lucene.search.FilterWeight class.


> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9290:


bq. if you have a link to a discussion about why it may lead to a distributed 
deadlock, I'd be happy to read it.
SOLR-683

Same logic applies to any internal general purpose thread pools or connection 
pools / connection limits.  Think of acquiring a thread like acquiring a lock.  
If there are going to be a limited number of resources, then one needs to be 
very careful under what circumstances those resources can be acquired.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.component.DistributedQueryComponentOptimizationTest:
 1) Thread[id=5384, 
name=OverseerHdfsCoreFailoverThread-96234629619580936-127.0.0.1:62058_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at 
org.apache.solr.handler.component.DistributedQueryComponentOptimizationTest: 
   1) Thread[id=5384, 
name=OverseerHdfsCoreFailoverThread-96234629619580936-127.0.0.1:62058_solr-n_01,
 state=TIMED_WAITING, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:137)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([4EC22375BC056528]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.component.DistributedQueryComponentOptimizationTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=5384, 
name=OverseerHdfsCoreFailoverThread-96234629619580936-127.0.0.1:62058_solr-n_01,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.] at 
java.lang.Thread.interrupt0(Native Method) at 
java.lang.Thread.interrupt(Thread.java:923) at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=5384, 
name=OverseerHdfsCoreFailoverThread-96234629619580936-127.0.0.1:62058_solr-n_01,
 state=RUNNABLE, group=Overseer Hdfs SolrCore Failover Thread.]
at java.lang.Thread.interrupt0(Native Method)
at java.lang.Thread.interrupt(Thread.java:923)
at 
org.apache.solr.cloud.OverseerAutoReplicaFailoverThread.run(OverseerAutoReplicaFailoverThread.java:139)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([4EC22375BC056528]:0)




Build Log:
[...truncated 10855 lines...]
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedQueryComponentOptimizationTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.handler.component.DistributedQueryComponentOptimizationTest_4EC22375BC056528-001/init-core-data-001
   [junit4]   2> 734462 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 734464 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 734464 INFO  (Thread-1854) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 734464 INFO  (Thread-1854) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 734564 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.ZkTestServer start zk server on port:37764
   [junit4]   2> 734565 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 734565 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 734570 INFO  (zkCallback-695-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@6a314281 
name:ZooKeeperConnection Watcher:127.0.0.1:37764 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 734571 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 734571 INFO  
(SUITE-DistributedQueryComponentOptimizationTest-seed#[4EC22375BC056528]-worker)
 [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 734571 INFO  

[jira] [Commented] (LUCENE-7013) Move license header before package declaration in all *.java files

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7013:
---

Ok, go ahead!

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Also [~markrmil...@gmail.com], for education purposes, if you have a link to a 
discussion about why it may lead to a distributed deadlock, I'd be happy to 
read it.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9300) fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId method.

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9300:
--

oof, +1 :)

> fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method.
> ---
>
> Key: SOLR-9300
> URL: https://issues.apache.org/jira/browse/SOLR-9300
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9300.patch
>
>
> Fix replace expression in GetMavenDependenciesTask's dependencyToArtifactId 
> method. (Christine Poerschke, Daniel Collins)
> One line {{replace}} vs. {{replaceAll}} in 
> [GetMavenDependenciesTask.java|https://github.com/apache/lucene-solr/blob/master/lucene/tools/src/java/org/apache/lucene/dependencies/GetMavenDependenciesTask.java#L643]
>  since [String 
> replace|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replace-java.lang.CharSequence-java.lang.CharSequence-]
>  takes the CharSequence (or char) literally and [String 
> replaceAll|https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#replaceAll-java.lang.String-java.lang.String-]
>  (or replaceFirst) takes a regular expression such a 
> {{"(? (As an aside, in case anyone else is also wondering about the meaning of 
> {{(? [Pattern|https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html]
>  javadocs list a special construct {{(? bq.X, via zero-width negative lookbehind
> and the [Lookahead and Lookbehind Zero-Length 
> Assertions|http://www.regular-expressions.info/lookaround.html] tutorial 
> helped us understand the meaning of that list entry.)



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

Thanks [~markrmil...@gmail.com]. In that case, what's your take on the issue at 
hand?

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-7013) Move license header before package declaration in all *.java files

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7013:


Thanks Uwe, I'll go fix all the violations and then commit the checker.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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-9090) solrj CloudSolrClient: add directUpdatesToLeadersOnly support

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9090: Add directUpdatesToLeadersOnly flag to solrj CloudSolrClient. 
(Marvin Justice, Christine Poerschke)


> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> -
>
> Key: SOLR-9090
> URL: https://issues.apache.org/jira/browse/SOLR-9090
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9090.patch, SOLR-9090.patch
>
>
> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> (Marvin Justice, Christine Poerschke)
> Proposed change:
> * Addition of a {{directUpdatesToLeadersOnly}} flag to allow clients to 
> request that direct updates be sent to the shard leaders and only to the 
> shard leaders.
> Motivation:
> * In a scenario where there is temporarily no shard leader the update request 
> will 'fail fast' allowing the client to handle retry logic.
> Related tickets:
> * SOLR-6312 concerns the ((currently) no longer used) {{updatesToLeaders}} 
> flag. The updatesToLeaders logic however appears to be slightly different 
> from the proposed directUpdatesToLeadersOnly logic: {{updatesToLeaders}} 
> indicates that sending to leaders is preferred but not mandatory whereas 
> {{directUpdatesToLeadersOnly}} mandates sending to leaders only.



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9290:
---

The defaults need to be very high to avoid distributed deadlock.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



--
This message was sent by Atlassian 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-9248) HttpSolrClient not compatible with compression option

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9248:
---

Nice Shalin, thanks for looking into this.

> HttpSolrClient not compatible with compression option
> -
>
> Key: SOLR-9248
> URL: https://issues.apache.org/jira/browse/SOLR-9248
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.5, 5.5.1
>Reporter: Gary Lee
> Attachments: CompressedConnectionTest.java
>
>
> Since Solr 5.5, using the compression option 
> (solrClient.setAllowCompression(true)) causes the HTTP client to quickly run 
> out of connections in the connection pool. After debugging through this, we 
> found that the GZIPInputStream is incompatible with changes to how the 
> response input stream is closed in 5.5. It is at this point when the 
> GZIPInputStream throws an EOFException, and while this is silently eaten up, 
> the net effect is that the stream is never closed, leaving the connection 
> open. After a number of requests, the pool is exhausted and no further 
> requests can be served.



--
This message was sent by Atlassian 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-9248) HttpSolrClient not compatible with compression option

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9248:
-

Working on SOLR-9290, I remembered about this issue. I think the problem here 
is that GzipDecompressingEntity (and DeflateDecompressingEntity) do not adhere 
to the contract laid out for HttpEntity#getContent which states that:
{code}
 * Returns a content stream of the entity.
 * {@link #isRepeatable Repeatable} entities are expected
 * to create a new instance of {@link InputStream} for each invocation
 * of this method and therefore can be consumed multiple times.
 * Entities that are not {@link #isRepeatable repeatable} are expected
 * to return the same {@link InputStream} instance and therefore
 * may not be consumed more than once.
{code}

So both those classes should always return the same object from the getContent 
method as long as the wrapped entity is non-repeatable and a new InputStream 
otherwise.

Also, I'd say it is a good idea in general to avoid calling getContent a second 
time just to be able to consume it. So even though all entities we actually use 
in Solr are non-repeatable, Solr code should just make one call to getContent 
keep the InputStream instance around for the consumption to avoid these kind of 
bugs.

> HttpSolrClient not compatible with compression option
> -
>
> Key: SOLR-9248
> URL: https://issues.apache.org/jira/browse/SOLR-9248
> Project: Solr
>  Issue Type: Bug
>  Components: SolrJ
>Affects Versions: 5.5, 5.5.1
>Reporter: Gary Lee
> Attachments: CompressedConnectionTest.java
>
>
> Since Solr 5.5, using the compression option 
> (solrClient.setAllowCompression(true)) causes the HTTP client to quickly run 
> out of connections in the connection pool. After debugging through this, we 
> found that the GZIPInputStream is incompatible with changes to how the 
> response input stream is closed in 5.5. It is at this point when the 
> GZIPInputStream throws an EOFException, and while this is silently eaten up, 
> the net effect is that the stream is never closed, leaving the connection 
> open. After a number of requests, the pool is exhausted and no further 
> requests can be served.



--
This message was sent by Atlassian 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-9290) TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-9290:
--

An update -- I've modified our solr.xml (which is basically the vanilla 
solr.xml) with these added props (under the {{solrcloud}} element) and I do not 
see the connections spike anymore:

{noformat}
1
100
{noformat}

Those changes were part of SOLR-8533. [~markrmil...@gmail.com] on that issue 
you didn't explain why the defaults need to be set that high. Was there perhaps 
an email thread you can link to which includes more details? I ask because one 
thing I've noticed is that if I query {{solr/admin/info/system}}, the 
{{system.openFileDescriptorCount}} is very high when there are many 
CLOSE_WAITs. Such a change in Solr default probably need to be accompanied by 
an OS-level setting too, no?

I am still running tests with those props set in solr.xml, on top of 5.5.1. 
[~mbjorgan] would you mind testing in your environment too?

[~hoss...@fucit.org], sorry I completely missed your questions. Our solr.xml is 
the vanilla one, we didn't modify anything in it. We did uncomment the SSL 
props in solr.in.sh as the ref guide says, but aside from the key name and 
password, we didn't change any settings.

> TCP-connections in CLOSE_WAIT spikes during heavy indexing when SSL is enabled
> --
>
> Key: SOLR-9290
> URL: https://issues.apache.org/jira/browse/SOLR-9290
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.5.1, 5.5.2
>Reporter: Anshum Gupta
>Priority: Critical
> Attachments: SOLR-9290-debug.patch, setup-solr.sh
>
>
> Heavy indexing on Solr with SSL leads to a lot of connections in CLOSE_WAIT 
> state. 
> At my workplace, we have seen this issue only with 5.5.1 and could not 
> reproduce it with 5.4.1 but from my conversation with Shalin, he knows of 
> users with 5.3.1 running into this issue too. 
> Here's an excerpt from the email [~shaie] sent to the mailing list  (about 
> what we see:
> {quote}
> 1) It consistently reproduces on 5.5.1, but *does not* reproduce on 5.4.1
> 2) It does not reproduce when SSL is disabled
> 3) Restarting the Solr process (sometimes both need to be restarted), the
> count drops to 0, but if indexing continues, they climb up again
> When it does happen, Solr seems stuck. The leader cannot talk to the
> replica, or vice versa, the replica is usually put in DOWN state and
> there's no way to fix it besides restarting the JVM.
> {quote}
> Here's the mail thread: 
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201607.mbox/%3c46cc66220a8143dc903fa34e79205...@vp-exc01.dips.local%3E
> Creating this issue so we could track this and have more people comment on 
> what they see. 



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

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

[jira] [Comment Edited] (LUCENE-7013) Move license header before package declaration in all *.java files

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7013 at 7/13/16 2:13 PM:


you are right :-) I'll change. copy'n'paste - shit'n'waste


was (Author: thetaphi):
you are right :-) I'll change.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

[jira] [Updated] (LUCENE-7013) Move license header before package declaration in all *.java files

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7013:
--
Attachment: LUCENE-7013-precommit.patch

New patch with [~steve_rowe]'s suggestion.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013-precommit.patch, LUCENE-7013.patch, 
> mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+126) - Build # 17238 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17238/
Java: 32bit/jdk-9-ea+126 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.overseer.ZkStateWriterTest

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.overseer.ZkStateWriterTest: 1) Thread[id=558, 
name=watches-81-thread-1, state=TIMED_WAITING, group=TGRP-ZkStateWriterTest]
 at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.overseer.ZkStateWriterTest: 
   1) Thread[id=558, name=watches-81-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest]
at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
at __randomizedtesting.SeedInfo.seed([7A410D0F7FCF5650]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.overseer.ZkStateWriterTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=558, name=watches-81-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest] at 
jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
 at java.lang.Thread.run(java.base@9-ea/Thread.java:843)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=558, name=watches-81-thread-1, state=TIMED_WAITING, 
group=TGRP-ZkStateWriterTest]
at jdk.internal.misc.Unsafe.park(java.base@9-ea/Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(java.base@9-ea/LockSupport.java:230)
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@9-ea/SynchronousQueue.java:461)
at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@9-ea/SynchronousQueue.java:362)
at 
java.util.concurrent.SynchronousQueue.poll(java.base@9-ea/SynchronousQueue.java:937)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(java.base@9-ea/ThreadPoolExecutor.java:1082)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-ea/ThreadPoolExecutor.java:1143)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-ea/ThreadPoolExecutor.java:632)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
at __randomizedtesting.SeedInfo.seed([7A410D0F7FCF5650]:0)




Build Log:
[...truncated 10749 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateWriterTest
   [junit4]   2> Creating 

[jira] [Commented] (LUCENE-7013) Move license header before package declaration in all *.java files

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7013:
---

you are right :-) I'll change.

> Move license header before package declaration in all *.java files
> --
>
> Key: LUCENE-7013
> URL: https://issues.apache.org/jira/browse/LUCENE-7013
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-7013-precommit.patch, 
> LUCENE-7013-precommit.patch, LUCENE-7013.patch, mvcopyright.py, mvcopyright.py
>
>
> In LUCENE-7012 we committed a change to the IDE templates to place the 
> license header before the package declaration in new Java files.
> I wrote a simple Python script which moves the header before the package 
> declaration. To be on the safe side, if a .java file does not already start 
> with the license header or with {{package org.apache}}, it doesn't modify it 
> and asks for manual intervention.
> It runs quite fast, so I don't mind running and committing one module at a 
> time.



--
This message was sent by Atlassian 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-7372) factor out a org.apache.lucene.search.FilterWeight class

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7372:
--

+1

> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



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

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

[jira] [Updated] (LUCENE-7372) factor out a org.apache.lucene.search.FilterWeight class

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated LUCENE-7372:

Attachment: LUCENE-7372.patch

* rebased for LUCENE-7368 changes and conflicts resolved
* @lucene.internal annotation
* javadocs for the two constructors

> factor out a org.apache.lucene.search.FilterWeight class
> 
>
> Key: LUCENE-7372
> URL: https://issues.apache.org/jira/browse/LUCENE-7372
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-7372.patch, LUCENE-7372.patch, LUCENE-7372.patch, 
> LUCENE-7372.patch
>
>
> * {{FilterWeight}} to delegate method implementations to the {{Weight}} that 
> it wraps
> * exception: no delegating for the {{bulkScorer}} method implementation since 
> currently not all FilterWeights implement/override that default method



--
This message was sent by Atlassian 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-9303) Refactor CloudSolrClient for extensibility

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9303:
--

GitHub user paulo-raca opened a pull request:

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

SOLR-9303: Refactor CloudSolrClient for extensibility

I'm using a custom Solr plugins which adds extra constraints on which nodes 
I can access.

To respect these constraints, I needed to use a customized version of 
CloudSolrClient.

Unfortunately, CloudSolrClient.sendRequest() is currently written as one 
big chunk of code, breaking OO's SOLID principle and making it is impossible 
for me to customize it on a subclass.

I have refactored this method in 3 steps:
- Finding the usable URLs
- Checking if a node can be used for this request
- Executing the request

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

$ git pull https://github.com/paulo-raca/lucene-solr master

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

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


commit c7362262e868b9311e94c954e6e1c9f866776ed2
Author: Paulo Costa 
Date:   2016-07-13T13:44:24Z

SOLR-9303: Refactor CloudSolrClient for extensibility

CloudSolrClient.sendRequest() is currently written as one big chunk of 
code, making it difficult to customize it on a subclass.




> Refactor CloudSolrClient for extensibility
> --
>
> Key: SOLR-9303
> URL: https://issues.apache.org/jira/browse/SOLR-9303
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 5.4, 6.0
>Reporter: Paulo Costa
>Priority: Minor
>  Labels: SolrCloud, solrj
> Fix For: 6.1
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I'm using a custom Solr plugins which adds extra constraints on which nodes I 
> can access.
> To respect these constraints, I needed to use a customized version of 
> CloudSolrClient.
> Unfortunately, CloudSolrClient.sendRequest() is currently written as one big 
> chunk of code, breaking OO's SOLID principle and making it is impossible for 
> me to customize it on a subclass.
> I suggest we refactor this method in 3 steps: 
> - Finding the usable URLs
> - Checking if a node can be used for this request
> - Executing 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

[GitHub] lucene-solr pull request #51: SOLR-9303: Refactor CloudSolrClient for extens...

[paulo-raca]

GitHub user paulo-raca opened a pull request:

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

SOLR-9303: Refactor CloudSolrClient for extensibility

I'm using a custom Solr plugins which adds extra constraints on which nodes 
I can access.

To respect these constraints, I needed to use a customized version of 
CloudSolrClient.

Unfortunately, CloudSolrClient.sendRequest() is currently written as one 
big chunk of code, breaking OO's SOLID principle and making it is impossible 
for me to customize it on a subclass.

I have refactored this method in 3 steps:
- Finding the usable URLs
- Checking if a node can be used for this request
- Executing the request

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

$ git pull https://github.com/paulo-raca/lucene-solr master

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

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


commit c7362262e868b9311e94c954e6e1c9f866776ed2
Author: Paulo Costa 
Date:   2016-07-13T13:44:24Z

SOLR-9303: Refactor CloudSolrClient for extensibility

CloudSolrClient.sendRequest() is currently written as one big chunk of 
code, making it difficult to customize it on a subclass.




---
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] [Created] (SOLR-9303) Refactor CloudSolrClient for extensibility

[Paulo Costa (JIRA)]

Paulo Costa created SOLR-9303:
-

 Summary: Refactor CloudSolrClient for extensibility
 Key: SOLR-9303
 URL: https://issues.apache.org/jira/browse/SOLR-9303
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 6.0, 5.4
Reporter: Paulo Costa
Priority: Minor
 Fix For: 6.1


I'm using a custom Solr plugins which adds extra constraints on which nodes I 
can access.

To respect these constraints, I needed to use a customized version of 
CloudSolrClient.

Unfortunately, CloudSolrClient.sendRequest() is currently written as one big 
chunk of code, breaking OO's SOLID principle and making it is impossible for me 
to customize it on a subclass.

I suggest we refactor this method in 3 steps: 
- Finding the usable URLs
- Checking if a node can be used for this request
- Executing 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